Field Groups in Features not importing

I got the same issue.
Moreover exporting the views, I noticed certain settings are lost.
Any solution?

Re-opening. It looks like on first export of a field group, the feature is missing this snippet in the hook_ctools_plugin_api() implementation:

  if ($module == "field_group" && $api == "field_group") {
    return array("version" => "1");
  }

As well as the following in the info file:

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

I have to export the field group in a feature, install the feature on the target site, then export the feature from that site again in order to get the feature where it needs to be.

same here, comment nr. 3 from above #1670136-3: Field Groups in Features not importing saved the day!
thanks!

Ran into this issue today and #3 fixed it. Thanks!

Add the function in field_group.features.inc (The file is in the directory of field_group module)

function field_group_features_rebuild($module) {
  $default = features_get_default('field_group', $module);

  if (false == $default) {
    return;
  }

  foreach ($default as $item) {
    $load = field_group_load_field_group_by_identifier($item->identifier);

    if (is_object($load) && empty($load->in_code_only)) {
      continue;
    }

    $group = field_group_unpack($item);
    field_group_group_save($group);
  }
}

Both "solutions" won't work for me. My feature stays in overwritten. Can we please have a fix from the author?

Running 7.x-1.4+16-dev

Stuck on this too.

The fix from #3 works fine for me.

The fix from #3 works fine for me.

Comment #3 correctly identifies the problem and is a good workaround. However, if you are creating features often, then manually updating the .info file and the .features.inc file for every feature is tedious. You can fix the problem more permanently by making the following addition to the field_group.features.inc file.

Inside field_group.features.inc, add this to the very end of the field_group_features_export_alter function:

  // Tell ctools that fieldgroups is being used 
  if (!empty($export['features']['field_group']) || !empty($export['features']['dependencies']['field_group']) ) {
    $identifier = "field_group:field_group:1";
    $export['features']['ctools'][$identifier] = $identifier;
  }

Alternatively, i've attached a custom d7 module called "field_group_features_fix". Enabling the module will fix the problem without needing to modify field_group module.

The fix from #3 works fine for me. (To apply it for fixing a feature import that missed out your field groups, edit the in the changes from #3 into your features files, disable the imported feature, and import it again … usually this simply means, disable and re-enable the module containing your feature.)

I tried the fix from #13 first (the patch in the comment text, not the module). It correctly puts in the features[ctools][] = field_group:field_group:1 line into the .info file when exporting the feature, but does not amend the hook_ctools_plugin_api() implementation as in #3. For this reason, it still creates feature exports that fail to create field_groups on import.

But we're close to a solution, people :)

Hi @tanius,

Are you certain that your hook_ctools_plugin_api() is not exported correctly after applying the fix in #13?

I have been using the fix in #13 for quite some time now and every feature I export is getting correct code in hook_ctools_plugin_api(). Just in case it is somehow different, would you be willing try using the module in #13 and report back if that works for you?

Here is a patch for the proposed change.

The tests seem to be broken. They expect a bundle "article" to be present - which is simply not the case.

Patch works, but is missing some code style.

1. +++ b/field_group.features.inc
   @@ -67,4 +67,10 @@ function field_group_features_export_alter(&$export, $module_name) {
   +  // Tell ctools that fieldgroups is being used
   

   .. is being used.

2. +++ b/field_group.features.inc
   @@ -67,4 +67,10 @@ function field_group_features_export_alter(&$export, $module_name) {
   +  if (!empty($export['features']['field_group']) || !empty($export['features']['dependencies']['field_group']) ) {
   

   )) {

I would suggest to also change fieldgroups => field_groups, in that comment, to reflect the official name of the module. I.e.

  // Tell ctools that field_groups is being used.

patch with #19 & #20 suggestions.

Patch #21 doesn't work for me (PHP7). Still empty field groups:

  $field_groups[''] = $field_group;

I think patch #21 does indeed work - it's just not the only problem to solve ;)

I tried the patch in #21 but I still had an empty string in my $field_groups (as in #23). I had to manually add the identifier in order to get my groups to revert/import.

@ducdebreme & @joekers: You are looking for #2649648: PHP7 - Uniform Variable Syntax updates are causing exported field_groups to not have names.. This patch only solves the remaining issue that's not already fixed in 7.x-1.x.

The patch in #21 works for me too (applied to 7.x-1.5, on PHP 5.5.9). And in the related issue in Features (#1619154: Fieldgroup exported feature reports as Overridden just after creating the feature) mpotter has indicated that this is the correct approach. PHP7 issues aside, seems like this is good to go.

Queer. I tried the patch, still got many false 'overridden' reports and remaking produced empty field group ids... Was using PHP 7 by default under drush.

With the patch AND rolled back to php 5_6, re-baking my features that contained field_groups only came up with the expected changes.

Odd that #2649648: PHP7 - Uniform Variable Syntax updates are causing exported field_groups to not have names. is a happening, but it's a real thing.
(May as well continue getting this patch in though, I guess)

The module from HelloLindsay on #13 fixed this issue for me too!

Was using php 7.0.8 and could not features revert because of empty field groups like $field_groups[''] = $field_group;. Downgraded to php 5.6.30 and worked perfectly without needing a patch. For a quick fix, if you're on ubuntu try:

add-apt-repository ppa:ondrej/php
apt-get update
apt-get install php5.6 php5.6-mysql libapache2-mod-php5.6 php5.6-mbstring php5.6-xml
a2dismod php7.0 ; a2enmod php5.6 ; service apache2 restart
update-alternatives --set php /usr/bin/php5.6

You may need to prepend commands with "sudo" depending on your setup.

Minor problem - while the patch appears to generally work, I noticed a few things:

• The CTools API dependency wasn't added to hook_ctools_plugin_api().
• Re-exporting the feature adds the CTools API pieces, however..
• Because of the missing CTools API lines, when the feature is re-exported the exported field_group items are dropped from the info file.

Was the #2649648: PHP7 - Uniform Variable Syntax updates are causing exported field_groups to not have names. fix not sufficient for resolving this already? Just applying that patch to field_group 7.x-1.5 did the job for me, when running under php 5.4.41 (my local default) or 7.

@vilepickle: This wasn't fixed yet, hence the "needs work" status on the issue and there's no reference to anything being committed.

Hi! I'm experiencing this issue on version 7.x-1.5 and the fix from PHP7 - Uniform Variable Syntax updates are causing exported field_groups to not have names. isn't there yet.

The fix for #2649648: PHP7 - Uniform Variable Syntax updates are causing exported field_groups to not have names. is not included in 7.x-1.5, no, but should be in the latest dev code. So @vilepickle and @leolando.tan, do either of you still experience this bug if you use the latest dev code (and after flushing caches)?
From my own testing, that was sufficient to fix this bug too.

Hi @james.williams, I can confirm that the code change is in the latest dev code based on http://cgit.drupalcode.org/field_group/tree/field_group.module#n2261. To fix this though, I applied the patch instead of updating 7.x-1.5 to the dev version.

Ok, so @vilepickle and @leolando.tan, with the patch/fix from #2649648: PHP7 - Uniform Variable Syntax updates are causing exported field_groups to not have names. in place, do you still experience this problem or not?

I'm going to take the bold step then of closing this as a duplicate of #2649648: PHP7 - Uniform Variable Syntax updates are causing exported field_groups to not have names., unless anyone can show it is actually still an issue with the latest dev code.

The functionality doesn't work with PHP 5.x, so this isn't a problem limited to PHP 7.

@DamienMcKenna: 7.x-1.x-dev on php 5.6 fixes the issue here

Had similar problems. Features wanted to safe groups variable without any content assigned. After installing the Dev version, all seems to work fine again!
We had this problem with PHP 5.6 .10 and 7.0.8.

I can also confirm that field groups & features behave as expected on php 5.6 after updating to 7.x-1.x-dev (0a5404d).

The functionality does not work with php5.6 . Confirmed. Features don't respect Field group configuration in content types

@neetu morwani which version of field_group are you running? Several people have reported that using the latest dev version has resolved the issue, so maybe you'll need to try that?

Running PHP 7.1. Switching to the latest dev version fixed the problem for me.

Switching to 7.x-1.x-dev fixes the issue for me. I'm running PHP 7.

Same issue over here. Switching to 7.x-1.x-dev fixed it for me. Running PHP 5.6

Ah! that was a missing from my-side forget to commit my module.field_group.inc from feature it-self!

If this is in dev, and does work on PHP 5.6 as many have confirmed, I think this can safely be set to Closed (Duplicate) (of #2649648) again, right?
Anywho, I'll just put in RTBC for @damienmckenna or whomever to update status, but it doesn't seem it needs work any longer, just a 1.6 release! :) Thanks all!

Same here, switching to 7.x-1.x-dev fixed the problem. Field groups were properly created.

A heads up: the 7.x-2.x-dev code still has a bug in this area:

$code .= " \${$export['identifier']}s['" . check_plain($object->$export['key']) . "'] = \${$export['identifier']};\n\n";

should be:
$code .= " \${$export['identifier']}s['" . check_plain($object->{$export['key']}) . "'] = \${$export['identifier']};\n\n";

Issue mentioned in #57 is fixed in the latest 7.x-1.x and fixes issue with PHP 7.

Related: #2916176: Use var_export() instead of check_plain() when exporting to PHP

EDIT: Forget it, it was a stupid mistake on my part.

My feature does contain the additions from #3, and I am using field_group-7.x-1.5+5-dev.
Still a drush fr FEATURENAME, or even disabling and re-enabling does not create the groups.
Running drush fu after drush fr removes the groups from the feature.

EDIT: More info:
- The server where I want to use the drush fr is using PHP 7.
- The server (local) where I created the feature is using PHP 5.6.
- The field groups are mostly for ..|form.
- The problem from #2649648: PHP7 - Uniform Variable Syntax updates are causing exported field_groups to not have names. does not apply anymore since I am using field_group-7.x-1.5+5-dev.

Please ignore previous comment #60, it was a mistake on my part.
(It is unlikely that others would do the same, so I won't explain it further).

According to RoSk0, 7.x-1.x is already fine. So moving this issue for 7.x-2.x.

Hi there,

I confirm as well that this works on 7.x-1.6 !
I would like to suggest to document the top of this issue with the following:
- first, mention that this problem has been resolved for 1.x branch because people (like me :) could think at first that this bug would require upgrading to 2.x or that it still needs work... But no! Great news you just need to upgrade to 1.6...
- second, that you actually need to recreate the Feature with FieldGroup 1.6 so that it can work. If you created the feature with 1.5 and try to install it on a website that you just upgraded to 1.6 hoping it will solve the problem, that won't be enough. Recreating the old feature is fine, you don't need to create another one from scratch, but you have to recreate it with 1.6.

Thanks for the fix guys!

The problem described in #3, hook_ctools_plugin_api() not being updated on initial export, is *not* fixed in 7.x-1.6. The patch in #21, which does fix this problem (according to my local testing), was never merged.

The patch in #21 does not completely solve the problem. The load callback is pointing to an invalid function. See attached patch.

Actually the patch in #21 breaks my site, I just need the new issue I provided above, see attached patch. I don't know if these are two different problems.