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.When a feature containing exported variables is first enabled the variables are not reverted and the feature appears overridden. Only when the feature is manually reverted the variables become available. This is due to a missing hook_features_enable_feature() implementation.
This is especially important when using features in install profiles, as certain functionality (such as available permissions) may depend on certain variables being set.
Here's example output from a feature that contains a variable named 'panelizer_defaults_node_landing_page':
$ drush en paddle_landing_page -y
The following extensions will be enabled: paddle_landing_page
Do you really want to continue? (y/n): y
paddle_landing_page was enabled successfully.
$ drush vget panelizer
No matching variable found.
$ drush fr paddle_landing_page -y
Do you really want to revert variable? (y/n): y
Reverted variable.
$ drush vget panelizer
panelizer_defaults_node_landing_page: Array
(
[status] => 1
)
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | 1965588-strongarm-enable_feature.patch | 948 bytes | pfrenssen |
Comments
Comment #1
pfrenssenComment #2
Sylvain Lecoy CreditAttribution: Sylvain Lecoy commentedThe patch does not fix this problem.
When I enable a feature with strongarm exported variables it is still marked as overriden.
Comment #3
Sylvain Lecoy CreditAttribution: Sylvain Lecoy commentedThe only work around for now is:
Really not appealing.
Comment #4
pfrenssenAre you perhaps trying to override variables that already exist in the database? Those are not reverted when the feature is enabled, that is by design. Otherwise you could have unintentional data loss when enabling a module containing a feature. In that case the feature will appear overridden and you will have to do a revert manually.
I'm setting this back to "Needs review", since I'm quite sure your use case is not what this issue is solving.
Comment #5
Sylvain Lecoy CreditAttribution: Sylvain Lecoy commentedMy use case is the following:
Installing a fresh drupal profile with a list on predefined features on a jenkins ci server.
The feature may depend or not on a module which define default values in the database. When enabling the feature for the first time (which may enable some module dependencies) it is marked as reverted. If this is by design I find it not well designed but this may belong to another issue. I let you decide.
Comment #6
pfrenssenYes that is probably what happens. So at the point when the feature is enabled the default variables already exist and will not be overwritten when the feature is enabled. You can solve this by reverting the feature or setting the variables manually in your profile's hook_install() which runs after the modules are enabled. I agree that this is inconvenient in your case.
But if this would work like you expect it would mean that all exported variables would blindly be overwritten when a feature is enabled. If this happens on a live site this could cause critical data loss. That is the reason why Features has a distinction between "rebuilding" and "reverting". Rebuilding is safe - it does not overwrite anything and is suitable for this situation, but reverting throws away existing config and replaces it with the exported settings, which is dangerous and should always be done manually.
Comment #7
hefox CreditAttribution: hefox commented#1572578: Rethink the way features are enabled / disabled?
Comment #8
pfrenssenPutting back to needs review.
Comment #9
frost CreditAttribution: frost commentedMy Use Case and issue appears to be similar to this one, so I just want to clarify if I've understood what Features/Strongarm is supposed to allow me to do.
I build new sites using Drush Make. My Use Case is to be able to include a few Features with my builds, so that once the site is installed, I can turn on the Feature(s) to automatically enable modules, add a theme, add a role with permissions, add a text format and its settings, and set a few site settings (default country, timezone, default theme etc).
In testing, the modules are enabled ok, but the role is added without any of its permissions, the theme isn't enabled, and the settings (variables) arent set. When I revert the feature, some of the settings are set but not all.
Is this considered correct behaviour, because the variables I'm settings are considered "already set" once a Drupal site is built?
Comment #10
pfrenssen@frost, that is not related to this issue. You are even in the wrong queue, the Strongarm module is only concerned with variables. If you are seeing problems with roles etc this is handled by the Features module, not Strongarm.
It seems like you're having the typical problem of trying to enable / revert features that depend on functionality that is not yet available. For example if you try to enable permissions for a role that does not exist yet this runs into trouble. You should take a good look at the different steps that are performed during the installation of your profile, and see if you can perhaps execute them in a different order to resolve the problem. If you need help with this your best bet might be to open a support ticket in the Features queue, or ask for advice on IRC.
Comment #11
frost CreditAttribution: frost commented@pfrenssen Thanks for clarifying, and apologies for posting in the wrong place.
Comment #12
iSoLate CreditAttribution: iSoLate at Randstad Digital for Government of Flanders commentedlooks good.