I recently ran into an issue where I was trying to manage some pathauto settings via features & strongarm.
I could not set the values for 'pathauto_node_pattern' without the value showing up as 'overridden' in the features overview.

Would you be open to a patch that updates pathauto such that all calls to variable_get() in the code are updated to the corresponding values from the install process and the explicit variable settings are removed from the install file? This seems like it would still address the concerns from http://drupal.org/node/113496 but allow for features to set these variables to a different value.

This issue is related to the following discussion: This is related to http://drupal.org/node/677200

Variables set during install:

pathauto_modulelist
pathauto_taxonomy_supportsfeeds
pathauto_taxonomy_pattern
pathauto_taxonomy_bulkupdate
pathauto_taxonomy_applytofeeds
pathauto_taxonomy_2_pattern
pathauto_taxonomy_1_pattern
pathauto_modulelist', array('node
pathauto_ignore_words
pathauto_indexaliases
pathauto_indexaliases_bulkupdate
pathauto_max_component_length
pathauto_max_length
pathauto_node_bulkupdate
pathauto_node_forum_pattern
pathauto_node_image_pattern
pathauto_node_page_pattern
pathauto_node_pattern
pathauto_node_story_pattern
pathauto_punctuation_quotes
pathauto_separator
pathauto_update_action
pathauto_user_bulkupdate
pathauto_user_pattern
pathauto_user_supportsfeeds
pathauto_verbose
pathauto_node_applytofeeds
pathauto_punctuation_hyphen

It looks like this issue is where the code was added; http://drupal.org/node/113496

Comments

jgraham’s picture

jgraham commented
Title: Pathauto sets 28 variables during install causes issues with strongarm » Pathauto sets 28 variables during install causes issues with strongarm/features
dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented

Please check 6.x-2.x. We've reduced the amount of variables that are set on install to six, five of them the 'default pattern' variables that are necessary for the module to work on install. Not setting these variables wouldn't really work with how the module operates as we can't just "add default values" to variable_get() because often we're using them in a dynamic way.

Also, I would not expect Strongarm to not be able to override variables set on a module install. That's just silly if it can't.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Status: Active » Postponed (maintainer needs more info)
greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

Agreed with Dave, but all that said, yes, if you can figure out a way not to set them during install we're open to that.

alfthecat’s picture

alfthecat commented

subscribing

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Status: Postponed (maintainer needs more info) » Closed (works as designed)

No response. Marking as works as designed.

jide’s picture

jide commented

A solution is to variable_del these variables at install, after they have been set by pathauto.

@Dave:

Also, I would not expect Strongarm to not be able to override variables set on a module install. That's just silly if it can't.

Correct me if I'm wrong but, precisely, strongarm sets default variables, if they are set in the DB, then variables will have the value set in the DB.

guenoz’s picture

guenoz commented

Genius !

jide’s picture

jide commented

That's a common problem with features, e.g. with modules creating default entities, content types, vocabularies, whatever.
In these cases, I use a hook_install in the feature, eventually enable the incriminated module there, and then delete unwanted defaults, such as the default profile type created by Profile2 or the default flag created by Flag module... or the variables set by Pathauto.