Hey - not sure if this belongs here or in the Features module (since I'm not really sure what the problem is yet). Hopefully somebody has seen this before!

I've been trying to use the Features module to set up the configuration settings for a custom module I wrote (basically we'd like different features for different configurations that our clients can choose between). The module stores it's settings using variable_get and has its own system_settings_form for editing them. Exporting the variables works fine (the .inc file has the appropriate values) but the variables are not set properly when importing.

I've done other, custom Feature imports, and they have been working fine but these variables just will not budge.

I'm going to continue to try and debug this, but I was hoping somebody else might have seen this before and know what I'm doing wrong (if anything). Maybe my use case is not the right one to use here.

Steps to Reproduce:

1. Create a very basic module that simply sets a variable when being enabled and provides a form for editing it.

  // in simpletest.module

  function simpletest_enable() {
    variable_set("simpletest_helloworld", "hello world");
  }

  function simpletest_menu() {
    return array(
      "admin/config/content/simpletest" => array(
          "title" => "SimpleTest Configuration",
          "description" => "Simple test configuration issues",
          "page callback" => "drupal_get_form",
          "page arguments" => array("simpletest_admin_form"),
          "access arguments" => array("access administration pages"),
      )
    );
  }

  function simpletest_admin_form($form, &$form_state) {
    $form = array();
    $form["simpletest_helloworld"] = array(
        "#title" => "Hello World Var",
        "#type" => "textfield",
        "#required" => true,
        "#default_value" => variable_get("simpletest_helloworld", "hello world")
    );
    return system_settings_form($form);
  }

2. Enable the module and edit the variable using the form at /admin/config/content/simpletest to something different (in my case, I changed it to Hello World!)

3. Create a new feature. Export only the simpletest_helloworld variable.

4. Verify, in the featurename.strongarm.inc file, that the variable value has changed:


function simpletest_export_strongarm() {
  $export = array();

  $strongarm = new stdClass();
  $strongarm->disabled = FALSE; /* Edit this to true to make a default strongarm disabled initially */
  $strongarm->api_version = 1;
  $strongarm->name = 'simpletest_helloworld';
  $strongarm->value = 'Hello World!';
  $export['simpletest_helloworld'] = $strongarm;

  return $export;
}

5. In a clean Drupal installation, install and enable the dependencies (ctools, features, strongarm) and the simpletest module created in step #1.

6. Install and enable the feature created in step #3.

7. You should now notice the following symptoms:

a) Browsing to /admin/config/content/simpletest will show you the default value (not the imported value)
b) If you click on the feature definition, Strongarm will be locked into OVERRIDDEN (despite you not changing anything).
c) Going to /admin/config/development/strongarm shows the variable with the storage set to Overridden and the value the same as the default value.
d) The correct value is stored in the variables table however.

Restoring the values to the default settings reverts to the imported value though and clears the OVERRIDDEN flag on the database.

So what it looks like is happening to me is that Strongarm is importing my variable, then overriding it with the original value.

Comments

Simon Georges’s picture

Which version of Strongarm are you using?

bblake’s picture

Status: Active » Closed (works as designed)

I've followed along and duplicated on my own, and I think what's happening is the correct behavior.

When you enable your initial module, it does a variable_set which does an insert into the variable table for that variable.

When you subsequently enable the feature, that initial value of the variable is still in the database, which is why the feature and strongarm thinks that the value for the variable has been overridden. ( because essentially it has been ). Doing a revert of the feature sets the correct value from the feature. ( enabling the feature by itself doesn't automatically override the values stored in the db )

After I enabled the feature, I still saw the initial value for the variable in the variables table, then reverting the feature sets it to the one from the feature.

Sylvain Lecoy’s picture

Status: Closed (works as designed) » Needs work

I think this could be worked out.

When enabling a new feature your expectations are not that the feature is de facto overriden, but defaulted instead.

I understand the logic behind it, but from a user standpoint or developer (through continuous integration server periodically installing a profile with features), we should not have to revert the feature once installed.

I have a use case where a feature contains the specific environment for Varnish and Solr. When I deploy the feature on the staging server, it cause drush errors cause varnish and solr could not be contacted. When I revert manually in the admin interface, it work ok but reverting manually on a nightly build is not an option, it should be de-facto imported as default.

Sylvain Lecoy’s picture

The only work around for now is:

# Starts the drush clean dance.
drush --nocolor --yes cc all
drush --nocolor --yes features-revert-all
drush --nocolor --yes cc all
drush --nocolor --yes features-revert-all

Really not appealing.

qqboy’s picture

why clear cache and revert by 2 times, 1 time not working ? @Sylvain Lecoy

Sylvain Lecoy’s picture

Guess what, no :)

That's why i'm calling this the drush clean dance.

But it was 4 years ago so maybe its working now !