The state of the fieldgroup module for Drupal 7

With Drupal 7 getting closer to release and field API, better known as CCK in Drupal 6, in core, the fieldgroup module was still left behind a bit. While Yves Chedemois (yched) was working on making the Field UI extendable from contrib, I started testing and working further on brand new code that was available on github that is destined to become the fieldgroup*1 module for Drupal 7. My colleague Jochen Stals (Stalski) also jumped in and after some internal discussion with Yves, we moved the code into a new project, away from CCK. The new module is available at http://drupal.org/project/field_group. Exciting for sure, but where are we exactly and where are we going?

Fieldgroups are everywhere *2

Every entity (node, user, etc.) in D7 shares the same UI for managing the form and display. This means that fieldgroups are available for your user profile, taxonomy or even your own defined entity. Refreshing also is that the order of fields is separated from the form and display. A fieldgroup can thus be displayed on top of the form and at the bottom of say your node - or not at all, it all depends what and where you want to show your data. Oh, and there's also unlimited nesting.

Formatting

Different formatting options are available: div, collapsible fieldsets and vertical tabs. With the jQuery library in core, it's now much easier to format also in different stylish ways: horizontal tabs and accordion are already supported. People wanting other formats can simply implement a hook to register the format and an output callback function.

Regions and layouts

Since we can output fieldgroups as a div, they can serve as containers to create a multi column layout if the right css is made available. Create nice forms or layouts for easy positioning of elements of a node, user etc. in any view mode (build mode in Drupal 6). People familiar with Display suite know we love such stuff and we're discussing how the two modules can work nicely together. The solution lies in the #region key available in the form and which module will make use of it. There is even a chance that #regions is not even needed at all and can be ditched completely. This could lead to a change in the name of this module to something more abstract like Group.

Obsolete modules

It's not our first goal, but with the power we now have in core, a few modules can be merged or easily replaced by the new version of fieldgroup: CCK fieldgroup tabs and Node form columns are two that come to mind, we probably forgot a few more. We invite maintainers of such modules to help along to bundle forces and share thoughts what steps we need to take. Documentation and guidance are most likely the key factor in succeeding.

Exportables

The module will have full support for exportables and features. Whether we'll write it ourselves or depend on CTools has not been decided yet. Input from both parties are greatly appreciated here. However, when we release, fieldgroups will be able to live in code.

Upgrade path

The upgrade path is the most difficult task. The module has been rewritten from scratch and has a complete new database schema. There is no clear plan at this moment, so input is more than welcome. We can get inspiration from the upgrade path that is partially available from CCK to field API - although at this point a lot of problems are still there.

Multigroups

Multigroups is a concept living in CCK3 (1 and 2), but has had no official release yet to this date. Support in this module is not planned yet for that reason. The code is also a bit hackisch and shouldn't probably live here anyway. Fieldable fields is most likely the answer and belongs in another project. Insights are welcome of course.

Update http://drupal.org/node/939836 is a nice start for discussion around multigroups (Thanks Yched).

Working together

Getting the module out will benefit everyone, so please test, create patches (+ tests), write documentation or record some screencasts. With the new options available to maintain a project, we can give more people access to commit or other responsibilities. Feel free to jump in, the community will appreciate all your hard efforts in making this module a huge success!

*1 There is still an internal debate whether we are going to write 'field group' or 'fieldgroup' as the title of the module or even something else (see Regions and layouts)
*2 persiflage of 'fields are everywhere', taken from the haiku written by Amitaibu for his Organic Groups presentation at Drupalcon Copenhagen.

Comments

Submitted by Stalski on October 25, 2010 - 15:32

Great write-up. Some additional statements to help us

As we have fieldable entities and those fields can be nested in a fieldgroup, then we actually created (field)groupable entities or fieldable grouped entities.

I like "Groups" as well, but this implies that we are planning to group not only fields ... but for instance blocks, views or nodes and that is not the case. So in my opionion we still should have "group" and we need "fields". A group is not a field, and a region is not a field, however a region can be a "group type".

I created the first issue in field_group as well, with a back links here and vice versa:
Field group, field_group or groups ... and what about regions

Submitted by Mark Dorison on October 25, 2010 - 17:34

I think we are facing a chicken vs egg scenario with regard to CCK3/Multigroup. I believe the reason that there has yet to be an official release thus far is because an upgrade path has not been defined.

Submitted by alex_b on October 25, 2010 - 19:45

Great to see movement on field groups. I recommend using CTools' export.inc or - if possible - field API's native configuration management. Either will get you Features integration for free.

Submitted by yched on October 25, 2010 - 20:14

Fieldgroup (adding presentational wrappers around some fields) and Multigroup (combining fields together so that they're associated by delta first) are two completely unrelated things.
Multigroup was heavily tied with fieldgroup in D6 only because it was the simplest way to store 'group' definitions and get a UI.

Multigroups will most likely be implemented as 'fieldable fields' in D7. In short, a *real* field, combining other fields - see http://drupal.org/node/939836 for details. An upgrade path should be doable.

But this will have nothing to do with fieldgroup. Fieldgroup is about fieldsets, tabs, and wizz-bang presentation, not data model.

Submitted by yched on October 25, 2010 - 20:20

Also, note that fieldgroup D7 is not only about "Field API" fields (like in D6 fieldgroup was only about CCK fields), but any 'node' (or entity) addition :
node title (on forms)
poll choices
views_attach views
...
Anything that you can drag-n-drop on the "Manage field" / "Manage display" screens.

+ Huge congrats to Stalski and Swentel for how fast they took the module to whole new grounds !

Submitted by Stalski on October 25, 2010 - 22:42

I totally agree with yched about the two concept being completely different. It's all about definitions. The concept of fieldgroup for D7 is actually nothing more and nothing less than "display of grouped fields". A fieldgroup will not store things and has no other functionality than the grouping.

Submitted by Joachim on February 3, 2011 - 01:07

In D7 node types can be created via node_type_save. Is there also a way to create the fieldgroups programmatically?

Thanks

Submitted by swentel on February 3, 2011 - 09:41

Yes the main function you can use in field group is field_group_save(). Put a dsm() there or so to find out how to create the right format for saving a group.

You are here