(Fair warning: This may belong in the Features issue queue.)

When using Strongarm in conjunction with Features, a handful of variables are marked "overridden" immediately after the feature is enabled. I think the problem is the result of Strongarm setting defaults before their corresponding modules were enabled.

I've attached a screenshot that shows some of the variables that are immediately overridden. In this example, all of the listed variables are being set by a feature that also enables several modules.

  • node_options_page: A core variable. The feature that sets this also enables the Revision module, which adds the node option "Create a new revision." Adding this "node option" may may alter the default Strongarm set earlier.
  • date_default_timezone: Another core variable. This one is probably being touched when the Date API module is enabled by the same feature.
  • The remaining variables are all related to Pathauto. Again, this feature is both setting Pathauro variables and enabling the Pathauto module.

Perhaps this can be solved by ensuring that Strongarm defaults are enforced after all modules in a feature are enabled?

CommentFileSizeAuthor
strongarm-defaults-overridden-automatically.png49.07 KBtodd nienkerk

Comments

todd nienkerk’s picture

todd nienkerk commented

I'd like to amend the Pathauto section above:

  • pathauto_update_action: This is likely changed when the Path Redirect module is enabled, as it adds a new update action to Pathauto.
  • pathauto_node_pattern: I don't know what other module could be touching this. Nothing comes to mind.
wik’s picture

wik commented
Version: 6.x-2.0-beta2 » 6.x-2.0-rc1

same here...

tirdadc’s picture

tirdadc commented

I'm having this issue with some exported variables that are settings for the Embedded Image Field module, namely to determine which providers are available by default.

Oscar Illada’s picture

Oscar Illada commented

same issue!!! but with others variables.

cknoebel’s picture

cknoebel commented

Me, too. IMCE for me.

mstef’s picture

mstef commented

+1..I made the same assumption for cause.

yhahn’s picture

yhahn commented
Project: Strongarm » Features
Version: 6.x-2.0-rc1 » 6.x-1.x-dev

Yes, this is a fairly common issue where a feature strongarms a variable or other component and then the install script of another module overrides it right away.

I think one way to address this would be to revert all components of a feature when it is enabled but it's not a particularly appealing option to me as there is no way to hook into a feature's install/enable event without writing a specific hook_install() or hook_enable() implementation for the Feature. In addition, this could be considered rather rude -- you could blow away some overrides that someone has in their DB by "accident" -- ie. they are just turning off and back on a feature to debug another problem, change their mind, etc.

I'll keep thinking about options here, but generally speaking I'm of the opinion that other modules, especially API/library type modules, should not be running variable_set() against their own variables in install/enable hooks.

that0n3guy’s picture

that0n3guy commented

sub....

mstef’s picture

mstef commented

When I come across this situation, I add an .install file, load the features file which contains the strongarm declarations, and explicitly set the variable. I suppose you could also delete the variable and let strongarm do what it does.

Would be nice if there was a more clean solution.

yhahn’s picture

yhahn commented

Patch the offending module. : P jk

mstef’s picture

mstef commented

Very good point

grzegorz.bartman’s picture

grzegorz.bartman commented

subscribing

timwood’s picture

timwood
Primary language English
Location Rockville, Maryland
commented

Sub

cleanthes’s picture

cleanthes commented

subscribing

nwe_44’s picture

nwe_44 commented

subscribing.

Grayside’s picture

Grayside commented

As a purely UI fix, it would be interesting if you could find out what variables are already set when installing a module with hook_strongarm(). Perhaps something like drush strongarm-overridden <module-name> and something called automatically on install?

lee20’s picture

lee20 commented

subscribing

jide’s picture

jide commented

Sub.

alfthecat’s picture

alfthecat commented

subscribing

dubois’s picture

dubois commented

I'm also having this issue with IMCE (6.x-2.0-rc2) specifically with IMCE profiles.

alfthecat’s picture

alfthecat commented

can confirm IMCE on my side too. As well as Pathauto patterns.

jgraham’s picture

jgraham commented

Opened an issue for pathauto to see if the maintainer is open to patching pathauto to avoid setting variables during install.

http://drupal.org/node/1026376

boobaa’s picture

boobaa
he/him
commented
Version: 6.x-1.x-dev » 7.x-1.0-beta3

Okay, this still applies to 7.x.

boobaa’s picture

boobaa
he/him
commented

I have found a way to get around this and I have documented it in my blog at KYbest.

Basically it looks like that Strongarm (and/or others) has some issues with some features in hook_install() or something; to be honest I dodn't have the time to dig deeper into it since I have found a way to get around it.

gantenx’s picture

gantenx commented

subscribing

RobW’s picture

RobW commented

Having the same issues with the variables posted in the issue description.

Is there a reason that a feature doesn't enable its dependencies in a separate step before enabling itself? It seems like that would be a simple fix (and is basically what #24 outlines in their blog post), but maybe someone more knowledgeable of the inner workings of Features can tell me if this would be a bad idea.

hefox’s picture

hefox commented

Features are modules, they need to be enabable/disable-able like regular modules via things like drush; drupal/etc. are the ones controlling that workflow.

Taxoman’s picture

Taxoman commented
Version: 7.x-1.0-beta3 » 7.x-1.x-dev
mpotter’s picture

mpotter commented
Status: Active » Closed (won't fix)