Fieldgroups should be created when adding the fields to the feature

It might make sense for the Field Group folks to implement Features integration? What do you think?

Features is trying to stay pretty close to core and supporting more exportable frameworks like ctools and providing an API for other modules to integrate with. One off integrations are best handled by the module themselves. Rules and Entity are such an example.

Field Group folks, what to you think?

Features support is built in since the creation of field_group. A field_group is a ctools exportable and ctools does that job. I tested this a lot and it works great.

Why do you think it is not there?

Yes, this is in by default.

This is not by design. The content type does not know it has groups. The entity knows it's fieldable and that it has fields ... but not further than that.
We could try to locate the groups and hook the dependency onto the content type being featured.
If anyone is up for a Proof-Of-Concept, patch along ...

Better title

How about something like this?

Forgot to add the field_group dependency when we add auto-detected field_groups. This patch should work.

One more try...

Yeah, that's awesome. You made my day, or at least my afternoon :)
I'll check it out asap.

Tested the patch and it works like a charm. To be honest, this rocks :p. Thx for the patch :). Committed it to dev.

Found a nasty little followup bug with this that causes the group's data property to be emptied out when groups are being re-exported. As a result, groups tend to lose their children and labels when re-exporting. Digging into the code, it looks like calling field_group_unpack unsets $group->data, which would be fine except that these are objects, which are passed by reference. So when we use ctools_export_load_object() later, we get the unset data versions. Long story short, the attached patch should correct the issue.

Awesome. I understand what you are saying and it's completely correct. I'll commit this later today.

Pushed to git

Interesting follow-up note.

This only works if the field group surrounds an added field. If you put a fieldgroup around 'Title' and 'Body', for instance, those are ignored.

@agentrickard: I never thought about that. For node fieldgroups, that could be fixed by adding an extra loop to make sure that if a whole node type is exported, we get all fieldgroups for that type. For other entity types, I'm not sure how easy it would be. Anyone know of an easy way to check for exported bundles of any entity type?

Hmm, interesting indeed.
And for the other entity types, I guess it will be as hard as it is for nodes. I only hope this won't push us to hard code.

I don't know that it has to be supported, but it does have to be noted. It probably has the same problem with fields defined by hook_field_extra_fields(), though I could not confirm #1298522: Extra field disappear when testing with Path/PathAuto.

I am gratified and awed by everyone's contributions to this issue. I will go out on a limb and suggest there is still an issue to be resolved. Although the patches contributed above go a long way toward getting field groups into the export when fields are selected, I still have a problem enabling the exported feature on another site. I compared the code exported between a feature that explicitly includes a field group and one that doesn't. This single line is missing in the in the feature module's info file if the field group is NOT explicitly included in the feature:

features[ctools][] = "field_group:field_group:1"

These lines are output by ctools_features_export IF the appropriate component is passed into this export. We need to alter the features pipe before ctools_features_export is called. I propose adding this hook to field_group.features.inc:

function field_group_features_pipe_field_alter(&$pipe, $data, $export) {
  ctools_include('export');
  $field_groups = ctools_export_load_object('field_group');
  
  foreach($data as $field) {
    list($entity_type, $bundle, $field_name) = explode('-', $field);

    foreach ($field_groups as $group_id => $group) {
        if ($group->entity_type == $entity_type && $group->bundle == $bundle
          && in_array($field_name, $group->data['children'])) {
          $pipe['ctools'][] = 'field_group';
          break 2;
        }
    }
  }
}

This is lifted from the patches above. It simply determines if ANY fields being exported are in a field group and if so, adds the appropriate ctools item to the pipe. This forces the export hooks to run again and ctools will output the correct line.

I would appreciate if anyone can verify if this approach is valid or even if anyone is still having trouble with field group exports that aren't explicitly enabled.

Thanks again to all the contributors, especially rbayliss.

I have a feature in which it is impossible to revert the field_group component. I am using custom Display Suite fields inside the field groups, but am not sure if this is causing the problem. I hope to find some free time later this week to investigate this further.

edit: It was solved by uninstalling and re-enabling the feature.

After upgrade to latest stable (7.x-1.1), Field groups is exporting ok for me. Previously i got empty data in the export... just like that: $field_group->data = '';

I added features[ctools][] = "field_group:field_group:1" manually to the .info file. Worked wonderfully. I also noticed that if I "recreate" the feature and save it, features[ctools][] = "field_group:field_group:1" is saved to the .info file inherently (...as you mentioned, at that point the field_group is explicitly enabled versus the auto detect in my first save.) To answer your question - with auto detect only, this line was not added. Is the code you provided already in place or where do I place it?

Huge thank you.

Every time I export a feature that contains field groups, hey data element seems to go missing, similar to the issue described in #13
, although that patch seems to have been committed, it doesn't fully resolve the issue.

Using 7.x-1.0-rc2

I have created a content type on one site and saved it as a feature, all the field groups appear to be fine in the feature tarball I download.
I upload and install the feature on another site and everything seems to work fine. Features tells me my fieldgroups are there & "DEFAULT".
When I go to my content type, everything was created correctly except for there are no field groups at all.

Same exact issue here. I get the full definition of field groups but not the actual groups created on the type itself. In fact, even browsing directly to the Content Type shows no field group. However, features does export the MYMODULE.field_group.inc file and it appears to be the right format. Unsure if this is a field group issue though.

Found the problem. Although I don't know how to fix it. :) Seems that exports are forgetting to include the following hook:

functions hook_ctools_plugin_api($module, $api) {
  if ($module == 'field_group' && $api == 'field_group') {
    return array('version' => 1);
  }
}

Include that and magically everything works as expected.

^ Magic!

Nice work.

And here's a one-line patch to fix the issue in the module. This is the first time I've written any code for Features, so I don't know if this is the right way to do it, but it does work for me.

I don't think you can trust the numeric identifier here:

field_group:field_group:1

What happens when you have more than one field group?

I think that's actually the API version number, not a field group id. Not that that makes my hack patch any better.

I wish I'd noticed Nick Aiuto's code in #21 earlier, that seems to do exactly what I was trying to achieve, but it looks like it's actually doing it the way it's meant to be done. Adding the pipe_field_alter hook works for me. So, here's Nick's fix rolled into a patch:

One more time, without the whitespace errors.

I keep getting an error with this patch:

Warning: in_array() [function.in-array]: Wrong datatype for second argument in field_group_features_export_alter() (line 23...

It then screws up my content types...

Anyone else getting this issue?

This is the line in question:

&& in_array($field_name, $group->data['children'])) {

rsgracey: Can you provide steps to reproduce the bug from a clean install?

No. It's taking me too long to recreate it with my feature and all the dependent modules, etc. I just wondered whether anyone else had encountered this error.

Well, days more of play and discovery. Try reproducing the error like this...

The errors above are being thrown when in the feature *_field_group.inc has all the field group "data" stripped out of it.

$field_group->data = '';

If I delete the feature and create a new one, then the field groups are written correctly. When I use Drush, and "drush fu [feature]", the field group properties are stripped out, with these errors:

in_array() expects parameter 2 to be array, null given field_group.features.inc:23

See if that happens to anyone else...

Once it's stripped out, it doesn't matter how many times I try "recreating" the feature--those blank data parameters are never rewritten, and they continue empty.

So I guess maybe it's the Drush implementation?

Here are a couple of other posts related to this issue. It seems to be a mismatch between arrays and CTools objects?

• http://drupal.org/node/1613286
• http://drupal.org/node/1619154

As people have pointed out above, automatically adding field groups to a feature that doesn't already have them can leave your feature without a CTools API declaration for field_group. This can cause all kinds of weird side effects, like future exports of that feature containing an empty $fieldgroup->data array. Since this only seems to happen when the field_groups are automatically added, I think the right place to ensure the field_group API is added is in field_group_features_export_alter(), right after we detect and add the field_groups.

Attached patch should fix this going forward, but I don't think this will fix the already broken features (i.e: missing the data array). I'm not sure it's possible to recover these automatically, and I'm not 100% sure how to fix these manually.

None of the patches here prevent the empty data array. I have a feature with a working field group definition. The .features.inc file contains the field_group API bit, but re-exporting the feature still results in an empty data array.

I ran into the bug with the missing data property again while using 7.x-1.1:

in_array() expects parameter 2 to be array, null given field_group.features.inc:23

After reading the comments on this issue, and doing some of my own debugging, I found that field_group_unpack() was causing my issue, in the same way that rbayliss described in #13. For me, this was because I was calling field_group_info_groups() in a hook_menu() implementation, which was getting executed during the menu_rebuild() that takes place during the drupal_flush_all_caches() operation which gets triggered by doing a drush features-update module_name or a drush features-export ....

It seems to me that the patch from #13 only corrected one instance of the problem, where it would actually make more sense to fix the problem at its source in field_group_unpack(). I've attached a patch which clones the $group before altering it, in a similar way to how field_group_pack() is implemented.

I hope there is no code anywhere else in the module that relies on the $group object being altered, but I have tested this locally without issues, so I think it is a safe change.

I had the same issue described in #41. I'm not sure why the call to unset($group->data) is made, but commenting out the unset allows me to use drush fu to export the field groups. Like @jamesharv, I don't know enough about the field group module to know if this would cause issues elsewhere, but it fixed my problem.

#41 Works for me
When I exported a fieldgroup added to commerce_order entity, $fieldgroup->data() was empty even in latest dev.
#41 corrects the issue.

As per #43 this is resolved by #41. RTBC++;

FYI, #1966624: Feature 7.x-2.0-beta2 defines fields in a new way will help fix problems for anyone using the latest release of Features.

#41 fixes features module exports for me.

+1 for #41.

For what it's worth I would expect this code originated back when objects weren't all passed as references, so you could do whatever you wanted to an argument ($group) without affecting it in the calling scope. If this was an intentional "alter" style function it would probably not bother returning $group at the end. Cloning the object instead of modifying it fixes this behaviour.

+1 for #41.

Works for us too! RTBC!

Patch has been committed to dev. Thx for the patch + reviewing it :)