In flag_features_export(), Flag kindly tries to add related modules as dependencies when a given flag type is exported.
That's all well and good for 2.x, when every module defining a custom entity had to manually implement hook_flag_type_info() in order to register it.
However, now that Flag supports entities on a generic level, this hook is only really ever used if you want to be able to flag custom schemas that aren't entities.
The problem is that if we export a flag on a custom entity, it will incorrectly assume that the entity is defined in hook_flag_type_info() and returned by flag_features_providing_module(), which it's not. It will throw a notice and won't add the dependency. (I ran into this issue exporting a Profile2 flag)
Initially I thought we might be able to assume that the entity name corresponds to the module name and add that directly to the dependencies but despite being the case 90% of the time it's a silly and risky assumption.
Therefore I think we might have to introspect the entity type and find out which module defines it in order to properly add the dependency.
Comment | File | Size | Author |
---|---|---|---|
#18 | flag-export-dependencies-1905004-18.patch | 1.37 KB | alexweber |
#16 | flag-export-dependencies-1905004-16.patch | 1.38 KB | alexweber |
#8 | flag-export-dependencies-1905004-8.patch | 1.36 KB | alexweber |
#4 | flag-export-dependencies-1905004-4.patch | 1.09 KB | alexweber |
#1 | flag-export-dependencies-1905004-1.patch | 1.02 KB | alexweber |
Comments
Comment #0.0
alexweber CreditAttribution: alexweber commentedUpdated issue summary.
Comment #1
alexweber CreditAttribution: alexweber commentedPatch attached that fixes this issue:
Comment #2
joachim CreditAttribution: joachim commentedGood catch!
However...
> Calls entity_get_info() to find out out what module should be required for the flag on the custom entity
The 'module' property in entity info is an Entity API extension -- it's not part of core: http://api.drupal.org/api/drupal/modules!system!system.api.php/function/...
I'm not really sure what we can do about this, other than try this, and then do nothing if we can't find the module that is responsible for an entity type. Hmm maybe the database schema would have it -- a bit convoluted, we'd have to get the base table for the entity, then find out who owns it.
Comment #3
alexweber CreditAttribution: alexweber commentedHmmmm, good call, I didn't realize the 'module' key was an Entity API extension.
That said, how many custom entities you think exist out there that haven't been built either using Entity API or ECK? And ECK depends on Entity...
Therefore, I think it's pretty safe that 99% of modules that implement custom entities do it through one of the above channels so maybe we could just do an isset() on $entity_info['module'] and if its not well than that's just too bad! :)
Odds also are that if the flag is being exported as a feature that the entity's bundles also are so the dependency will already be there in the first place! ;)
Comment #4
alexweber CreditAttribution: alexweber commentedPatch attached just add that extra isset() call to make sure the 'module' key exists in entity_get_info()
If not, we just don't add the explicit dependency.
Comment #5
joachim CreditAttribution: joachim commentedI take it this is a first pass where we see if there is a module with the same name as the entity? (eg, 'node').
Could this have a comment to say that please?
Could this comment mention that we're looking for the Entity API 'module' property?
Not sure what this means!
> That said, how many custom entities you think exist out there that haven't been built either using Entity API or ECK? And ECK depends on Entity...
Agreed.
Though I can't help but notice that this will all fail with plain old taxonomy terms!!! ;)
Comment #6
joachim CreditAttribution: joachim commentedComment #7
alexweber CreditAttribution: alexweber commented@joachim, I'll clean up the comments.
Now, what if we implement hook_flag_type_info() on behalf of taxonomy terms?
We already do that for nodes, users and comments, I see no reason Taxonomy wasn't included in the first place... after all, its a core module! :)
New issue: #1905750: Implement hook_flag_type_info() on behalf of non-required core modules
Comment #8
alexweber CreditAttribution: alexweber commentedComment #9
joachim CreditAttribution: joachim commentedI suspect this needs work now #1905750: Implement hook_flag_type_info() on behalf of non-required core modules is in.
Comment #10
alexweber CreditAttribution: alexweber commentedIt actually looks good... that patch wouldn't have picked up taxonomy dependency without #1905750: Implement hook_flag_type_info() on behalf of non-required core modules but it works as expected now.
Comment #11
joachim CreditAttribution: joachim commentedSurely we should be looking at the 'module' property we're now putting in core flag type infos?
Comment #12
alexweber CreditAttribution: alexweber commentedflag_features_providing_module() already does that for us :)
Comment #13
joachim CreditAttribution: joachim commentedUrgh, sorry. Pre-breakfast patch reviewing :/
Comment #14
alexweber CreditAttribution: alexweber commentedhahaha no problem! It's lunch time here ;)
Comment #15
joachim CreditAttribution: joachim commentedBreakfast again, but slightly more awake! :)
'it's' should be 'its'.
That's going to fail if $data contains more than one flag. You need to reset $module to NULL or '' or something at the top of the loop.
Comment #16
alexweber CreditAttribution: alexweber commented:)
Comment #17
joachim CreditAttribution: joachim commentedIs that going to work first time round? Reads a little weirdly.
Sorry... could this be change to just $module = ''; and then check it with empty() rather than isset()?
Comment #18
alexweber CreditAttribution: alexweber commentedYou the boss!
Comment #19
joachim CreditAttribution: joachim commentedFixed.
Thanks for persevering with this! :)
git commit -m "Issue #1905004 by alexweber: Fixed flag export to Features not finding module that provides the entity as a dependency." --author="alexweber "
Comment #20
alexweber CreditAttribution: alexweber commentedphew! :)
Comment #21.0
(not verified) CreditAttribution: commentedUpdated issue summary.