Problem/Motivation
Right now components running order cannot be configured. This lead to the situation when some components are reverting before other component can provide them with fresh data in database. For example if a revert brings a new field type, then the module providing that field type should be installed first. In other words, the 'dependencies' component should be reverted before 'field_base' component.
Proposed resolution
Implement weight on components so that components are loaded ordered by weight. Set 'dependencies' weight to -10.
Remaining tasks
Research if other components need prioritization and open separate issues, if case.
User interface changes
None.
API changes
The component defined in hook_featutes_api()
can define a weight
value. If omitted, it defaults to 0.
Data model changes
None.
Comment | File | Size | Author |
---|---|---|---|
#44 | features-sort-components-by-weight-1814122-44.patch | 934 bytes | gnucifer |
| |||
#39 | fieldexception_-1814122-39.patch | 4.18 KB | claudiu.cristea |
#39 | interdiff.txt | 462 bytes | claudiu.cristea |
#36 | fieldexception_-1814122-36-test-only.patch | 623 bytes | claudiu.cristea |
Comments
Comment #1
humansky CreditAttribution: humansky commentedI ran into the same issue....I agree that features should enable the dependent modules first, then add fields, permissions, etc. The obvious workaround, is to add the dependency to the feature first, deploy, then add the field and redeploy. Just seems like a kludge to me, but that works.
Comment #2
hefox CreditAttribution: hefox commentedPatches welcome to autodetect whatever dependency, though I thouht it already did that.
Comment #3
mpotter CreditAttribution: mpotter commentedFeatures should already be scanning your Field export and adding dependencies for modules that it needs. Sounds like maybe there is some obscure type of field being added by a module that is not doing this?
For example, when I add a "number" field, Features properly added "number" as a dependency. When I export a entityreference, it added "entityreference" module. So we'd need a step by step procedure with more detail for whatever specific module you had a problem with. I can't think of anything Features can do that it's not already doing.
Comment #4
joachim CreditAttribution: joachim commentedIt was a while since I filed this, but my wording suggests that the module that provided the field type was included as a dependency of the Feature. The problem was that it was *added* as a dependency, and on deploying the code, Features was trying to create the new field before the extra module had been enabled.
Comment #5
mpotter CreditAttribution: mpotter commentedUnfortunately that becomes a core issue. If the dependency is listed in the .info file for the feature module and Drupal is not enabling that module before your Feature module, then there isn't much Features can do.
Comment #6
joachim CreditAttribution: joachim commentedI think you're misunderstanding the problem I reported.
The sequence of events is this:
- on dev server, create a feature
- deploy it to production. Everything fine.
- back on dev, add and enable a module that provides field type foo
- still on dev, add components to the feature, including a field of type foo
- deploy the feature
So at the point where the crash happens, the feature is already enabled, but a dependency and a field have just been added to its code.
Comment #7
mpotter CreditAttribution: mpotter commentedOK, Right, I understand now. But how is Features supposed to deal with this? Your Feature Module A now depends upon Module B. You need to disable Module A, enable Module B, then re-enable Module A. Features has no way to detect that this needs to be done. It's just a normal job of deployment. Part of deployment is to run update hooks, revert features, etc. You can't just push new code and expect everything to magically work.
For example, when I work on a site and add a new module dependency, I write an update hook that enables the new module on production, and part of the production deployment runs the update.php (drush updb) to handle that.
Comment #8
hefox CreditAttribution: hefox commentedFeatures does enable newly added dependencies during features_rebuild to my memory, though I never rely on it and likely caches are not cleared between enabling the module and rebuilding the rest of the feature
Comment #9
Matters CreditAttribution: Matters commentedI ran into the same problem. The solution for me was to perform in "mysite.com/devel/php" the function "module_enable(array('fivestar'), TRUE);"
Comment #10
RogerBThanks Matters for the solution. My site was completly locked up. Lifesaver.
Comment #11
VladSavitsky CreditAttribution: VladSavitsky commentedI've solved the same issue by using field_cache_clear() in hook_update() after module_enable() and before field creation.
See https://api.drupal.org/api/drupal/modules!field!field.module/function/fi...
Comment #12
joco_sp CreditAttribution: joco_sp commented#9 worked for me. Lifesaver for me too. Thank you
Comment #13
claudiu.cristeaI'm getting the same error. On dev, to an existing feature, I'm adding a new field having a type provided by a new installed module. I'm recreating the feature and the new module, the field and the field instance are added. When I'm reverting on the other side with "revert all", I'm getting the error. A workaround is to manually revert first dependencies and then the field instance. But this is bug.
Comment #14
claudiu.cristeaThis is fixing the issue. It might be less elegant but having the modules enabled before anything else seems to me more than critical. I believe that dependencies must be treated with highest priority.
Comment #15
ovidenov CreditAttribution: ovidenov commentedThe patch from #14 seems to work for me.
Comment #16
claudiu.cristea@ovidenov, great! Then why not setting the issue to RTBC? :)
Comment #17
ovidenov CreditAttribution: ovidenov commentedComment #18
hefox CreditAttribution: hefox at Phase2 commentedA few more reviews and testbot are needed. One review isn't really "the community" :( Thanks though!
I haven't been paying attention to this, but from a brief look at what the patch does, I prefer a patch that changes the order that components are reverted -- there's an issue about that (revert order) but so far no good patches IIRC
Comment #19
jorgegc CreditAttribution: jorgegc as a volunteer commentedPatch in #14 no longer applies. Uploading rerolled patch.
Comment #20
jorgegc CreditAttribution: jorgegc as a volunteer commentedFYI this patch does not work when rebuilding the registry. We need to come up with something that takes that into consideration too.
Comment #21
jorgegc CreditAttribution: jorgegc as a volunteer commentedUploading a patch that covers both scenarios. Also, changing the version of the module this bug affects. Please review.
Comment #23
jorgegc CreditAttribution: jorgegc as a volunteer commentedI have run simpletests locally and they all passed. Uploading new patch!
Comment #24
shahmeerarshad CreditAttribution: shahmeerarshad as a volunteer commentedfeature name field exception handeled
Comment #26
jorgegc CreditAttribution: jorgegc as a volunteer commentedWhat has just happened? Spam?!
Comment #27
shahmeerarshad CreditAttribution: shahmeerarshad commentedsorry about the previous post
i am a newbie at drupal open source community
Comment #29
claudiu.cristea@jorgegc, we cannot go in that direction because in #18 the module maintainer disagreed with this approach. And I have to agree with him even it was my idea to implement
hook_features_pre_restore()
.The solution should be something like this but we need tests and I don't know how to write a test for this case.
Comment #30
claudiu.cristeaComment #32
claudiu.cristeaThere was a circular call in
features_get_info()
:features_get_info()
>features_get_components()
=> ... =>_ctools_features_get_info()
=>features_get_info()
I used
system_rebuild_module_data()
instead offeatures_get_info()
in_ctools_features_get_info()
because the only thing needed there is the module name and this is faster because the module list is statically cached.@hefox, @mpotter, I still have no clue how we can test this. Can you take a look to this patch?
Comment #33
claudiu.cristeaAdded docs.
Comment #34
claudiu.cristeaMinor doc typo fix.
Comment #35
hefox CreditAttribution: hefox at Phase2 commentedhm, test that components are ordered correctly in feature info?
what really want to test is that dependencies are always enabled first, but off top of head, not sure how that'd be tested.
Comment #36
claudiu.cristeaThis test alone should fail. It tests if 'dependencies' is on top.
Comment #37
claudiu.cristeaComment #39
claudiu.cristeaYes. Perfect!
Changing the issue title and summary. Added a CHANGELOG entry.
Comment #40
claudiu.cristeaMarked #1997412: Allow specificying order of components or depdency between components when reverting/rebuilding as duplicate of this.
Comment #41
claudiu.cristea@hefox, Unfortunately this patch assures that components are ordered when loading a feature with
features_load_feature()
but I'm not so sure that on revert/rebuild the components are loaded in this way... :(Comment #42
Maico de JongNice work!
#23 worked for me
#39 didn't
I was using drush (drush fr) to revert the components, permissions we're still reverted before dependencies causing an error. Maybe drush is using a different way to loop through components?
Comment #43
gnucifer CreditAttribution: gnucifer commented@claudiu.cristea One place to reorder components could perhaps be in a hypothetical alter hook for each modules components right after hook_feature_pre_restore is invoked, or to sort them by weight there. But I could have missed something.
Comment #44
gnucifer CreditAttribution: gnucifer commentedHere is a patch with my suggested solution.
Comment #45
gnucifer CreditAttribution: gnucifer commented@claudiu.cristea I looked through your patch again, and I really should have included your changes as well. I think that if you include the small fix in my patch (sorting before components are rebuilt/reverted) that would hopefully be a working solution for this problem.