Fieldgroup exported feature reports as Overridden just after creating the feature

Please keep at it. I'm also having this trouble. I really need to resolve it....

It's related to this: http://drupal.org/node/1613286 in the CTools.

All my features have the include_once line inserted by features. I dont think that is the problem.

I'm getting this too.
Spent some time lightly debugging/rebuilding.

I was continually getting 'needs review' after the first import (and any reset) of a content type that's using fieldgroups in the display (not the edit form, fwiw)
The features diff told me that my feature code needed

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

added. Doing that made it think everything was up to date and in sync, but I'm still not seeing those fieldgroups anywhere.
Getting a green light on the feature status means the fieldgroup definition must now be in the system?
Disabling/rebuilding etc to see if I can trigger it...

All our features have the CTools line in the .info file too, so I don't hink that is the problem either. I already spent a huge chunk of time tracing the problem down to a bug in CTools, which I reported at #1613286: Is 'data' a reserved property name on ctools export objects?.

This could be worked around in fieldgroup by using a key other that 'data' to store the fieldgroup field configuration options. Alternatively, the bug in CTools would need to be be further investigated and resolved.

Thanks for looking. I could only trace it so far into ctools and its magically instantiated pseudo hook function declarations when it melted my head.
The system seems to export it OK, and the feature 'data' matches. But I can't get the rebuild to stick.

Closed #1672472: Fieldset is not getting imported as a duplicate of this one.

1. Open field_group.api.php in field_group module

and copy hook

/**
* Implement hook_ctools_plugin_api().
* This hook is needed to let ctools know about exportables.
* If you create field groups by using hook_field_group_info, you
* will need to include the ctools api hook as well.
*/
function hook_ctools_plugin_api($module, $api) {
if ($module == 'field_group' && $api == 'field_group') {
return array('version' => 1);
}
}

2. paste into your .features.inc, and change the name for hook, and rem the one that automatically generate for us like below:

/**
* @file
* license_database.features.inc
*/

/**
* Implements hook_ctools_plugin_api().
*/
/*
function license_database_ctools_plugin_api() {
list($module, $api) = func_get_args();
if ($module == "field_group" && $api == "field_group") {
return array("version" => "1");
}
}
*/

/**
* Implements hook_ctools_plugin_api().
*/
function license_database_ctools_plugin_api($module, $api) {
if ($module == 'field_group' && $api == 'field_group') {
return array('version' => 1);
}
}

3. That works for me, I think the problem here is the code
return array("version" => "1");

So we should change to :
return array('version' => 1);

But I don't make sure it is always the case, so do my process above to make sure the correct api that field_group module expose for us.

#15 worked for me. I was having same issues. Though my generated features code had no ctools hooks in the *.features.inc whatsoever.

Every other module uses a quoted "1". I may be wrong, but think you are barking up the wrong tree here.

function cw_core_ctools_plugin_api() {
  list($module, $api) = func_get_args();
  if ($module == "bean_admin_ui" && $api == "bean") {
    return array("version" => "5");
  }
  list($module, $api) = func_get_args();
  if ($module == "context" && $api == "context") {
    return array("version" => "3");
  }
  list($module, $api) = func_get_args();
  if ($module == "ds" && $api == "ds") {
    return array("version" => "1");
  }
  list($module, $api) = func_get_args();
  if ($module == "field_group" && $api == "field_group") {
    return array("version" => "1");
  }
  list($module, $api) = func_get_args();
  if ($module == "page_manager" && $api == "pages_default") {
    return array("version" => "1");
  }
  list($module, $api) = func_get_args();
  if ($module == "strongarm" && $api == "strongarm") {
    return array("version" => "1");
  }
}

Why would field group need to do it any differently?

Same here. 1.x and 2.x failed as of now. Even with: http://drupalcode.org/project/field_group.git/commit/964f0a8

Using Features 1.0 Ctools 1.0 and Fieldgroup 1.1

Workaround in #15 solved problem

This is really bizar.
Does anyone have a feature export I can work with to reproduce this?

I created a feature this week during drupalcon. Deleted all my fieldgroups, and then enabled my feature. All the groups show up.
This one uses:
return array("version" => "1");

In attachment my feature. (Latest ctools / features version)

Little mistake. The version of features was still RC-1. Did now the test with 7.x-1.0, also looks like working.

In attachment the new feature.

After changing something, the features gets status 'overridden'. After reverting, everything is ok again.

There is still one bug left. And i think this is the problem that most of you have.

When you create your features, and then delete all the fieldgroups that are in the feature. Ctools will set it to disabled.
After you enable the feature, ctools still doesn't know that the groups are now enabled.

A little fix was already committed on #1067816: Can't restore a programmatically created field group once it's been deleted, so you can see disabled groups.

To completely fix this issue, there is an issue on the features issue queue. Once they help us out, i can continue with this fix. #1239734: Feature not beïng set to overriden, when a ctools export (fieldgroup) is disabled

I was having the same problem. I just finished installing the latest 7.x-1.x-dev version, and it appears to have fixed the problem.

I have found a workaround. I am using the latest versions of all modules and a fresh Drupal installation and yet, when attempting to install a content type using features, field groups are not created for that content type. Frustrating. Nevertheless, this worked for me:

On the source installation:

1. Begin creating a new feature
2. From the "Edit components" menu, choose "Content types: node" and select the content types you want to copy
3. Change the "Edit components" menu to "Field group: field_group" and select all the groups contained within this node
4. Save your feature, install it on a new site and presto, field groups appear.

It seems you have to do the work manually. Features claims to be able to figure out which field groups belong to your node, but in practice, you have to specifically tell it which ones to copy.

I couldn't get field groups to apply correctly, but adding the hook from #15 to the .features.inc file seemed to do the trick. I should note that the hook did not exist in features.inc before I added it, so perhaps that was the problem?

I had the same issue, but my feature already had hook_ctools_plugin_api implemented.

I only added the following into myfeature_ctools_plugin_api()

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

So the entire function looks like this

function myfeature_ctools_plugin_api() {
  list($module, $api) = func_get_args();
  if ($module == "ds" && $api == "ds") {
    return array("version" => "1");
  }
  list($module, $api) = func_get_args();
  if ($module == "resp_img" && $api == "default_resp_img_suffixs") {
    return array("version" => "1");
  }
  if ($module == 'field_group' && $api == 'field_group') {
    return array('version' => 1);
  }
}

Now, all fieldgroups get deployed nicely. Honestly, I have no idea why this works. I'd like to know, though :)

Hi, I want to encourage that we move forward towards resolving this issue. Zuuperman, your last post mentions that you are waiting for an issue in the Features queue to be resolved. The maintainer for Features posted a reply to your last question issue on September 17th. (Here: http://drupal.org/node/1239734).

Perhaps we have what we need to solve this?

Same as #28. Just added this to hook_ctools_plugin_api():

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

From #28 and #30 what is nicely deployed?

This issue is about 'report as overridden'. I'm not sure that's fixed by #30.

#1239734: Feature not beïng set to overriden, when a ctools export (fieldgroup) is disabled still needs feedback from @zuuperman I guess.

I'm seeing the same issue when using Configuration Management (http://drupal.org/project/configuration) module. If I change the install scheme to fg_data it then imports more than before but still messes up the label and children items - both blank. Is there a solution to this?

My issue was that a feature I had just created, exporting only a few content types one of which had field groups, appeared overridden immediately upon install.

The solutions posted in 28 and 30, which hearken back to 15, worked for me; the feature no longer appears as overridden. Mrfelton's comments from 18 appear to be well-founded, however, inasmuch as quoted or unquoted "1" both work just as well. I have not tried using the dev version per 25.

Same issue as reported in #28. My xxx.features.inc already contained the ctools_plugin_api() hook for a different module. Then I added fieldsets and everything was added (module dependency, data for feature) but the ctools_plugin_api() hook was not modified. Fix from #28 worked for me.

Same situation here as #34. Adding fieldgroups to an existing feature which already implements hook_ctools_plugin_api() doesn't work. After adding those 3 lines and deploying the code to the test server, the fieldgroups immediately popped up, even without reverting the feature.

Re #31, it seems as if this issue is about multiple problems. To keep things clear, should we split off some of the problems into their own issue?

I ran into the same issue. I created a feature including some field groups and the implementation of hook_ctools_plugin_api() was missing in the feature. I added the hook manually and everything works.

But than I re-arranged the field groups and recreated the feature using a new version number. Now the hook_ctools_plugin_api() is included in the feature!
Additionally features[ctools][] = field_group:field_group:1 has been added to the feature's info file.

subscribing..

I just created added a group field to a basic page type. Exported a feature and the group field is not being imported. I have tried using 7-x-1.1, 7-x-1.dev and 2.dev

One other thing... If I create two features... one for just the node type and then the other for just the field_group - this the feature deploys properly.

It seems trying to bundle these items together, does not work.

rtdean93: see comment #28.

I can confirm #28 works. This has been bugging me for a long time. Now which module would need to fix this: Features module or Field group?

#42: that would be a core update...
Move it to be fixed in Features 7.x first, and then subsequently into the D8 core queue?

Every thing is generated only thing correct explanation is #7 ... according to this the problem can be resolved.
But is there any patch or solution from feature module it self?

No, there is no patch yet, and I'm not sure if anyone knows what the best solution would be. Maybe it's should be fixed in Features rather than Field Group.

PS. Since there is not patch, the status of this issue must be 'active', not 'needs review'.

Issue is in Feature as far #7 & #44

I'm using the 7.x-1.1 version of Field group and the 7.x-2.0-beta1 version of Features and I'm not seeing any problem. My features.feature.inc file looks fine:

function oa_pages_ctools_plugin_api() {
  list($module, $api) = func_get_args();
  if ($module == "field_group" && $api == "field_group") {
    return array("version" => "1");
  }
}

so it already has the code listed in #28. #994140: Modify .module file when a features.inc is added in #7 was already fixed, so marking this as cannot reproduce. Re-open this with step-by-step details on what you are doing and exactly what isn't working if it's still a problem.

I think my description of the problem in #35 was pretty accurate: "Adding fieldgroups to an existing feature which already implements hook_ctools_plugin_api() doesn't work." But anyway, here are the step-by-step instructions.

- Download Drupal 7.21 and do a site install (drush si). Download and enable the features, field_group and strongarm modules.
- Log in.
- Edit the article node type in admin/structure/types/manage/article, for instance, change comment settings. (This is necessary to store a couple of variables in the variables table, to be exported with strongarm.)
- Create a new feature, containing the article node type and all its auto-detected dependencies. (This is the alpha1 version attached to this comment.)
- Notice this hook implementation in features_fieldgroup_testcase.features.inc:

/**
 * Implements hook_ctools_plugin_api().
 */
function features_fieldgroup_testcase_ctools_plugin_api() {
  list($module, $api) = func_get_args();
  if ($module == "strongarm" && $api == "strongarm") {
    return array("version" => "1");
  }
}

As you can see, hook_ctools_plugin_api() has been implemented because that was required by Strongarm.
- Extract the downloaded feature to disk and enable it.
- Go to admin/structure/types/manage/article/fields, add a field group to the article node type and place the image and tags fields in it.
- Return to the features UI and recreate the feature. Notice how your field group will appear as a new component.
- Download and extract the feature again. (This is the alpha2 version attached to this comment.)
- Notice that in the alpha2 version, the file features_fieldgroup_testcase.field_group.inc has been added, but features_fieldgroup_testcase_ctools_plugin_api() is unchanged.
- Copy the entire codebase of the testsite, delete settings.php and spin up a second test site.
- Enable the feature (drush en features_fieldgroup_testcase -y).
- On the second test site, go to admin/structure/types/manage/article/fields and say: "Hey! Where's my fieldgroup?"
- Open features_fieldgroup_testcase.features.inc and edit features_fieldgroup_testcase_ctools_plugin_api() so it reads:

/**
 * Implements hook_ctools_plugin_api().
 */
function features_fieldgroup_testcase_ctools_plugin_api() {
  list($module, $api) = func_get_args();
  if ($module == "strongarm" && $api == "strongarm") {
    return array("version" => "1");
  }
  if ($module == 'field_group' && $api == 'field_group') {
    return array('version' => 1);
  }
}

- Revert your features (drush fra -y).
- On the second test site, refresh admin/structure/types/manage/article/fields and say: "Hey! There's my fieldgroup!"

Hope that helps.

Every thing is ok only thing during field-group export by feature
.module file is blank so we need to do what #7 has done as far 7.x-1.1 version other wise feature inc file implements ctools_plugin_api hook for field group as well!

Confirming workaround, with a hint.

My existing feature didn't have anything to declaer on ctools_plugin_api hook, so the features.inc file didn't exist. Nevertheless, adding field_groups did not create it and the bug was also present. I manually created the file and added include_once() in .module, then reverting and it all works.

#28 worked for me, but I only had one implementation of hook_ctools_plugin_api().

I'm totally stumped. I have the following:

include_once 'module.features.inc';

in my module file, so it's not #7, and

/**
 * Implements hook_ctools_plugin_api().
 */
function module_ctools_plugin_api() {
  list($module, $api) = func_get_args();
  if ($module == "field_group" && $api == "field_group") {
    return array("version" => "1");
  }
  list($module, $api) = func_get_args();
  if ($module == "strongarm" && $api == "strongarm") {
    return array("version" => "1");
  }
}

in my features.inc, so it's not #28. And yet it still shows as default when the field group is nowhere to be found. I've put logging statements, hook_field_group_info is firing inside of the field_group.inc file, but it still thinks it's default even without it. Doing a forced revert doesn't seem to be working either.

@ wbobeirne, remove the quotes around "1" for the field_group entry in module_ctools_plugin_api().

@xatoo, no such luck after changing. Double-cleared cache and it's still 'default'.

Using Features v2.0-beta2 and either Field Group 7.x-1.1 or 7.x-1.1+66-dev, I'm experiencing very erratic behavior.

First off, all of the features were originally build with beta1 or a dev release from ~February.

Secondly, all of the existing feature exports have correct settings - the correct lines are in the info, features.inc, and field_group.inc files.

The key problem appears to be that most of the field groups do not show up on the Features export page, though they do still show on the content type's field UI page. The site has twenty different items in the {field_group} table, but only five or six show in the Features UI.

As can be expected, once the feature is then exported using Drush the field group definitions are removed.

I dug through this for a while.

The core problem I've ran into is that Features rearranged where some of the settings were but, either through my own screwup or Features being a PITA, there's a disconnect between the contents of the .field_group.inc and .info files across multiple features. All of the field groups are exported, they're just in unexpected places.

I think the problem started in #1966624: Feature 7.x-2.0-beta2 defines fields in a new way, so the sooner we get that fixed the better.

Figured out my problem, here's an explanation for anyone who's still stuck as I was.

So I decided to track this down and see where the comparison was being made, and why it thought it was the same. I followed it all the way down to ctools_component_features_export_render(), which gets the export code for hashing purposes. The ctools object of my field group looks like this:

http://cl.ly/image/063Z3x0r2h2x

The thing of note is that my field group is in code only, and disabled. I decided to check the variables table for anything with group in the name, and lo and behold, I found 'default_field_group', a serialized array of all my field groups. Tried deleting it, and everything showed up fine. I grepped for default_field_group and came up with nothing, so I'm really not sure where it came from...

Thanks for the hint @wbobeirne

I just tried the cure for all ills : clearing the cache while I tried to imagine what the problem was ... and it cleaned right up.

I am seeing this problem now with CTools 7.x-1.3, Features 7.x-2.0-rc1, and Field Group 7.x-1.1 (I also tried the -dev version of Field Group, and also the -dev version patched from this issue: #1966624: Feature 7.x-2.0-beta2 defines fields in a new way -- same effect).

Just to be clear, the problem I am seeing is:
- I create a feature containing a field group.
- I enable this feature.
- The feature reports as "Overridden"
- Using the Diff module, you can see that the data array in the field groups is empty in the module, whereas the "overridden" column shows the fields that are part of the field group -- I made a screen shot on that other issue: https://drupal.org/files/featurediff.png
- But if you try to recreate the feature you get the same broken feature without any data in the field group section.

I spent an hour or two debugging this problem, and found out that if I disabled the caching the CTools module is doing in export.inc / ctools_export_load_object(), this problem went away. I do not know why, but when CTools read the Field Group data from the cache during the , it was getting a different value than if it read the data using a database query. The call stack is something like this at the time when the wrong value is read from the cache:

We're doing an export or a diff... Eventually, we get to the 'field_group' component, and we call:
features_invoke($component, 'features_export_render', $module_name, $data, $export)
which for Field Group, ends up using:
ctools_component_features_export_render() in features/includes/features.ctools.inc, which calls
_ctools_features_export_crud_load() in the same file, which calls
ctools_export_crud_load in ctools/includes/export.inc, which calls
ctools_export_load_object() in the same file

And in this function, if I comment out the code that says:

  // Don't load anything we've already cached.
  if ($type == 'names' && !empty($args)) {
...
    // If nothing left to load, return the result.
    if (empty($args)) {
      return $return;
    }
  }

then it all works fine.

What I don't know is where this bad cached data it is reading and returning is coming from.

What's interesting is that when this whole string of calls comes from features_detect_overrides() [which is what the Diff module is displaying], the cache is OK and I can see the correct data. But when it is coming from drush features-update or clicking the "Recreate" button in the user interface, the cached data is wrong, so it's getting screwed up somewhere before this sequence of calls happens.

I really don't know what the underlying problem causing bug is (like why is the cached data wrong?), but if someone is running into this problem, editing the ctools export.inc file will "fix" it.

#15 worked for me

The solution is given in #57 and #58 which is: Clear the cache! Creating a feature and then enabling it isn't the full procedure. Enabling a module does not clear the Drupal cache and in many cases for modules (not just Features) you need to clear cache after enabling something new.

@mpotter: Should Features preemptively clear the caches after enabling a feature, given this is a known problem?

I thought that enabling a feature was the same as enabling a module. If so, caches are cleared. Are you sure about #61?

I gotta say, my feature was labeled as overridden and every time I tried to revert my field groups it would remain overridden. Clearing the cache made the changes stick for me as well. Really strange. Never had this with any other features on my site but just this one and it used field groups.

This is usually due to missing include in the .module file. Happens with other things than fieldgroups too, sometimes clearing cache adds it, sometimes you have to do it manually.

So, add

include_once 'myfeature.features.inc';

to the myfeature.module file.

added about fieldgroups not getting created

Reading through the issue it's clear there is more than one problem here.

#1 - Field Groups are showing as overridden when they are freshly exported

#2 - Field Groups do not become enabled when a feature containing them is enabled on a fresh site. It's been established the reason this happens is because my_feature.features.inc needs this code:

function my_feature_ctools_plugin_api($module = NULL, $api = NULL) {
  if ($module == 'field_group' && $api == 'field_group') {
    return array('version' => "1");
  }
}

In my case, I was having trouble with #2. I already had that hook implemented (but for strongarm) in my feature, so I just had to add the code there.

I'm not sure why Features didn't automatically include that hook. It seems that some people in this thread have NOT had this problem.

After some research I also found that #61 – clearing the cache – solved my problem.

The issue in #66 was happening for me too, and solution the solution worked great. Thanks bkosborne.

I don't believe this is resolved in all cases by clearing the cache, based on #64, possibly #63, and my own experience, although I may be experiencing two separate problems here.

I had two pre-existing features to which I added fieldgroups. Both then could not be reverted so that fieldgroups would appear on the production site. However, they displayed different symptoms:

• Feature A previously contained only a View. Then I added a Profile2 profile type which contained fieldgroups. When deployed to production, the feature reported as default status with no diff available, and showed the new version number (even though the feature had not been, and could not be, reverted), but the fieldgroups were not present in the profile.
• Feature B previously contained both some views and a node type, and I added fieldgroups to the node type. On production this feature reported as overridden, but the overrides were all changes that had been made in the db on production. The version number registered as the old version number before the feature was exported, updated, and re-imported. There was no evidence at all (through drush or Features UI) that the new version of the feature was on the site, although I confirmed it was by looking at the files through ssh.

No amount of cache clearing, drush fr --force, or anything else I tried made any difference.

Both features had the lines of code mentioned in #7:
include_once('FEATURE_X.features.inc');
and the code in #28

<?php
if ($module == 'field_group' && $api == 'field_group') {
    return array('version' => 1);
  }
?>

But neither one had the line mentioned in #10:
features[ctools][] = "field_group:field_group:1"

I re-recreated both features on dev and this time the code from #10 was present in the info file. When I redeployed, Feature A finally showed as overridden and the diff was what I expected; I was then able to revert it and get the fieldgroups in the profile. However Feature B still reported the original version. I then tried creating an identical feature, Feature C, with a different namespace from Feature B, thinking I'd delete Feature B and that would eliminate the bad information that seemed to be cached about it. However, when I deployed Feature C (and cleared the cache 5 million times), Features reported that Feature C was in conflict with Feature B, even though Feature B had been deleted from the server! (Which I confirmed through ssh.) What could possibly be caching the feature that is not being updated by clearing the cache (through drush and Admin Menu)? At this point I am giving up and recreating all the elements of the feature by hand directly on the production server.

I feel that my experience with Feature A supports some of the comments that have been made here. Not sure that the Feature B problem is similar to anything else reported here, although it clearly involves caching and fieldgroups.

Thanks @BrightBold (and everyone else that debugged this issue)! I added

<?php
if ($module == 'field_group' && $api == 'field_group') {
    return array('version' => 1);
  }
?>

to myfeature.features.inc file and then put

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

in my myfeature.info and that fixed the issue of the field_groups not being created.

I can confirm @dags #70. Manually adding in the field group declarations in both myfeature.features.inc and myfeature.info corrected the issue. In my case, I was adding field groups to already existing features.

Was having the issue of Feature, freshly generated, showing 'OVERRIDDEN' for Field Group:

- Ctools field groups correctly referenced in .info file
- features.inc file correctly included in .module file
- hook_ctools_plugin_api() correctly referenced in features.inc file

Solution: Clear all caches, feature now displays 'Default'

This is still occurring. Exporting Field Groups as a new Feature DID NOT add this into the .features.inc file:

/**
 * Implements hook_ctools_plugin_api().
 */
function FEATURENAME_ctools_plugin_api($module = NULL, $api = NULL) {
  if ($module == "field_group" && $api == "field_group") {
    return array("version" => "1");
  }
}

Nor did it add the ctools dependency line in the .info file.

After adding this and clearing cache, my field groups showed up as expected.

I can confirm kevinquillen's experience: it does still occur.

I had this problem as well today. Manually adding the field group declarations as suggested in #70 and #73 solved my problem.

#72 solved it for me

#73 fixed the issue for me.

just adding the code in #73 solved it for me.
Thx @kevinquillen

Same problem here. field_group piece was missing in the .features.inc file. #73 fixed it for me, but I think it should be automatically added by features, no?

I would think so, but it doesn't always seem to happen.

Field groups not displaying after moving feature to different site.

• Ctools field groups correctly referenced in .info file
• features.inc file correctly included in .module file

hook_ctools_plugin_api() did not include 'field_group'.

Code in comment #73 worked for me. Field groups now display in content type.

Features managed with Drush.

Also same issue here and was solved by #70 en #73. Thanks for helping the community ;-)

#73 works for me as well.

I'm willing to write a patch for this - i'm just not sure whether I should be writing a patch for features or for field group?

This has also been raised at #1670136: Field Groups in Features not importing

@rcross, currently this is set as a features issue, but I would expect this should be handled by field_group. I know this works for strongarm. So I would check to see if it is done for strongarm in features or in the actual strongarm module.

If strongarm does it then put this into field_group.
If features does this for strongarm then put this into features.

I have found another workaround. Inside the file_group module, in field_group.feature.inc, add the following lines to the end of the field_group_features_export_alter() function:

  // ctools needs to tbe told that field_group exists so
  // it can export the right code into .info and .features.inc 
  // files -- in other modules (ex. strongarm) hook_features_export 
  // is used instead of hook_features_export_alter and then this step
  // is not necessary
  $identifier = "field_group:field_group:1";
  $export['features']['ctools'][$identifier] = $identifier;

By making this change, the .info file and the .features.inc file will be exported correctly.

Comment #70 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.

#87 worked for me. Thanks!

Features update with generate inside UI doesn't include the stuff commented on #73 and #81.

If I do a `drush features-update feature_x` then it correctly includes the api stuff.

This is definitely something that needs to go into the Field Group module and not Features itself. Features only implements the hooks for core functionality, such as fields, content types, etc. Other contrib modules are responsible for their own hooks for features.

The code from #87 is the correct way to handle it.

Could somebody create a proper issue in the Field Group project and then link it here? Then we can close this.

#87 worked perfectly for me.

But did a small modification in the code:---

// 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;
  }

Yes i am totally agree with @mpotter, this is not the bug of Feature module, we need to fix this issue into the Field Group module itself.
Here is the link to get the issue in Field Group module.

bisw, I can't see what you changed in the code.

Still having problems.

my bad. It was php 7 and latest dev version helped.

The issue for Field Group has a patch (#1670136-21: Field Groups in Features not importing) which contains the solution in #87. Hope I'm not stepping on anyone's toes in closing this bad boy.

Confirmed, #66 solves my headache.

Reminder for myself - stop using PHP 7 with Drupal 7. Got the Overridden because of that. Again :)