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
Comment #1
merlinofchaos commentedIt 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.
Comment #2
karolrybak commentedThe same things happens on my site.
Comment #3
karolrybak commentedI'm experiencing the same issue
Comment #4
karolrybak commentedAlso 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.
Comment #5
joachim commentedIf 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.
Comment #6
Stalski commentedHmm, 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
Comment #7
joachim commentedI 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?