Fieldgroup support

Will take a look at this -- might need some custom detection as fieldgroups aren't CCK fields themselves but metadata.

Where would I put the code that makes a fieldgroup and saves my field in it? hook_strongarm() seems not the right place to do such things.

TUc

Is this doable ? The fieldgroup module doesn't seems to use exportables. The fieldgroup_groups function fetch the groups definitions from the database. Maybe a fieldgroup issue "Use an exportables architecture to allow integration into features" is needed ?

Setting to postponed until CCK fieldgroups has exportables.

I created the issue in the fieldgroup queue #547572: Use an exportables architecture to allow integration into features

Seeing as how that issue is now marked as fixed, it doesn't look like the maintainers of CCK have any intentions of adding fieldgroups in the way you're hoping. Re-setting to active.

Subscribing.

With the response in CCK's issue queue, it looks like there is not a push to change the formatting of fieldgroups at this time. It looks like this will need to be implemented as a special use in the short term. Over the longer term, fieldgroups and other content type layout options need to be easily exportable. This will be especially important come D7 when mode functionality and configuration will be strictly field based.

Would be great if fieldgroups/multigroups were exportable so features could export these without manual intervention.

Certainly not suggesting that this is the best way to do it but it does work for now while things get sorted out.

function FEATURE_install() {
  // Add fieldgroups.
  $fieldgroups = array();
  $fieldgroups[] = array(
    'group_type' => 'standard',
    'type_name'  => 'page',
    'group_name' => 'group_images',
    'label'      => 'Images',
    'settings'   => 'a:2:{s:4:"form";a:2:{s:5:"style";s:18:"fieldset_collapsed";s:11:"description";s:0:"";}s:7:"display";a:8:{s:11:"description";s:0:"";s:6:"teaser";a:2:{s:6:"format";s:8:"fieldset";s:7:"exclude";i:0;}s:4:"full";a:2:{s:6:"format";s:8:"fieldset";s:7:"exclude";i:0;}i:4;a:2:{s:6:"format";s:8:"fieldset";s:7:"exclude";i:0;}i:2;a:2:{s:6:"format";s:8:"fieldset";s:7:"exclude";i:0;}i:3;a:2:{s:6:"format";s:8:"fieldset";s:7:"exclude";i:0;}s:5:"token";a:2:{s:6:"format";s:8:"fieldset";s:7:"exclude";i:0;}s:5:"label";s:5:"above";}}',
    'weight'     => -3,
  );

  foreach ($fieldgroups as $fieldgroup) {
    db_query("INSERT INTO {content_group} (group_type, type_name, group_name, label, settings, weight) VALUES ('%s', '%s', '%s', '%s', '%s', %d)",
      $fieldgroup['group_type'],
      $fieldgroup['type_name'],
      $fieldgroup['group_name'],
      $fieldgroup['label'],
      $fieldgroup['settings'],
      $fieldgroup['weight']
    );
  }

  // Place individual fields into fieldgroups.
  $group_fields = array();
  $group_fields[] = array(
    'type_name' => 'page',
    'group_name' => 'group_images',
    'field_name' => 'field_images',
  );
    
  foreach ($group_fields as $group_field) {
    db_query("INSERT INTO {content_group_fields} (type_name, group_name, field_name) VALUES ('%s', '%s', '%s')",
      $group_field['type_name'],
      $group_field['group_name'],
      $group_field['field_name']
    );
  }
}

We won't be implementing any kind of automatic hook_install() scripts for setting up fieldgroups and until there are real exportables here don't expect much from Features. You are certainly welcome to script their creation a la #8 in your feature module though.

This patch tackles this issue in content_features_export, content_features_render, and content_features_rebuild. Using this patch, fieldgroups should work as well as other CCK fields.

This is tested against CCK 6.3 from CVS and supports the new multigroup module, but should work properly with 6.2 stable as well.

I tested the patch, it worked well.

Reviewiing it later.

Patch also worked great for me!

The patch worked for me too, but I had some trouble while updating features.

With this patch, fieldgroups don't get updated at the same time as CCK fields (clearing all caches resets the fieldgroups but not the fields). I haven't taken an in-depth look at the code, but the issue I had was that when I changed fieldgroup weights, they were reverted before the feature was re-exported, thus putting the field and fieldgroup weights out of sync. My quick solution was to update the weights directly in the exported feature.

Patch also worked great for me! Thx!

I'm also having the same problems as #13, patch works but there are some details. The fieldgroup is there but the fields are not inside the fieldgroup, I don't really know how to control this manually with code.

I got the patch to apply to the latest code in CVS (had 1 failure, but was easy to fix). I had 2 fieldgroups set up, 1 had 4 fields in it, the other had 2. When I installed the feature on another setup, I had the 2 fieldsets - one had one field inside it, the other had no fields in it!

Updated patch attached. The difference is in content_features_rebuild(). The bit that does "// Update the group of this field." was not within the foreach loop for the respective field, so only the last field processed would get added to a fieldset. After moving the routine into the foreach loop, all fields are added to the correct fieldset.

Works for me - please test.

Tested and saw no problems. cck_sync module days are getting shorter ;)

I was successfully able to export a fieldgroup and inport it somewhere else with patch #17

Thanks to the patch #17, it works also fine for me with version 6.x-1.0-beta4. Thanks a lot.

I've encountered an issue after applying patch #17: at some point (probably when you have no group) the "$fields['groups']" value is empty within content_features_rebuild(). In such case the $field entry will NOT be unset (line 167 of the patch). Having an empty "groups" field entry present in the list of fields will lead to some side effects: the following for-loop will handle the empty field through content_field_instance_create(). I think that explains the presence of the odd "content_type_" table in my database.

I have just tested out this patch and it applied and worked flawlessly for me. But I have not tried it on content types that have no group as mentioned in #21.

This is still an issue as of the latest beta. I just got bitten by it as well. :-(

Subscribe, i had this problem today with the last version.

Patch #17 seems to have some trouble dealing with features that have multiple content types. I have a feature that has an Author type and a Publication type (in that order). Both have field groups. After applying the patch, I had no trouble getting the Publication field groups to register, but for some reason I had to disable Publication to get the Author field group to register.

I was able to resolve the issue by recreating the feature twice, once with Publication enabled, and once without, merging the changes in my SCM. Obviously, it would be better if I didn't need to do that.

Note: I develop on PHP 5.3.0.

patch in #17 is working for me using beta5, of course, the patch has to be applied to the site where the feature it's being created and the sites where the feature is being used.

I am using beta5 and successfully applied this patch. The exported code seems to contain the fieldgroup definitions but they are not created when enabling/deploying the feature. I tried clearing cache as mentioned in a previous comment.

I have one content type in the feature with several fieldgroups. I export the feature and enable it - groups are not created and it shows up as 'overridden' straight away.

Importing the cck type using content_copy module after enabling the feature recreates the fieldgroups and feature is reported to be in 'default' state again.

This might seem obvious but, do you have features patched on the site you're applying the feature?

Yes, the same patched version of features on both sites.

Subscribe, have the same problem

Assigning to me, am working on a patch now.

whoops

So, here's my stab at this. This patch departs from previous patches in that it separates out all fieldgroup handling into separate hooks and a separate file. IMO, this is a much cleaner approach. Please test it out!

Updated patch fixes translatables.

+subscbribe

Patch looks great. Committed: http://drupal.org/cvs?commit=325370

The component tests should be added next http://drupal.org/node/706950.

Neither beta5 version with #36 patch nor beta6 version work for me..
beta5 version with #17 works fine, anyone else experiencing the same?

tried patching beta 5 with the patch in #34.
patch applies and fieldgroups seem to be exported, however when i enable the feature on a site the fieldgroups do not show on the content types.

See #725132: fieldgroup duplicate entry which is related.

Please don't change the status. Download the dev version for fieldgroup support. Thanks!

6.x-1.0
can't export fieldgroups independently from CCK fields or Node types - they don't show on the list.

i have to export nodes to get the fieldgroups.
the nodes also includes the cck fields.

if i export the cck fields, i don't get the fieldgroups.

and since i can't export some node types (blog, forum, poll, panel, product, product_kit), i don't get to export their fieldgroups AT ALL...

@LPCA, I would open a separate issue for what you're experiencing, as this one is closed. Thanks!

For add ability export fieldgroups independently need add hook_features_export_options into includes/features.fieldgroup.inc:

/**
 * Implementation of hook_features_export_options().
 */
function fieldgroup_features_export_options() {
  $options = array();
  $groups = fieldgroup_groups($type_name);
  foreach (node_get_types('names') as $type => $type_name) {
    $groups = fieldgroup_groups($type);
    if (!empty($groups)) {
      foreach ($groups as $group) {
        $group_name = isset($group['widget']['label']) ? $group['widget']['label'] : $group['group_name'];
        $options[fieldgroup_features_identifier($group)] = "{$type_name}: {$group_name}";
      }
    }
  }
  return $options;
}