the field_group module uses the 'data' keyword in its exportable definitions. For example:

/**
 * Implements hook_field_group_info().
 */
function cw_event_field_group_info() {
  $export = array();

  $field_group = new stdClass();
  $field_group->disabled = FALSE; /* Edit this to true to make a default field_group disabled initially */
  $field_group->api_version = 1;
  $field_group->identifier = 'group_tab_media|node|cw_event|form';
  $field_group->group_name = 'group_tab_media';
  $field_group->entity_type = 'node';
  $field_group->bundle = 'cw_event';
  $field_group->mode = 'form';
  $field_group->parent_name = 'group_tabs';
  $field_group->data = array(
    'label' => 'Media',
    'weight' => '18',
    'children' => array(
      0 => 'field_cw_media_main_image',
      1 => 'field_cw_media_media',
    ),
    'format_type' => 'htab',
    'format_settings' => array(
      'formatter' => 'closed',
      'instance_settings' => array(
        'description' => '',
        'classes' => '',
        'required_fields' => 1,
      ),
    ),
  );
  $export['group_tab_media|node|cw_event|form'] = $field_group;

  return $export;

In some cases, when the feature is regenerated, the content of the data array gets completely wiped out, resulting in a broken field_group default object. I spent a long time tracing this, and managed to trace it to the ctools_export_load_object() function. The behaviour seems to change depending on where it's called from. If you call it standalone, then the data property is properly included, but sometimes, when called from within Features export, it isn't. Possibly something to do with caching. ->data itself gets lost, but the individual array keys within that array are flattened out the outer array.

If I rework field_group to store this data somewhere other than ->data, then everything exports ok. The _ctools_export_get_defaults_from_cache function does look like it it makes some special use of the 'data' keyword, but I don't see anything in the documentation that indicates that 'data' is a reserved keyword and should not be used. Is it reserved? Is this possibly just some undocumented behavior?

Comments

merlinofchaos’s picture

It may be a bug that no one has ever noticed, because it only affects that single keyword. data should not be reserved.

I think I know the code you're referring to, and I do recall that it has some buggy behavior already. THe data keyword may exacerbate this.

karolrybak’s picture

The same things happens on my site.

karolrybak’s picture

I'm experiencing the same issue

karolrybak’s picture

Also i found out that when i export field groups like

drush @site.pl fe module field_group:group*

It creates empty data values.

However after issuing

drush @site.pl fu module

data objects are created properly.

joachim’s picture

If the problem with this bug is specifically field group support, I've found the bug, and it's in Features: #994140: Modify .module file when a features.inc is added.

More details at #1619154: Fieldgroup exported feature reports as Overridden just after creating the feature.

Stalski’s picture

Hmm, I'm a bit late to see this issue.
The only reason I chose data is since it is well known as a serializable storage field. I'm checking how fieldgroup can fix this.
The easiest fix is to alter .install so the schema and upgrade path changes the field "data" in "settings" or whatever name.

- Edit - Just realized the data key will be invoked or called by other contribs depending on field_group or custom implementation. Bummer

joachim’s picture

I had to file a patch on CTools some time ago because my exportable was using an object property CTools wanted to use for the status (in code/in db/overridden/etc). An extra setting was added to tell CTools to put that in a different property.

Same sort of problem here and same sort of fix maybe?