This is from the nested fieldgroup issue thread here: http://drupal.org/node/300084 and was forked into its own issue to make life easier for all those involved at the request here: http://drupal.org/node/300084?page=1#comment-3181400

The attached patch is roughly identical to the patch here: http://drupal.org/node/300084?page=1#comment-3178416
The difference is that with the -4 patch version I accidentally included a few useless .orig files.

The purpose of this thread is to hold the cumulative patches. Report bugs and get fixes at this thread: http://drupal.org/node/300084

Comments

thank you for compiling these.

Should there be an attachment on this issue, or should we get it from the link above (3178416)?

yep, it seems that Kevin forgot to attach the new patch or an upload error occurred somehow.

subscribing. My findings during testing were already posted here:
http://drupal.org/node/300084?page=1#comment-3179494

StatusFileSize
new59.66 KB

The patch was supposed to be here.

subscribing

sub'ing

sub

subscribing

This cumulative patch gave me the bug mentioned in #300084: Nested fieldgroup #341 (fields in wrong order), so I had to back the changes from the unserialize patch out. Looking forward to a new cumulative patch.

Here is the latest roll-out with the unserialize fixes.
I also just noticed that I got out of habit for the cck-2.x patch that is for those who do not use multigroups.

Subscribing...

subscribing

#10 worked a treat for me (cck-6.x-2.x-nested_fieldgroups-6.patch)

Big thanks to all involved!

Status:Needs review» Needs work

I'm trying this out, the 6.x-3.x version with multigroups. I'm going to close the long long thread at #300084: Nested fieldgroup, we don't need multiple issues open for the same topic.

I'm thinking that it might make sense to apply this only to 6.x-3.x, since it's a new and somewhat experimental feature. It seems pretty late to add a new feature to the stable branch.

Mostly this worked reasonably well. In particular I was interested in this because it makes multigroups more useful. A multigroup is really more like a field than a group, but currently you cannot put it in a group. Not only that, you cannot even use hook_form_alter() to move it anywhere else on the form without breaking. This patch makes at least an attempt to make the form work even if the group is moved somewhere other than the default position.

On the other hand, the drag n drop is still buggy. I could not drag a multigroup into a standard group until I added another standard group inside the group. So I could make it work for multigroups by creating a parent group, nesting a bogus standard group below it, add my multigroup to the mix, and then remove the bogus group.

I see issues noted about sort order too. So all of this needs to be figured out.

@KarenS, the sort issue was fixed via the latest pacth in #10. Are you saying you saw another issue? If not, it would be nice to commit #10 to 6.x-3.x, unless someone objects... Thanks.

One other thing, the file fieldgroup.tabledrag.js is not needed, see http://drupal.org/node/300084#comment-1181858 where it was discussed and removed.

Subscribing

I think things are working fine without fieldgroup.tabledrag.js and I certainly don't want to add it if it is not needed. I added a validation step and a warning that you cannot add groups to multigroups (a multigroup is a sort of a field, the logic that makes it work would not support another group nested below it.) And now the drag n drop seems to be working fine.

If I don't run into any more problems I could commit it to the dev version of 6.x-3.x so others could try to do more testing. I'm not sure what, if anything, might be broken by this patch, so it needs as much testing as possible.

@KarenS - So did someone deal with the items I listed here in comment #66: http://drupal.org/node/300084#comment-1229762???

Also comment #302 and #303 talk about it: http://drupal.org/node/300084#comment-2922392

Did work after #303 make it so it could be removed? If so, how? Additionally, there was a huge advantage of having each nested layer have its own numbering - like you would do if writing an actual outline.

I'm still working through all the issues. I still don't believe it is necessary to have separate numbering for each group, the basic way that tabledrag numbers things works fine for me so far. I am trying to test all the kinds of problems that people have reported and make sure I'm not missing anything and see if you're right that I have to have that extra step. I want to take it as far as possible using what the core code produces because it simplifies the code and will make it easier to port later.

I also ran into some problems in the code. There is a whole validation section, content_multigroup_field_overview_form_validate(), that wasn't working at all. The first problem is that it was looking for a value called 'parent' for the group, and that value had gotten renamed to 'parent_group_name'. There are places where one value was used and other places where the other is used. It makes more sense to me and seems much cleaner to use 'parent' everywhere. Fields have a 'parent', which is the name of the group they are in. Groups can also have a 'parent', which is the name of the group they are in. With that change I didn't have to keep trying to figure out which value was being used in the current context.

After I got that working, the rest of the validation logic that was supposed to keep groups out of multigroups was not working right. Instead of keeping me from adding a group to a multigroup, it let me add it and then refused to let me remove it. That was because at that particular place in the code, the value it was checking was the original 'parent' value rather than the proposed new 'parent'. I'm reworking that logic so it behaves correctly.

So my initial pass is getting the Manage fields screen to let me order things the way I want them. The next pass will to be sure that the node form looks and works correctly after those changes.

subscribing

I have never seen nested fieldgroups work without the fieldgroup.tabledrag.js file.

@KarenS - you said "So my initial pass is getting the Manage fields screen to let me order things the way I want them. The next pass will to be sure that the node form looks and works correctly after those changes." and that was the process I used, so naturally, that sounds like a good approach to me.

@thekevinday - yeah, me too.

@KarenS - if you can get it all to work without the js file, that would be great. i just hope you don't miss any functionality in that case since it seems like you didn't really test what was going on with it in use. i hope that didn't sound harsh since i didn't mean it that way.

hmm. i just thought of something... you're talking about getting the manage field screen to look right and then checking the node form. i do, in fact, recall that that was the whole reason i went to 'each nest having its own weight numbering'. initially, everything had looked good on the manage fields screen, but was all bunged up on the node edit screen - which also necessitated the fieldgroup.tabledrag.js file. the weight numbers that were assigned by the core version of tabledrag resulted in messed-up node forms. plus, having each nest have its own numbering is more like a person writes an actual outline. it seems there were other advantages too, that i'm failing to recall. perhaps i left comments in the code?

so if you can get it all working without either of those features, then great! i think we who have been following and contributing to this thread can all agree that we just want this to work and be rolled into the official release. so thanks very much for your contributions!

This patch sounds like it may make multi-group even better- excellent. Thank you for your work on this rconstantine and KarenS!

Category:feature» support

please anyone, attach the latest cck 3.0-dev that already patch ...

I'm read many long post but still confuse, then I try to use eclipse to patch cck-6.x-3.x-nested_fieldgroups-6.patch to cck-6.x-3.x-dev.tar.gz (August 26,2010) ... I don't know is that correct ?

But it's fail, a lot of error came (I'm new to use patch with eclipse too) ... Maybe I done something wrong I don't know, (maybe use incorrect file, patch file mismatch or wrong direction with eclipse, etc.)

I think it'll be easy if someone post the already patch files here ...

regards,

Category:support» feature

Category:feature» support

thanks thekevinday, that link very useful but quite not help because ...

the cck 3.x dev version you mention and tested in the past does not exist anymore, I'm try to keep track comment by comment again and found that your lastest patch was test on cck 3.x date June 18, 2010 (2010-06-18), with a datestamp of 1276862557 ...

but now, that dev version could not be found anymore, it's update to cck 3.x date August 26, 2010 (2010-08-26) and many line of code was re-arrange, so that maybe confuse patching program and cause error ...

It's quite make problem to inexperience guy like me, solution maybe post the dev version along with the patch or better post the already patched version like rconstaintine did in the past ...

regards,

StatusFileSize
new68.85 KB

I'm trying again with Cygwin instead of Eclipse ...

patch cck-6.x-3.x-dev (August 26, 2010) with latest patch (cck-6.x-3.x-nested_fieldgroups-6.patch) ...
this time no error came and no .reg file generated anywhere, this time maybe luck ...

Please check my attach image below, and tell me if anything wrong or anything I'm should concern ... but I'm try to experience this cck with patch now ...

regards,

Category:support» feature

FYI: Please do not change this to a support request.

The drupal bug category system is global to the entire issue and not individual posts.

subscribe - having issues with fieldgroups

and that is...?

Issue tags:+fieldgroup

Ah sorry it was this one http://drupal.org/node/962610 #962610: Fieldgroups do not appear once created but exist in DB
I was looking before filing but couldn't find anything similar. Fieldgroups created in DB but missing on the form.

I am running CCK 6.x-2.8 version and applied cck-6.x-2.x-nested_fieldgroups-6.patch listed in #10 above, but still cannot create a nested fieldgroups. Any attempt to drag a fieldgroup into a fieldgroup fails.

Thanks,
Tim

update: after I disabled all CCK modules, re-enabled them and applied fieldgroup module update 6007 the patch allows me to nest a group on the edit fields screen, however when I click save, the group is moved back to the root level.

subscribing

Hello everybody
First thanks a lot for the work on this, it is a killer feature for CCK.

I have an issue though, I can't put a standard group inside a multigroup and have it working the right way.

The way I understand it, standard groups are mostly "visual eye candy" but have no impact on the underlying DB structure.

But each time I move a field inside a standard group, itself inside a multigroup (illimited repetition), CCK tells me I am removing the field I move from the multigroup.

My goal is to do something like this :

Multigroup (repeated unlimited)
+++++standart_group1
++++++++++field1
++++++++++field2
++++standart_group2
++++++++++field3
++++++++++field4
++++++++++field5

it is a fairly flat structure in fact.

I did not see this has an issue in the posts here, so I wanted to mention it.
It feels like the standart CCK logic is deducing what happens wrongly in that case.

Using (wrongly) a multigroup instead of a standart group as sub-group does not work either, the group and its elements is not displayed at content node creation time.

My versions are http://drupal.org/node/484068 (June 7, 2009 ) and cck-6.x-3.x-nested_fieldgroups-6.patch

Right now I seem to only be able to nest groups visually in the CCK "manage field" editor but not to really nest them "for real" :)

Any pointer is appreciated, or if people encounter a similar issue ...

thanks a lot.

cheers

for comments #32 and #33:
Are there any other patches to cck involved?
Are there any other modules that involve groups or field manage pages?

The symptoms you describe are symptoms that generally resulted from not having the fieldgroup.tabledrag.js file.
I just double checked the cck-2.x patch here and the fieldgroup.tabledrag.js does seem to be present.
Can you confirm if that file properly exists? (at: modules/fieldgroup/fieldgroup.tabledrag.js)

If thats not the case then the problem may have something to do with the 2.x series and not the 3.x.
It will take me some time to diagnose this, but considering that you describe previously solved problems word for word, I may re-look at the old bug reports and see if there was anything left out.

Yes, fieldgroup.tabledrag.js is present. The ability to move the fields is operational, but they do not save correctly. I have given in and moved on to CCK-3, which is working correctly.

Best - Tim

Then that confirms that the cck-2 version probably has a logic flaw in my changes.

I subscribed to #35, how can i do this?

#35 can't be done and has been discussed many, many times. think of multigroups as a row in an array. as of now, you cannot do multi-dimensional arrays. a total rework of multigroups and how it stores data, particularly deltas would be required. normal groups are not just eye candy when it comes to nesting and multigroups. feel free to write this functionality. everyone would love you.

Well finally i resolved this funcionality with multigroups (not nested) and tabs. It is not the perfect solution but works for me ;)

Thanks

Xarbot

subscribing

StatusFileSize
new51.54 KB

Couldn't get it to properly patch 6.x-3.x-dev's 12/6/10 update, here's my re-roll

Your patch missed the modules/fieldgroup/fieldgroup.tabledrag.js file.
On the good side, it showed that I accidentally included two stale files: includes/content.node_form.inc.orig and modules/content_multigroup/content_multigroup.admin.inc.orig that should not have been in the patch but cause no harm.

With diff, one should pass -N to make sure new files are created.
It seems however that you used diff --git to recreated the patch.
I am not familiar with how --git works, but it does not seem to add new files.

Please regenerate with the modules/fieldgroup/fieldgroup.tabledrag.js added.
(But don't include those two mentioned files I mistakenly included)

StatusFileSize
new61.14 KB

Patch doesn't add the .orig files for me (ctrl+f ".orig" in patch, nada).
Adding tabledrag back in, sorry about that. Procedure (for those using git) was git add .; git diff --cached -p --no-prefix > patch.txt

Please excuse me from not talking about the direct development of this patch but I am having a very difficult time installing this patch. Is there any particular command I need to use? I am running ubuntu and drupal 6.20 and any help would be very helpful.

There is some documentation here: http://drupal.org/patch/apply

The -8 patch above from #45 seems to include the entire path of the module from the website and not the just the module.

This means that to apply the patch from #45 you have two choices.
1:
- Make sure the module is here: (your website root)/sites/all/modules/cck/includes/
- Change to your website root
- Apply the patch
2)
- change to your individual module ad pass an additional parameter to your patch program.
- with program called 'patch', specify the -p command and then a number of directories to ignore.
- in this case, it would be either -p3 or-p4

I personally prefer to make the patches directly from the module such that the users do not have to specify a -p option.

StatusFileSize
new59.52 KB

The -8 patch from #45 did not apply cleanly cck-3 version from 2011-Jan-03.
There was a "No newline at end of file" that was being handled and now seems to have a trailing newline.

There are no functional changes in this patch.

As a side note, the 2.x version of this patch is still affected by the issue in: #33, and possibly issue #32.

@thekevinday

I figure this will all need to be rewritten for D7's fields. Lame, huh? Would've been nice if this had gotten in last year. Or the year before. Or did I finish this in '08? I know of a ton of sites that use this and will stay on D6 because of it. I was able to do my original cut of the code here thanks to my day job. I'm not sure I'll be able to do that again any time soon. We would need a compelling reason to switch to D7. So I'm glad you're on the scene. Any idea if you'd be able to migrate this to D7?

I have recent experience with writing drupal 7 code, so it should be possible.
I am trying to push every system I have to drupal 7 asap, so I can definitely add this to the todo list.

I would first need to know the extend of what needs to be done and how to do it.
Most of my experience with nested fieldgroups is from hack and slashing previous patches just so I can get by for drupal 6.

We made sure that D7 core field_ui had everything in place to support nested groups, and the d7 field_group module does have native nested grouping - http://drupal.org/project/field_group.

I fully understand the frustration of having to struggle with a giant patch on the D6 side, and yes, it would have been nicer to get this in D6. The amount of work that went on D7 Fields up until the very last couple weeks - and there's still work ahead - made it plain impossible for me to add and actively maintain new features in CCK D6 as well.

I know that this isn't a satisfying answer for folks with actual D6 websites out there, but we are in much better shape in D7 (both on this topic and on the 'multigroup' side), and in the long run, that matters much more.

I'm still intending to update this, but have not had time to finish working on it. As I noted earlier, I think changes may be needed to the patch -- I still am not sure the extra js file is necessary nor the fancy numbering and I found other changes that made sense.

I have a client that needs it but have had other things that had to take priority, but am still planning to do something with this. The client needs it by the end of the month, so something will happen by then.

I would not spend time trying to port this to D7 because 1) it may change, and 2) I'm not sure it's necessary. There are other modules in D7 that can provide similar functionality and we will only have to make some sort of upgrade path that gets the data in the format they need.

in reply to #40
I am sorry to hear that but I purposefully stated that is was a flat structure, or more exactly a one level deep nested structure as I understood the nested field-groups module was about, and that the rest of the "nesting" was only visual eye-candy grouping, I don't understand (and probably the many people coming before me) how this can be seen as multidimensional in structure.

The underlying meta information for the field presentation (and thus nesting) may not support this but that is really not obvious for anybody thinking in terms of data structure and coming to the "nested field-group" functionality.

No chance I would write any code if I can't understand how it works, even less how presentation and content is tied together and even less how the code is structured and documented.

I am probably wrong and just not good enough a developer but to me CCK , the form API, views and panels are at the same time the peak of PhP wizardry development and such a peak that very few people know how it works or just how to extend them without breaking something else. And indeed it is not rare than some update break something else.

just keeping tabs on this issue.

Thank you so much for developing and maintaining this patch. It is a great help for me.

Subscribe.

I just tried the patch and it seems to work for me. It lets me get vertical tabs working with multigroups, which is great.

Is there any reason why this isn't being incorporated into the 6.2.x and 6.3.x dev releases? Seems like a feature a lot of people would want, and it seems to be more or less ready to use, so what is the point of making everyone go through the hassle of having to patch every upgraded release?

@NathanM : read just a little up ? #51 and #52

Ok, I misread that as a reason why you hadn't ported to D7, and not why it wasn't in D6 dev.

Have been testing the patch in #48 and it works just great!

My data structure is like this:

  • Contact Information: standard group
    • Contacts: standard group
      • field_contact: noderef (unlimited)
    • field_address: location
    • Phone Numbers: multi-group (unlimited)
      • field_phone_type: text
      • field_phone: phone
    • Email Addresses: multi-group (unlimited)
      • field_email_type: text
      • field_email: email

The node form itself works just great, no glitches, even when using Vertical Tabs, so MAJOR WIN right there!

Further, the display settings worked correct, even when I tried a whole bunch of different settings on the different field levels.

So amazing work everyone who contributed to it, it gets a big thumbs-up here!

So what are the glitches then?

@NathanM: sorry, when I started testing the output I thought I was seeing a glitch, but then with further testing I saw it worked just fine. I've fixed my review to remove any references to glitches as I couldn't find any :)

Should we change the status to needs review?

Unable to patch, so will wait for the dev incorporation.

Unable to patch, so will wait for the dev incorporation.

Wait - go the patch to work, I think. I did have this message when updating:

user warning: Duplicate column name 'parent_group_name' query: ALTER TABLE content_group ADD `parent_group_name` VARCHAR(32) DEFAULT '' in /home/votesizi/public_html/includes/database.mysql-common.inc on line 307.

... however, I think the patch is in as I'm able to nest multigroups into a vertical tab group.

But it seems like I have lost the ability to have the group function as a conditional field group. Is there a way to have these child groups show/hide according to sibling conditional fields (inside a vertical tab)?

See my patch for conditional fields: http://drupal.org/node/650008
With the most recent patch at this time being: http://drupal.org/node/650008#comment-3779648

@kevintheday I'll have to check out your patch. I'm running a patch I made myself from over a year ago. My patch allowed for nested conditionals. Does yours?

StatusFileSize
new50.32 KB

I noted above several times that I am working on a simplified patch that doesn't require an extra js file and uses the core js tabledrag functionality. It also uses the core terminology of 'parent' everywhere instead of 'parent_group_name'. The idea is to use the basic core functionality instead of re-inventing parts of it.

This seems to work fine once you have the manage fields screen set up the way you want. The only problem I'm seeing now is an occasional problem where I drag a field or group into a spot I want it but it doesn't stick in the right place the first time. I can then drag it into position a second time and it stays and after that it's fine.

@KarenS that is indeed the same problem I was having.

I think this only happens when you drag a field or a multi-group out of a group. When you save it it looses the location you placed it in.

@KarenS: my feedback above on the most recent patch wasn't to ignore your status update on this issue, rather a comment to others that if they really need this functionality right now that the patch is a good temporary solution while waiting for an official solution from you. I / We'll be only delighted to hammer pretty hard on any improved patch that you or anyone else comes up with :)

I'm working on some code cleanup. For instance, the original patch created some functions to find the nested value in the form, calling them content_get_form_element() and content_set_form_element(). They are kind of specialized to this particular use. In Drupal 7 we have some new core functions that can be used to get/set any nested value in any array, called drupal_array_set_nested_value() and drupal_array_get_nested_value(), so I'm backporting them to the content module and using them instead, figuring they can be used here and might be useful elsewhere. I'm trying to see if I can backport any other goodness from D7 that will be helpful.

IMHO if this works as expected, it should then be included in the latest dev ASAP and individual problems should be handled in separate issues.

After I don't know how many hours of banging my head against the wall, I think I found the source of the mysterious problem where some changes don't get set the first time and you have to do them again.

I identified the pattern of the bug as something that happens whenever you move a field or a group in or out of group. I checked the values that were getting returned and every time that happened the weight was reset to zero and the field or group moved to wherever on the form a weight of zero belongs instead of where it was supposed to be placed.

I tracked back through CCK 6.2 to confirm that moving fields out of fieldgroups didn't work that way, then confirmed that CCK 6.3 before this patch didn't work that way. It only starts acting this way after the patch, and even with a simple changing like moving a field out of a standard fieldgroup.

I started through every line in the patch to see what changed in the patch that might have caused a problem and finally figured out it is this line:

<?php
drupal_add_tabledrag
('content-field-overview', 'order', 'sibling', 'field-weight', 'field-weight-' . $parent, NULL, TRUE);
?>

That line was a adding a class that included the parent name to every element. Which worked fine as long as the parent didn't change and broke when it did. Getting rid of that extra class made everything work fine, whether the parent changed or not.

I'm going to do a bit more code cleanup and some final testing, but it's getting close now.

Status:Needs work» Fixed

I tried and gave up on getting a backport of drupal_set_nested_array() working and reverted back to content_set_form_element() and also incorporated the tabledrag class fix noted in #74. This seems to be working, but could probably still use more cleanup and review. But it's working well enough that I am committing it to the dev branch.

I made a few more changes before committing it, small things. I made the private function _fieldgroup_get_field_parents() into a public function fieldgroup_get_parents(). Public because I think it may be needed in other places, renamed because it is used not just to get field parents but also to get group parents. And I removed the last argument, $is_group, because you can easily deduce that from the name of the field/group. I think there may be more cleanup like that that would be useful, but it doesn't affect the functionality.

Wow ! Congrats, Karen !

Thanks Karen & everyone who contributed to get the patch built!

Please forgive my naivete, but given that I applied the patch in #48, if I now download the latest dev, will it work? Is there anything else I need to do to fix my site, given the changes between the patch and what got committed?

You need to get a clean copy of the latest code, with no patches. You also need to run update.php. The original patch created a field called 'parent_group_name', the new patch ignores that because it creates a field called 'parent' (and uses 'parent' instead of 'parent_group_name' throughout the code to match the language used by default in tabledrag). You can manually remove the 'parent_group_name' column from your database.

You will probably need to re-visit the Manage Fields screen for your fields to be sure things are still arranged the way you want and may need to re-save that page.

@KarenS - thanks for getting this into the dev branch.

I have a production site using the old patch. So got the latest cck 3.x dev to try it out but on a development copy of database. As suggested in #80, I ran update.php, but it did not appear to do anything.

Could it be that the dev version is not the latest?
edit:
- the fields now need rearranging... All the groups with group are now out, and when I rearrange I get:

# user warning: Unknown column 'parent' in 'field list' query: UPDATE content_group SET weight = 0, parent = ....

So new parent column was definitelyt not migrated.

New dev version works great for me after the update. Should get an update #6008 for the fieldgroup module or something like that.

Thanks for your feedback.

Did you download the cck dev from here: http://drupal.org/node/484068 ?

I did not get #6008 automatically. Had to go and select it myself duing update.

I think the issue is that I am applying the new code to a database that already had the old patch applied and working. So we need a way to make the new code backward compatible to convert the old 'parent_group_name' column to the new one 'parent', or else I have to receate all the nestings again.

Still when I forced #6008 the new parent column was not migrated. So maybe I have the wrong version? Or do I have to rename the column in the database?

update:
- for my case it seems that doing the following makes it work but I'll need comments from @KarenS in case there is something:
a. replace old patched cck with new cck dev
b. rename 'parent_group_name' column to 'parent' in "content_group" table in database via mysqladmin
c. resave content types layouts
d. clear cache via admin/settings/performance

We don't do updates from patches that were not committed, only updates for changes to code that was actually committed. I wasn't thinking about the fact that that update has already run for people who applied an older patch. The steps in #83 would be the right way to fix things I believe (just from looking at it, not tested.)

It looks like I'll need to find an excuse to build a site to test this. I hope kevintheday does too since I think he and I have spent the most time with the original patch code and probably know how it is 'supposed' to work the best.

@KarenS - I know you and the rest of the CCK maintainers have been busy over the last couple of years, which is why it has taken so long for you to be able to pay attention to this, but I appreciate that you finally did. Also, note that the functions you almost tossed - content_get_form_element() and content_set_form_element() - are (IIRC) used by my patch of cck_fieldgroup_tabs to properly nest everything. I don't know whether other modules use it or not - although I seem to recall that this patch also patched multigroups and used these functions to do so. I could be mistaken about that. Have you tested multigroups with this? Naturally, you should not be able to nest something inside a multigroup, but you should be able to nest a multigroup as deeply as you want.

Anyway, cck_fieldgroup_tabs has been waiting an official release of this CCK patch in order to commit our nested patch to it as well. So that's something I'll be testing too.

However, for D7, I'd agree that if there is a more universal function out there, that it should be used in that version.

The issue you mention in #74 didn't exist in my version, though I have not tested the latest patches you started your work from. However, in mine, as I've stated elsewhere, I was messing with the weights such that each new layer had it's own numbering - just like a regular outline you'd write would have - i.e.:

1 - item
2 - item
     1 - item
     2 - item
          1 - item
          2 - item
     3 - item
3 - item
     1 - item

etc.

It also made it very simple to debug, since I could just look at the table's weight and parent values. But if you've worked it out so that this isn't needed, then great.

I look forward to testing this out!!! I hope it works 100% right out of the gate. It will be nice to get several dozen sites back on to an official CCK release! And I look forward to more and more people discovering this kick-ass feature. I think you'll find that it will quickly become indispensable to a lot of CCK users and will allow for more creative use of CCK - especially when used with cck_fieldgroup_tabs.

I've said it elsewhere before, but without this combination, I would not have been able to have a manageable CCK form containing over 200 fields. Most users won't ever come close to that number of fields, but on our corporate intranet site, we needed to replace file shares of Word docs for our application support, and that's how many fields we track. We have nearly 300 applications deployed in our hospitals, and the old Word docs were poorly maintained and not searchable. Now everything is in one place and information can easily be gotten to. I think I'll have to clone that site and use it to test your version. I can't think of a better test than that.

I appreciate all the work you did on this and your patience waiting until we could properly test it.

content_get_form_element() and content_set_form_element() are probably still going away because they are hard-wired to only work for fields that are nested in cck fieldgroups -- not if those groups are further nested in fieldsets added by other modules. Our client needed to collect various combinations of CCK fields, groups, and multigroups and non-CCK fields into fieldsets on the form and have multigroups work from within those fieldsets. I am most definitely testing all this with multigroups, that's what our client needs.

I have some new code that q0rban created for our client project that will get/set a field/group no matter where it exists in the form. The D7 functions that I tried to incorporate are limited by the fact that you have to know the parents array, so they added too much complication. This new function doesn't require any pre-knowledge of what the parents are or what the parent groups are -- it will zero in on a field or group to let you get/set it wherever it is in the form. I'm doing some more testing of that to be sure it works correctly before committing it.

I got that additional change committed -- to add new functions that enable the get/set work for fields/groups no matter where they are in the form, even if buried in fieldsets created by other modules. It also makes multigroups work even if they are nested inside fieldsets that use vertical tabs, so long as the multigroup itself is not a vertical tab.

FYI: #74 sounds familiar. I am wondering if it was one of the problems solved or worked-around via the custom javascript. If you found a way to get this to work without the corrected javascript, then good job!

As far as testing the new nested_fieldgroup code is concerned, I did the following:
1) update to latest code
2) alter table: alter TABLE content_group RENAME COLUMN parent_group_name to parent;
3) updated cache

I have not touched resaving the form just yet because:
1) All nested fieldsets nested deeper than the first depth have been pulled out
2) The order of the fieldsets and fields seem to have been randomly shuffled
3) I have conditional fields module, which depends on the location of nested fields.

It looks like every fieldgroup and top-level field will need to have their positions and depths recorded before updating so that they can be manually corrected.

You may have to re-set any existing fields because the system for handling weights has changed. Once you set them up correctly on the Manage fields form they should work fine.

It seems I had some modules that were patched to work with nested fieldgroups.
They all had parent_group_name somewhere in their code.
I changed all 'parent_group_name' to 'parent' in all modules grep told me about.

The order seems to be correct now, so my problem may have been a result of something crashing during the page load. I will report to the conditional fieldset nested fieldgroup integration patch thread accordingly.

Nested multigroups appear to be working with no issues so far, but I have yet to fill out a form and look at the display side of the equation.

So far, this is working beautifully for me. Two questions though.

First, will this functionality be included in the CCK2 dev? It seems like this would be useful on some sites that do not need multigroup. (If not, then this seems like yet another reason why there should be an official release of CCK3, even if listed as unsupported.)

Second, is there any way that this could be updated to allow non-CCK fields to be placed in a field group? For instance, I would LOVE to be able to group the taxonomy field in a vertical tab with some other CCK fields, but currently I am not allowed to drag non-CCK fields into a group. I don't know what would be involved in implementing this feature, but it would be a great feature.

I'm not planning to add this to the 6.2 version, I am planning to get a release of 6.3 out as soon as I can get through some more issues.

I also wondered about whether we could add non-CCK fields to groups with this change, but there is a fair bit of work it would still take for that and other things to focus on that will take priority. What *will* work now that this patch is in is to create fieldsets in code that contain both CCK and non-CCK elements -- so you can do it in code but not in the UI.

Non-fields into groups : so far we always replied by a won't fix.

fieldgroup D6 (both 2.x and 3.x) currently acts directly in form_alter. This means that the form structure is changed during FAPI form processing. If we allow non-fields within groups :
- any 3rd party module willing to act on a non-field (say, hide core node title), needs to consider whether its hook_form_alter() runs after or before fieldgroup_form_alter()
- depending on how #tree is configured up the form structure, this might or might not alter the structure of $form_state['values'], which would badly break validate and submit handlers that deal with the non-field at hand.

D7's field_group module does allow non-fields within groups, because we made sure it acts on #pre_render, that is: only at display time, once FAPI processing is over. Thus : D7 field_group is a generic "entity form organizer", not specifically related to field or non-field elements.

With some work, I guess this behavior could be backported to D6 fieldgroup (I'm not sure of the exact status of #pre_render in D6). But in turn, it's hard to predict what existing 3rd party code, relying on fieldgroup's current modus operandi, would break.

Exactly, lots of work. I have no plans to try to do that ATM. But I suppose if someone wants to get it all figured out and debugged and make sure it doesn't break other things it might be possible. But this is only after other things are fixed and working, so very very low priority, if at all.

@yched #51

Hi, just one quick question, you mention d7 is in much better shape on the multigroup side. When I look at http://drupal.org/project/field_group it specifically says "This project will NOT include: * multigroup feature as it existed for drupal6."

Further in the issue queue it states:
"No, fieldgroup will not do this. Multigroup in D6 was an ugly hack to begin with (and still has issues). This module will only be responsible for display of fields, not storage of data."

Is multigroups possible at this stage in Drupal7?

@peramet : yes, multigroups in D7 will be possible, but unlike in D6, they will be completely unrelated to fieldgroups. Fieldgroups are presentation-only, while multigroups pertain to the data model.

The D7 equivalent of Multigroups will most probably live in http://drupal.org/project/field_collection. Not ready for prime-time yet, though.

Status:Fixed» Closed (fixed)

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


I've just installed the latest dev release (6.x-3.x-dev on 6.20) to try and get nested multigroups working, and I still get the error message:
"You cannot place any kind of group inside a multigroup. The group [###] was moved back to where it started."
from content_multigroup.admin.inc when I try to nest a multigroup.

Is there another dev version somewhere that I should be using instead - or do I have to patch it in some way? I gathered from the comments above that the patches were committed into the dev branch - am I missing something?

Thanks.

Edit: I've re-read the comments (particularly #40) and it looks like nesting a multi-group within a multi-group is not possible, sorry for my misunderstanding. Feel free to delete this comment!