Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Short story: When installing more than one feature at a time, for example using drush, an install profile using dependencies or features_install_modules(), every time features are requested to be rebuilt, every feature in the system is reverted regardless of its status.
Long story: While building a complex, installation profile based site referencing lots of feature as dependencies, by looking at Drupal's log files we were noticing that features are rebuilt over and over again during deployment using drush site-install. This happens because features_get_component_states() maintains a static cache of component states, causing a full rebuild of all active (or to be activated) features each time hook_flush_caches() is triggered. By resetting the component states we were able to avoid those multiple rebuilds; as a byproduct the install time could be significantly reduced. As the to-do indicates, resetting the cache should probably happen way more often than now, which explicitly checks for being triggered by drush.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | features-1188066-6.patch | 969 bytes | febbraro |
| #1 | features-stalled-component-list-1188066.patch | 1003 bytes | smk-ka |
Comments
Comment #1
smk-ka CreditAttribution: smk-ka commentedNeeds work regarding the to-do. Possibly resetting the static cache at the end of a feature rebuild (and only in case there really was something to rebuild) would be more ideal.
Comment #2
smk-ka CreditAttribution: smk-ka commented#1195432: Use dependency information when importing is a prerequisite for this patch.
Comment #3
febbraro CreditAttribution: febbraro commentedAdding a tag for webchick
Comment #4
febbraro CreditAttribution: febbraro commented@smk-ka Trying to understand how to approach the @todo.
To get up to speed, by resetting the component state cache you are limiting the rebuilding when multiple features are enabled in the same pass? Have not fully grokked that part yet. Will continue pouring through the code for that piece. Any hint you can give me will help.
Back to the cache clearing, seems that if we can find the right point in time to clear the static, we can move that static $cache in features_get_component_states to a drupal_static so we can clear it from wherever that place might be?
Comment #5
tirdadc CreditAttribution: tirdadc commentedTested this with both the manual installation process and using drush site-install. While it makes no difference in the former case, it does result in a huge performance boost when using drush to instantiate a site, even with 5-7 features.
What I can't figure out yet is how given that features_get_component_states() gets called 3 times with or without the patch when using drush site-install, and forcing the reset actually unsets other static cache variables in a number of other places too (including features_get_normal and features_get_default). Can you please provide any details on where the fact that the component states are cached causes a full rebuild each time?
Comment #6
febbraro CreditAttribution: febbraro commentedRerolled with a diff mechanism to test for drush.
Comment #7
tirdadc CreditAttribution: tirdadc commentedThis one yields the same performance gain as the original patch during a drush site-install.
Comment #8
febbraro CreditAttribution: febbraro commentedCommitted to 7.x branch. http://drupalcode.org/project/features.git/commit/cd5ccbf
hefox anything to be ported here?
Comment #9
febbraro CreditAttribution: febbraro commentedRemoving release blocker tag for D7
Comment #10
febbraro CreditAttribution: febbraro commented