Work is under way to refactor D7's Field UI overviews ('Manage Fields', 'Manage display') so that contrib modules (fieldgroup...) can add their rows in the reorderable tables : #616240: Make Field UI screens extensible from contrib - part II.
The patch currently only takes care of the 'Manage fields' screen for now. 'Manage display' will receive the same treatment after the HTML changes in #796658: UI for field formatter settings get in.

Once this lands, fieldgroup D7 will be (at last) possible. Here are a couple thoughts on what a D7 version could be:

- I think this - and the fact that D7 ships with jqUI - would be a great opportunity to centralize 'grouping flavours' in a single super-fieldgroup module in a dedicated project, handling :
- fieldsets
- js tabs
- vertical tabs
- accordions
- ... ?
The base code should be basically the same, it's just a question of generating slightly different render arrays using D7 core features.

- D7's vertical tabs have a way of reorganizing the output without altering the structure of the form / render array (operating in #pre_render or something). Keeping the form structure intact was the main reason why we always "won't fix"ed requests for 'allow non-field elements in groups'.
Using this method for all grouping flavours would allow the module to be a generic, non strictly Field related, module for form / display grouping. Gives another reason to move this out of the 'cck' pack.

- It's also a good occasion (and probably a required preliminary step) to rewrite the module from scratch. Poor old fieldgroup code is roughly 3+ years old, and received little love since then. It's not a complex module, but IIRC, the CRUD code is kind of... perfectible...

I don't plan to work on this myself, so this is actually a call for feedback and volunteers :-).

#46 work.patch879 bytesjpstrikesback
#45 work.patch876 bytesjpstrikesback


Forgot to add : #616240: Make Field UI screens extensible from contrib - part II wires everything needed to support nested grouping on the UI side.

This allows nested 'fieldgroups' in D7 (as long as the fieldgroup module or its successor does the right job at storing and handling the parenting info accordingly, of course)


I would like to recommend this module,, as a grouping flavor as well :)
Works like magic.

Also, if possible, it would be great to add single field storage option also, instead of the default CCK storage, since it is not always efficient to have a separate table with row for each selection in the case of unlimited value storage. For example, recently I needed 100 checkboxes for a field, but my db table would have gotten very big very fast if each selection would have had a row as per the standard CCK storage mechanism. I built a CCK computed field, where selections were stored as comma separated values in the main content type table. Much faster for my needs, and I can save a db admin down the road.

Here it is:


#3 is out of scope, fieldgroup module is only presentational.



Unfortunately I have not the time to take over this, but I do think fieldgroup in d7 should be improved to only touch the rendered array, but not the FAPI structure itself. That way modules don't have to support the original and the fieldgroup altered $form structure. This should be doable by using #pre_render for inserting the groups.

Fieldgroup is the one thing I miss in the Drupal 7, so I want to develop it.
Will start work on this project since monday, 12 July.

I dont exactly understand the bug in #10 but I need fieldgroups in D7 so Im interested in working on it. GAV: have you started to working on it?

I have a question: I was wondering if the fieldgroup could be programmed as a #post_render function that will see what fields are in a group and arrange them into fieldset "group" and add ahah functionality to add new sets of fields when set to multiple values? Or the logic has to go deeper?

Subscribe. One feature request if that's possible here: I would love to be able to place a fieldgroup inside another fieldgroup (for example to place a collapsed fieldset inside a vertical tab on node forms). Also to be able to freely put the title and body fields (and any other field) inside fieldgroups. I guess that's two feature requests.

Nested groups is an obvious requisite for this D7 version, supporting Vertical Tabs kind implies it. The core UI work happening in #616240: Make Field UI screens extensible from contrib - part II has everything needed to support it from a UI point of view.

Supporting non-fields : yes, see the OP (paragrpah starting with "D7's vertical tabs have a way of reorganizing the output..."). And yes, that relies on reshuffling the render array at #pre_render time rather than at alter() time.

Ive started to work on d7 version but Im not that skilled with ahah and javascript that Drupal uses to add new fields, validate them etc, so Ill just make a new field type that I need with multiple fields and use it instead of more flexible multigroup solution. Good luck GAV.

Issue tags:+multigroup fields



Subscribing - I want to start a port of DS (Display Suite) in the next couple of days and with the patches which are already in, it could mean that we can use the CCK screens instead of implementing our own - which we really had to, D6 was a nightmare to extend those screens. I'm pretty hopefull especially in combination with Field API which is way mature now :)

The clue for me is to see if I can get fieldgroups so we can create our 'regions' system again which we have in Display Suite - if that works, the DS module for D7 should become so small and possibly also the only module we should maintain for the complete DS ecosphere of modules. So potentially exciting stuff for us maintainers. I'll start working on a fieldgroup module separatly, we'll see what code comes up :)

@all - The ongoing work on #616240: Make Field UI screens extensible from contrib - part II required me to implement the beginnings of a D7 fieldgroup module, just to make sure that the core patch has everything needed to support fieldgroup UI needs. This initial code takes care of the UI part (inserting fieldgroup rows to the 'Manage display' screens), and is mostly stub code for the rest (CRUD API, display of groups...).
I will post this here when I have a companion core patch ready to post in #616240: Make Field UI screens extensible from contrib - part II.

@swentel : sweet that you should post that :-).
Part of the work in #616240: Make Field UI screens extensible from contrib - part II is precisely to support regions, since with D7's d-n-d reordering on 'Manage display' screens, we now have a 'Hidden' region. While doing so, I'm trying to make it generic enough so that it supports any number of regions, precisely so that DS can plug into the existing screens.

It seems the main difficulty is to determine which form element determines the 'region' (in existing core rows for fields, region is 'hidden' if the value of the 'format type' select dropdown is 'hidden'). Needs to live on both the PHP side (displaying the table correctly) and the JS side (updating the form when a row is dragged to a new region).

I'll report back soon. Meanwhile, it would be great if someone explored a way to display fieldgroups in forms while keeping the $form structure unaltered until render / pre_render phase - like D7 vertical tabs currently do. That would open the way to have fieldsgroups act on any node component instead of only CCK fields in D6 - see the item that starts with "D7's vertical tabs have a way ..." in the OP.

'Meanwhile, it would be great if someone explored a way to display fieldgroups in forms while keeping the $form structure unaltered until render / pre_render phase'

Send me that beginning code and I'll have a look - and I can compore with my beginnings :)

OK, posted my code in
You'll need the core patch in #616240-46: Make Field UI screens extensible from contrib - part II.

For now I followed the D7 trend of not munging words in module names (nodereference D6 => node_reference D7, userreference D6 => user_reference D7, fieldgroup D6 => field_group D7). Not completely sure about that, though, because this complicates/forbids an upgrade path. should use proper _load/_save/etc function names, regardless of whether it stores in db or not.

Renaming of modules should be fine, as long as old names no longer exist, also doesn't forbid an upgrade path. Re: *_reference, I wonder why those aren't simplified and merged into a single "reference field" module.

CRUD API : sure, the current is only a draft, I did nit even intended to make it public that early. Note, though, that as far as the rest of the module is concerned, the one and only useful function is field_group_get_groups(), which is fairly faithful to what it should be in the future.

Re: "*_reference, I wonder why those aren't simplified and merged into a single "reference field" module."
Packaging them into a separate 'reference fields' module is one thing. Actually merging them, i.e being able to abstract out reusable code parts is another job, it just needs someone to sit down in front of the code and dig :-).
Whole different topic though - see #533222: node and user reference fields in D7 - maintainer needed (mainly the 1st posts, and #43 for my latest position to date)

I forked the code into
It has basic storage and CRUD, still needs a lot of work, but it's a start - more commits at the end of the day.
You need the patch in #21 to make the manage display screen work, but it breaks the manage fields screen completely.

Quick update - the code in #21 is working: you can add groups on form & display for every entity - you can also see fieldsets when looking at a node.
Again, lots of stuff todo still and I'm not happy myself about the recursive function right now, although it does the trick nicely.
Let's get this further on, fork away people! :)



yched could we consider, in addition to the standard cck method, an alternative storage for this module whereby the group is stored in a single db field, serialized? This would save some mysql processing required if no search or views is needed on those columns. I have in mind something like this :

re #28: AFAIK, this is what does.
Completely out of scope for fieldgroup module, though. This is only presentational stuff, and doesn't have anything to do with storage.




listening and able to volunteer.

Subscribing. And off to github.

I wanted to try out the current state of this issue. I have a fresh installation with the latest D7 code, including the committed core patch referred to in #33. I then added first yched's and then swentel's field_group modules. In neither case does any option to add a fieldgroup show up on the manage fields screen.

There must be some other patch or configuration step I am missing. I've dug around in the code but can't find it.

OK, found the problem. There is still a 'fieldgroup' module in CCK. Do not make the mistake of enabling that one instead of the substitute. We should either take that out of cvs or get one of these replacements into cvs to avoid confusion. Since that code is not correct, I guess it would be best to remove it from CCK. I'll try to get that done, in the meantime, anyone who tries this out should be warned to remove it (or at least don't accidentally enable it).

Using the latest version of yched's fieldgroup module I get the option to add a fieldgroup on the screen but cannot save it. Ditto with swentel's version.

I have no more time to dig into this now, is there work going on anywhere else that I'm missing?

I think it would be a good idea to move the current git repo's content into CVS, entirely replacing the current fieldgroup module. Middle-term, we might want to consider to separate it back out into, but short-term everyone is going to expect it in the CCK package, so that will be the best place to make it work first.

I agree, plus this way we can file issues against it here to track the progress. I assume yched's module is the one to use, but just checking in case swentel thinks his version might be preferable for some reason.

Yched's version is more up to date, so you need to use that one.

OK, old fieldgroup removed, new one added to cvs.


Lots of activity on this today. That's good to see since we'd like to have this ready to go, too. :-)


new876 bytes

This makes it able to save/list for me.

Just needed the #required attribute set in each ['parent_wrapper']['parent']... to me it seems that if it doesn't indicate it's #required the default should be set as this really a Form API issue?

new879 bytes

oops, tab removed...

Status:Active» Needs review

I'm not having any luck testing this, even with the patch from #46. I've tried using @yched's github as the starting point (not sure where in CVS @KarenS's commit lives) in an otherwise fresh Drupal install, but I get strange behavior adding field groups.

My Drupal version is 7.0-beta1, but I have also tested with HEAD.

First error:
I create a field group. Then, every page view following a page view of the field manage ui (admin/structure/types/manage/page/fields) this error is displayed:

Notice: Undefined index: name in _field_ui_reduce_order() (line 72 of [path-to-drupal-here]/modules/field_ui/

Second error:
Rearrange anything on the field manage ui, then save. The request to save times out, as does any attempt to view the field manage ui.

For reference, here's my Drush make lines for setting up the module:

projects[field_group][type] = module
projects[field_group][download][type] = git
projects[field_group][download][url] =
projects[field_group][patch][] = ""

Got the version from CVS, just in case, same issues.

projects[cck][type] = module
projects[cck][download][type] = cvs
projects[cck][download][module] = contributions/modules/cck
projects[cck][download][revision] = "HEAD"

Does this still require any core patching? I thought the patch @yched's github refers to was already in HEAD (and beta-1?). #616240: Make Field UI screens extensible from contrib - part II

I had no time to look back at this recently, but yes :
- the prerequisite core patch has been included in D7 beta1
- Karen took the github code and committed in the HEAD branch of the CCK module

If you used that drush make file you put the code from git into modules/field_group and then you pulled down cck head which has the module in modules/cck/modules/field_group, which would give you two copies of the file. So start by making sure you actually have the code from cck HEAD, the only code you need. Do not add the code from github to the mix.

I prefer not to completely wipe the github code for now, but I added a warning on the repo description stating that the code now lives in CCK HEAD.

I did wipe the github from my codebase and start over with the CVS code. I didn't check to see if the code is identical or not, but I'm getting the same error. Wouldn't be much use as an update to the bug report if I hadn't removed the github code first. :)

It appears that part of the error I'm seeing is that a new field group erroneously gets all fields (including the "new field" fields) assigned to it as children. I don't have my head wrapped around this code (at all) yet, but the timeout and the children issue suggest it might be an infinite loop or recursion. I'll keep looking at it...


Is there anyone here who can give me a roadmap or some starting point?

I didn't mean when I said "I'll keep looking at it" that people with more experience with the code should just leave me to assess this issue. :) If no one can duplicate it, then I'll assume I'm doing something obviously wrong, but I don't have any reason to suspect that yet.

Unfortunately, the thin response from other developers on this issue (no judgement - I know everyone is busy) makes it seem like I'd be on my own, at least in the short term, in getting this module ready for use, and I just can't take that chance, currently. The project that I'm starting was balanced on a knife's edge between Drupal and a simpler but more easily customized application framework. I've got to be working on building this thing, starting now, so I'm going to be stepping out of this issue, except as a free-time pursuit.

@michaek : i had the error as well and the fix is simple. I 'll provide a patch shortly with updates on this.
at line 162 or so , make sure you have the following:

['#parent_options'][''] = ''; // This is the new line
$table['#parent_options']['_add_new_group'] = t('Add new group');

If this is not set this way, the group name get their own parent name since there is only one option. and that's food for endless loops ;)

In general: i am more working on a way to have fieldgroup formatters in much the same way as field do. As swentel says in the .module file comments, it's very ironic, almost sarcastic that it would just work out of the box when fieldgroups are fields.
In my opinion, i once built a OOP form generator, and the field as we know it was just a leaf in a tree of field components. So if you see it that way, then the only thing that would have to change is that a field is an instance of a FieldComponent where a FieldGroup implements the FieldComponent as well as Iterator. An extra property children does the job.
Since a field and instance is still an array, we could look for a way to have the same pattern with functions. The main problem imho is the word "field", but i could live with the fact that a fieldgroup is a extension of a field.

That's said, i am still following the comments in the .module file and trying to work out a formatter thingy for every module to use and/or alter.

Thanks, @Stalski. I'll give the change in #59 a try!

@michaek :
the bug should be fixed in latest CCK HEAD - the core patch in #936536-7: Missing #empty_option on a couple selects is also required.

Note that the current state of the code is still largely a proof of concept, to make sure that core's Field UI was flexible enough to allow fieldgroup UI in contrib. Not much actually works, and I wouldn't encourage anyone to start developping an actual site on this yet..


Just a status update. Locally i have working now:
- configuration of field group formats
- 3 new hooks to define grouping formatters, create elements of a form and create corresponding summary.
- Added a div next to fieldset in the display form
- Changed the function to render fieldset, div, tabs ... to real theme function delegating from a field_group_render function.

The most difficult part was the row-rerender after selection. The configuration would not change so only form_state could help here. I must say it already rocks.

- create simpletest for the new added features and introduced hooks.

@yched: do you want me to send a patch (i synced yesterday with the head since changes were made there) or upload it immediately here?

Is it correct to assume that the Field Group module is the result of the work here?

Yes. I asked Stalski if he was willing to to take over field_group as a separate D7 module, and he very kindly accepted.

The field_group project at now contains the previous code from CCK HEAD's modules/field_group, along with the work Stalki mentioned in #64.
I'm about to play with it, but the screenshots posted on the project page are simply gorgeous !

I removed the previous state of field_group from CCK HEAD (D6 fieldgroup still lies in CCK, of course), and updated the "D7 status" section on

Jup that's correct. There are still some key main features that need to be added and some newly added bugs worked out.
So there will be a development phase going on but it can easier be followed now on

Status:Needs review» Fixed

Which means we can set this issue to rest :-).

Yay! Thanks so much Stalski, it looks great! And thanks yched for all your work on this :)

Status:Fixed» Closed (fixed)
Issue tags:-multigroup fields

Automatically closed -- issue fixed for 2 weeks with no activity.