strongarm_vars_load returns the current state of all variables, so the value key is set to current state (e.g. the database value) not the default state, so well, it doesn't do anything atm cause $var->value == $conf[$name] (for existing variables).
On 2.1 but checked repo and seems like not fixed yet.
Quick patch against 2.1; figured a new function was better as other places strongarm_vars_load is being used, the current state is what is desired
Cannot use same logic as variable_features_revert as strongarm doesn't depend on features.
Not sure of status of d7.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | strongarm_default_1670040_1.patch | 1.63 KB | hefox |
| strongarm_default_vars_load.patch | 1.62 KB | hefox |
Comments
Comment #1
hefox commentedWell, major oops on return value from new function
Comment #2
roderikI can confirm that in 7.x-2.x (where, I bet, things should be fixed first) the bug is still the same and the patch applies.
However, This makes (almost?) all variables be reverted, also when the --force option is not passed. That's because of the
if ($force || !empty($var->in_code_only)) {in the caller, while 'in_code_only' is almost always set in the new function.I don't know enough about the CTools API to comment on details.
Comment #3
dealancer commentedAlso the work around will be run both commands:
drush fl
drush fra -y
fl (freatures-list) forces Drupal to check status of features.
P.S.
need to admit this is not working always.
Comment #4
marttir commentedPatch from #1 fixes my problem: reverting features when Features Override is used override Featured Strongarm variables.
Comment #5
guypaddock commentedThis still needs work per #2 and #3. Just b/c it worked in #4 does not mean it's good-to-go for all cases.
Comment #6
chipway commentedPatch do not apply now on 2.0.