Posted by Wanjee on August 11, 2010 at 8:18am
4 followers
Jump to:
| Project: | Strongarm |
| Version: | 6.x-2.0 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
Hello,
We use features module together with context and strongarm and we get a strange issue.
A lot of variables such as language_negotiation, i18n_selection_mode,... have been selected in the strongarm section of a feature. Once we apply this feature on a website to upgrade it we get our variable table emptied of all of these vars. Then the language negotiation (as an example) is not available anymore in our menus and so on, so our site is basically not multilingual anymore.
We had to go to admin/settings/language and save each tabs in there to get the multilingual system working back. It had the effect of adding back these vars in Drupal's variables table.
Any idea on how to fix this ?
Thanks a lot,
Wanjee
Comments
#1
In admin/settings/language the selected options were the good ones so my guess is that for form display Drupal can retrieve variables from Strongarm but for some reason i18n cannot when it's time to build menus and so on.
#2
I got the same bug on other modules than i18n.
I start from a fresh install, put my modules and my features, in sites/all/modules and I enable feature ctools and strongarm.
Then I enable my feature, and I do a revert on the strongarm part of this feature.
Then in every settings forms for the third party modules that my feature auto enable, I got the correct values that I exported in the feature, but I need to go on each of these forms and manually save if I want to have the "variables" table populated with all the variable that my modules provides.
Every variables in the strongarm part of the feature are deleted from the "variables" table, but are not set after the "revert" operations.
Any ideas ?
David
#3
I had a look at the code of ctools and strongarm, and I have seen an explanation.
The strongarm module merge the $conf array in hook_init with default vars from db or conf file and the "strongarmed vars".
if a module uses variable_get before this is done, as the variable in base is deleted in case of a revert, this will make a bug !
To avoid this, the "revert to default" of a strongarmed var should delete the vars in the database and then set it again with a variable_set.
Maybe i18n use hook_boot or do something before the hook_init of strongarm (which as a weight of -1000 to try to be the first ...) and it will bug because at this time "strongarmed vars" will not be available.
The other solution is that module implementors should be aware of this and code with that behavior in mind !
I will change my creeper module in order to be strongarm compatible !
Hope it will help others ;)
David
#4
Damn it was already here !
#5
#1062452: strongarm_set_conf() needs to be called sooner seems to be related.