Similar to views_api_version(), it would be useful to have a context_api_version(). See #634552-50: Conflict with context module.

CommentFileSizeAuthor
#5 context-910220-5.patch710 bytestim.plunkett
#1 910220-1.patch458 bytespfrenssen

Comments

pfrenssen’s picture

pfrenssen
Location Sofia
commented
StatusFileSize
new 910220-1.patch458 bytes

Patch against 6.x-3.x-dev

pfrenssen’s picture

pfrenssen
Location Sofia
commented
Status: Active » Needs review

change status

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
Status: Needs review » Needs work

For this to be useful Context would include it's API version in it's exportables, and check for it when importing those exportables.

Grayside’s picture

Grayside commented

hook_ctools_plugin_api() is already generated when you export contexts, in module.features.inc.

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
Status: Needs work » Needs review
StatusFileSize
new context-910220-5.patch710 bytes

So it is!
Let's standardize on the ctools output.

Grayside’s picture

Grayside commented

Why do we need both?
EDIT: Oh, so the current Context install reports what it is.

yareckon’s picture

yareckon commented

tracking.

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
Status: Needs review » Closed (won't fix)

I don't think this is actually needed.

Grayside’s picture

Grayside commented
Status: Closed (won't fix) » Postponed

I disagree. I think it doesn't matter unless something like hook_requirements() is implemented to compare the output of hook_ctools_plugin_api() against context_api_version().

That would have been impressively useful to all the people that spent several hours scratching their heads when installing features built on Context 2 in a site running Context 3.

That will require a broader functionality in Features and/or ctools before an api version callback actually has a use.