Strongarm variable with indexed array - override not detected

Discovered something interesting while doing this. Some of my overrides are detected, but not the one involved in my original report.

Here's the current diff:

$ drush -l local.site.com features-diff site_core

Component: variable
          ),
          'talent_portfolio' => array(
<           '0' => 2,
---
>           '0' => 1,
>           '1' => 2,
          ),
        ),
      'api_version' => 1,
      'name' => 'preprocess_css',
<     'value' => '1',
---
>     'value' => '0',
    ),
    'preprocess_js' => array(
      'api_version' => 1,
      'name' => 'preprocess_js',
<     'value' => '1',
---
>     'value' => '0',
    ),
    'site_403' => array(

You'll see in the attached screenshot, that the overrides to preprocess_css and preprocess_js are detected. However, the third override is not detected.

As I mentioned, the difference is to a variable that is a serialized array (and it's a fairly big one too). It's the variable content_access.module uses to store it's per-content-type access settings. Below is what I currently have in the feature's .strongarm.inc file. I've commented where the diff occurs:

  $strongarm = new stdClass;
  $strongarm->disabled = FALSE; /* Edit this to true to make a default strongarm disabled initially */
  $strongarm->api_version = 1;
  $strongarm->name = 'content_access_settings';
  $strongarm->value = array(
    'view' => array(
      'company_news' => array(
        0 => 2,
      ),
      'gift_card' => array(),
      'how_to' => array(
        0 => 2,
      ),
      'static' => array(
        0 => 2,
      ),
      'talent_match' => array(
        0 => 2,
      ),
      'stock_gift_card_image' => array(
        0 => 2,
      ),
      'webform' => array(
        0 => 2,
      ),
      'talent_fact' => array(
        0 => 2,
      ),
      'talent_portfolio' => array(   /******  This is where the diff/override is   *******/
        0 => 2,
      ),
    ),
    'view_own' => array(
      'company_news' => array(
        0 => 2,
      ),
      'gift_card' => array(),
      'how_to' => array(
        0 => 2,
      ),
      'static' => array(
        0 => 2,
      ),
      'talent_match' => array(
        0 => 2,
      ),
      'stock_gift_card_image' => array(
        0 => 2,
      ),
      'webform' => array(
        0 => 2,
      ),
      'talent_fact' => array(
        0 => 2,
      ),
      'talent_portfolio' => array(
        0 => 2,
      ),
    ),
    'per_node' => array(
      'company_news' => 0,
      'gift_card' => 0,
      'how_to' => 0,
      'static' => 0,
      'talent_match' => 0,
      'stock_gift_card_image' => 0,
      'webform' => 0,
      'talent_fact' => 0,
      'talent_portfolio' => 0,
    ),
    'priority' => array(
      'company_news' => '0',
      'gift_card' => '0',
      'how_to' => '0',
      'static' => '0',
      'talent_match' => '0',
      'stock_gift_card_image' => '0',
      'webform' => '0',
      'talent_fact' => '0',
      'talent_portfolio' => '0',
    ),
  );

After tracing through the code, I did indeed find a problem that will occur with the first key of indexed arrays (0).

In features_override.module:198, there is the following:

    if (in_array($key, array('content_has_extra_fields', FEATURES_OVERRIDE_RECURSION_MARKER))) {
      return;
    }

When my strongarm variable export (which contains an indexed array) is processed, this condition will return TRUE for key 0.

Looking at php.net, you'll see several people warning about in_array() not using strict comparisons, and how this can cause problems with 0: http://ca3.php.net/in_array

Seeing how this condition is really only looking for specific strings in $key (contains 'content_has_extra_fields' or 'features_override_recursion_marker'), it might be reasonable to cast $key to a string:

    if (in_array((string) $key, array('content_has_extra_fields', FEATURES_OVERRIDE_RECURSION_MARKER))) {
      return;
    }

This change fixes the problem with my override not being detected. There are probably other ways to skin the cat as well...

Ryan

Problem duplicated with -dev branch. Patch attached.