LeftRightMinds has sponsored this patch.
It permits to nest fieldgroups defining a hierarchy.

#360 cck-6.x-3.x-fieldgroup_unserialize-2.patch1.34 KBthekevinday
#355 cck-6.x-3.x-nestedfields_formstate-1.patch3.01 KBthekevinday
#347 cck_options-proof_of_concept_version.tgz7.99 KBthekevinday
#344 cck-6.x-3.x-nested_fieldgroups-4.patch143.73 KBthekevinday
#336 cck-6.x-3.x-fieldgroup_unserialize-1.patch1.15 KBthekevinday
#330 cck-6.x-3.x-fieldgroup_typo-1.patch726 bytesthekevinday
#329 cck-6.x-3.x-nested_fieldgroups_shared_groups_fix-1.patch1.9 KBthekevinday
#326 cck-6.x-3.x-nested_fieldgroups-3.patch58.3 KBthekevinday
#326 cck-6.x-2.x-nested_fieldgroups-3.patch47.83 KBthekevinday
#324 cck-6.x-3.x-display_subgroup_save_fixes-2.patch2.53 KBthekevinday
#320 cck-6.x-3.x-display_subgroup_save_fixes-1.patch1.79 KBthekevinday
#315 cck-6.x-2.x-nested_fieldgroup_fix_deep_nesting-1.patch1.18 KBthekevinday
#315 cck-6.x-3.x-nested_fieldgroup_fix_deep_nesting-1.patch1.18 KBthekevinday
#314 cck-6.x-x.x-tabledrag_sticky_fix-2.patch1.28 KBthekevinday
#312 cck-6.x-x.x-tabledrag_sticky_fix-1.patch834 bytesthekevinday
#303 cck-6.x-2.x-nested_fieldgroup-2.patch54.79 KBthekevinday
#303 cck-6.x-2.x-add_multigroups-2.patch110.36 KBthekevinday
#303 cck-6.x-2.x-nested_multigroup-2.patch9.7 KBthekevinday
#303 cck-6.x-2.x-workaround_multigroup_bug-2.patch1.88 KBthekevinday
#303 cck-6.x-3.x-nested_fieldgroups-2.patch55.23 KBthekevinday
#303 cck-6.x-3.x-workaround_multigroup_bug-1.patch1.88 KBthekevinday
#295 cck-6.x-2.6-nested-muligroup-all-inclusive.patch196.95 KBayalon
#293 cck-6.x-2.x-nested_fieldgroup-1.patch45.23 KBthekevinday
#293 cck-6.x-2.x-nested_multigroup-1.patch9.69 KBthekevinday
#272 300084-nested_fieldgroup_1.patch46.12 KBckng
#245 sdf.PNG9.92 KBtijeika
#234 stuck-group-1.jpg101.81 KBSc0tt
#234 stuck-group-2.jpg100.36 KBSc0tt
#234 stuck-group-3.jpg100.3 KBSc0tt
#230 cck.patch47.16 KBrconstantine
#230 cck.tar_.gz434.57 KBrconstantine
#227 cck.patch47.22 KBrconstantine
#227 cck.tar_.gz434.57 KBrconstantine
#219 Nested Field Example 4.png57.64 KBTomSherlock
#219 Nested Field Example 3.png19.32 KBTomSherlock
#219 Nested Field Example 1.png15.67 KBTomSherlock
#208 cck-nested-fieldgroup.patch46.05 KBrconstantine
#206 TwoChanges.tar_.gz23.42 KBrconstantine
#203 Right.jpg970.47 KBrconstantine
#203 Wrong.jpg972 KBrconstantine
#190 Create Product Knowledge Entry.png305.8 KBrconstantine
#190 Create Printer - Printer Inventory.png96.17 KBrconstantine
#187 cck.tar_.gz407.98 KBrconstantine
#186 cck-nested-fieldgroup.patch48.25 KBrconstantine
#178 cck-nested-fieldgroup.patch51.02 KBrconstantine
#175 cck.tar_.gz409.16 KBrconstantine
#156 Picture 74.jpeg92.75 KBsquarecandy
#137 multigroup-adding-value.png324.78 KBRoulion
#134 cck.zip364.13 KBrconstantine
#133 cck.zip731.52 KBrconstantine
#116 cck.zip466.52 KBrconstantine
#113 nestedfield-multigroup.png335.13 KBRoulion
#110 cck.patch200.09 KBrconstantine
#109 cck.zip466.5 KBrconstantine
#108 Page.png29.07 KBrconstantine
#99 cck.zip1012.45 KBrconstantine
#97 cck.zip1012.45 KBrconstantine
#85 cck.zip1011.85 KBrconstantine
#80 cck.zip1011.45 KBrconstantine
#75 Test.png37.83 KBrconstantine
#71 cck.patch44.94 KBrconstantine
#66 cck.patch44.79 KBrconstantine
#68 monster content type - incomplete.png599.05 KBrconstantine
#65 cck.patch39.98 KBrconstantine
#62 nested_fieldgroup-300084-62.patch42.16 KBmarkus_petrux
#60 nested_fieldgroup-300084-60.patch41.49 KBmarkus_petrux
#56 content.node_form.inc_.zip4.75 KBrconstantine
#49 cck.patch43.2 KBrconstantine
#48 cck.zip994.11 KBrconstantine
#42 Test application - before.png131.25 KBrconstantine
#42 Test application - after.png118.17 KBrconstantine
#36 Test1.png140.85 KBrconstantine
#35 cck.zip433.84 KBrconstantine
#32 cck.zip444.26 KBrconstantine
#22 fieldgroup.tabledrag.js_.txt1.4 KBmarkus_petrux
#20 content.admin_.inc_.diff4.85 KBrconstantine
#20 fieldgroup.module.diff20.3 KBrconstantine
#17 content.admin_.inc_.diff4.47 KBrconstantine
#17 content_copy.module.diff589 bytesrconstantine
#17 fieldgroup.install.diff20.59 KBrconstantine
#17 fieldgroup.module.diff19.39 KBrconstantine
#17 tabledrag.js_.diff709 bytesrconstantine
#17 theme.inc_.diff771 bytesrconstantine
#11 ScreenHunter_01 Dec. 17 10.13.jpg117.05 KBrconstantine
fieldgroup.module.patch11.79 KBRoberto Gerola
fieldgroup.install.patch1.29 KBRoberto Gerola
Members fund testing for the Drupal project. Drupal Association Learn more


perarnet’s picture

Anyone know if there is progress on nested multigroup (adding a multigroup within an existing multigroup)?

Rconstantin mentions:

No nested multigroups. That's an issue with multigroups. If you find the original multigroups thread, you'll see where that is discussed.
That would be something to tackle after this patch goes in.

Anyone know where to find the original multigroups thread?

rconstantine’s picture

the tabledrag.js file is essential to the correct operation of the patch and can be found in one of my previous tars. it was what prevented the crazy behaviors which recent bug reports have been complaining about. as you all can see, after 7 months or so of work trying to get this patch in, i gave up. it has now been over 15 months with little progress. i was intending to revisit this issue once D7 and whatever accompanying CCK comes out, but i'm glad that some have taken this up where i left off and that there is still quite a bit of demand for this.

i haven't yet looked at the current state of the code, but i can assure you that with the version that i'm running, the recently mentioned bugs do not exist. moving fields from one subgroup to another, or out to the top level works as it should. changing field names works as it should, etc. in fact, the only strange behavior in my version is that you cannot move an item to the very top of the list, but you can move the top item down. there were reasons for that in the js file. i have created literally dozens of sites and dozens of content types including one with 230+ fields using fieldgroup tabs, nested fieldgroups, and multigroups - which was the reason for the work i did in the first place.

additionally, filefield and imagefield were known issues. they modify the node's data structure and expect those fields to be top-level items. the modules don't know what to do (since they use AHAH) when the fields are nested. the two new hooks i had implemented (which it sounds like may still be there but modified?) would have solved this issue. that is, IIRC. i also think that my changes to the js positively affected the AHAH from those two modules as well - i.e. they wouldn't have needed their own override functions. in fact, i might even be running an modified filefield module on that 230+ field site. i'd have to check. by the way, the hook addition also affected the multigroup module! so i hope that the new patches that have been rolled are also patching multigroup.

another thing - as someone pointed out, there IS a change to the DB that this patch should be making. when i rolled the patch in the first place, i had set the name of the update function in the .install file correctly. if 3.x has moved on, perhaps the name needs to reflect a higher number so that the change is correctly made on existing systems.

regarding nested multigroups - as quoted in #301, that was discussed here: http://drupal.org/node/119102 somewhere. the problem is both conceptual and technical. conceptually, multigroups are like fields. for example, an address should be one 'field' but made up of smaller parts. i'm not sure that people have really come up with many example use cases for having one multigroup inside of another. here is one, but it isn't necessary: if you make a multigroup called "contact" and then place "address" multigroups inside - where you would then possibly have more than one contact, each with more than one address on a given node, then i'd say there might be a problem with the site design. one way to get around this would be to create a "contact" content type which just has the "address" multigroup, and then to use nodereference with "multiple" set greater than one to have more than one contact on that node. technically, you're talking about big changes to the database and the way that cck keeps track of multiples both in storage and via both server and client code. there would be a particular headache getting the AHAH to work right.

although i haven't been able to do as much on d.o as i would like to these past months (see my neglected modules as evidence) i still very much use drupal daily. if i can ever get more help in my department, then i'm sure i'll be able to get time to again return to contributing here, which is something i very much enjoy. until then, good luck with keeping this patch going. i think it's important and enhances cck far more than some of the changes that HAVE gone in this past year. i hope these comments were helpful.


thekevinday’s picture

Okay, thanks rconstantine for letting me know where to get that file.

I have tested with the mentioned file and the bugs I mentioned do go away.
I have rebuilt the patches I previously submitted to include the missing file.

There are a number of people who may not want multigroup support added and in their favor I am still breaking up the patches.
However, to save people like ayalon time and effort, I will upload every patch I have that completely gets fieldgroups+multigroups working without flaw under CCK-2.
(The only issue multigroups has is that it is not quite views compatible. Other than views integration, multigroups seems quite stable under cck-2)

The order of the patches are important and are explained below.

Patch Order for cck-2:

  1. 2.x-nested_fieldgroup-2
  2. 2.x-add_multigroups-2
  3. 2.x-nested_multigroup-2
  4. 2.x-workaround_multigroup_bug-2

Step 1 adds nested fieldgroup support.
If you do not want multigroup support, you can stop there.

Step 2 adds the entire multigroup from cck-3-dev to cck-2.

Step 3 adds nested multigroup support to the newly added multigroup module

Step 4 adds a workaround for a bug that I found where multigroup fields don't get saved to the database

Applying nested fieldgroup patches to CCK-3 is even easier:

  1. 3.x-nested_fieldgroups-2
  2. 3.x-workaround_multigroup_bug-1
perarnet’s picture


Is there a big hurdle to get nested multigroups to function under 3.x?

thekevinday’s picture

Status: Needs review » Needs work

I found a bug introduced by the tabledrag.js file.

When dragging a row to the topmost position of the root of the table, the row will not 'drop' in place.
The row gets "stuck" on the mouse and will not drop at that point unless somewhere other than the topmost position is placed.

That depends on what you are asking when you mentioned nested multigroups.
- I would say that multigroups current lack of (active) development is a big hurdle, but that is probably not what you are asking.
- If you simply are asking if nested fieldgroups works with multigroups, then there is no hurdle as multigroups works fine (with one major exception).
- If by nested multigroups, your are specifically talking about multigroups nested within multigroups, then yes. (this is the major exception).

I am going to assume multigroup nested multigroups is what you are asking about.
As far as I can tell, the problem seems to be that CCK was not designed in a way that will allow for this to work properly.

To properly support multigroup nested multigroups would require a significant redisgn (if not complete).
And I do not refer to what is going on in CCK-3.
This is a problem all the way down to the database level.

However, do not put too much credit to my words. I am not a CCK developer and I have only jumped into this fieldgroups/multigroups rather late in the game.
There is still quite a lot about how CCK works internally that I do not know.

perarnet’s picture


Yes, I did mean multigroups nested within multigroups. I misread your last post, believing you had solved this for 2.x. Guess I'll have to figure out other ways to solve my problems.

rconstantine’s picture

@thekevinday - The row getting "stuck" is what I was talking about when I said that "in fact, the only strange behavior in my version is that you cannot move an item to the very top of the list, but you can move the top item down." I think you can also click once stuck to unstick yourself - at least if you move that item you tried to move to the top back down to at least the 2nd spot.

SO - unless someone can fix that bug, the workaround is to 1) move the item you want at the top into position #2 2) move the top item down to position #2 which will bump the desired item into position #1.

@perarnet - that feature would require rewriting many, many cck functions and would also require a significant rework of the cck database tables as well. i believe i linked to the previous discussion which touched on the difficulties. in the very least, with so much moving into core for D7, it would be a huge waste of time to do it now.

silurius’s picture


miro_dietiker’s picture


emilyf’s picture

thanks @thekevinday patch for 6.x-2 fieldgroup only seems to work great!

emilyf’s picture

hmmmm, i guess i spoke a little too soon. first patch from http://drupal.org/node/300084#comment-2930694 works well with one issue. if you drag a fieldgroup inside another fieldgroup, save the manage fields page, but THEN you edit that nested fieldgroup, it bumps it back out of the other fieldgroup. so if i save it like this:

fieldgroup 1
------fieldgroup 2

and then i edit fieldgroup2, the next page it bumps it back to this:

thekevinday’s picture

The solution to the bug mentioned in #307, #305, and on the other posts seems to be the following.

Only line 53 of fieldgroup.tabledrag.js, the following exists:
if (siblingIndent == indents) {

What I am thinking is happening here is that when at the root level siblingIndent = NULL (or 0?) and indents may be set to NULL (or 0?) as well.
The root level does not indent siblings if I remember correctly.

So I decided to try changing the mentioned line of code to the following:
if (siblingIndent == indents && newGroupName != "top") {

With this change in place, the drag+drop no longer sticks at the top level.

Please Review, I am confident that this works but not confident that this is the most correct solution nor am I confident that this does not produce any regressions.

This patch goes on top of the nested_fieldgroup patch from #303

zeno129’s picture

I used the patches in #303 for cck 3 and I also used the patch in #312.

But there seems to be a problem with the patch in #312:
After patching the js file, whenever I "manage fields" in a content type, I re-order them and click save the fields get all disorganized and placed in (what seems to me like) random positions.

Field 1
Field 2
Field 3
Field 4

I click save and:

Field 3
Field 2
Field 1
Field 4

I think the problem is with the js patch because when I reverted it and tried to do the same changes, it worked fine.

thekevinday’s picture

Thanks for the help.
I have been able to close in on the problem.

For some reason, when at the root level of the table, dragging the row to the very top will result in siblingWeightFieldUp[0] being undefined.
Because this value is undefined, the code: siblingWeightFieldUp[0].value will fail.
When javascript fails, it just stops executing the remaining code and silently exits.
Because javascript suddenly terminates, the row gets stuck on the mouse.

The solution is to prevent this case from happening by doing an is undefined check:
The code:

    var siblingWeightFieldUp = $('input.field-weight', siblingRowUp);
    var siblingWeightUp = siblingWeightFieldUp[0].value;
    var newWeight = parseInt(siblingWeightUp) + 1;
    $('input.field-weight', tableDragObject.rowObject.element).val(newWeight);

Should now be:

    var siblingWeightFieldUp = $('input.field-weight', siblingRowUp);
    if (siblingWeightFieldUp[0] != undefined){
      var siblingWeightUp = siblingWeightFieldUp[0].value;
      var newWeight = parseInt(siblingWeightUp) + 1;
      $('input.field-weight', tableDragObject.rowObject.element).val(newWeight);

The attached patch does this.
Use this instead of the patch from #312

I am confident this is the correct fix and should not cause any regressions.

thekevinday’s picture

I have identified a problem with deeply nested fieldgroups.
This problem may be the same problem mentioned here: #311 and probably somewhere else amongst the 300 other posts for this issue.

The problem is that when a fieldgroup is nested within a fieldgroup, it gets pulled to the root of the table and placed at the top.
This was due to a logic flaw in the code.

The logic flaw are these lines here:

$dummy[$parent][$name] = $dummy[$name];

Ultimately, this code removes a nested fieldgroup from the root of the table.
When a fieldgroup is nested within a fieldgroup, the parent fieldgroup may have already been removed from the root of the table.
The end result is unexpected behavior.

The fix is attached.

Please apply this after applying patches from:
#303 and #314

klonos’s picture


thekevinday’s picture

Status: Needs work » Needs review

Follow patches from #303, #314, and #315.
Please review this, I have not found any new nested fieldgroup specific bugs.

As far as the detailed information from #302 is concerned:
Modules that assume the structure of fieldgroups are bugs with that module+fieldgroup and not fieldgroup itself and should be left to the other module to correct itself (Unless otherwise proven to be caused by a fieldgroup bug).

This module seems to work fine under the 2.x series without multigroups added.

I do not see any reason why nested fieldgroups should be held back by a module that is not even released.
Nested fieldgroups does not depend on multigroups.

Please consider the patches thus far (and perhaps any needed database changes that were mentioned in #302) for applying to 2.x stable.
Considering the sheer size of this issue and the number of claimed usages in #302, nested fieldgroup is well ready to be considered to be merged into stable.

rfoster’s picture

Status: Needs review » Needs work

I found a bug so I set the status back to needs work.

On the display fields tab ( admin/content/node-type/[your-content-type-here]/display ), changes made to any drop downs in a "[Subgroup format]" row do not save after applying the patch cck-6.x-3.x-nested_fieldgroups-2.patch (from #303). This should only affect people who are using multigroups since these options are specific to multigroups.

Thanks for all of your great work thekevenday!

rfoster’s picture

(removed duplicate comment)

thekevinday’s picture

Well, I looked into and here is my explanation of the problem and the patch to fix it.

The display submit function attempts to save the subgroup settings on its own by manually calling: fieldgroup_save_group().
The fieldgroup module also calls fieldgroup_save_group() via the fieldgroup_display_overview_form_submit() function.

The end result of this is that two calls get made that write to the database.
The first call will contain the subgroup settings information.
The second call will not contain the subgroup settings information and overwrite the existing saved information.
The subgroup settings information at this point is non-existent.

There is then a second problem, this time with the display loading code.
(This may be caused by my solution to the first problem).
The display code looks for the saved subgroup data in: <?php $group['settings']['multigroup']['subgroup'] ?>
However, the subgroup data is actually stored here: <?php $group['settings']['display']['settings']['multigroup']['subgroup'] ?>

The patch solves both cases.
The patch prevents two calls from being made and so also provides a slight performance gain (probably unnoticeable).

This might be a multigroup bug with fieldgroups, but considering that this bug is reported to appear after the fieldgroup patch, I am reporting it here.

The attached patch does work against the cck-2.x version as well as the cck-3.x.

jvieille’s picture

That's a lot of patching!
(I never succeeded patching with Tortoise...)
Would it be possible to get the modified files full cooked to try this really important feature?

Thanks in advance

rfoster’s picture

Thanks for the quick response. I tried the patch in #320 but it actually made the problem more complicated, so it is better without the patch. This is what I found:

1) I can now change the "Subgroup format" settings, and the settings are saved and reloaded. However, these settings have no impact on how the form is displayed!

2) I had a "Subgroup format" that was set to display as "Table - multiple columns" (I reversed the patch in #303 to set this, and then reapplied it). After applying the patch in #320, that content type still displays the data in a table, but on the "Display fields" tab it says that the display is set to "Fieldset" (the default option). As with #1, I can change these settings any way I want, and it does not change how the fields are displayed.

So it looks like the latest patch is saving and loading extra data (in the wrong location or format), separate from the data that actually affects the display of the fields. Before applying the patch, loading the settings worked fine. It was just impossible to make any changes to those settings.

ndm’s picture

subscribe for a stable solution

thekevinday’s picture

Status: Needs work » Needs review
2.53 KB

It turns out that the <?php fieldgroup_display_overview_form_submit() ?> function forcefully moves all fields from settings into display->settings.
That explains the second bug I mentioned in #320.

This problem can be fixed by specifically looking for the multigroup data and preventing the data from ending up in display->settings.
With this done, the fix for the second bug in #320 has been reverted/removed and the problems mentioned in #322 are gone.

Please Review and let me know if I blew anything else up with this patch.

rfoster’s picture

Appears to be working fine now with the latest patch. I'll report back if I discover anything later. Thanks!

thekevinday’s picture

Then here is a combined patch to make peoples lives easier.

This is a combined patch from the following patches:
cck-6.x-3.x-nested_fieldgroups-2.patch from http://drupal.org/comment/reply/300084?page=1#comment-2930694
cck-6.x-x.x-tabledrag_sticky_fix-2.patch from http://drupal.org/comment/reply/300084?page=1#comment-3005354
cck-6.x-3.x-nested_fieldgroup_fix_deep_nesting-1.patch from http://drupal.org/comment/reply/300084?page=1#comment-3042808
cck-6.x-3.x-display_subgroup_save_fixes-2.patch from http://drupal.org/comment/reply/300084?page=1#comment-3073766

The multigroup patch found here: http://drupal.org/node/300084?page=1#comment-2930694 still needs to be applied.

The cck-2.x patch does not provide multigroup nor does it patch multigroup.

rfoster’s picture

Status: Needs review » Needs work

OK, I found another bug that I traced back to this patch. I am getting some SQL duplicate key errors on inserts and updates to the table d_content_group_fields. I think this only affects users who are sharing groups across content types. If you aren't doing that, then you may never have this problem.

So this is what I did. I created a complex content type with lots of nested groups. Then I exported the content type, renamed the original, and then reimported it. So I have a content type called 'firewall' and an identical content type called 'xyz.' Then if I delete a group in one of these, it actually tries to make updates to the other content type too, since some of the queries are not specific enough.

One query is the last query in this function:

function fieldgroup_remove_group_submit($form, &$form_state) {
  $form_values = $form_state['values'];
  $content_type = $form['#content_type'];
  $group_name = $form['#group_name'];
  $parent_group_name = db_fetch_array(db_query("SELECT parent_group_name FROM {". fieldgroup_tablename() ."} WHERE group_name = '%s' and type_name = '%s'", $group_name, $content_type['type']));
  $result = db_query("UPDATE {". fieldgroup_tablename() ."} SET parent_group_name = '%s' WHERE parent_group_name = '%s'", $parent_group_name['parent_group_name'], $group_name);
  $result = db_query("UPDATE {". fieldgroup_fields_tablename() ."} SET group_name = '%s' WHERE group_name = '%s'", $parent_group_name['parent_group_name'], $group_name);
  fieldgroup_delete($content_type['type'], $group_name);
  drupal_set_message(t('The group %group_name has been removed.', array('%group_name' => $group_name)));
  $form_state['redirect'] = 'admin/content/node-type/'. $content_type['url_str'] .'/fields';

Need to add AND content_type = ... to the WHERE clause.

As for the duplicate key error on inserts I didn't make a note of the line number, so I'll have to wait until it pops up again...

rfoster’s picture

Some more notes:
I had a field 'field_other' in both content types. I deleted this field from type 'firewall.' Then I geleted the parent of that field, group 'group_other_tab' from the firewall type, and I got this error:

user warning: Duplicate entry 'xyz--field_other' for key 1 query: UPDATE d_content_group_fields SET group_name = '' WHERE group_name = 'group_other_tab' in [omitted]/sites/all/modules/cck/modules/fieldgroup/fieldgroup.module on line 216.
thekevinday’s picture

Status: Needs work » Needs review
1.9 KB

I tried what was explained in #327.

I did not get the duplicate key error and was able to delete one group, and the other did not get deleted.
The group did have one of its entries deleted from the content_group_fields table.

What confuses me is this concept of sharing groups, I am unclear as to what you are saying.
Do you have a third party module that enables sharing groups between content types?
Or are you simply talking about groups sharing the same system name between different content types?

Either way, I have made a patch that applies your fix where I found the problems.
This patch is against cck-3, but still applies against cck-2.

thekevinday’s picture

Out of pure chance as I was looking at the cck code I noticed the following inside the fieldgroup.module in the fieldgroup_nodeapi() function:

         $fields = $node->content;
         if (!empty($fields)) {
           foreach ($fields as $name => $more) {
            if (is_string($fields) && strstr($fields, 'field_')) {
               $field_rows[] = $name;

That seems odd to me, shouldn't <?php if (is_string($fields) && strstr($fields, 'field_')) { ?> instead be: <?php if (is_string($name) && strstr($name, 'field_')) { ?>?

I seem to have overlooked the typo at #282.

rfoster’s picture

I've been experiencing another problem that I finally discovered is related to the combination of multigroup + nested field groups.

If I have a structure like this:

Standard group
      text field using select list widget

then I can't delete rows in the multigroup if a value is set in the dropdown. I can delete the rows by clearing the value of the dropdown, but I cannot delete them using the normal row delete button--when the form is saved the rows don't delete (and data in other fields can get saved in the wrong row as a result).

If I move the multigroup out of the standard group everything works fine.

I'm using a the latest available version of cck-6.x-3.x-dev with these patches applied:

thekevinday’s picture

I can reproduce your problem in #331.

It seems that the data gets cleared out but the existence of the row does not.

I have also noticed that Required Fields do not work correctly in a similar manner.

The problem happens on line 402, which immediately follows the added code from my patch: workaround_multigroup_bug-1
Which, ironically, works around a data saving problem.

This means that either the workaround fixes the node create and breaks the node edit or there is more to this bug than I first realized.
This will take some time to debug.


Update on the mentioned problems:
1) Fields that violate the standard definition of "multiple values" (such as radio buttons/checkboxes and select lists) do not work properly because they do not properly use "multiple values".
- This also breaks the required fields for such problematic fields
- The solution to this is to replace the existing radio buttons/checkboxes and select list functionality with new versions that do things properly.
- I intend to do this and will open of a separate thread when I am done.
2) The delete does seem to work, but all fields passed the first do not get saved.
- Still being investigated
3) The _remove array value does not get stored twice, example:

FORM STATE group_test_00001_00002 = 
  Array (
    [0] => Array (
      [field_test_00001_00002] => Array ( [_remove] => ) [_weight] => 0 [_remove] => 0
      [field_test_00001_00003] => Array ( [value] => 3 [_error_element] => group_test_00001_00002][0][field_test_00001_00003][value )
    [1] => Array (
      [field_test_00001_00002] => Array ( [_remove] => ) [_weight] => 1 [_remove] => 0
      [field_test_00001_00003] => Array ( [value] => 7 [_error_element] => group_test_00001_00002][1][field_test_00001_00003][value )
    [2] => Array (
      [field_test_00001_00002] => Array ( [_remove] => ) [_weight] => 2 [_remove] => 1
      [field_test_00001_00003] => Array ( [value] => 8 [_error_element] => group_test_00001_00002][2][field_test_00001_00003][value )

- Still being investigated
4) As seen in the above example the _remove field only gets placed in the first field
- Is this a bug?

zeezhao’s picture


thekevinday’s picture

The problem seems to be that for some reason the fields multiple value do not get set when the field is moved into the multigroup.
The end result is that the database table that handles multiple values is missing.

As a temporary fix, until a patch can be made, drag all fields out of the multigroup, set those fields to have the desired number (or unlimited), and then drag those fields back into the multigroup. Once this was done for all fields in a given multigroup, everything seemed to work fine for me.

zeezhao’s picture

Hi. Thanks for all your efforts in producing this module and its fixes.

Please, in order to get all the right/latest patches, could you post your fully patched cck 3.x with the nested fieldgroup? This will be much appreciated. It would mean that someone like me can just install the whole module. Thanks for your help.

thekevinday’s picture

I have found the proper solution to the bug mentioned at #331 and #332.

Heres what happens.
The nested fieldgroup patch manually performs a db_query instead of calling the pre-defined CCK query functions.
This is because this query is doing an INNER JOIN from its own private table with the CCK table.

Some of this queried data is serialized but fieldgroups does not unserialize the data.
What this means is that much of the field data, such as widget_settings, display_settings, etc.. is unparsable.
The result is that the field settings are never used and a bunch of weird things happen.
In particular, the mentioned fieldgroup+multigroup bug happens.

The solution is simple, unserialize the data when retrieved.
The attached patch does just that.

Now here is the thing.
The field data was never being used so expect this patch to reveal bugs that have been sitting around for a long time, unnoticed.
In particular, I have noticed that when the multigroup is set to something like 9, instead of unlimited, the fields do not properly save.
Also, I need to research if this patch is the real solution to the multigroup_workaround patch I created.

Please review this patch and report all new bugs that appear.
Once this is done, and once I have confirmed whether or not the multigroup_workaround patch can be removed, I will then make a new cumulative patch that has all of the existing patches applied.

zeezhao’s picture

Hi. Thanks for the new patch in #336. I tried it out but I am still unable to delete a row as in #331 in a multigroup. In my case the dropdown contains a list of users. It deletes the other fields but not the userlist, so the row still remains.

I am using latest cck-6.x-3.x-dev with these patches applied:

Please let me know if I am missing anything. Thanks.

thekevinday’s picture

The way in which CCK dropdowns are designed, they will not work.

A replacement dropdown solution will have to be written.

The problem is that the developers decided that instead of creating new options for drop downs (aka select lists) they would recycle existing fields that they thought would not be used.

In this particular case, the Multiple Values feature that CCK provides is recycled to represent whether or not the drop down is a single select or multi select drop down.

Any module that re-defines the "Multiple Values" settings for its own use will likely break.

zeezhao’s picture

Thanks for your reply. Not sure I fully understand it though...

The user list I referred to is acutally a "User reference" field in cck.

Are you saying that this can also happen for any select list of any other cck field type e.g. "Text"? Not tried that yet.

Please what do you recommend I do to solve this?

Once again, thanks for you help and efforts.

Forgot to mention that the only way to delete the rows, is to set the lists to "None" option, and then remove the rows, and then save again.

zeezhao’s picture

@thekevinday - as a continuation of my earlier post #339, one way to ensure the rows get deleted is to set the values of any dropdown lists to "None" before doing the delete. Maybe if this could be done automatically in the code, then the rows can get deleted. Please let me know your thoughts on this workaround. Thanks for your help.

zeezhao’s picture

Title: Nested fieldgroup » Nested fieldgroup - order of fields when viewing the node is different from order in edit form
Category: feature » bug

Another thing I just noticed after applying the patch is that - the order of fields when viewing the node is different from order in edit form, for some of my fields... Is this a known bug, or is there a patch I am missing? Thanks.

edit: This happens after applying cck-6.x-3.x-fieldgroup_unserialize-1.patch

zeezhao’s picture

Title: Nested fieldgroup - order of fields when viewing the node is different from order in edit form » Nested fieldgroup

Sorry. Mistakenly changed title.

thekevinday’s picture

At this point the problems I am seeing are slightly different than the ones you two are seeing in: #339 and #340.

What version of cck-3-dev are you using?
Mine is: June 18, 2010 (2010-06-18), with a datestamp of 1276862557

The developer has been doing a good job of updating cck-3-dev when cck-2 gets updated and there has since been a recent update.

What specific module, fields, and widgets are you using that have this problem?
I have been doing most of my tests with text field and widget types of 'text field', 'select list', and 'check boxes / radio buttons'
(Note: text (space) field is referring to the field type that is called 'text' and 'text field' is referring to the widget type called 'text field')
I also have conditional fields-2.x module in use.

As far as #339s question/
This happens for every select list (including the cck core select list) that changes how the "Multiple Values" works.
By 'Multiple Values' I am referring to the global setting that says: 'Number of values: ' and has a number of options from 1 to 10 and also unlimited.
This should not appear for fields inside a multigroup but should appear for fields outside a multigroup.

Outside of a multigroup if the value for some text field was changed from 1 to 5 there should be 5 of those fields.
For example, a text field with a widget type of 'text field' will have 5 separate text field input boxes.
However, a text field with a widget of 'select list' will have a single select list that shows 5 options at a time.
Instead it *should* show 5 separate select field input boxes.

This is a multigroup problem that appears to expand into nested fieldgroups when use in conjunction with multigroup.
This is what I am currently thinking is causing the problem with #339, #340, and my problem.

Now, for #340.
The problem I am having is that for my select lists, they are always set to -none- when editing a node (even if set otherwise).
Do the proper values show up in the select list when you edit your node?

To try and reproduce your problem, I tried changing my select list value to a non-none- value and then deleting that row.
The delete worked, but with the following warning:
warning: Invalid argument supplied for foreach() in sites/all/modules/cck/modules/content_multigroup/content_multigroup.node_form.inc on line 401.

The challenge now is to figure out why we are having different results.
There may be a 3rd party module causing the difference.

My Full list of modules at this time is:
cck_accessibility (written by me)
cck_label_field (written by me)
privileged_cck (written by me)

and i almost forgot, #341 sounds like a new problem to me.

thekevinday’s picture

At the request of a few here is a new patch will all of the ones before it rolled into one.

This includes these patches:

bleen’s picture


zeezhao’s picture

@thekevinday - thanks for your reply. To answer your questions in #343

- using same cck as you i.e. 6.x-3.x-dev of 2010-06-18

- the main reason for me using the nested patch, is to have 2 or more multigroups within a standard group.

- I am using "user reference" select-list, "text" select-list, "date", "text" field, all within a multigroup that sits within a standard group. In fact there are 2 multigroups within this standard group.

- The fields in the select lists show up as normal during edit, and can be selected and saved without any issues.

- Issue seen so far is with the "user reference" select list, and "text" select list, when I try to delete rows in a multigroup. Everything else gets cleared but these fields. Hence the rows remain undeleted. This is the main issue I am seeing.

- One workaround my issue, is to make all the multigroups to be of fixed "Number of repeats", so that user can not delete the rows anyway, and will always have to clear the fields. When this is done, multigroup disables its row-delete icon.

- when I add the cck-6.x-3.x-fieldgroup_unserialize-1.patch, it shows fields in random order when in node view mode, so I backed this out.

- All my "multi value" fields are within a multigroup i.e. multigroup can have unlimited sets of the data. So I do not have multi-value fields in a normal standard group or nested.

- modules - using many..... and a few custom ones. The standard ones are:

acl                        menu_editor
admin_menu                 messaging
advanced_help              nice_menus
autoload                   node_agreement
button_field               node_clone
calendar                   node_gallery
captcha                    node_import
casetracker                nodeformsettings
casetracker_notifications  nodehierarchy
cck                        notifications
cck_fieldgroup_tabs        pathauto
chart                      preview
charts_graphs              print
computed_field             privatemsg
content_access             querypath
content_taxonomy           quiz
customreports              rsvp
date                       rules
devel                      simplemenu
extended_ldapgroups        stringoverrides
faq                        swftools
filefield                  tabs
flashnode                  taxonomy_csv
format_number              taxonomy_manager
formatted_number           taxonomy_vtn
formfilter                 token
hierarchical_select        tooltips
imageapi                   transliteration
imagecache                 user_import
imagefield                 views
jquery_countdown           views_bonus
jquery_update              views_bulk_operations
ldap_integration           views_calc
ldap_provisioning          views_charts
ldaphelp                   views_groupby

Hence so far, it works well apart from the delete issue I have. Will be doing more testing over the weekend.

thekevinday’s picture

Here is a proof of concept select list replacement.
I took the entire optionswidget module and started stripping out the problems I mentioned in #338 and I also think in #343.

This module will be called cck_options.
This module is incomplete and the only widget I have working this far is "Drop Down - Single".
I am using "Drop Down" instead of "Select List" to avoid conflicting with the current Optionswidgets module. (I would rather use Select List to be consistent but that would be confusing at this time).

For any field in which you use the Select List widget, replace it with this modules "Drop Down - Single" and tell me what happens.

And as a reminder this module is woefully incomplete, use it only for testing purposes at this time.

seworthi’s picture

@thekevinday - Thanks for so much work on this.

I installed #344's patch on the 6.x-3.x-dev of 2010-06-18.

I have a std group, with 2 multi groups in side of it. In one multigroup I have file uploads, and the other has image uploads (using the latest 3.7 version's of filefield and imagefield module).

If I try to add a new item to either group, after hitting the upload button, the field disappear. The other fields remain, just the one I tried to add. The file is uploaded to the server. I can delete existing fields fine, and saving the node w/o doing anything work and the items are still there.

Has anyone else experiencing this?

klonos’s picture

@thekevinday: I've been monitoring all related issues (fieldgroup/multigroup) and I see you've been doing a great job trying to clear things up. Thank you for all the effort and time spent on this. It's really appreciated!

I like what you've done in #344 and the idea to have all related patches bundled so people apply them in one go. This will simplify the process and hopefully bring more testers, but the greatest thing about it is that all testers will have a common ground when giving feedback. That is they will have all patches applied and maintainers won't have to repeat the procedure of asking reporters to make sure and then point them to any missing (or perhaps outdated) patches.

This whole thing is great for checking any issues that might arise along the way of trying to get fieldgroup and multigroup committed and detect if one's changes get in the way of the other. But still, posting patches in issues should be limited to those patches meant for each specific issue. How about we open a new issue that simply holds only 'cumulative' patches? This issue should be updated with feedback only by people that have applied all patches in regard. I mean, right now you risk people reporting back issues that might be caused by the multigroup patch and they should be posting these kind of issues there and not here.

What say you?

thekevinday’s picture

That would make life easier.
The other reason I post the partial patches are so that any screw-ups are more easily found by people and can be more easily pointed out.

This issue was rather overwhelming when I joined in and I just had to figure things out as I went. I can only imagine how much more difficult it is to follow for any people joining 100 posts later.

You can find the cumulative patch issue here: http://drupal.org/node/849420
I re-diffed the -4 patch because I accidentally included a few .orig files.

ianchan’s picture


ayalon’s picture

Hi thekevinday!

I was able to insert nested field groups into the database:

Example with 3 fields.
Title Surename Lastname
Mr Peter Black
Mrs Emily Lafontaine

But the big question is, how to displaxy these fields in a view!
It's not possible to output these fields in a logical way, f.ex. a line for each person.

Mr Peter Black
Mrs Emily Lafontaine

How did you manage this problem?

thekevinday’s picture

I believe you should look into custom_formatters: http://drupal.org/project/custom_formatters
Or contemplate: http://drupal.org/project/contemplate

With custom_formatters being the simpler of the two.

Andrew Gorokhovets’s picture

Can you to Include a patch in the dev version?

thekevinday’s picture

When nested fields get used, the location of fields and groups probably will not be at the root of the array structure given that they are nested inside of some group.

This becomes a problem with all form_set_value() function calls.
form_set_value() only works if the field is at the root of the array.

What this means is that most validate and submit functions will have some problem with fields not working properly within nested fields.
The solution is to provide a function that recursively walks through each group and returns a referential array of fields and groups.

Attached is a patch that adds the function: content_get_single_depth_array_of_fields(&$form_values, &$array_of_fields) to content.module.
This patch then uses the said function to fix a problem with multigroup values not saving.

Let me know if any of the existing problems go away with this patch.

I also suspect that this is the proper solution to what I did with the workaround_multigroup_bug patch.

rconstantine’s picture

So I suppose I have lost track of this thread, but what has happened to make it so that nested fields are not properly validated? I'm using an old version of this - i.e. I haven't updated my version since the last patch I posted - and I have a content type with over 200 fields, some nested 5 levels deep, including multigroups, which all properly validate. And I have updated the error message to show the whole path to the field - FieldGroupTab->NestedGroup1->NestedGroup2->Field - which was just a matter of listing #parents I think.

Maybe I should do a diff of the latest against mine? Could someone roll the patch and then put together a cck.zip file with all cck files including the latest patches? That would be helpful for a comparison. All I know is I definitely get error messages if nested fields don't pass validation.

Or am I talking about something other than the issue you mention because I'm that far behind in understanding what is going on here these days?

thekevinday’s picture

This is the reason why I have been submitting individual patches before merging them into a newly rolled one.

A list of the patches are: #303 + #314 + #315 + #324 + #329 + #330 + #336 + #355.

At the request of many, a new thread has been forked for the cumulative patch here: http://drupal.org/node/849420

Here are a list of reported problems:
#340 - I have not been able to reproduce myself, but I have reproduced similar..
#341 - I have not been able to reproduce myself
http://drupal.org/node/853290 - possibly related to #340
http://drupal.org/node/848758 - situation possibly caused by this module, but I do not know how to reproduce

As far as the "validator issue", the issue is not with the individual fields validators being called.
The issue is that the multigroup validator fails to do its multigroup specific stuff given that it tries to work with fields only at the root level and does not know to search inside of groups.

Also, for #352, I just realized that you could also be talking about the "Views module" view and not "viewing a node" view.
You should look into the multigroup documentation (if any..?) as that may be a multigroup issue.

zeezhao’s picture

@thekevinday - thanks for trying to nail down these issues. To add to #357

- error reported in #341 occurs for a standard group - the fields in my case appear in reverse order once cck-6.x-3.x-fieldgroup_unserialize-1.patch is applied. So backed it out.

- #340 still appears for me too. The only way to delete the row is to clear the drop-down list. Living with it for now, as benefit of nested group outweigh the bug...

- did not have validation issue. Since I was always using multigroup before I found nested groups, I had to use recursive functions to do validations/hiding/setting required of cck fields etc. based on: http://drupal.org/node/357328 or looping through fields in a custom module.

elektrorl’s picture

hi, great innovation,

same error, in #341 for standard group created with cck-6.x-3.x-. I tried to understand if CCK fieldgroup tabs could be the problem, but i have the same without this module. Will try this on a clean install.
Thanks for all your time developping this. I subscribe ;)

thekevinday’s picture

I have the "solution" for the bug from #341.

What happens is that fieldgroup seems store store its field 'weight' in its own database table.
When I unserialize the actual field settings, the 'weight' from the actual field settings overrides the 'weight' from the fieldgroup database table.
My solution is to make sure the fieldgroup database table field 'weight' gets used instead of the fields actual weight.

Try the patch and let me know if it works.
If this patch is confirmed to work in replacement of my patch from #336, then I will rebuild the cumulative patch.

I believe the "proper" solution is to not have a separate 'weight' in the fieldgroup database table.
This probably happened because the developer must not have realized the data was serialized and in order to fix their 'weight' problems they added their own separate 'weight' values in the fieldgroup database table.

elektrorl’s picture

I will try this very soon. Thanks for your time.

Andrew Gorokhovets’s picture

#326 works perfectly for me.

CCK 2.x

mcpuddin’s picture

I tried the unseraize-1 patch but had ordering problems. However, unserialize-2 (the patch in #360) fixed the ordering.

Thanks thekevinday!

thadwheeler’s picture

This was a lifesaver for me. Thanks. I am testing it on a local dev and hope to roll it out to a live dev soon.

dspring0021’s picture

Umph...my head is spinning! To anyone who is willing to give me some guidance, I am running CCK 2.8 on Drupal 6.19. All I know is that--based on descriptions of each--I (think I) need multigroup and nestedgroup, but after spending the better part of 3 hours reading this thread and the state of the multigroup thread, I have no clue what I need to do to try to implement these. It's hard to follow the trail of archives, bugs, and patches and understand what works with which versions of the module. Can someone point me in the right direction, please? Thank you!

zeezhao’s picture

To answer #365:
1. for multigroup, first you need cck 3.x. You can get it on the release page - http://drupal.org/node/48429/release

2. Once this is installed, then for nested field patches to cck 3.x, see her for latest: http://drupal.org/node/849420#comment-3269982

That's all you need.

clashar’s picture

I can't find the file "fieldgroup.tabledrag.js" to be patched in the latest "cck-6.x-3.x-nested_fieldgroups-6.patch"
it refers to
diff -Nurp ../cck.orig/modules/fieldgroup/fieldgroup.tabledrag.js ./modules/fieldgroup/fieldgroup.tabledrag.js

where it is? I searched modules: CCK 3, fieldgroup, but didn't find there.

thekevinday’s picture

The patch adds the file.
It should not exist until after the patch is applied.

I can only assume/guess that you are not applying the patch correctly.

Normally you would so something along the lines of patch -p0 -i cck-6.x-3.x-nested_fieldgroups-6.patch.
(or alternatively change to the source directory and execute: patch -p1 -i cck-6.x-3.x-nested_fieldgroups-6.patch.

You can see the drupal tutorial on such here: http://drupal.org/patch/apply

klonos’s picture

...or he was simply patching manually. If so, create the file yourself ;)

clashar’s picture

thekevinday, thanks for link!
klonos, a little bit manually.

I run shared virtual hosting and don't have access on Linux, so I usually do patches with NetBeans IDE on my Windows PC and upload by FTP, but with this time I checked the file after applying the patch and it was not patched properly. File "content.admin.inc" had about 300 lines added, so there was a problem with either my software or the patch, I don't know exactly.

Then I divided file to different independent files for each file to be patched, that's how I couldn't find fieldgroup.tabledrag.js ))

SpookyK’s picture

So after reading all this am I right in saying that Multigroups within multigroups are not yet possible, and probably not even feasible?

jvieille’s picture

Following this thread for months, expecting something great.
After doing some testing, before the patch:

Content creation
Fieldgroup F1
-field F1.1
-field F1.2
Multigroup M1
-Field M1.1
-Field M1.2

Fieldgroup F1
-field F1.1 => value a
-field F1.2 => value b
Multigroup M1/1
-Field M1.1 => value c
-Field M1.2 => value d
Multigroup M1/d
-Field M1.1 => value e
-Field M1.2 => value f

After the patch
Content creation:
Fieldgroup F1
-field F1.1
-field F1.2
-Fieldgroup F2
--field F2.1
--Field F2.2
-Multigroup M1
--Field M1.1
--Field M1.2


370 posts later, we just got the "simple" fieldgroup nesting, for which I can really figure out a practical critical use case.
Is there any chance that Multigroup could be addressed as well?


jvieille’s picture

I think this is part of what we need to complete this work

KarenS’s picture

Status: Needs review » Closed (duplicate)

I'm going to close this issue in favor of a newer, cleaner issue that has the latest cumulative patch on it, #849420: Cumulative Nested Fieldgroup Patches.