I want to add an extra input field with info about the images I upload. Is it possible to add extra input fields to the imagefield(or can this be done using CCK?)

thanks in advance!

This issue was locked as requested by markus_petrux.

#554 access_restricted_fields_bug_fix_2.patch2.76 KBAgileware
#550 access_restricted_fields_bug_fix.patch1.46 KBAgileware
#529 SchoolField.png14.79 KBrjbrown99
#529 Required.png2 KBrjbrown99
#518 content_multigroup_test.patch8.15 KBandreiashu
#514 Multigroup_test_1_0.png23.19 KBandreiashu
#514 Multigroup_test_1_1.png10.68 KBandreiashu
#514 Multigroup_test_1_2.png8.8 KBandreiashu
#511 content_multigroup-119102-511.tar_.gz17.61 KBmarkus_petrux
#512 content_multigroup-119102-512.tar_.gz17.62 KBmarkus_petrux
#500 multigroup_html_header.jpg380.7 KBandreiashu
#497 Create Test multigroup - Drupal Test_1238255992628.png3.73 KBandreiashu
#497 Create Test multigroup - Drupal Test_1238256007922.png5.12 KBandreiashu
#491 multigroup_header_th.patch646 bytesandreiashu
#486 Example screenshot 190.41 KBeliosh
#486 Example screenshot 211.76 KBeliosh
#482 screen-capture-10.png58.86 KBrjbrown99
#476 content_multigroup-119102-476.tar_.gz17.42 KBmarkus_petrux
#475 content_multigroup-119102-475.tar_.gz0 bytesmarkus_petrux
#468 content_multigroup-119102-468.tar_.gz17.4 KBmarkus_petrux
#454 content_multigroup.test8.24 KBcoltrane
#424 content_multigroup-119102-424.patch78.75 KBmarkus_petrux
#424 content_multigroup-119102-424.tar_.gz17.35 KBmarkus_petrux
#416 cck.zip477.77 KBrconstantine
#414 multi_save.JPG21.66 KBservantleader
#414 multi_edit.JPG15.37 KBservantleader
#402 five_saved_multis.JPG32.12 KBservantleader
#398 Test multigroup - no_dpm_call.png8.23 KBandreiashu
#398 Test multigroup - with_dpm_call.png28.17 KBandreiashu
#398 Test multigroup - dpm_call_show_contents.png48.44 KBandreiashu
#391 119102_391_Lost-fieldgroup-option.png21.45 KBBWPanda
#378 content_multigroup-119102-378.tar_.gz17.34 KBmarkus_petrux
#367 Picture 1.png33.2 KBcYu
#367 Picture 2.png15.4 KBcYu
#367 Picture 3.png35.72 KBcYu
#353 content_multigroup-patch-fix-undefinedness.patch1.66 KBeMPee584
#320 content_multigroup-119102-320.patch77.91 KBmarkus_petrux
#320 content_multigroup-119102-320.tar_.gz17.23 KBmarkus_petrux
#352 cck.zip453.95 KBitaine
#286 content_multigroup-119102-286.patch74.43 KBmarkus_petrux
#286 content_multigroup-119102-286.tar_.gz16.53 KBmarkus_petrux
#274 content_multigroup-119102-274.patch71.2 KBmarkus_petrux
#274 content_multigroup-119102-274.tar_.gz16.21 KBmarkus_petrux
#259 content_multigroup-119102-259.zip14.16 KBmarkus_petrux
#255 content_multigroup-119102-255.module.txt58.36 KBmarkus_petrux
#245 content_multigroup-119102-245.patch66.23 KBmarkus_petrux
#245 content_multigroup-119102-245.css_.txt870 bytesmarkus_petrux
#245 content_multigroup-119102-245.module.txt57.5 KBmarkus_petrux
#245 content_multigroup-119102-245.info200 bytesmarkus_petrux
#241 content_multigroup-119102-241.patch56.52 KBmarkus_petrux
#241 content_multigroup.module-119102-241.txt51.45 KBmarkus_petrux
#227 content_multigroup.module-119102-227.txt43.99 KBmarkus_petrux
#227 cck-multigroup-119102-227.patch44.96 KBmarkus_petrux
#224 content_multigroup.module.patch38.43 KBKarenS
#221 content_multigroup.module-119102-221.txt42.51 KBmarkus_petrux
#219 content_multigroup.module-119102-219.txt41.82 KBmarkus_petrux
#218 content_multigroup.module.txt43.04 KBmarkus_petrux
#165 Snapshot 2008-10-02 16-53-10.png11.45 KBmarkfoodyburton
#191 cck_multigroup_filefield.txt1.81 KBjhodgdon
#190 cck_multigroup_filefield.txt1.8 KBjhodgdon
#182 initial.gif4.28 KBWoodside
#182 updated.gif3.44 KBWoodside
#182 views.gif4.28 KBWoodside
#162 multigroup.module.txt43.19 KBKarenS
#152 multigroup.module.txt42.79 KBKarenS
#152 multigroup.info.txt205 bytesKarenS
#152 multigroup.css_.txt135 bytesKarenS
#138 combofield.module.txt35.28 KBKarenS
#137 combofield.module.txt36.7 KBhass
#125 combofield_manage_fields.jpg33.44 KBKarenS
#125 combfield_node.jpg17.06 KBKarenS
#125 combfield_edit_form.jpg30.56 KBKarenS
#125 combofield.module.txt36.68 KBKarenS
#124 combofield.module.txt36.1 KBKarenS
#116 frmFieldGroupDup.png3.19 KBilluminaut
#113 combofield.module.txt22.68 KBKarenS
#107 combofield.info.txt190 bytesKarenS
#107 combofield.module.txt17.15 KBKarenS
#92 combo_node_form.jpg26.07 KBKarenS
#92 combo_node_display.jpg20.86 KBKarenS
#91 fieldgroup.module.patch21.83 KBKarenS
#90 fieldgroup.module.patch19.48 KBKarenS
#70 fieldgroup.module.patch17.75 KBKarenS
#64 fieldgroup-combos-1-79-2-22.patch14.68 KBeMPee584
#37 fieldgroup.module.patch12.92 KBKarenS


dopry’s picture

Category:feature» support
Status:Active» Fixed

On a node you can add an extra text field using cck. Or you can hack imagefield to do it. I'm not just going to add an 'extra' field to the module.
recategorizing to support and marking fixed.

edrex’s picture

Title:Add extra input field» allow fieldgroups to be multi-valued
Project:ImageField» Content Construction Kit (CCK)
Version:5.x-1.x-dev» 6.x-1.x-dev
Component:Miscellaneous» fieldgroup.module
Category:support» feature
Status:Fixed» Active

I think there is a general need in cck to be able to bind several fields together as a "multivalue bundle".
This would make field developers' live simpler:

  1. Unified handling of multivalue UI on the node edit form
  2. Users can extend field-types with their own extra fields.

Maybe this is already in the works with fieldgroup module? This would certainly require delicate handling of the underlying storage layer.

anybody out on the lazy Internet wanna code this up?

yched’s picture

I do agree this would be a valuable feature.
Unfortunately I don't think this is currently easy to implement. You'd need a way to synchronize the number of widgets for the grouped fields, and currently every field widget decides how many empty widgets it provides, depending on how many are filled.

Plus additional issues for widgets that group multiple value selection in one form element (say, noderef select widget)

I think a prerequisite is to have multiple values management moved back to content.module, allowing field modules to provide a form callback for _one_ value. Then an extended 'fieldgroup' thing can do the correct loop and build the 'grouped fields' form. The question of controlling precisely how many values a field can have (another long-standing request) also depends on this.

This is in the TODO somewhere, but won't happen before a potential CCK 2.0.

yched’s picture

Title:allow fieldgroups to be multi-valued» combine fields in fieldgroups

http://drupal.org/node/127879 has been marked a duplicate.

hbfkf’s picture

yched, could you explain in more detail what needs to be done to get "multiple" for groups? In particular, could you maybe

  • name a CCK module whose code is simple (to understand, as a non-CCK expert) and shows (maybe not all but some) problems that might pop up? (This could serve as a starting point)
  • explain what you mean by "synchronize the number of widgets for the grouped fields"? Hm, it's always the same, right? You have for example three widgets in the group and, because of the group's "multiple" attribute (which is set), it shows itself several times (each time with three widgets). — My little toe tells me you are talking about something else, aren't you?
  • explain what you mean by "currently every field widget decides how many empty widgets it provides". The individual fields of a group do (normally) not have their "multiple" attribute set; only the group has its "multiple" attribute set. So we do not need to care about how many empty widgets are shown inside the group. The group module shows some more instances of itself, yes. — Or do I misunderstand something?

It seems to me that this feature (aggregation) is a very fundamental thing and should have high priority.


yched’s picture

what needs to be done to get "multiple" for groups
You won't get multiple for groups. Groups are just a presentational layer, they do not hold any values - fields do and it's fields that are 'multiple-enabled' or not.

What you would get is just a way for fieldgroups to arrange fields differently on node dorm and node display.
Instead of the current :
- field A - value 1
- field A - value 2
- field B - value 1
- field B - value 2
you'd get :
- field A - value 1
- field B - value 1
- field A - value 2
- field B - value 2

BUT in order to do that consistently, you must ensure that you get as many form widgets for field A that for field B. Not possible right now without a non-minor rewrite of cck _and_ field modules. This is on the TODO, but probably won't happen just right now...

I'm short of time right now to provide a more detailed explanation. You'll see whet I mean by playing a little with 'multiple' fields in cck current state (since you just discovered them :-) )

And text.module might be the simple field module to look if you want to familiarize yourself with CCK API.
You'll see notably that field modules are currently completely free to display as many 'empty' form widgets as they like.
You can also look at the documentation 'field.php' file in the cck folder, and this section of the handbook : http://drupal.org/node/101742

hbfkf’s picture

I understand: Your assumption was that not the group but its individual items get the "multiple" attribute set. Design-wise, it would, in my humble opinion, however, be much better to make the "group" field a real field (not just a "presentation" feature) and equip it with a "multiple" attribute. (One might think, in the future, also of aggregates that do something like "image or text", not "image and text" like the thing we are discussing now.) What do you think?

But talking about design is easy... You seem to know CCK's internals: Do you think that groups cannot easily be made standalone enough to come with a "multiple" attribute? If to the contrary there is a chance that this might work without breaking everything, I would be interested in working on it. (But before I start, I prefer to ask the experts ;-))

yched’s picture

Do you think that groups cannot easily be made standalone enough to come with a "multiple" attribute?
Yes I do. This is basically rewriting the whole cck module on new concepts. I don't want to sound dogmatic, but lets not clutter the feature request with hypothetical discussions :-)

jyamada1’s picture

just wanted to add my vote for this sort of functionality that would allow multiple fields to be grouped/related. in my most recent project, i keep hitting a wall when i need functionality like this (which is a lot). coding fieldtypes together in order to get related fields is just cumbersome! it's too bad to hear that this would require a rewrite of CCK, but i think this is the last step (or at least one of them) in allowing any sort of content type to be custom made easily.

moshe weitzman’s picture

CCK2 is nearing completion and features like this are in discussion (but not yet implemented). KarenS or yched will post here when we have an update.

cabbiepete’s picture

I too have this as a requirement, has there been any progress on CCK2 where/how do I find it have tried a few searches but can't seem to find much about it

yched’s picture

Not yet. CCK for D6 aka 'CCK 2' is still in 'under construction'. It's probably only after its foundations are strong and solid that this feature will be tackled (meaning, but that's only my personal guess, after the first release or RC)

catch’s picture

Component:fieldgroup.module» content.module
Status:Active» Postponed

Marking as postponed for post RC/release.

catch’s picture

Title:combine fields in fieldgroups» Grouping of multiple fields

er, and retitling.

yched’s picture

Title:Grouping of multiple fields» Combo field - group different fields into one

Renaming to mention the official 'codename' for this.

jahwe2000’s picture

Is there a schedule for this feature? I would greatly appreciate to be able to have this great thing soon, but of course there are so many other important things

eMPee584’s picture

yched: can't the fieldgroup widget be expanded to have a multiple values setting? The empty checking would be simply empty(group) = (empty(field1) && empty(field2)), the storing does not need to chenge imho...... ?????

eMPee584’s picture

Version:6.x-1.x-dev» 6.x-2.x-dev

mmhh first: sorry about my uninformed question (#17)..
second: what is the state of things?
I guess the foundations of CCK-2 are now pretty close to being strong enough.. i had a look into this and also at the patch posted at http://drupal.org/node/108753 (Allow fieldgroups to be nested).. i do not yet fully grok the inner workings of cck as this is my first contact with it, coincidently i need this functionality for my graphviz module...
So, how has the situation regarding the possible implementation of this changed, API-wise? Any hints how it would be best to implement this, i.e. change fieldgroup to take over saving for child widgets or a new combo field?

eMPee584’s picture

Title:Combo field - group different fields into one» Combo field - group different fields into one (multi value fieldgroup?)
Status:Postponed» Postponed (maintainer needs more info)

please update this flaming hot issue when you find the time between release polishing and testcase writing ;)

eMPee584’s picture

Priority:Normal» Critical

ehh hallo yves, karens, can you please answer these questions:
1) has converting the fieldgroup into a multi-hierarchical multi-value field container now become a feasible task?
2) is someone already working on it?
3) if not, who can i consult for support if i try to do it on my own?
4) any recommendations how to do it?

abloodworth’s picture

Version:6.x-2.x-dev» 5.x-1.7

I am using Drupal 5 and just upgraded to version 1.7 of CCK. I *see* a "multiple values" checkbox on the "Edit group" page of my fieldgroup, but when checked it doesn't appear in to make any sort of change the data entry form which will allow the entry of multiple field groups (e.g. I have an "Example" group and I'd like to be able to enter multiple examples). Any idea what that checkbox is supposed to do? Thanks so much!

abloodworth’s picture

Aha, according to this thread: http://drupal.org/node/209033#comment-941987 the "Multiple values" checkbox isn't supposed to be there as an indicator that you can enter multiple fieldgroups. Apparently it indicates that you can have multiple fieldgroup tables as it disappeared when I turned the "Fieldgroup Table" module off.

tecto’s picture


Terebinth’s picture


catch’s picture

Version:5.x-1.7» 6.x-2.x-dev
Priority:Critical» Normal
Status:Postponed (maintainer needs more info)» Active

There's no way this will go in to 5.x, and it's not critical - so please leave the status in some kind of reasonable state.

eMPee584’s picture

well ibtd, this feature itself is indeed a critical component for many 2.0-ideas people have... and i wanted to start coding this but yves is deliberately not even responding to my questions since weeks, i am quite demotivated to only move a finger when he is simple ignoring questions only karen and he can answer. Or if you can, catch, please do so.

KarenS’s picture

Well, we are 'quite demotivated to only move a finger' when we are spending every available minute for many weeks trying to fix bugs and get broken things working in this and other modules we support and we get nasty comments about not doing enough work. This is a *feature request*, it is not a bug. It is something that would be very nice to have, once the bugs are fixed, but it is not more important than fixing bugs.

Even answering the questions in this thread would take more time than I have now to spend on this. We are not 'deliberately ignoring' this, we just don't have time right now.

It is doubtful this could be done by anyone not intimately familiar with the new CCK, which probably means one of us. If anyone wants to try to figure it out, they are more than welcome to do so, but they'll have to do it without expecting help until there is more time.

eMPee584’s picture

Karen speaking for me, i very much appreciate the work you two are doing, i am following the CVS commits very carefully and see you are putting a lot of effort into this. Of course i understand what you are saying BUT at the same time it was like hitting a brick wall when i wanted to start coding at this a month ago or so and just wanted to make sure to incorporate any ideas or code already done on this, or helpful suggestions. Well of course getting out a stable release is top priority. But even though it may seem childish, i actually felt hurt being ignored as a person (remember that cartoon on dpo few days ago? yes, OSS *is* about emotions, and yes, the project i need this for is so very important to me) and now my free time has also almost run out. I really wished someone would have taken the 4-16 minutes to answer my questions regarding this; i didn't even ask for close counceling or anything... so i understand my side but please try to understand mine, and let's just move on with the coding..

and P.S., i really do think that such a thing as a critical feature request does exist; this one is not about a new icon or a string translation; implementing this really expands the scope of CCK to cover the many special cases this would be useful in like bla.. and blaargh and so on.. ;)

yched’s picture

Ok, I'm not "deliberately not responding", only having a hard time doing everything that needs to be done *and* doing my own job / living my own life. Karen currently has date and calendar modules keeping her more than busy. We're also supposed to actively help on #265604: Fields in core, which we have failed to do so far.
This is an (important) new feature, but is not critical to a final D6 release which is our main focus for now.

Letting constructive offer for help go unanswered is wrong, so sorry for letting this go by.
However, as you'll see below, the task is not simple, so simple good will won't do the trick.

So, answers to #20 :
1) has converting the fieldgroup into a multi-hierarchical multi-value field container now become a feasible task?
This is now less 'plain impossible', thanks to the widget handling refactoring that happened in CCK D6.

2) is someone already working on it?
Not that I know of.

3) if not, who can i consult for support if i try to do it on my own?
I'd say current CCK maintainers, but you just got a preview of their current availability.

4) any recommendations how to do it?
OK, here we are :

2 options for this :

a) Implement this through fieldgroups : fieldgroups get a 'combo' checkbox on their settings page.

- This means that the combo 'field' is not actually a field. The fields that compose it are still stored in separate tables if they are multiple.

- This only acts on the presentation layer on node forms and node displays.

- Views still sees separate fields.

This is how I was seeing this at first many months ago, but is probably not really the way of the future.

b) Implement this as a real field type, whose set of db columns is the sum of all the columns of the fields that compose it. All values are stored alongside in the same table.

- Its hook_field / hook_field_settings / hook_widget / hook_* basically call the corresponding hooks in all its child field types. Expect a few gotchas here and there... Form manipulation for widgets might also not be trivial.

- UI problem : settings page for the combo field.
One giant settings page that gathers all the settings for all the fields ? Yuk - plus gets really nasty when you think you need to be able to change the widget for one of the fields (changes the 'widget settings' part of the form...)

IMO 'individual' settings forms need to be kept accessible as we know them, only they are intercepted by the combo field submit handlers and affect the overall combo field settings instead of the field itself (which doesn't actually exist anyway).

- Not sure how Views integration happens : for instance, you might want to filter on a lot of things... I don't even want to start thinking about relationships :-)

- The creation workflow for this field is also not too simple : how do you specify which fields compose your combo field ?

Ideal UI would be : take existing fields and drag-drop them as children of the combo field, like we currently do for fieldgroups.
Gotchas : adding existing fields to a combo field is tricky : it means migrating the data and deleting the old field. 'Multiplicity' and 'required' settings need to be changed to match those of the combo field. Plus : if the field is shared, you can't add it to a combo (current d-n-d feature in core won't let us specify such subtleties)

'Simpler' UI : no existing field can be added to a combo field.
Adding new fields to the combo happens inside the 'combo field' settings page - requires some multistep form handling.

Here's all I can think of for now. Not simple, as you see.

eMPee584’s picture

Version:6.x-2.x-dev» 5.x-1.7
Priority:Normal» Critical
Status:Active» Postponed (maintainer needs more info)

ok cool yched thx for pointing me at things to look out for, i knew about some of the problems but the details - that's why i asked these questions.. i'm gonna give it a spin this weekend.

eMPee584’s picture

Version:5.x-1.7» 6.x-2.x-dev
Priority:Critical» Normal
Status:Postponed (maintainer needs more info)» Active

(wtf firefox is wierd)

KarenS’s picture

BTW I also apologize for not answering, but I am working on hundreds of issues (and I'm not exaggerating, I have several huge issue queues to maintain), so even when I see issues that I could and should comment on, I often can't even take 5 minutes to do so. And sometimes I don't answer quickly because I want to provide a meaningful answer but don't have time to do that right away, and then I get caught up in other issues and never get back to it :(

moshe weitzman’s picture

A totally different take on combo fields - http://drupal.org/project/flexifield

yched’s picture

@moshe : yes, I saw that too a few days ago.
Problem is that it stores the combined values as a serialized array,
- saves messing with variable storage columns
- basically kills any views integration :-(
I haven't actually looked at how it solves UI stuff.

eMPee584’s picture

@karen: i totally know this from myself, it's called procrastinating or 'getting lost in multi-tasking' .. funny thing is, as soon as someone brings in emotions, things pick up speed instantly ;D
this flexifield mod seems pretty clean (apart from the white space at end of lines *g), gonna check it out later on.. maybe out of this together with the fieldgroup table module and some changes in the storage schema will show the way.

dodorama’s picture

A way we can help is by proposing use cases and some kind of UI.
I can think of at least two completely different scenarios.

1. In a recipe content type a combo-field for ingredients that stores the name, the quantity and the unit.
tomatoes - 400 - grams.
2. A taxonomy like combo-field; three select fields: Brand, Model, Color. In this case we have a parent-children relationship between the single fields so that if I choose Honda only corresponding models are available. This would be much harder code-wise (I guess) and there are modules available to do that, but I suspect once we'll have combo-fields someone will ask for this kind of stuff. Even harder if we want the type of the field dependant on a parent selection. e.g. when I select a specific model a textfield is presented instead of a select list so that i can write down the color. This not only will require a lot of code but a really complex UI. Not something for the prime time but we should probably try to keep the code open to this.
Just my two cents. Anybody has more use cases?

KarenS’s picture

Status:Active» Needs work
new12.92 KB

Here's a first pass at this. Lots of work is still needed, lots of things not yet working. I tried this several ways and decided the simplest was to build it on the fieldgroup module.

1) Create a new fieldgroup and give it the type 'Combo'.

2) Set the number of multiple values for the group. All fields in the group will be silently changed to have the same multiple value setting you pick for the group.

3) Drag fields into the group and arrange them however you like.

4) When you edit the node, the module hook_form_alters it to group the delta values of each field together. In other words, the delta and field name are swapped.

5) You can drag n drop each delta group of fields to rearrange them.

6) When you save the form, the fields are massaged back to their regular structure so they get saved properly.

I have made no attempt to get the AHAH add more button working with this, you can select a specific number of multiple values, but not unlimited. For now I am only trying to get simple fields working, so I'm testing with text fields.

Anyway, here it is...

eMPee584’s picture

Very cool Karen, sorry i did not yet deliver anything more than mouthspeak ... i was very busy this week getting our new server (hfopi.org) set up and running, also in office working on some braindead Twiki code (OOP on mad cow disease! truly bonkers.) and doing my license at the moment so i was really all lost in tangential tasks..
Well I did check out the flexifield module however and while i didn't verify if it all works as advertised, from what i understand it simply uses a custom node type as field - personally i don't think that would scale well and also i certainly don't want to have this critter field nodes littering my node table...
Anyways, highly appreciate your shot at this and will definitly give feedback on it when i come back home today.. this weekend i need to reimplement the TWiki TreeViewPlugin which will block me a bit but i'm more than ready for it.. maybe we can have a chat on irc about the todos etc on sunday or so..

one question: are you personally satisfied with this approach, or do you see it as temporary hack?

KarenS’s picture

I think it's a reasonable approach, not a hack. I originally wanted to create a complex custom field by aggregating the selected fields into columns for each sub-field, but after spending quite a bit of time wrestling with that approach I decided it was way too cumbersome to create ways to create and edit all those settings. You lose the advantage of all the other things built into CCK and have to create custom methods to do everything.

There are problems with this approach, too, but it uses regular CCK fields that work the way CCK fields already work, so it's much simpler. It interferes very little with the regular way that CCK works, so much so that you could disable the module and your individual fields will still be there, still have all their data, and still be editable.

The one thing it doesn't do is store all those fields in a single table, you will get a separate table for each field (assuming these are multiple value fields), and it would be more efficient to keep them in a single table, but that's probably the only big downside.

eMPee584’s picture

well personally i couldn't care less in which table the data lives, as long as it doesn't add overhead and the corresponding field values can be retrieved.. so ok cool ;)

vkr11’s picture



eMPee584’s picture

uarg got distracted again (after creating the first five icons for the languageicons module i just couldn't stop, now the count is somewhere near 75 and most of them don't even have a translation yet d'oh!).... anyways, couldn't test far beyond surface.. the include has to be content.crud not content.admin however and on some of my fields undefined index errors pop up but can't keep my eyes open much longer right now so ..

KarenS’s picture

Let's start by getting this working with simple fields -- number and text using textfield widgets. Once that is working, we can try getting optionwidgets working. Once that is working we should be able to add in nodereference and userreference. By that time we should have a handle on whether this can work for all fields or needs to be limited to a fixed set of field types that we know work correctly.

In other words, don't throw in all the possible complications of all possible CCK fields right now, lets take this in stages.

Even if we end up with something that only works on CCK core fields, it could be pretty powerful, since you have all the basic building blocks for many kinds of fields.

Also, be sure you turn off any modules that might be interfering with the way fieldgroups works (like Fieldgroup tables mentioned above).

A simple way to test this is to create an address combo field -- three text fields called 'Street', 'City', and 'State' (or whatever makes sense in your area). Let's get that working and then move on.

Cybso’s picture


j0rd’s picture

subscribing. Thanks for moving this forward. Desperately needed.

Freelance Web Designer

jakeo’s picture


BWPanda’s picture

Component:content.module» fieldgroup.module

I'm using the above patch to create a multi-valued fieldgroup containing one text field and two decimal fields.

When creating a node (to which the fieldgroup is a part of), I didn't seem to get an option to create multiple fieldgroups. I'd set it to max. 10, but when creating a node, it only gave me the one fieldgroup. I figured I'd be able to add more when editing the node, but when I went to edit it, there was no way to add more groups. In addition, the two decimal values were blank (i.e. they didn't save properly), though the textfield value was there.

I went back to edit the content type and re-save the max. 10 value in the fieldgroup settings, but when I hit save, it causes an error saying: "Fatal error: Call to undefined function content_field_instance_update() in /var/www/drupal-6.4/sites/panda.id.au/modules/cck/modules/fieldgroup/fieldgroup.module on line 754"...


lacitpo’s picture


markus_petrux’s picture


jeronimost’s picture


keithmorr’s picture

Status:Needs work» Active

I have been looking for a module to do this exact thing and I stumbled across the Recipe Module http://drupal.org/project/recipe This module has a section for creating a "Multi Value Field" for ingredients. Can this be applied here to make this development easier?

I have personally stripped out all of the other fields that they have in the module to create my own "Multi Value Field" but it is severely limited and my coding skill is too low to really do anything with it. It is working for what I need but I think would not be good for others.

Maybe people smarter than myself can use it to make a good MVF module.

yched’s picture

Status:Active» Needs work

Please don't change status.

eMPee584’s picture

@keithmorr: the patch Karen posted is a good start but it needs some polishing and testing.. myself i've been too busy in the last two weeks but still hope to get something done on it soon, i need it too >)

marcvangend’s picture

Subscribing, and re:#36, one more use case:
Content type "Team", containing:
- Combo field "Team member", containing:
-- User reference: user
-- Taxonomy term: function in the team
hmm... that would be great!

yched’s picture

Let's try to keep the noise minimum, please, or this issue will become hard to follow.
We don't need more "use-cases". The goal is to let *any* available field type be grouped together in the way the admin decides, so "yes, and also an imagefield with a noderef please" followups are pointless.

kobnim’s picture


chasz’s picture

an addition array would be nice lol...

image file plus width and height

chasz’s picture

does this do what the LINK.module can do or is it grouping the various cck fields??

illuminaut’s picture


graou’s picture


gauravkumar87’s picture


markus_petrux’s picture


I was about to give patch in #37 a try, but it does not apply.

Is it possible to get an updated version?

I'm interested in getting this done, and maybe I could help in someway. Also, it would be nice to know if KarenS's guidelines in #37 have changed, and if so, best way to help here.

KarenS’s picture

I'll re-roll this shortly (and add in the missing include file noted in #42).

eMPee584’s picture

new14.68 KB

Karen i have already done so.. here it is (before you spend time on it)

For all others: DON'T even try to use this if you cannot debug this code. It does not yet work reliably, it will eat your data in oh so many corner cases!

KarenS’s picture

eMPee584, what kind of issues did you run into? It has been working fairly well for me so long as I stick to very simple fields. If you can give me some examples of what broke for you I can try to debug.

And, yes, obviously, this is not fit for anything but a test development site :)

eMPee584’s picture

well, mostly data not showing up when moving fields into a combo group.. i was at debugging but got distracted by some other work.. i'll post back l8r.

KarenS’s picture

One thing that is already apparent is that you can't allow people to freely move fields in and out of combo groups once they have data in them, they will have to be locked down somehow. Otherwise you will have the database structure changing wildly, potentially causing loss of data. For instance, what should happen when you move a field with 10 multiple values into a combo field that only has two? You will lose eight values. And what happens when you have a group of 5 fields that each have 4 values and you change the combo group to only have one value? You will lose 4 values in all five fields.

These are the same kinds of things that can create data loss now -- changing things about the field that affect its data structure -- but multiplied because they affect all the fields in the group and the way the group behaves.

So I am trying to see if there is some way to lock it down a bit. If our recent 'locked' function was more flexible I could lock down the changes that would destroy data and allow all others, but it's not.

markus_petrux’s picture

@eMPee584: thanks for the patch. I have a clean environment to test this feature, so debugging stuff is not a problem. :)

Well, applied the patch and did a simple test and got an error:

- Created a new content type. Then, from Manage fields:
- Added a simple text field with number of values = 1.
- Save.
- Added a combo group setting number of values = 2.
- Save.
- Dragged the simple text field into the combo group.
- Save.

Now, create content and combo field appears, but only the textfield of the first simple text field in the group appears. !

- Next, edit content type, manage field.
- Edit combo group and set number of values to 5.
- Save.

Now, the content edit form is correct. All textfields appear.

- Next, edit content type, manage field.
- Edit combo group and set number of values back to 2.
- Save.

Now, the content edit form is correct. All textfields appear.

It looks like it is missing something since the first time I add a text field to a combo group, the edit form is not complete.

I tried to find the cause, but some other things distracted me this morning, so I could not see more...

I stopped testing, for now.

@KarenS: I think it should be possible to change multiple values attribute in a combo group, as well as adding and/or removing fields. Just warn the user when removing fields that data will be lost. Otherwise, what if one really needs to remove fields/ocurrences?

KarenS’s picture

There's a new theme in here for the form so you have to be sure the theme registry is rebuilt or it won't work right.

I have made some changes and will post back soon, what I've got will let you move fields around and change the group multiple value so long as you don't already have data in the database that would be lost by that action. I am adding a helper function in the content module that will test that.

I don't want to make it possible to destroy data, even with a warning, because I guarantee 100% that our issue queue will fill up with people who ignored the message and destroyed their data and expect us to fix it.

The only times you would be prevented from making changes would be if you have a field with existing data for, say, 10 multiple values, and you try to drag it into a group that only allows 2 values, or you have a group that already has, say, 5 multiple values created in the database and you try to reduce that to a smaller number.

I think that's a reasonable constraint. You can play around all you want before you create data and you can make any change that won't destroy data.

If there's a big outcry afterward that people *want* to be able to destroy their data, we can re-visit that later, but let's start this way.

KarenS’s picture

new17.75 KB

I committed some helper changes to core CCK, things that will make this work better and probably be useful for other purposes, too. One is a helper function to provide a way to test whether a field actually has data in the database and the maximum delta value that is actually in use. Another change was to mark the previous parent in the field overview form so we can tell if the parent has changed and test whether that's a change we want to allow. The last change is to allow a way to override the multiple values settings for optionwidgets so we can put a select field that will select a single value into each combo field delta group instead of getting a single multiple value selector.

With those changes, the attached patch is working for me. I even tried optionwidgets to add some selectors to the combo field.

eMPee584’s picture

Wow Karen I'm still a bit lost in the code, complex action flows uaarg. I did some small local changes besides the debug output but seeing as you are making progress on this much faster than i can, i will just comment on a couple of things. (This all reffering to the code you checked in today.)

1) my biggest problem: changing fields in a combo group doesn't persist even to the preview phase. For a standard group, value change correctly, but not the weights.
2) a field with 3 existing values in a std group even looses its values when the containing group is transformed to a combo group.
3) the new form error reports 2 existing fields when in reality there are three
4) the message itself, maybe better "The field 'foo' already has N values in the database, to prevent the loss of data you cannot set the number of combo values to less than this."
5) the function function fieldgroup_update_fields maybe should be renamed to fieldgroup_update_field($field_values)
6) the new interface for adding fields/groups is functional, but there should be a clearer separation between the existing fields and the 'Add' section...
7) hope this gets committed again soon (just put a $enable_combo_fields constant in the source..), fed up of dealing with all this patch-rebasing *g
8) thx again for your ongoing work.

edit: btw, i tested with date and integer fields.

illuminaut’s picture

I'm glad to see progress. This is absolutely powerful functionality and can revolutionize CCK. Just imagine how this dramatically cuts down on the number of custom compound CCK widgets around today, when people can just re-combine existing core and other well-maintained widgets. KUTGW

KarenS’s picture


1) Previews are a special issue, I haven't even addressed them yet.
2) Haven't yet tested what happens when an existing group is converted, I need to investigate that.
3) Not sure what error report you mean.
4) Yours is a better message, I was struggling with a way to word it :)
5) Maybe
6) The interface on the Manage fields screen is already in place and has nothing to do with the combo field, I'm not going to do anything about that in this patch.
7) I hadn't thought about finding a way to enable it provisionally, that's a thought. It is very hard to do something like this with complex patches.

eMPee584’s picture

1) changed values don't propagate to preview, but neither to save. just wanted to emphasize not even preview
2) works fine, only problem is 1
3) the error if you try to set the multiplity of a combo group to less than any fields saved maximum count.. it's off by one!
6) well that was just a side note i guess Yves will beautify this sooner or later
7) well it's not that complex anymore, and that switch would just have to turn off the interface exposure, trivial if ($enable) ...

KarenS’s picture

1) Just tried this out some more, I can make changes on individual fields and the values 'stick', both in the form and in the preview, even if I rearrange them, and the right values get saved. Can you provide a step by step example of something that isn't working right for you, especially what type of field you use that isn't working. I'm still testing mostly with simple fields like textfields to be sure that much is working right.

KarenS’s picture

I found what you probably were running into -- when we are using optionwidgets we don't get the right individual value for each of the selects. That's because the current optionwidgets code will always give us the last available value if it's a non-multiple value widget and we feed it multiple values. There was an intention to make it possible to ask for a specific delta value for optionwidgets, but the code to make that work never got finished. I'm adding some code to optionwidgets so you can trigger it to generate only the second value, or whatever specific value you want. With this fix I can get the combo field to correctly display the right one. I can't commit this until I do a bunch of testing that my changes won't break anything else in optionwidgets since that's a very tricky part of the code, but once it's working I'll commit that fix and make the related change to the combo field to display the right value.

yched’s picture

side note : content.test currently has automated tests for option widgets - not sure they are 100% exhaustive, but they can be a 1st level barrier

I couldn't find the time to look into this so far. I'm just wondering, in terms of UI / creation workflow :
Do 'combo' groups deserve a row of their own in the 'Add new' section on the 'Manage fields' screen ? I see several advantages (but there are possibly drawbacks that I don't see yet) :
- lets the user specifiy the combo's multiplicity immediately when creating it - an thus lets us issue warnings / confirmation forms straight ahead if the user starts dragging fields inside the yet-to-be-created combo.
- this lets us establish for sure that this 'new group' row is a combo (and not 'maybe a combo / maybe a group'), and thus tag it with special behaviour for d-n-d.
I'm thinking that if / when #300084: Nested fieldgroup gets in some day, then possibly this should only be a feature of regular groups - do we want a combo inside a combo, or a group inside a combo ?

More generally, I'm thinking that maybe it would save some headaches if the 'is combo' attribute was frozen once the group has been created - meaning, you can't turn a
group into a combo or a combo into a group. These are different animals for different needs, they *just* happen to be stored in the same {content_group_*} tables. I don't think I see value in letting users switch back and forth.

KarenS’s picture

I forgot about the tests, good point on that.

As to whether you should be able to switch back and forth between a regular group and a combo field, it would definitely simplify the logic if we say 'no' to that. That means you can't start out with existing groups and turn them into combo fields, but it is not *that* hard to create a new combo and drag the fields into it. It would also make the group UI cleaner since we would leave all references to 'combo' out of the normal group UI, and be able to add other 'combo' settings to the combo UI that only show up for that type. So I guess, yes, that might make sense.

I actually started out making 'combo' a setting just to avoid the need to alter the database to make it easier to play with this without breaking other things, but it would make more sense at this point to promote that to a group 'type' value and actually add a column to the database to track it. Once we alter the database you can't go back and forth between a normal setup and one with the combo field working. I guess it would be safe enough to go ahead and commit a change to add a 'type' column to the group info, we just wouldn't be doing anything with it in the unpatched code.

yched’s picture

"add a 'type' column to the group info" - sounds good to me.

eMPee584’s picture

well regarding the possibilty of 'morphing' a group from standard to combo and vice versa, i don't see the need for restricting this yet.. only the multiple vals count check is needed imho, because only that is pretty much the inherent essence of the comboness of a group...
anyways, what will also be needed is a autocomplete/edit coupling of sorts or something aswell as a visual encapsulation of the individual combo group instances...
waiting for further committs now :)

illuminaut’s picture

Re #77: I think conceptually a regular field group and a combo group belong together. When I first used field groups I expected this functionality to be already a part of it; it's a logical extension. However, we must be careful not to complicate the Add Group tab too much, so making a clear distinction between the types is a good idea. Only reveal the extra options when the user ticks a checkbox or selects the type from a list, indicating that he wants to use the group that way.

Instead of calling the type "combo group" I suggest using some other term that more accurately describes the functionality. One suggestion would be "compound widget", but maybe there are better, less-technical, terms.

KarenS’s picture

Actually I think the naming is the best reason to keep them completely separate -- we can continue to call a regular group a 'group' and start calling a combo group a 'combo field', which is more intuitive. It will exist in the database as a type of group, but we can describe it differently and use a different UI for it.

I can already see that the switching option will be confusing to many and that will get worse if we find other things that need to be different between them (I've already though of a couple things that might be nice to have as settings for combo groups that would make no sense for regular groups, like an option to give each delta a name, like calling one group of address fields 'Home' and the other 'Work'. Piling things like that into the regular group interface without making it really confusing will start to get hairy.)

The more I think about it the more I agree that we need to distinguish it from a regular group and not make it possible to switch back and forth. That will make them more cleanly separated to the end user. And there is no strong reason to allow going back and forth, other than 'just in case we find a reason'. It's easy enough to create a normal group and drag the combo fields into it, or vice versa, to move them back and forth.

markus_petrux’s picture

Agree. Conceptually, I think you probably know in advance if a group needs multiple instances or not.

<< like an option to give each delta a name >>
That's great.

It happened to me several times that I got time to spend on testing this, but the patch was already tested and there was little I could add. You're doing a great job!

yched’s picture

Right, that's a no for 'back and forth' switching.

I'm really not sure about the 'combo field' terminology. What is being defined here is *really* different from a field, I don't think we want this confusion. There are lots of stuff you can expect from a field that do not apply here, both externally (UI / features) and internally (code) : fields have widgets, fields have formatters, fields can be used in views, fields data can be retrieved by $node->field_foo[0]['key']...

I agree that 'combo group' is not ideal, but at least it's conceptually closer to what it actually is. I'd suggest we keep this working name until we find something better.

KarenS’s picture

Agreed on leaving the name alone for now, but I'm open to ideas on how to name it. It must be clear that it is different that a regular group and also different than a field -- 'Linked field group', or something that indicates it is a group of fields that have a relationship to each other.

[Edit] Maybe Multiple field group??

illuminaut’s picture

Conceptually, I think you probably know in advance if a group needs multiple instances or not.

I disagree. I'm not trying to bring new use cases into it, so let's stick with the address combo as an example: I might initially think I need just one group of fields called Address, at which point a regular field group suits me just fine. At a later time I decide that the user should have the option to enter additional addresses, i.e. for home and work, so now a combo group is the way to go. Instead of just checking off a box that means "I want another group just like that", he will now have to create a new combo group and drag all the fields out of the old field group into the new combo group.

To the user, the main distinction is that a field group is merely a visual grouping, while the combo group lets you use multiple instances of a group. Conceptually, it's still a group - it's not a different object.

If we separate these groups, you open the door for a lot of initial confusion: when the user creates the initial Address group, he has to decide between a field group and a combo group. Both work for his purpose, but only one is extensible. That's an unnecessary decision to have to make at that point. Yes, you can switch to the combo group, but not easily, and we're talking about restricting that possibility rather than simplifying it.

eMPee584’s picture

regarding the name - i favor compound group, combo sounds less professional ;)
And i second Illuminaut's points, however, Karen: do you really see any features that would benefit from separating the handling of these two types of groups? To me it seems, compound groups provide everything that standards do but ADD things as compound group labeling, possibly javascript sync/autocompletion, numerical multipleness checks etc..

markus_petrux’s picture

Regardless of field implementation details, from the user point of view, number of ocurrences is just an attribute. So it might make sense to not create a special type of group with its own name when the only difference is multiple attribute? So one could create a group with multiple attribute set to 1, and increase that value after some time, just like it works for fields?

Moving up and down multiple attribute for fields works like a charm. Database schema is updated perfectly well, from fields in content type table to its own table and back when necessary. Only that if you decrease multiple attribute, then you loose data. You shouldn't touch these if you don't know what you are doing. You shouldn't probably do this in production site and/or you would have to make backups, even when making simple changes in fields.

Anyway, even if you have backups of the whole database, one possible source of problems might come when changing content types structure if there are thousands of records... the process may take a long time, possibly generating DB connection timeouts, PHP max_execution_time issues, etc. This would be worst when changing multiple attribute in groups since there may be more tables involved.

KarenS’s picture

It doesn't matter whether it only looks like a minor difference to the end user, combination groups are going to be quite different behind the scenes and that's why they may need to be more separated. Both yched and I are very aware of the kinds of maintenance problems that could be introduced, which is why we are thinking they need to be more locked down.

I'll keep the option to switch back and forth for now, but if it appears there are going to be problems that will have to be changed.

One of the issues, the one holding things up right now, is how to handle optionwidgets. If you have a multiple value selector in a normal group, it creates a single selector with multiple options. In our combined group that has to be switched to a series of single value selectors. The optionwidgets code is quite complex already and adding in a capability to switch back and forth this way makes it even more complex, so this is not a simple thing.

Moving up and down multiple attribute for fields works like a charm.

Well, maybe to you guys it does, but it is one of the most complex, troublesome changes you can make with regard to the things that go on in the database when this happens. We don't need to add new ways to break that code, we spend way too much time fixing things there already :)

one possible source of problems might come when changing content types structure if there are thousands of records

That's already a problem, with or without this change, so it's always an issue.

KarenS’s picture

new19.48 KB

Latest patch. I've added in some of the terminology and name changes noted above and have optionwidgets working. Still need to do lots of testing, but it's moving along.

Requires the latest -dev version of CCK with some changes I committed this morning and involves running update.php to add a 'group_type' column to the fieldgroup table.

KarenS’s picture

new21.83 KB

Another update and then I'm done with this for today, at least. I've added in the beginning of re-formatting the node display to group the fields by delta in the same way we do in the node form. Just to keep it simple and to make it easy to see what goes together, I put each one in a fieldset.

KarenS’s picture

new20.86 KB
new26.07 KB

And a couple screen shots.

moshe weitzman’s picture

Yummy screenshots - thanks.

markus_petrux’s picture

Looks great :)

The group name is missing in the node edit form. ie. the fieldset title is not set.

In node display it is set, but there's a TODO note.

For combined groups, may I suggest to use some kind of hook to allow external modules set the group field name?

illuminaut’s picture

It doesn't matter whether it only looks like a minor difference to the end user, combination groups are going to be quite different behind the scenes and that's why they may need to be more separated.

That may very well be so from a development point of view, but I'm a UX guy, and I'm concerned that if that separation is exposed to the user he will be confused and you'll end up with frustrated users and a lot of support requests. Can't we find a way to keep the separation on the backend, but make it transparent to the user in the UI?

If this proves too difficult or will cause long-term problems, I think at the very least we should stay completely clear of anything "group" related in the name of the new object. The user can conceptualize it as a single widget with multiple fields, so let's call it something like compound widget, multi-field widget, combination field, or something along those lines that makes it clear that we're treating this as a single object. I'm obviously not a tech writer, and maybe someone has better ideas.

yched’s picture

@illuminat - Nope for widgets : widgets are 'something else', and do not affect node display, so this would end up in further concept confusion. Nope for anything that contains 'field' as well, for the same reasons.
I'm all for something that would contain 'combo / combined' and not 'group', but we need to find what :-)

@Karen : this looks very very cool. I'm thinking that, besides optionwidgets, any widget that bypasses content_multiple_value_form() (because they are inherently 'multiple') will be problematic. Do you think any such widget (I don't think we currenlty have lots of them even in contrib fields...) will need to include special code to handle combos ?

KarenS’s picture

I'm guessing that there will be fields that won't work, if they do really funky things with multiple values in forms or displays. I don't know if things like computed field or viewfield, would work (I haven't tried). I think normal date fields will work, but repeating dates might or might not (I haven't tried that either).

Getting optionwidgets working was the biggest hurdle. That should mean that most fields will work.

What I ended up doing that works fairly well in both the form and in the display is to create a psuedo node that only has the one value I want to use that I can feed to multiple value widgets and formatters. That way I didn't have to alter field or widget or formatter code at all to bring back the right result for each individual delta value, even if they handle their own multiple values.

One thought I had was to add a hook in of some kind where fields can notify us that they're available to use in combo fields, then we check fields that are brought in to see if they're allowed. I can't think of any other way to exclude ones that won't work (if it turns out that some won't).

@illuminat -- did you try it out? I tried to make things clear in the descriptions. I'm concerned about the UX, too, but this is tricky stuff and I'm still trying to figure out how to get it to work. Getting it working is more important that speculating about whether the ultimate UX (whatever it might be) is clear enough, so let's don't go too far down that path yet.

If anyone with jquery skills is interested in taking a shot at this, I'd like to get the AHAH 'Add more' option working. That's going to be kind of complex and that kind of thing is not really my strength.

yched’s picture

So that maens no specific code is needed in widgets ? way cool !

About jQuery / 'add new' button : I'm afraid I won't have time to look at this before I go on vacation :-(.
Don't want to sound like I'm giving people away, but I think Moonshine got pretty savvy on this area ;-)

illuminaut’s picture

@Karen: Agreed, it's more important to get it to work first. I just thought I bring these concerns up early so the UI doesn't have to change that much once you got it working, but don't let that side-track you. Also, the help-text you included explaining the differences is quite helpful.

@yched: I thought "field" is the common terminology within CCK. The new object is basically a repeatable grouping of fields, but for the reasons mentioned above we should not re-use "group". How about a field container or multi-field container? Other terms that convey the same meaning as "group" in this context: array, collection, set, and cluster.
Alternatively, we could think about renaming field groups to make it more clear that they don't have any functional effects and merely affect the layout ("section"?). Of course, renaming something that has already been used another way is always tricky and may make matter worse.

KarenS’s picture

I used the term 'Combination group' in the latest patch, but I'm not sure I'm in love with that term. I keep trying to think of names that imply you can combine different fields together in to one, but a regular group does that, too so using that characteristic doesn't make a clear distinction. That's why using words like 'combination' or 'collection' or 'set' might not be clear enough. I'm starting to think the characteristic that really sets this apart from a regular group is that you can repeat the field set as many times as you need, so maybe 'Repeating group' would be more intuitive? The other characteristic that's unique is that the fields have a relation to each other, so maybe something like 'Linked fieldset'?

Also, I'm in the process of moving this code into a separate module. That would make it possible to commit something that won't break the way regular fieldgroups work but would still make it possible to try this out. It would also keep the new strings out of the fieldgroup module, since we want to freeze strings, and move them to the new module. And we could make clear in the description that this module is still in development so people don't try to use it on production sites yet. So we could have this module in a 'beta' state even if the rest of CCK is further developed.

I found that I can't completely rip all the code out of fieldgroup because fieldgroup already has a weight of 9 to get behind all other modules in processing, so it's very hard to get a new module in behind fieldgroup to make further changes. So I will have to leave a couple small hooks in fieldgroup so the new code can work right, but I can move most of the code out.

markus_petrux’s picture

If that helps...

- I believe 'Repeating group' makes things clearer since the 'Linked' characteristic is implied.

- Implementing this extension using hooks sounds better since it does not depend on module weights and opens the door to other possible extensions with clearer methods to do so, IMO, probably much easier than having to use form_alters, nodeapis, etc.

dydecker’s picture


yched’s picture

That's only my personal opinion, but "repeating group" doesn't seem that much clearer to me, and not very nice too :-).
I find 'combination'-based terms do say something accurate about the specificity of this new entity. Regular groups, well, group fields together (as in 'gather'), while these new kids *combine* fields (as 'intertwine') into something different. Not to say we cannot find better, but the current is not too bad IMO.

+1 for a separate module - though I'm not sure shipping it beta is a good idea. 'beta', 'RC', 'stable' applies to the CCK bundle as a whole, so getting people to understand *one* of the modules is beta might not be easy.

I don't get why fieldgroup's weight 9 is a problem. If the new module needs to come after that, it can use a weight of 10 (or 99, for that matter) ?

yched’s picture

"repeating group" doesn't seem that much clearer to me :
To be more specific, I don't think this prevents a "er, what is this ?" reaction and saves a visit to the 'advanced help' section. If we can find a self-explanatory term, cool, but I doubt we will. My feeling is that new-comers will have to go to the help page to get what this is about anyway. Once they get it, whether it's called 'repeating group' or 'combo group' make little difference to them IMO.

illuminaut’s picture

One more post on terminology: I agree with Karen that variations on the group theme doesn't aid in distinguishing it from a field group. Repeating group sounds awkward but I think you're on the right track. How about a minor simplification of the concept: let's just make it clear that it's an object with multiple field groups. Terms like Field Group Set, Field Group Array, or Field Group Collection all sound good too me, and by keeping the Field Group moniker we immediately draw the attention to the main difference, which is that there are more than one.

Seeing as people already understand Field Groups and the concept of multiple values, we might as well just stick with it. Yes, some may wonder why you didn't just make the field group multi-value like in the initial request here, but the technicalities could be explained in the readme if anybody really cares.

KarenS’s picture

The field group weight is a problem because there are already some modules that set their weight to 10 assuming that will make them dead last in the pecking order and they won't be any more. I don't like to mess with weight, it can cause unexpected problems, especially since we can work around it by using hooks so things happen during fieldgroup's processing. Plus that saves yet another pass through the node handling -- first by the node module, then by the content module, then re-arranged by fieldgroup, then re-arranged again by this new module.

If we get the hooks into fieldgroup, we can ship without this module and people can drop it in, so we don't have to include it in the package. It's just that if we don't commit it we have no way to see what incremental changes are being made, we can only pass around the whole thing until we get it to the point where we feel we can commit it.

If we were to commit it, I was thinking we could put a message in the description that you see on the modules page saying it isn't production-ready. You can't enable the module without seeing that message, so that should be fair warning.

KarenS’s picture

Status:Needs work» Needs review
new17.15 KB
new190 bytes

OK, I committed the new hooks in fieldgroup and also added the group_type info to the new Manage fields screen and processing. We need to confirm that nothing I changed breaks normal fieldgroup processing without using the new Combo field. I tried to confirm that before I committed things, but other confirmation would be nice.

Then you need the new module attached here to implement the combofield stuff. I called the module 'combofield', since that's been our working name all along. We can still change the terminology the user sees.

Create a new 'combofield' folder in cck/modules/ and drop in the following two files, renamed to combofield.info and combofield.module, enable it, and try it out.

I'm going to mark this Patch Needs Review to get people to test it.

marcvangend’s picture

I'd love to test this... but alas it didn't work.

I started with a clean Drupal 6.4, running locally on XAMPP, installed CCK 6.x-2.0-rc7 (enabled content, fieldgroup, node reference, number, option widgets and text) and added the combofield module as described above.

I deleted the story and page content types (as I always do) and created two new ones ('team' and 'employee'). When trying to add a fieldgroup (path 'admin/content/node-type/team/add_group'), I got a 'Page not found' message. The Drupal log shows the same 'page not found' warning, but no further interesting info.

With the combofield module disabled, the add group page works just fine. I added a group and enabled the combofield module again. On 'admin/content/node-type/team/fields' the fieldgroup was still there, but the configure link led to another 'page not found' (on 'admin/content/node-type/team/groups/group_team_member').

Upgrading to CCK 2.x-dev did not solve the problem. It did enable me (thanks to the changed UI in the dev version) to add a fieldgroup with combofield enabled, but I still couldn't access the configure page.

Not sure if I should change back to 'patch (code needs work)' now...

KarenS’s picture

You have to have the code that includes today's commits, which is the current -dev version in cvs. If you use the tarball, you have to wait until today's commits get in, which will be sometime tonight. Almost everything done in this thread was done after rc7 was released, so obviously rc7 is missing all the necessary changes.

Also there is no longer a path for 'admin/content/node-type/team/add_group', that's all changed in the newest version which has a whole new screen for adding fields and groups, which is unrelated to this patch. If you haven't used the newest CCK, you should get current on that version, without this module, and become familiar with the way it works before trying out the new module.

markfoodyburton’s picture

I just tried the code
When I tried to config a 'group' I got a 404.

Seems that on about line 130 of the module, you need 'type' rather than 'name' ??

Then it all works for me :-)

This is FANTASTIC, thanks KarenS et al.



KarenS’s picture

I just ran into the reason why you can't go back and forth between a standard group and a combo group. Regular textfields are no problem, go back and forth and they keep the same values. The problem is if you have something like the following:

Create an optionwidget with a yes/no option, like my 'Active?' field in the screenshots above. Create a normal fieldgroup with that field in it, along with other fields. You can choose one value, yes or no.

Now create a new combo group that will have four values, like a group of address fields in my screenshot above. Drag the yes/no widget into it. Now you have four yes/no options, one for each set of address fields. Turn a couple to yes and a couple to no and save it. In the database you will have four records for the yes/no value, two with yes and two with no. So far so good.

Now turn this back into a regular group. You now have a 'Street' field with four streets that still have the right values. Ditto for all the other textfields. But you now have only one Yes/No field, not four of them, and if it's a single value widget it can only have a single value. If you save the node now, only the first Yes/No value will be saved and the others will be wiped out.

And even if you leave it a multiple value field, it only has two options so the most it can save is two values, so you'll end up with one yes and one no in the database.

The way to prevent this, other than not allowing you to switch back and forth, would be to not allow any optionwidgets into a combo field that have fewer values than the combo field has, which would mean you couldn't use this Yes/No widget in a combo field with more than one value, which would make this feature much less useful.

I hope that example is clear, it's confusing stuff, but I think it will be necessary to make a group either a normal group or a combo group and not allow switching back and forth.

sjf’s picture

Looks really good with the fix in #110. A couple of small issues:

1. If the labels are inline, they only appear on the first entry in a repeating combo group
2. On the node edit form, I seem to be able to pickup a date field within a combo group and move it around. Not sure if this is only possible because I'm admin but it does seem to screw with the ordering.

Very small issues though. Many thanks for providing this functionality.

KarenS’s picture

new22.68 KB

Updated code, includes the fix noted in #110. I also added a bunch of validation for what kind of fields and widgets you can move in and out of a combo group. It looks like any widget that allows the Content module to handle multiple values will work fine. Optionwidgets is an example of a widget that handles its own multiples, so it needs special handling. I added some validation that will allow you to add optionwidgets into combo groups, but you can't move them out once you've created data, to prevent the problem in #111.

I also added hooks modules that do their own multiple values handling can use to allow their fields in or out. The Date module is one of those, which is why you have the odd results there. I have to go back and do some work now in Date to make sure it will work right in combo fields. Until I add a hook in the Date module indicating it is working, you will not be able to add date fields to combo fields.

The inline text issue will need a small tweak, but I'll worry about that later.

illuminaut’s picture

I understand the difficulty between switching back and forth between group types and why we shouldn't allow it. I've always wondered why we still need regular field groups if we can make the combo group work for any field. After looking at the combo group a little closer, I realized that there is another major difference to field groups, other than just allowing for more than one group. A regular field group doesn't care about how many values a field inside it has, while the combo group doesn't allow you to use fields with more values than what the group is set up for. That restriction makes sense looking at the implementation, but it's not intuitive if you conceptualize a combo group as just another form of the field group.

The point of this post is that I think it's actually beneficial for the user if we don't allow switching back and forth, and concentrate on making the concept of a combo group clear. Any feature that blurs the distinction between the group types is actually harmful because it sets wrong expectations. For that reason I wouldn't even allow turning a field group into a combo group, even though it's technically possible. You can save yourself a bunch of sanity checks, and save the user frustration when being told he can't drag this field because it has too many values.

KarenS’s picture

Now you're starting to come around :)

I'm leaving the switching in while I develop it because it's useful to be able to go back and forth so I can figure out exactly what things will and won't work in the new groups. I also have to leave most of the validation in there because I have to be checking when people drag fields in and out of groups to be sure they're not doing anything that will break (and have a method that can be used as an API if custom modules are adding or removing fields from groups).

I think we can get the final separation in by doing two things -- removing the drop-down selector in the group edit screen and making that a hidden value, and adding a new, separate item on the Manage fields screen for adding a new combo group instead of using the regular fieldgroup. With those two changes it should not appear to the end user that regular groups and combo groups have anything to do with each other (even though I'll be using lots of the same code in the background).

We still need a name for this thing, though.

illuminaut’s picture

new3.19 KB

+1 for providing separate interfaces.
Regarding the name, I've tried to find inspiration at work in Oracle's vast assortment of widgets and realized that they handle this concept a little different:
The Oracle UI allows for 4 different kinds of groups: Section, Group, Child Group, and Field Group (there's also a content container, but it's not intended for form widgets and is more like what we call panels).

A section is exactly what we call Field Groups, and I must say I like Section a lot better because it implies that it's just a visual grouping.

A group separates one set of prompt/data pairs from another. (In the Oracle world, single fields are always described in terms of prompt/data pairs, so just read that as "fields"). The guidelines sometimes call a group "Component Group". By default, a group has no label/header, but it's possible to use one. It's basically a section without a visual border around it, and mainly meant to simplify coding of hierarchies - the user is unaware of their existance.

A child group combines a set of prompt/data pairs beneath a parent component. This allows for things like collapsing or hiding child groups based on the content of the parent component.

And now, ta-da, the field group, which combines multiple components with a single prompt. This is like our new combo group, and allows you to add additional field groups using what they call "duplication buttons" - a set of +/- buttons to make a new copy of the field group that can hold different values. Attached is a screen shot of their version of field group.

It would be interesting to see how this is named in various other UI libraries, so please pitch in with some other real-world examples. Maybe we can find a common ground.

okeedoak’s picture

"Group", being already define and used, should not, IMHO, be part of the new name. If I may be so bold to suggest:

Perhaps too esoteric, perhaps not.


KarenS’s picture

Actually, if we're going to completely separate this from fieldgroup in the UI, I kind of lean toward the original name, combofield. It behaves more like a complex field than a group, and I think the name still conveys that it is something different than a normal field. The fact that we use lots of the fieldgroup code to make it function is irrelevant if the end user can't see any connection to groups.

And I think I would call it ComboField rather than Combined Field, which feels a little artificial and odd to me.

Ensemble is meaningful, but perhaps a bit too far removed from what we call everything else.

illuminaut’s picture

I quite like the "complex field" that you used as an explanation. It's better than combo IMO because a combo box/field is usually associated with the standard web widget (the editable drop-down list). It's also a lot better than my original suggestion of "compound field".

Of course we could just re-define it, seeing as a google search for "combo field" brings up this very thread in first place: http://www.google.com/search?hl=en&q=combo+field&spell=1 :)
But to me, and I'm sure a lot of other people, a combo field already means something else.

yched’s picture

re #111 :
Actually I don't see this as 'buggy' behavior. 'Multiple option widgets' are inherently limited to only the maximum number of options - you can't select the same value more than once. Well, that's the way it is, IMO. You get the same behavior (loss of values) when changing the widget of a textfield widget from 'Text field' to 'Select List' : next time you edit the node, duplicate values will be wiped (plus you lose the order...). That's sort of included in the definition of option widgets.
This being said, I'm still in favor of not allowing back and forth switching, so...

KarenS’s picture

I wasn't saying it was 'buggy' behavior, I was saying there's a difference between the way it will work in a combofield and the way it normally works, and that's why we can't use them interchangeably.

And it's not just if you have only two options in a 4 value field, it's also the difference between having one selector with 4 values (where no two can be the same) and 4 selectors with 1 value (where all four can be the same). Since those fields behave completely differently and store different values in the two scenarios, we can't move them back and forth.

But I think we're all agreed now that there will be no back and forth between them :)

KarenS’s picture

And right, the current behavior, allowing you to switch back and forth between the selector and textfields, could create just as many problems. But if there is an allowed values list I doubt people are actually switching between a selector and textfields, it wouldn't make much sense to use textfields, which I think is why we don't have any issues about people losing their data doing that.

But this is different -- if we allow people to move a selector back and forth, they will probably do so, and they would not expect that the values in the database would change.

marcvangend’s picture

Re #108, #109: Problem solved once the tarball was updated.

My thoughts about the name:
- I like 'repeating group', because in my experience, that's exactly what it does: It allows you to create a group of fields and repeat it.
- 'Combo field' sounds awkward to me. I'm not a native English speaker, but the way I understand language, "combo field" literally means "a field with 'combo' characteristics". Linguistically speaking, I guess "field combo" would be more appropriate, meaning "a combination of fields".

KarenS’s picture

new36.1 KB

Latest patch. I now have the AHAH add more feature working so you can select the 'Unlimited' option for multiple values and use it to add new field collections.

I also made the separation between regular and combo groups by adding a new widget to the Manage fields screen for creating these fields and turning off the ability to switch a group from one type to the other.

Getting the new item to work on the Manage Fields screen required a few changes to the core Content module, so I just committed changes to make that work. The changes won't show up in the tarball until tonight, but they're in cvs now.

Also, when I added the new item to that screen I see that I can't completely get away from the 'group' terminology -- the name has to have the 'group' prefix that other groups have or it won't work, so I'm trying out the name 'Repeating group', which IMO doesn't seem too bad.

As noted above, we are not going to come up with any name that makes it immediately obvious what this is, so we can't hold out for that before moving forward.

If we give this some further testing, and come up with a reasonable name, I think it is close to being ready to commit.

KarenS’s picture

new36.68 KB
new30.56 KB
new17.06 KB
new33.44 KB

Some updated screenshots and one more stab at the module text to fix a couple undefined index errors.

KarenS’s picture

I take it back about the 'Add more' button working. It looks nice and it adds a new fieldset, but there are some funky things going on when you save things, so it's still buggy and needs work.

markus_petrux’s picture

Is it me or the option to add a group is missing?

I checked out an export directly from CVS, run update.php and cleared all caches.

markus_petrux’s picture

Oops... sorry, now I see it is only available from the new section at the bottom of "Manage fields" panel.

Sorry :(

illuminaut’s picture

To be honest, I don't think it matters if it's not called "group" and has a group_ prefix in the machine name. I'm still for "complex field". The group_ prefix may even help by giving an additional hint as to what the field is doing. Combined with a description text like "A complex field groups other CCK fields into a single component and can have multiple instances", and I think it'd be pretty clear. Maybe another sentence about the limitations.

markus_petrux’s picture

Well, using CVS export from tag DRUPAL-1--2 + combofield module in #115.

Installed on top of an existing installation that was running latest RC and already had a few content types and CCK fields defined. Executed update.php prior to starting to test.

When adding or moving weights for a repeating group, I sometimes get a new group created with empty group_name and label.

I tried to find a way to reproduce:

1) On the Add section of the Manage fields panel, for New repeating group
enter a label and a group name, select some repeating values, 2 for example.
2) Save
3) The new group appears at the bottom of all fields in the contect type. That's Ok.
4) Drag the newly created repeating group to another position.
5) Save.
6) Opps. Now there's a new repeating group with no label and group name.

hass’s picture

Status:Needs review» Needs work

There are a few bugs in translatable strings inside that should be fixed.

Bad and unsupported:
t('\'Unlimited\' will provide an \'Add more\' button so the users can add repeat it as many times as they like. ');

t("'Unlimited' will provide an 'Add more' button so the users can add repeat it as many times as they like.");

1. Don't add slashes if double quotes are possible.
2. Never add a "blank" to a strings end. Move it outside for e.g. t('foo') . ' ' . t('bar')

KarenS’s picture

I didn't know that translations can't support slashes, I'll have to check my other code, I probably have it elsewhere.

eMPee584’s picture

Well finally, good to see this progressing and people actively pickung up development! I'm really annoyed that i did not have enough time to contribute any code yet... maybe in the next days.
BTW: no one in favor of the name compound group?

jmesam’s picture

#130 Try to install the lastest dev version of CCK and execute update.php. It worked for me after do that.

mistresskim’s picture

I'm getting the same error in #130 with latest dev version of CCK plus code in #125.

Node reference fields also throw up this error:

warning: Illegal offset type in isset or empty in .../drupal6/sites/all/modules/cck/modules/nodereference/nodereference.module on line 198.

My textfields also are no longer being repeated either. Whilst the earlier patches on the Fieldgroup module worked for me, I haven't been able to get the combo fieldgroups happening again since the code was moved into the Combofield Module. Do I need to do something else to get this working?

KarenS’s picture

How about 'Synchronized group'? Because the difference between this and a regular group is that the fields are synchronized to each other.

Or 'Reverse group' to indicate that it's a group that behaves the opposite of a regular group, as noted in #6:

Instead of the current :
- field A - value 1
- field A - value 2
- field B - value 1
- field B - value 2
you get :
- field A - value 1
- field B - value 1
- field A - value 2
- field B - value 2

hass’s picture

Status:Needs work» Needs review
new36.7 KB

@Karen: I translated the latest code level to German and reviewed the translatable strings. I fixed the code style bugs mentioned above and added the word "field" in some strings where they seems to be missing. Module attached.

KarenS’s picture

Status:Needs review» Needs work
new35.28 KB

The reason why this broke so badly was two things, one was when I tried to create a separate interface for adding a new group. Because this uses the fieldgroup processing it's quite difficult to add a new group in a separate interface without either duplicating huge chunks of the fieldgroup code or breaking some of it. I decided to go back and get rid of the separate interface for adding a new group and make it a selector to add a standard group or a repeating (or whatever other name we come up with) group. That also simplifies the Manage fields screen which gets really messy with another 'add new' item on it. I had to commit another hook to the fieldgroup module so I can create a default value for an important setting -- the multiple value setting. With those changes I can get the process of adding a new group on the Manage fields screen working correctly.

I switched back some of my earlier code for the node edit and node view, changed when I added the 'Add new' button, and got them working better again, and then got the 'Add new' button incorporated back in again.

So here is the current state of things (requires today's commits to the Fieldgroup module to work right). I haven't fully tested this yet, but it's less broken than the last version and I'm going to pull away and work on other things for a while, so here it is.

marcvangend’s picture

Re #136:
To me, synchronized means that there is a time factor and that values are updated once in a while.
"Reverse group" doesn't sound right to me either. I've read the explanation from #6 a couple of times, but I guess I just can't agree that "it's a group that behaves the opposite of a regular group". The combo field does not reverse anything, it adds functionality.

But here's another thought: why don't we use "multi value fieldgroup", which has been in the subject of this issue for quite some time now? In the early days of this issue there have been many title changes, but since the addition of "multi value fieldgroup" (#19) the title has not changed anymore. Could that mean that 'multi value fieldgroup' explains it all? (BTW, the word 'multiple' is also used a lot to describe this functionality in this heavily-subscribed forum thread: http://drupal.org/node/232184.)

illuminaut’s picture

I agree with your reasons for not liking the some other terms. "Multi value fieldgroup" or "multi fieldgroup" does capture it fairly well, but the thing we need to decide on is whether we want users to look at it as a type of field group or a special type of field. Let me summarize the arguments against "group":
1) it blurs the distinction between a regular field group and a multi fieldgroup. The difference between the two is not just that one can hold more values, and if it were, the user would rightfully question why we don't handle that the same way we do for other fields that can be multi-value.
2) it doesn't help you understand the restrictions that come with it. If you think of it as just another field group, you don't expect that all fields inside of it must have the same dimension.

That being said, it looks like the implementation right now puts that functionality inside the field group screen, so if that stays that way we can't suddenly call it a field. I'm not a big fan of putting it there, but if technical reasons dictate so then the name has to follow suit, and we'll just have to do our best to be as clear as possible in the accompanying help text to prevent tons of "omg, where did my data go?" support requests.

markus_petrux’s picture

I'm not sure whether it is possible to find a short name for this that is precise and concise. It is a complex and particular enough concept that will need to be documented anyway, so I think "any" name will suffice. I would even say the more esoteric the name it has, the more people would be encouraged to read its documentation, which is something good IMO. In the end, we all need a short names to think about complex concepts. Time and experience will teach everyone what it really is.

The word "combo" is used all around the code, in this thread, etc. so I would vote for leaving as it that way, unless the word "combo" can lead to confusion, which is something me, not being english native, can't say.

hass’s picture

There seems to be problems with translation. "Add field" and "Add group" and a few others are not displaying in other languages. Not yet verified why.

KarenS’s picture

@hass - I needed to use the same group name validation in both fieldgroup and combofield so I moved it into a separate function in the fieldgroup module and removed the prefix, so 'Add new group: the group name is too long.' became 'The group name is too long.'. I just realized that is going to screw with translations already done. If that's a big problem I can change it back and duplicate all that code in this module.

@everyone else - Looking though the proposed names and all this discussion, two things are clear. First, there is no name we can use that will instantly convey what this module does. Second, we cannot completely keep it from having some connection to groups. So, my new suggestion is to use the name 'Complex group'. It is a group, might as well admit that. And I assume a name like 'Complex' will force people to the documentation to see what it is. Then I will also be sure that documentation is included.

I'm almost finished getting this working again. Most fields are working well, but I'm still having trouble getting nodereference fields working. Once it's done, I'll post it back here and change the name of the module to match the name we come up with, like 'complexgroup'.

KarenS’s picture

@hass - actually now that this *is* a group again, I can put back the 'Add new group: ' prefix to the messages. If I do that, will that eliminate the need to change translation code? The phrase would be the same but it's in a different place in the code.

illuminaut’s picture

"Complex group" is not bad. A suggestion, the short description associated with it (the one you see right there in the interface without going to help) could mention that a complex group causes the fields it contains to act as one (or in unison). Maybe that helps to understand the usage and restrictions.

hass’s picture

@Karen: stop, please :-) I will provide a screenshot later... I think - I mean something different than you do. No need to add the older strings back.

eMPee584’s picture

Mutli value fieldgroup is to much of a technical term, Complex group implies it's hard to understand. Even though noone has picked it up, i still like 'compound group' best for it on the spots conveys the message: everything in this group is glued together in a single unit. And it can have multiplicity, too! which is self-explanatory.

hass’s picture

Deleted. I should update the translation first.

marcvangend’s picture

For me, 'compound group' is not self explanatory at all.

Personally I like 'repeating group' or 'multi value group' best, but I agree with the point Karen is making in #149: if there is no name that will instantly convey the message, we better pick a name that encourages people to read the documentation. 'Complex group' indeed implies that it's hard to understand, so I'm not too enthousiastic about that. Maybe 'advanced group' is a good option? It had a more positive sound to it, I think.

KarenS’s picture

I had to make a decision so I can get this thing working without breaking it again if I change the name. I decided to call it a 'Multigroup'. The key characteristic of how this differs from normal groups is the way it handles multiple values. 'Repeating group' and 'Multiple values group' convey that, but are kind of long, technical names. The other names miss that characteristic. 'Multigroup' is a made-up name, going back to the idea that if we can't come up with an instantly recognizable term we may be better off just making one up. And it should still be enough to force people to go to the documentation to figure it out. The name then exactly matches the module name.

I'm re-working the code now to use it and it works in nicely. I think when you see how it behaves in the interface it will seem satisfactory.

BWPanda’s picture

Not sure if you're wanting bug testing yet, or if you already know about this, but the module from #138 spits out the following errors when trying to use the 'Add more values' button on an unlimited combofield/multigroup:

* warning: Invalid argument supplied for foreach() in /var/www/drupal-6.4/sites/panda.id.au/modules/cck/modules/combofield/combofield.module on line 877.
* warning: array_keys() [function.array-keys]: The first argument should be an array in /var/www/drupal-6.4/sites/panda.id.au/modules/cck/modules/combofield/combofield.module on line 886.
* warning: Wrong parameter count for max() in /var/www/drupal-6.4/sites/panda.id.au/modules/cck/modules/combofield/combofield.module on line 886.

Looking forward to the finished product!

KarenS’s picture

Status:Needs work» Needs review
new135 bytes
new205 bytes
new42.79 KB

Here we go, requires the latest -dev version of CCK (with a few minor changes I committed today).

I have all core fields and Date fields working, and have added settings to give each delta a label (like 'home' and 'work'), added it to the 'Display fields' screen so you can select a format for the sub group display (only a couple options right now, plain, fieldset and separating each sub group with a horizontal line).

You can set the group to have whatever number of sub groups you want to have, including Unlimited, the AHAH add more button seems to be working fine.

The only thing I couldn't get working was drag n drop. It looked fine and worked fine for simple fields, but complex fields got their validation all screwed up. Maybe just as well anyway, since labeling each subgroup won't work right if you are dragging the groups around.

So I think it's ready to test. It's now renamed to Multigroup, and it has new themes, so you need to be sure to clear all your caches out and start over if you tried the previous versions.

markfoodyburton’s picture

this module is great, and will be widely used, I'm sure, it's a great building block, so - thanks!

I tried out with text fields, worked a dream

For a node reference, when I tried to move the field into the group, I got

This change is not allowed. The field menu handles multiple values differently than the Content module. Making this change could result in the loss of data.

I _think_ the idea here is to stop me moving a current field into the group and potentially loosing all the data, but its not so obvious how you create a field to put into the group?

For the AHAH thing re-ordering thing - with the default +- 1 2 3 sort of thing... I'm not sure. I think I'd be tempted to say, if the user hasn't put some tags in, then... I'd say, dont make the fields weighted... I mean, in general, people will use this to put 3 or 4 small bits of data in, so if they need to move them about - cut'n'paste can be their friend. For the few cases where people do want to play with ordering, the web designer can add some tags - even if they just use 1 2 3 4...?

I'd also be inclined to suggest that the tags are more likely to be output from either (a) some PhP code, (b) a view - or possibly, most likely of all - and most scary of all - some javascript....

In other words, if you want to order 3 pizzas, then you could call them 1, 2 and 3. But if you want to book rooms between the 10th and the 15th of October, then you might enter those dates first in one field, and then have a selection for the room on the 10th, 11th, 12th, etc...

Not sure how to make that easy in the GUI.... "type your javascript code in here ?"....

Thanks again :-)



KarenS’s picture

If you have a field that already has data in the database and you would lose data if you move it into a multigroup, it stops you from doing it.

This only happens if you are trying to move around fields that already have data, you can create a new field and move it into the group with no problem. Or change the number of values in the multigroup to make it high enough to include all your data, or delete the specific nodes that have those extra values in them so that you don't have anything in the database that will trip you up.

The sub group labels are intended for easy situations where they make sense, like my 'home' and 'work' example, where you always want each position to carry a specific meaning. You can add another custom field to the sub group and call it 'label' to do fancier things.

markfoodyburton’s picture

Hi, I have a totally new field, and no nodes using it... and this only happens with node references

I 100% agree on the sub-group label things,
I was assuming they would be used for ordering too?
I was suggesting, to keep things simple - not to put the '+1' '-1' select odering on by default, and to only do "ordering" if the sub-group labels were defined....
Not sure I've explained what I mean very well.... sorry... Hopefully you'll get it though :-)



KarenS’s picture

I turned 'ordering' off, or at least I turned it off in javascript. It see I didn't turn it off if you have javascript disabled. That's the drag n drop re-ordering that won't work. It should not be used.

BWPanda’s picture

I got the message:
This change is not allowed. The field Date/Time handles multiple values differently than the Content module. Making this change could result in the loss of data.
when trying to add a datetime field to a multigroup (a new field, not an existing one).

Is this supposed to work yet?

markfoodyburton’s picture

sounds like the same problem... ?

KarenS’s picture

Get the latest -dev version of Date and run update.php. After that you will be able to add date fields. Repeating dates are disallowed because they have an unknown number of repeats, but any others will work.

markfoodyburton’s picture

Err, what about the node reference problem which looks the same? I already took the latest CCK ....



KarenS’s picture

Nodereference was OK to move before, I think I just need a slight tweak to fix that. I'll investigate.

KarenS’s picture

new43.19 KB

This should fix the problem moving nodereference and userreference into a multigroup.

markfoodyburton’s picture

That works :-)

Wow - this is ends up being a complex module - I'm glad its you not me!!

so, carrying on with the test, I get

Fatal error: Call to undefined function dsm() in /home/www/drupal/drupal/sites/all/modules/cck/modules/nodereference/nodereference.module on line 198

When I try and save a multigroup node with nodereferences in it...

I also notice that when I first press the "add mode" button, I think it does a validation of the form, but without any data in it - which results in errors about any mandatory fields???

Also, I still dont get the 'ordering' thing..... (I've not understood what you said about it above... maybe you have already answered this.... and said you would work on it, in which case, please ignore me!)
I get the field I've asked for in the multigroup, and I get a selector (which increments) as I 'add more' (using the AHAH)... All very cleaver...

But, I previously thought I would be able to influence the names of this using the fields given in the multigroup
(day 1, day 2, whatever...)
And then those labels would be used for the selector... but that does not seem to be the case?
Indeed, I can't see where those labels would appear?

Meantime, the '0', "-1 0 1", "-2 -1 0 1 2" stuff is interesting, but as I've said before, probably only needs to be there for 'advanced' use.. I think it's cleaner for now not to have it. (Or to have the proper javascript version working)... - I THINK this is what you have said too, but I'm not 100% sure ;-)



KarenS’s picture

The 'dsm' error is debugging cruft I left in nodereference, I just committed a fix for that.

I don't know where you're seeing a 'Add mode' button. I don't have any such thing. How about a screen shot?

The 'ordering' thing is probably that you're not seeing the right form because you either have javascript turned off or you need to clear the theme registry out by emptying the cache table. With javascript turned on and the right theme you won't see it.

markfoodyburton’s picture

new11.45 KB

So, I have a multigroup call menu
inside there, I have a node reference...

you can have a screen shot attached ... actually - you can visit http://www.petitstilleuls.com/ , as long as you don't laugh, and you come and stay :-) - it's a simple site (and actually, in some ways, I was experimenting with Drupal to see HOW simple I could make things - and ended up realising some of the stuff isn't quite as simple as one might expect) - anyway, we're planning on running a Chambre D'Hote (Bed and Breakfast) which does evening meals, so, a really really basic application for a web site - In this case, I want people to be able to say what - if any - evening meals they would like - nothing could be simpler for by the power of Drupal.... Errr.... Doh... You will see on the booking form I've gone for the simple option (just the number of meals), but, wouldn't it be nice if they could say "On the evening we arrive we want a slap-up meal, and then the next day, something simple will do" sort of thing... hence the multigroup....



BWPanda’s picture

Get the latest -dev version of Date and run update.php. After that you will be able to add date fields.

Thanks, that did the trick.

BWPanda’s picture

Ok, this time I'm having the same problem with the Computed Field module. I've updated to it's latest version, but no luck...

dydecker’s picture

Fantastic work, KarenS

Unfortunately there is some Javascript interference between multigroup.module.txt and the taxonomy-based Active Tags module. Clicking "add more" to add another group brings up another instance of the taxonomy field.

jastraat’s picture

Karen - thank you for implementing this! It's a great addition to CCK. When do you plan to integrate it into the Drupal 6 version?

amariotti’s picture


Junro’s picture

subscribing :)

KarenS’s picture

To the last few questions:

#167 - not all fields will necessarily work, I am assuming I can count on those that let the content module handle multiples, so that's what I'm allowing in. I also added a hook so other modules can let us know their fields are OK. If computed field handles its own multiples but the field will work correctly in this code (someone will have to test that), it can implement a hook to allow it in.

#168 - I'm no javascript guru, so I don't have any good ideas on how to debug that, patches welcome.

#169 - I'm going back and forth about whether or not this is really ready for prime time. I may leave it out of the official release and then commit it to -dev immediately after that. Or not. I can't decide.

melchior’s picture


has somebody get combofield or multigroup working with drupal 5.x?

or is there an alternative?


KarenS’s picture

It would be impossible to get this working in D5. It relies heavily on the fact that we've moved multiple value handling out of the fields and into the content module in D6, and also on the improved FAPI-ization of the D6 widgets. I wanted to do it in D5, but couldn't get it to work. I used what I learned by trying that to make changes in the D6 CCK code so that it could be done in D6.

mattiasj’s picture

Subscribing. I am really looking forward to using this when it's official. My projects would benefit from this functionality alot.

melchior’s picture

Hi KarenS,
thx for reply.

I just switched the project over to Drupal 6.

The reason I needed multiple groups is that I need a grouped field with 2 file-fields in it. (one for pdf and one for txt per item).

I tested combo field and multi group but only I only got multi group to work (don't know whats the difference at all)

The problem is that multi group don't like file-fields :( When I upload sth. any files appear as uploaded)

any ideas?

I now got it work with multi group that 2 file-fields are grouped. the problem is now, that the remove function
for files isn't working. it's ignored in every cases I tried :(

thx! :)

daggerhart’s picture


darrenmothersele’s picture


eMPee584’s picture

Dear Karen, would it be possible to commit your current code work and just hard-disabling it (f.e. by just gzipping the info file that should do) ?

KarenS’s picture

That's a thought, I could commit a version that has the .info file disabled. Let me think about that.

KarenS’s picture

I renamed this again, to content_multigroup, after a lengthy discussion about namespace problems with some of the CCK modules we can at least start this one off right.

I committed the code with no .info file to the -dev version. If you want to use it you'll need to create an info file so you can enable it. For everyone else, it will be invisible and won't even show up on the modules page because of the missing .info file.

This way people can try the code out and submit patches to improve it.

Woodside’s picture

new4.28 KB
new3.44 KB
new4.28 KB

Came across an issue with deleting values in grouped fields. I have a combo field with 2 columns. After adding data, if I go back and clear out some of the fields, the data shifts up a group instead of staying in the initial group. See the attached. I created 6 record groups, then cleared out the cells on some of the middle groups, the bottom data shifted up.

The attached screen shots should make it more clear. Also attached is a simple views in table format.

sbrattla’s picture

Title:Combo field - group different fields into one (multi value fieldgroup?)» FileField


Would anyone have any idea on how to get the CCK FileField (and possible ImageField) working with this? It works fine to add FileField to a multigroup,
but every time i try to upload a file - i can't see the file as uploaded. However, when i check the file folder, the files are there. So, it seems that files are uploaded but just not shown as uploaded...

catch’s picture

Title:FileField» Combo field - group different fields into one (multi value fieldgroup?)

reverting title.

KarenS’s picture

#182 - I was confused about what you meant at first but I think I get it now. You have a multigroup with several fields and you want to have some blank values in the middle for some of those fields.

The normal CCK handling of blank fields is to wipe out empty values and that's what's doing this. The empty values get wiped out which moves the filled out values into a new position. So we need to find a way to preserve those empty values in the middle of the pack. This might be very tricky. This sort of leads into another old issue that we've never done anything with -- changing the way we delete values to allow you to mark the ones you want deleted instead of assuming all blank values are to be wiped out. Fixing that would probably fix this, but that will require a change in the way core CCK handles empty values.

That issue is #196421: Deleting unwanted multiple values / multiple values delta issues, so that probably needs some attention.

sbrattla’s picture


How did you get the field fields to work? I have the excact same problem as you - the files does not appear when they are uploaded (even though they are uploaded, because i can find them in the files folder).

drupaloSa’s picture


hass’s picture

Found a bug in content_multigroup. See #324049: Layout issues with long fields

obrigado’s picture


jhodgdon’s picture

new1.8 KB

Re #182, I am having the same problem, with the FileField and ImageField modules. If you browse to find a file, and then click Upload, the file is actually uploaded, but it then gets lost in the shuffle.

I actually spent a long time today debugging this and have found where the problem is.

Now the trick will be to fix it.

I will make a text file explaining the problem and attach it, because I think if I put it in the body of the report here, it will be formatted badly, yes? And probably not everyone wants to read it.

jhodgdon’s picture

new1.81 KB

Sorry, the formatting there wasn't good, try this one.

corneverbruggen’s picture


Dimm’s picture

Great work!

japerry’s picture

subscribing =D

sbrattla’s picture

Absolutely great work!

jhodgdon’s picture

Just as a follow-up to item #190-191...

I started on a simple patch (basically hacking that function that I pointed out in my attachment so it would look deeper in the array to find its values). I managed to get uploads to show up through that method, but then some other features were still broken (the Remove button didn't work, and sometimes you would upload a file and it would get attached to all 3 visible multigroup items in the list instead of just the one you were trying to attach it to). It was VERY buggy.

So, my opinion is that the simple patching approach I was trying isn't going to work... there is more going on than just this one function, and more places where assumptions are being made about the structure of $form or $formstate that are not valid any more in a multigroup. It's more than I can take on right now to fix it up, being in the midst (of course) of a project with a tight deadline. So I have decided not to try to use multigroups for this project. Instead, the plan is to use little nodes to store the "multigroup" fields, and a node reference field on the main content type, and hopefully get the Popups: Add and Reference module (or some similar hook_form_alter method) working with the latest CCK release so the sub-nodes can be edited from the main node (see http://drupal.org/node/322015 to watch progress on that).

3duardo’s picture

just wanted to add my vote for this sort of functionality too !!!!

Ekoe’s picture

Your solution in comment #196 is one we've used for my employers custom content manager and has served us very well. It's been a while since I last looked into this feature in CCK and I am very excited to see it's progress. Wish I got back to this sooner to have been a little more active in it's progress, it looks like dev has been on fire since I last visited.

jeremy_a’s picture

Bug report: "add more" in non-javascript doesn't add a new group.

I'm using the multigroup version in cck 6.2 dev.

gregstout’s picture

Bug report: This multigroup features works with tabs (cck_fieldgroup_tabs) when it comes to displaying the fields and groups correctly. The entire new tab because a multigroup. But when you click on the "add more values" button it only works for the first tab. If any other tabs have a multigroup on them, then these tabs will display with empty contents.

Great work on this addition to the module, by they way. Exactly what we needed to simplify things on some content forms.

(I am new. Let me know if I should post this or file bugs against "dev" versions some other way)

jhodgdon’s picture

Another followup on #190, #191, and #196 - the sub-node option didn't work out well for me either in Drupal 6. I ended up defining some custom content fields in a module - fields combining an image upload and some other text fields mostly. They are working fine, but since the D6 documentation on making your own CCK field module is lacking, it took a bit of work. Maybe it is time for me to add to the doc effort. :)

mistresskim’s picture

Problem in #199 can be fixed by changing line 971 from:

'#submit' => array('content_multigroup_add_more_submit_proxy'),


'#submit' => array('content_multigroup_add_more_submit'),

In the content.module, the submit handler in the content_add_more function goes via a proxy because the submit function is in a different file. Here, it looks like it's okay to skip since all the code is together. Maybe KarenS can confirm?

jrefano’s picture

this is great -- my only request is that eventually it allow for nested multigroups.

Jacine’s picture

This is so unbelievably AWESOME!

I can't even express how excited I am about this new feature, but I just wanted to say thank you so, so much!

jeremy_a’s picture

In a multistep form, or in a form with another submit button on it, Multigroup doesn't rebuild all of the groups; it starts again afresh. This is because it is building the $node object from $form not rebuilding from $form_state in content_multigroup_fieldgroup_form.

This workaround makes multigroup work in a multistep form: Change line 549 from

$node = $form['#node'];


$node = node_submit($form_state['values']);

arhak’s picture


peroyomas’s picture

May be good if the module accepts to use fields with data stored outside cck tables. At least from taxonomy, like the ones from Content Taxonomy.

jeremy_a’s picture

Bug report: Default values don't keep with textfields in multigroup, either as text or PHP. I tried setting the default with hook_form_alter as well, but it just returns the first letter of the string...

KarenS’s picture

For #208, mulitgroup needs to test whether the form is a normal form or not. There is work going on to fix the #196421: Deleting unwanted multiple values / multiple values delta issues, which is still a blocker. I'll try to get some of these changes incorporated into the module so that it will work when that gets fixed, but don't have time right now. If anyone wants to roll a real patch in the meantime, that would be great.

#207 is outside the scope of even regular CCK fields right now, so that won't get added in.

Scolo’s picture


mehlbye’s picture

subscribing and using :-)
Nice work!

markus_petrux’s picture

Patch is ready for review here: #196421: Deleting unwanted multiple values / multiple values delta issues If someone else could test the patch in there would be great.

I hope it makes it easy to build the multigroup module from there.

markus_petrux’s picture

Status:Needs review» Needs work
japanitrat’s picture

awhhhhhhh, I have desperately tried to find such a feature in other modules (like flexifield for instance, which doesnt really work) the last week and now I am reading THIS!

Absolutely needed feature that is. Hopefully we will find this one in 2.2

Roulion’s picture

I desesperatly waiting for this feature... Is there a release date we can expect?

3duardo’s picture

Thanks to all who are making this happen. It looks like it is getting close!

It would be great if someone intimate with this feature implementation could briefly summarize (ideally in lay terms) it's current status including any limitations, drawbacks or any other need to know details and, if at all possible, an idea of ETA on a release.

Having this information in one place would be great as it would help developers like myself and I'm sure many others in our project planning.

I am 40 days to launch and would really benefit from this. Thanks again for all the effort.

Roulion’s picture

exactly in the same situation.. I plan to launch at the end of next january, but i can wait for this thing (as well as this one http://drupal.org/node/295477).
Thanks a lot to all who are working on these real improvement !

markus_petrux’s picture

new43.04 KB

Here's a modified version of the content_multigroup module. It's not a patch so it can be reviewed easilly. Also, it is not working fully yet.

It needs the patch to content module posted in comment #40 of this issue: #196421: Deleting unwanted multiple values / multiple values delta issues

I would appreciate a quick review, but I will update this issue when I can fix the add more button and test optionwidgets, which is pending yet, so the review can wait until there's something more consistent to check. :-)

markus_petrux’s picture

new41.82 KB

And here's a new version where "add more" button works. I had to change a few more things, and also tried to optimize the code on a few places, when reading content type information, etc.

To test this, it is required to apply the patch posted in comment #40 of this issue: #196421: Deleting unwanted multiple values / multiple values delta issues

This version of multigroup module provides a checkbox that is used to tell CCK which fields should be deleted. On the other issue, it is mentioned that this 'remove' checkbox conflicts with filefield/imagefield modules because they provide their own 'remove' button. I'll try to prepare an alternative for cck and multigroup where a 'remove' checkbox is not needed, so it will work as it does now. CCK will consider fields to be removed when they are empty, but for multigroups, all fields in a delta row would have to be empty to be removed. This is not intuitive, but it is how CCK works right now, and it may offer less possibilities to conflict with existing CCK related modules, I guess, I hope.

Please, try this multigroup version, as it may help me find possible bugs. The way this module manages FormAPI structures is really complex, and I'm not 100% sure it works in all possible situations.

markus_petrux’s picture

A note on the version posted on #219: The AHAH "add more" button does not work when creating a node. It works when editing, however. I believe I know the cause and I have to test and code the workaround...

Though, I'll try to implement it all without an additional 'remove' checkbox (problematic for filefield/imagefield, ...). Field deltas will be deleted when they are considered empty, as it works now, BUT... when multigroup is involved, then Fields would have to be empty in the whole delta row, so CCK doesn't shift deltas for individual fields.

markus_petrux’s picture

Status:Needs work» Needs review
new42.51 KB

Here's a new version where "add more" button should work in all situations.

There's no additional 'remove' checkbox, and fields in deltas are only removed when all are empty, otherwise they remain and deltas are kept, so there's no shift causing inconsistencies.

The related patch for content module, which is required by this new version of multigroup module, can be found in comment #43 #196421: Deleting unwanted multiple values / multiple values delta issues

Code needs review, please.

KarenS’s picture

Status:Needs review» Needs work

I tried this out with a simple 'recipe' content type. Regular text and integer fields worked fine, but when I tried to add an optionwidgets select list for another field, you get all kinds of errors and the values are not saved. I don't have any more time to work on this now, but someone needs to try to find a way that optionwidgets will work.

KarenS’s picture

I should be more clear. I added a text field that uses a select list to provide a short list of text options. It shows up on the form just fine, but when you try to save it, all kinds of errors are thrown and the values for that field are not saved.

Optionwidgets was working in the earlier code, but you're made a lot of changes so I'm not sure where the problem is.

KarenS’s picture

new38.43 KB

Here are markus's changes as a patch.

markus_petrux’s picture

I'm sorry, KarenS. I forgot to test with optionwidgets, and so I forgot to check for that in the form validation process of the multigroup.

On my dev environment I added now a check for content_multigroup_uses_optionwidgets(), but there's something that doesn't work correctly, yet. The form is now processed and saving the data into DB as expected, but the values for optionwidgets elements are not correctly managed when building the form.

I'll try to fix that and post a new version, full code and patch.

qbnflaco’s picture


markus_petrux’s picture

Status:Needs work» Needs review
new44.96 KB
new43.99 KB

Well, here it is, in patch form, and also the complete multigroup module if that helps someone else to test.

Please, don't forget it is required to apply first the patch for content module located in comment #43 #196421: Deleting unwanted multiple values / multiple values delta issues

The patch here is quite big because it not only changes the way empty fields are managed, but also optimizes a few things and fixes bugs that were present in multigroup module as distributed in 6.x-2.1 release of CCK.

mistresskim’s picture

Would like to check this out but all five hunks of the #43 patch for content.module fail for me. Is that patch for CCK 2.x dev or 2.1?

markus_petrux’s picture

Would like to check this out but all five hunks of the #43 patch for content.module fail for me. Is that patch for CCK 2.x dev or 2.1?

The patch in comment #43 of #196421 modify content.module and includes/content.node_form.inc that have not been changed since 6.x-2.1.

- CVS Log for content.module
- CVS Log for includes/content.node_form.inc

I generated the patches from the command line in unified format and paths are relative to content module.

markus_petrux’s picture

There is an issue with inline labels for fields that needs an additional patch, as posted in comment #5, here: #173824: CSS: hidden inline field is a bit unexpected, add option for visible inline

Without that patch, inline labels are only visible for the first subgroup of fields. With that patch applied, then inline labels are visible for all fields in all subgroups.

cYu’s picture

I'm seeing odd behavior with nodereference fields. If I set up a nodereference to be Check boxes/radio buttons outside of a fieldgroup, set it required, and also set Number of values = 2, then it will display as I believe it should as checkboxes.

If I then move this field into a multigroup fieldset it will appear as radio buttons (acting as if I'd set Number of values = 1), and in the field configuration I no longer see Number of values as a setting.

Moving the field back out of the multigroup fieldset will then show Number of values = unlimited.

I also noticed that a Nodereference with two values will show in a multigroup fieldset as 2 radio buttons. But then when you click "Add More Values" the original 2 radio buttons are pre-pended with an "N/A" radio button for group 1 and for all subsequently added groups.

I believe I've correctly applied all the needed patches to the proper version of CCK to test out this, but being new to this I'd feel better if somebody could replicate these issues before setting the patch status to needs work.

markus_petrux’s picture

@cYu: AFAICT, this is intended behaviour because how certain fields store their own information. For example, optionwidgets for text/number fields, or nodereference with checkboxes. Each possible value for one of these is stored in its own delta in the database.

The mutltigroup module moves each delta value to its own subgroup of fields, so it needs to change checkboxes into radios because now you cannot enter more than one value per subgroup.

Then, the N/A is required in radios to allow you to enter an "empty" value.

When a field is moved into a multigroup, it inherits the multiple values of the multigroup. In fact, the multigroup module updates the 'multiple' attribute of the field to match the 'multiple' attribute of the group. Then, you can only change the 'multiple' attribute of the group from the administration panel, and the multigroup module will update all the fields accordingly.

cYu’s picture

@markus_petrux: Hmm...that explains it, thank you. I consider it a limitation that the current structure means that all fields within a multigroup have to be single value, but the functionality added by multigroup easily outweighs that I suppose.

I am aware of the N/A being needed in order to allow an empty value, but I forgot to mention that I was seeing this with a required field which should preclude N/A from being added. The N/A in fact is not added to the first fieldset when creating a new node with an Unlimited multigroup fieldset, but as soon as you "Add More Values" the second fieldset is generated with an N/A option and the first fieldset also gets an N/A radio pre-pended to the existing options.

yched’s picture

I consider it a limitation that the current structure means that all fields within a multigroup have to be single value
You're confusing fields and values. In a multigroup, all fields are multiple, with each 'row' holding *one* value of each field :

field_a 0, field_b 0
field_a 1, field_b 1
field_a 2, field_b 2

as opposed to a 'regular' group where you'd get :

field_a 0,
field_a 1,
field_a 2
field_b 0,
field_b 1,
field_b 2

'field_a [0-2]' *are* the multiple values, there's no way 'field_a 1' can hold several values itself.

Other than that, the behavior you describe about n/a and the 'add more' button definitely looks like a bug.

cYu’s picture

Ok, I think I follow. I originally had a misconception about what a multigroup fieldset was meant to do. I was picturing this sort of setup...

On a content type for a recipe you could have Ingredient as your multigroup fieldset, and each ingredient could have 2 text fields, one that was the ingredient name and one that was amount of that ingredient. That works fine in the current setup, but if you then want a set of checkboxes for each ingredient that lists stores where this ingredient is available and you want to be able to select multiple stores, then this is not feasible. Is that correct?

Concerning the N/A behavior, I think it might be linked to how "required" is handled in general in multigroup fieldsets as I'm also seeing inconsistent results for required textfields.

markus_petrux’s picture

Correct. CCK creates a table per content type where fields with just one allowed value are stored, primary key is the vid (node revision id.). When a field is defined to contain more than 1 value, then CCK creates a separate table for that field where the primary key is vid and delta.

CCK also creates a separate table for fields that are reused between several content types, but that's a different reason.

I'll look into the N/A issue, and let's see if we can turn this into something that worths releasing. Thanks for testing! :-D

markus_petrux’s picture

Regarding the N/A in required radios within multigroup behavior...

In the original code of the multigroup (the one that is shipped in CCK 2.1) there was the following code, that I respected in my modifications:

// Make sure new fields after the first have an 'empty' option.
$field['required'] = $delta > 0 ? FALSE : $field['required'];

This means that there will only be one value required. As soon as you create more subgroups, you need to be able to delete them, which is done by setting all the fields empty, so I guess the described behavior in #231 #233 by cYu is in fact necessary because we need a method to delete subgroup of fields.

Other than that, I'm ready to post an updated version of this module, as well as a new updated patch for #196421: Deleting unwanted multiple values / multiple values delta issues

Can someone please confirm what to do with the N/A issue? :-)

markus_petrux’s picture

I've found a situation that's not easy to solve, raised when testing date fields as mentioned in comment #46 here: #196421: Deleting unwanted multiple values / multiple values delta issues

The thing is, the multigroup module changes the form moving fields from their original position $form[$field_name][$delta] to $form[$group_name][$delta][$field_name]. Because this changes will affect the field identifiers in the form, and $form_state['values'], it needs to inject a validation routine that moves the fields to their original position. It can do so using form_set_value(), but that only affects $form_state['values']. It doesn't affect $element['#parents'].

The multigroup validation routine used now, is installed in a way that is executed after the field validation routines. This is required because since $element['#parents'] needs to reflect the position of the field in $form_state['values'] so field validation routines can use form_set_value() themselves. One example of this case is the nodereference module. Most of the fields can do their own validation regardless of the position of the field value in $form_state['values'].

The problem comes when a field validation routine needs to get the field value from $form_state['values']. An example of this is the date field. Since the multigroup validation routine has not been executed yet, the date field validation fails because the field value is not located where exepected yet. Date fields needs the value at $form_state['values'][$field_name].

If the multigroup validation routine is executed first than everything so it can move all the values to their original position before the field validation routines take control, then form_set_value() is broken for them because $element['#parents'] points to the position where the multigroup module moved the field on form preparation stage, and we cannot alter $element['#parents'] from the multigroup validation routine.

KarenS implemented multigroup validation routine to act prior to field validation rountines. I had to change that a bit as part of all the rest of the changes made to the multigroup module, but still used the same approach because that works for most of the fields shipped with CCK, and others.

But this approach breaks fields that need to access $form_state['values'][$field_name] from their validation routines, such as the date field. And this is not easy to know from the multigroup module so it could disable fields that are not compatible.

In summary, we need a method to alter $element['#parents'] to reflect the changes we make to $form_state['values'], so everyone else can use the FormAPI from their field implementation. The problem is HOW?

One thing I'm going to try is inject a valitation routine for every field that is executed before the original. If this validation rountine declares &$element, it can modify the callers value that will be used to call the validation routine of the field itself. And here I belive it's possible to alter $element['#parents'] so the field validation routine can use form_set_value(). I'm not sure yet if it will work.

Other than that, I'm not sure what else can be done. Suggestions welcome.

markus_petrux’s picture

Status:Needs review» Needs work
markus_petrux’s picture

Daily report :)

Well, I finally had to use #after_rebuild to undo the changes the multigroup applies to the form, so that all form related routines (cck field validation, subfields, nodeapi validation, etc.) can work as if the multigroup module was not present.

As an example of how this is moving to, here's the #after_rebuild implementation. It doesn't fully work yet. I'm having problems with delta values loosing sync, but I hope to get it fixed.

 * Fix posting data in the form structure.
 * We need to move the fields back to their original positions in the form.
 * To do so, the $form_state['values'] structure is scanned to move the fields
 * from multigroup->delta->field to field->delta position.
 * Once this is done, the '#parents' array of all elements in the form needs
 * to reflect the new position of the fields in the $form_state['values']
 * structure. Otherwise, validation routines implemented in fields would not
 * be able to use form_set_values() successfully.
 * The '#post' attribute of all form elements needs to be rebuilt as well.
function content_multigroup_node_form_after_build($form, &$form_state) {
  if (
$form_state['submitted'] && isset($form['#multigroup_info'])) {

// Fix $form_state['values'] structure for all fields in every multigroup.
foreach ($form['#multigroup_info'] as $group_name => $group_fields) {
$element = array(
'#type_name' => $form['#node']->type,
'#group_name' => $group_name,
content_multigroup_node_form_fix_values($element, $form_state);

// Fix $element['#parents'] array for all fields in the multigroups.
content_multigroup_node_form_fix_parents($form, $form_state, $form['#multigroup_info']);

// Make sure the previous changes are executed once.

 * Fix the element parents array for the fields in a multigroup.
function content_multigroup_node_form_fix_parents(&$form, &$form_state, $multigroup_info) {
  foreach (
element_children($form) as $key) {
    if (isset(
$form[$key]) && $form[$key]) {
// Check if the current element is child of a multigroup.
if (isset($multigroup_info[$form[$key]['#parents'][0]])) {
// Remove the group name, delta and field name from the #parents array.
$group_name = array_shift($form[$key]['#parents']);
$delta = array_shift($form[$key]['#parents']);
$field_name = array_shift($form[$key]['#parents']);

// Insert the field name and delta to the #parents array.
array_unshift($form[$key]['#parents'], $delta);
array_unshift($form[$key]['#parents'], $field_name);

// Update the #post attribute with the new form values structure.
$form[$key]['#post'] = $form_state['values'];

// Recurse through all children elements.
content_multigroup_node_form_fix_parents($form[$key], $form_state, $multigroup_info);

Any idea if using #after_build could cause problems that I could be missing?

markus_petrux’s picture

Status:Needs work» Needs review
new51.45 KB
new56.52 KB

Here's an updated version of the multigroup module. It requires the patch to core posted in comment #47 of #196421: Deleting unwanted multiple values / multiple values delta issues

It fixes the issue with inline labels for fields in multigroups mentioned here: #173824: CSS: hidden inline field is a bit unexpected, add option for visible inline

It also fixes a bunch of situations. The whole form processing for moving fields from group->delta->field back to field->delta has been completely rewritten and extended to work on all CCK fields we've tried. For example, text, number, nodereference, optionwidgets, datestamp, money, addresses and content taxonomy. I believe I don't forget any.

There are a lot of possible combinations, so there maybe some issues yet to arise. It needs testing. Please, test and report back any issues that you may find.

In regards to the N/A issue (comments from #231 to #237 above)... I have the feeling that required fields in multiple groups don't work as it should, and that there may be a better way. What we would like to do is this: When a field is required in a mulltigroup, it needs to be filled when a subgroup of fields (a delta) is not considered empty. But you should be able to empty a required field because that's required when you want to remove a subgroup. In any case, when a field is required, there should be at least one subgroup with values. Please, test current implementation and think about this approach. Sorry if I have not explained this correctly.

I'm attaching a patch and the whole multigroup module here if that helps someone testing.

markus_petrux’s picture

I have posted a note in the "Reviewers" group at g.d.o.


I hope this helps in testing this feature. The more it can be tested, the better for us all.

cYu’s picture

markus_petrux: I think the required issue comes down to 2 use cases
1. fieldset being required (meaning at least 1 non-empty set)
2. field being required (meaning field is filled in for every non-empty fieldset)

Right now you accomplish #1 in a round about manner by making at least one field in your fieldset required and have no way to accomplish #2. It looks like you might intend to code #2 but then will have no way to accomplish #1. So I would propose coding #2 but then also adding 'Required' to fieldgroup config to accomplish #1.

The use case that would not be covered by that approach is where you have a fieldset in which you want one or more specific fields to be required for the first (or at least one) fieldset but not for any subsequent fieldsets....which is the current functionality. But that seems to be the most obscure of the 3 use cases described.

keith.smith’s picture


(I've recently started testing this; so far, my experience has been very positive. I'll post back with more substantive reviews after I get further into it.)

markus_petrux’s picture

Hi all,

I believe this is almost ready. Let's see what you guys think about it. :-D

Again, here's an updated version of the multigroup module. It requires the patch to CCK2 posted in comment #47 of #196421: Deleting unwanted multiple values / multiple values delta issues

Changes since #241:

  • The required attribute of fields is applied to the scope of a single sugroup of fields. If a subgroup is used, it contains any non-empty field, then required fields are required, heh. If a subgroup is not used, all fields are empty, then required fields are not required, and FormAPI will not complain about that. The required star is displayed for required fields, but the validation is skipped when the whole subgroup is empty. It was tricky, but I believe I got it.
  • There is a new option for multigroups: required. It's available from the multigroup settings form. When enabled, a minimum of one collection of fields in that Multigroup is required.
  • There is another new option for multigroups: Multiple columns. Also available from the multigroup settings form. When enabled, each field is rendered on a separate column on the node edit form.
  • There is a new display option for multigroup subgroups: Table. There was a TODO note on the multigroup module to implement this feature. Now, it's done.

I hope you find it as useful as we do! :-D

Please, test and report back any issues that you may find. This will help the CCK maintainers evaluate it all, and maybe we can count on it for a future CCK release.

I'm attaching a patch and the whole multigroup module here if that helps someone testing.

VeeLin’s picture


Just like to say that this development looks really promising and thank you to all those who spend their free time working on it . . . I apologize for asking these non-critical questions but think a few people (including myself) would love to know:

1. How does this module relate to flexinode? Same question as posted here: http://drupal.org/node/324929 I know this is perhaps a bit unrelated but I was trying to figure out how flexinode works (what it actually does on the database side) and since the people in this group seam very knowledgeable I thought you may be able to answer it . . .
2. I'm assuming all this is NOT part of the current dev version so when do you anticipate content multigroup to be added to the dev version?

Thanks for any insight.

markus_petrux’s picture

1) I have posted in that thread. Hope that helps.

2) That depends on the CCK maintainers. I cannot speak for them, but I would guess that they won't include this feature unless they feel it worths. And they seem to be now more focussed on moving Fields to core, which means a lot of work, and time passes quickly. So who knows...

That being said, I guess this feature won't get in unless it's proven to work, and that means it needs testing and feedback. I hope that helps getting a more solid implementation, and that may help the CCK maintainers feel it worths. :)

markfoodyburton’s picture

just started testing. One small, yet huge disadvantage of this approach. I think this relates to #234. The multigroup object is NOT a field, its a group. I think there is a great deal to be said for thinking about a multifield object ?

Other than that (!), works as advertised for me.

guidot’s picture

I installed the latest module and the patch from #196421 and started creating an order form with a multigroup of unlimited items.

Every order has at least one item (multigroup setting "required" checked)
Fields used (name type, widget - settings):

integer, text field - min 1, max 9999, required
text, select list, list of allowed values - default value set, required
order number
text, text field
text, text field
node reference, auto complete text field - match: contains, reference by view
node reference, auto complete text field - match: contains, reference by view
text, text field
price per unit
decimal, text field
computed - multiplies amount by price per unit

Creating a new order works as expected. Great!

The problems so far:

  1. Every time I edit a node I get an additional item of fields with all fields empty (the unit field is set to "None") and FormAPI complains upon saving as long as I do not fill all required fields.
  2. There seems to be no way to delete a subgroup. (If deleting only works by emptying all required fields, than this depends obviously on 1.)
markus_petrux’s picture

@guidot: Thanks for testing! :-)

The problem with your example is the Computed field. Its own implementation of hook_content_is_empty() is returning FALSE, always. Try changing it to return TRUE. Probably, the Computed field author would have to implement some kind of check to tell if the field is empty or not, though. This is critical within the context of the multiple group because it affects how the required attribute of the other fields in the subgroup is checked. If any field on the multigroup is not empty, the subgroup cannot be considered empty, hence all required fields need to be filled in, and that's what's causing the problem that you have described.

markus_petrux’s picture


just started testing. One small, yet huge disadvantage of this approach. I think this relates to #234. The multigroup object is NOT a field, its a group. I think there is a great deal to be said for thinking about a multifield object ?

AFAICT, "multifields" need to be implemented by CCK field modules.

The Money field is one example, with just amount and currency. It's written to reused other components as much as possible, but it is still a particular implementation of "multifield". The Addresses module is another example of a configurable "multifield" field.

There's a lot of things to take into account, that may vary from different use cases, that's only possible with custom CCK fields.

The multigroup, on the other hand, allows you to keep several multivalue fields in sync. It's similar concept, but still each field is managed by itself. The multigroup module just deals with node editing and node view, so the fields in multigroups are presented in a particular form.

markus_petrux’s picture

@guidot: If you have the oportunity, please try testing the multigroup module with the code for Computed Fields I posted here:

#349548: Conditional result for hook_content_is_empty()

Edit: Here's another thing I noticed that you may wish to try with the Computed Fields module:

#349555: Triggering Computed Field code on node preview

markfoodyburton’s picture

Thanks for your reply,

your description of both alternatives is spot on - and I think they are two different ways of doing the same thing - and, actually, I'm not sure which is best.

My concern is about modules that will 'process' fields in some way. 2 examples: Computed fields and Editable fields.

For computed fields - it doesn't make much difference either way, but I think the grouping mechanism makes most sense.

For editable fields - I did think that the multi-field approach would be nicer - but ... actually - I dont think it would! You may want to mark SOME of the elements of a multigroup as editable, but not others - so you would not want to mark the entire group (field) as editable

In short - I think I was wrong - as normal - sorry :-)

But, what this means is that I need to work on editablefields to somehow enable an editable multi-group such that you can (if you wish) add the 'add more' and 'rearrange' mechanism to a multi-group when it's viewed as well as when it's edited.

Do you think that would make sense?



markus_petrux’s picture

But, what this means is that I need to work on editablefields to somehow enable an editable multi-group such that you can (if you wish) add the 'add more' and 'rearrange' mechanism to a multi-group when it's viewed as well as when it's edited.

To deal with fields that are part of a multigroup, the widget might be different than the one used when the field is not part of a multigroup. You may look at the function content_multigroup_group_form() to see how this is managed in the multigroup module. The multiple attribute of the fields is disable prior to invoking content_field_form(), also the required attribute is altered. For fields that manage their multiple values only the element related to the corresponding delta is used for each subgroup of fields. It's tricky.

For editablefields you can place the resulting form element on top of the form, so you don't have to worry about moving fields around the form as the multigroup module needs to do, but the submit handler needs to update only the corresponding delta value.

The editablefields module is a great thing. We'll probably use it for the project I'm working on. I may try to help integrating with multigroup module as soon as it's considered stable enough for inclusion in the CCK package.

markus_petrux’s picture

new58.36 KB

Here's an update with a couple of minor fixes:

- Add support for default values.
- Use group label for reporting error when multigroup is required (it was using group name).

I'm posting the full module only, mostly because the patch is quite big. Please, let me know if you prefer the patch.

markfoodyburton’s picture

If I understand you correctly, your suggesting if I find an element is 'editable' and it's part of a multi-group then I should ask the multi-group to build me it's part of the form and - as you say - add this to the top of the form - something like that...

Maybe the plan should be that the javascript finds the surrounding multigroup if it exists, and then does a different (multigroup) AJAX request back - asking for the full multi-group form (but, then, we should be careful to only allow editable those elements of that form that have been marked as such, and display the rest normally)...

I think merging multigroups and editable fields will be extremely valuable - obvious shopping cart like, or more generally 'spreadsheet' like applications.

However - happy to work on this together once editable fields is, indeed, stable... watch that space :-)

rconstantine’s picture

Are these changes being rolled into the dev version of CCK?

alextronic’s picture

Markus, I followed your advice in another thread and I got here, installed the module in cck's folder, activated it... but nothing, there's no change, there's no new (multi)group field available in the "manage fields" page. I even tried configuring the fieldgroups that I previously had formed, but there are no new options. Content module and Fieldgroup module are both enabled.
Sorry I'm not good at all creating / modifying modules, in fact I'm thankful that you prepared a version of the module with the patch applied... please tell me if I'm missing some step.
Thank you very much in advance, great work.

markus_petrux’s picture

new14.16 KB

@rconstantine #257: Yes, the D6 branch.

@alextronic #258: Once installed, you should see an single select list to choose type in the Add fieldgroup section of Manage Fields page. If you cannot see this, then maybe you need to clear the caches.

I'm attaching a ZIP that contains all the files of the content_multigroup module to help testing. The ZIP contains no directory structure, so it can be unzipped inside the modules/content_multigroup folder of CCK2 6.x-2.1.

Though, it is still required to apply the patch to CCK2 in #196421: Deleting unwanted multiple values / multiple values delta issues. That patch modifies a few lines of the files content.module and includes/content.node_form.inc and is required so that CCK can keep deltas for empty elements in multigroups.

Please, don't test on production sites!

cat999’s picture

Markus, could you please add 'content_taxonomy_options' and 'content_taxonomy_select' to $allowed_widgets and $no_remove_widgets (to add support of content_taxonomy module)
Thank you very much in advance, great work.

alextronic’s picture

It worked.
This is just wonderful.
You made an awesome work on this one.
When will it be official?

markus_petrux’s picture

@cat999 #260:

add 'content_taxonomy_options' and 'content_taxonomy_select' to $allowed_widgets and $no_remove_widgets (to add support of content_taxonomy module)

This is something where the multigroup module includes only widgets provided by CCK modules that manage their own multiple values. Third party modules providing widgets that manage their own multiple values should implement hook_content_multigroup_allowed_widgets() and hook_content_multigroup_no_remove_widgets() to tell the multigroup module whether they can be used with multigroup or not. Unfortunately, the only available information about these hooks is located on the multigroup module code itself, functions content_multigroup_allowed_in() and content_multigroup_allowed_out(). It's a general issue in CCK that it needs a bit more documentation, though I hope this will change in the future.

@alextronic #261:

Thanks for testing. The more people can review and test this, the easier for the CCK maintainers. They are busy now working on Fields in core, so I can't tell for sure.

markus_petrux’s picture

@cat999 #260 and #262: You may want to watch this one:

#350669: Add support for the content multigroup module?

rconstantine’s picture

I'm excited about this module and should be able to assist in testing after the holidays. I've been working on http://drupal.org/node/300084, the patch for nesting fieldgroups, and want to make sure it works with all of this. It already works with the "cck fieldgroup tabs" module, and I'd like to combine all three elements on a project I'm working on at work where I need 'spreadsheet-like' areas combined with regular fields in other areas, broken up into several pages (tabs) without using multiple content types. For spread-sheet functionality, previously I've just written traditional multi-field cck modules to handle this, but with coworkers that are more DBAs than programmers, I'd like to work to get as much functionality into the front-end as possible - and then get as much into the CCK module as possible to limit my maintenance.

So kudos for all of the work going into this. Dissecting other people's modules and patching them is not easy as I know.

markus_petrux’s picture

@rconstantine #264: Nesting fieldgroups is useful, and it would be nice if both features could work together. Please, let me know if you think the multigroup needs to be adapted in some way to make both changes compatible.

Back to multigroup updates... I have changed my workking copy to fix a couple of minor things (fix the form when number of repeats is 1, coding style, ...). Though, I'll wait a little to upload because there is something else that I'm wishing to achieve:

In #255 I added support for default values, which was something missing in original multigroup code. But, I now realise that this is not useful in all situations. The problem with default values is that they may cause confusion when the user doesn't want/need to fill in a subgroup of fields. A subgroup of fields is ignored, not stored in the database when all fields in the subgroup are empty. But if the widgets are built with default values... Maybe default values should be used only when the number of repeats for the multigroup is unlimited and just for the first delta when the node is created? Can anyone test this and provide some feedback. How default values should be used within the context of multigroups? Should we add an option for the multigroup to enable default field values or is there a reasonable way to do it programatically?

cat999’s picture

The patch for context_taxonomy works perfect.
Thank you!

cYu’s picture

@markus_petrux: I think the way you've implemented default values is the behavior I'd assume when dealing with the module. If a default value is configured, having a fieldgroup appear on the page containing this field without this default value would be undesired.

The issue seems more with displaying empty fieldsets before they've been demanded by the user and also with only being able to delete a fieldset by emptying all the data in it (which relates to #237, something less than ideal in my mind).

I haven't had a chance to grab your latest code, so excuse me if I've misinterpreted something. I should have some time to do more testing soon and also have an interest in combining this with nested fieldgroups. Looking forward to helping this progress, great work thus far.

markus_petrux’s picture

The issue seems more with displaying empty fieldsets before they've been demanded by the user...

hmm... I think that's the key. How about this? Empty subgroups should only be rendered on demand, or just one when creating a node. That way there would be no need to unset fields with default values. When you want a new subgroup you'll have to request it explicitly, and that will come with default values, if defined. I think I'll try coding this. :) (well, please correct me I'm missing something).

BTW, I have been talking about rconstantine's patch for Nested fieldgroups here in our office, and they say we need that as well, so I'll install that patch here... and well, see what happens.

rconstantine’s picture

Another option would be to allow the admin to choose which fields are the ones to look at in determining whether the the group is empty. The new CCK API allows us to specify what qualifies as an empty field in a traditional, hard-coded multi-field field, so maybe you could do something similar. You wouldn't be looking at the individual fields' required-ness, nor would you do a blanket 'all must be empty' check. I suppose at the same time, you could allow the admin to decide whether to populate each field with its default value or not.

I know this would be a lot of work, but sometimes the flexibility is worth it - though admittedly, I can't think of specific use-cases where this would be an advantage. The comment in #267 might be just what the doctor ordered.

@markus - I'm sure you'll let me know how my patch goes. Although I won't be in the office until next week, I will be checking the threads here (for fun?) and maybe working on it from home if I get bored.

markus_petrux’s picture

Oh, but we cannot touch the way CCK fields works. We should go live fully compatible with existing CCK user base. See this issue for details: #196421: Deleting unwanted multiple values / multiple values delta issues

Anyway, we've been testing here the approach mentioned in #267/268 and it seems to work nicely. Fields with default values are not the problem. The problem happens when "new" subgroups that the user has not requested are rendered with default values. If they don't need the subgroup, they have to unset the defaults manually, and that's annoying. But if "new" subgroups are only rendered on demand, then the problem is gone, bye. :D

Merry Christmas to all! ;-)

alextronic’s picture

@markus_petrux #262: Perfect so far... this thing works for me. If I should find anything strange will tell you. Thanks again man.

guidot’s picture

Markus, related to the computed field problem in #249 I tried it with setting hook_content_is_empty() to TRUE and that made it work. Thanks for that and for providing the patch to computed_field module (which I'm going to test later).

I think one big usability issue is the current way of deleting a subgroup. There is no way we can ask users to empty ten or more fields by hand (maybe each in a different and time-consuming way, depending on the widget) just to delete a single subgroup, not to think of multiple subgroups. I'm aware of the problems discussed #196421. Contributed fields like file field need to provide a standardized way (hook/function?) to trigger the deletion programmatically. That needs to be defined and multigroup needs have its part implemented. Then anyone who wants to have a specific field in a multigroup can go and file a feature request.

Thinking of it, the possibility of actions on multiple subgroups come to mind (like changing the content of several fields at once). Another feature could be creating a new entry by doubling an existing one.

markus_petrux’s picture

@guidot #272:

It's been discussed in comments #38/#42, and in comment #43 I opted for the current behaviour (see #196421: Deleting unwanted multiple values / multiple values delta issues). It's known for CCK users of multiple valued fields that they need to empty the values if they want to remove them, so the multigroup module works like that, and we don't need to worry about compatibility issues with other CCK fields (filefield and imagefield minimum).

On the other hand, a button to empty subgroups could be implemented by a separate module that could add a javascript behaviour to attach a 'remove' button or something similar. We discussed this in our office, and we'll probably do at some point, but the main goal now would be to complete the multigroup module, and that's easier if it can go live with less compatibility issues to worry about.

markus_petrux’s picture

Here's what could be the last patch, unless a major issue arises.

Changes since last patch:

- Fixed default values behaviour mentioned in latest comments.
- A couple more of minor fixes.
- Since it's not so experimental as it was :) it also includes .info and fixes the README.

I'm also attaching a tar with the whole module because the patch is so big that it might be easier this way for someone out there.

Don't forget that this module requires the latest patch to CCK2 in #196421: Deleting unwanted multiple values / multiple values delta issues

Please, don't try on production sites! ;-)

Edited: Known issues:
- Quick bugfix for red asterisk bug when pressing the "Add more values" button: see comment #280 bellow.

markus_petrux’s picture

Oops, the tar file has been renamed by the uploader (adding an underline after the word "tar").

Please, rename it to content_multigroup-119102-274.tar.gz before extracting.

cYu’s picture

The way that required fields are working is still irksome to me and it is because of the need to empty values in order to delete a fieldset. Perhaps I'm arriving too late in this issue, and none of these are real deal breakers, but I think the conceptual change of being able to remove a fieldset without having to empty values would be a more usable approach. Here are a few aspects of the module which I find confusing/less than ideal, but are necessary as long as emptying values is the only way to delete a multigroup. Even if another module is added later which can add a button that basically does the emptying for the user, these issues will still exist.

- Having a text field appear on a page with the little red asterisk should mean a validation error occurs if that field is not filled out. There are several scenarios, though, where that is not the case with this module.

- Not having a red asterisk next to a field while filling out a form, but then submitting the form and then seeing the asterisk along with a validation error does not seem good either but can happen when you "Add More Values".

- Having an N/A option automatically added to required radio button fields as described in #237 so that it is possible to empty a fieldset seems confusing since making a field required in the normal way to make sure you do not get that N/A radio button.

- Having a red asterisk next to a field, and then as soon as you click "Add More Values" seeing that go away can be confusing as well.

I think I understand why these need to happen with the current structure, but I think all of them could be worked around if emptying fields was not the way of deleting a fieldset.

markus_petrux’s picture

Having a text field appear on a page with the little red asterisk should mean a validation error occurs if that field is not filled out. There are several scenarios, though, where that is not the case with this module.

It happens only when the whole subgroup of fields is empty. Unless it is the first subgroup and the multigroup is configured to be required.

If there was a 'remove subgroup' button, there would be no inconsistency because the user is explicitly saying what should be ignored/removed. But we cannot ship with a 'remove' button because that generates a problem with fields such as filefield, imagefield, which provide their own. Please, see references in #273 above.

Not having a red asterisk next to a field while filling out a form, but then submitting the form and then seeing the asterisk along with a validation error does not seem good either but can happen when you "Add More Values".

AFAICT, the red asterisk is displayed for all required fields in multigroups. Always. It is just that the requirement is only enforced when a subgroup is "in use". ie. it contains non-empty fields.

Now, there is no empty additional subgroup. Only one when creating a node, and the user should press the "Add more values" button to request a new empty subgroup. This solves most of the annoyances because is the user itself who requests a subgroup that may come with required fields, which is known in advance because the first subgroup is always rendered. If you haven't already, please try the latest version.

Having an N/A option automatically added to required radio button fields as described in #237 so that it is possible to empty a fieldset seems confusing since making a field required in the normal way to make sure you do not get that N/A radio button.

The multigroup is just consistent with the way CCK2 works. If you create a field with optional radio buttons, CCK adds a N/A option on top of the list. The same happens with optional select lists, where '--None--' is added in this case.

IMHO, this is something we can live with. Well, not just me. The people who will be using the site I'm working on (meristation.com) was fine with that. Also, think about the huge user base of CCK2 today. http://drupal.org/project/usage/cck ...and the number of modules (contrib and surely custom) that depend on this.

Having a red asterisk next to a field, and then as soon as you click "Add More Values" seeing that go away can be confusing as well.

hmmm... this shouldn't happen. Was it with latest version? Could you please provide a bit more information on how to reproduce this?

In summary: I agree with you, but this discussion is too late now since CCK2 was released and started to collect a huge user base quickly. We discussed this in the other thread, and if you look, I tried to code this differently, but I had to agree with CCK maintainers it was too late for such a change.

If you think there is a better way to solve any of these issues, I would be glad to fix anything. But it should be something that can co-exist with current user base and dependent modules with 0 impact.

cYu’s picture

It happens only when the whole subgroup of fields is empty. Unless it is the first subgroup and the multigroup is configured to be required.

Yes, those are the scenarios where I saw this. Except the situation I'm describing as odd is -it is the first subgroup and the multigroup is configured to not be required.- Even with a remove button a user would still be able to create a new node without removing that fieldgroup or filling in that required field and then successfully submit the node without error.

Only one when creating a node, and the user should press the "Add more values" button to request a new empty subgroup. This solves most of the annoyances because is the user itself who requests a subgroup that may come with required fields, which is known in advance because the first subgroup is always rendered. If you haven't already, please try the latest version.

When clicking "Add more values" the new subgroups don't show required fields with the latest version, but that is by design because the originally rendered subgroups should let them know what is required or not? The problem I mentioned below with original subgroups losing their asterisks complicates this, but even if they do not lose their visual indicators it is still awkward for subsequent subgroups to not label required fields that can end up failing validation because they are required.

The multigroup is just consistent with the way CCK2 works. If you create a field with optional radio buttons, CCK adds a N/A option on top of the list. The same happens with optional select lists, where '--None--' is added in this case.

The issue is that this is happening on required radio buttons and select lists because it is needed in order empty a fieldset. In effect, as soon as more than one fieldgroup exists a required field cannot act like a required field because it needs to have the ability to be emptied.

hmmm... this shouldn't happen. Was it with latest version? Could you please provide a bit more information on how to reproduce this?

This happened with a fieldgroup with 2 basic text fields, one required and one not with unlimited number of repeats on the group. Adding a new node it appears with the first text field required, but as soon as you "Add more values" the first group loses the asterisk and the second group does not have one either. Maybe I have some other patch floating on my cck install causing that, I will try starting fresh.

It's been discussed in comments #38/#42, and in comment #43 I opted for the current behaviour (see #196421: Deleting unwanted multiple values / multiple values delta issues).

I didn't realize the comment numbers there were referring to the other issue and had never read through that thread. Now, though I see how you've arrived at where you are and see that this conversation has already been had. Thanks for bearing with me. I'll get a fresh install going with your patches and see if some of these issues go away and also put some thought into any ways that the other issues could be addressed without impacting current users.

markus_petrux’s picture

The issue is that this is happening on required radio buttons and select lists because it is needed in order empty a fieldset. In effect, as soon as more than one fieldgroup exists a required field cannot act like a required field because it needs to have the ability to be emptied.

Oh, I see. I didn't got it at once, sorry.

Anyway, we'll have to live with this unless a new idea arises to deal with how to flag empty subgroups. At least, my collegues here at the office agreed on working like this. And maybe they require me to work out an additional module to easy this. That could provide the 'remove' button, and even hide those N/A options if necessary. But we have a lot more things to work on, so maybe we don't have the time for this "add-on" after all, TBH. But still, it would be possible.

This happened with a fieldgroup with 2 basic text fields, one required and one not with unlimited number of repeats on the group. Adding a new node it appears with the first text field required, but as soon as you "Add more values" the first group loses the asterisk and the second group does not have one either. Maybe I have some other patch floating on my cck install causing that, I will try starting fresh.

Oops! You're right. This is a bug, and I'll to fix this. It shouldn't happen. The red asterisk should be displayed for all required fields. That was my intention.

I didn't realize the comment numbers there were referring to the other issue and had never read through that thread. Now, though I see how you've arrived at where you are and...

You're welcome. Thanks for the feedback. I basically agree with you, but we cannot do whatever we want because any possible incompatibilty, would affect a lot of users, requiring time and also money to adapt to anything we do here. So we are somehow anchored.

I'll post back when I can fix the red asterisk issue when using the "Add more values" button.


markus_petrux’s picture

A quick fix for the red asterisk bug when pressing "Add more values" button:

Affected file: content_multigroup.module

1) In function content_multigroup_node_form_after_build():

-      content_multigroup_node_form_fix_required($form[$group_name], $required_fields, FALSE);
content_multigroup_node_form_fix_required($form[$group_name], $required_fields, !empty($form_state['multigroup_add_more']));

2) In function content_multigroup_add_more_js():

[$group_name][$delta]['_weight'] = $delta;
$form_state = array('submitted' => FALSE);
$form_state = array('submitted' => FALSE, 'multigroup_add_more' => TRUE);
$form += array(

I'll post a new patch with this change and everything else that may arise when I have the time.

cYu’s picture

Thanks, those fixes did the trick for the required fields. A couple other things I'm noticing....

- On a required radio button text field within an unlimited repeat multigroup, if I create a new node and do not leave the group empty but also do not select one of the available options, validation will tell me "An illegal choice has been detected. Please contact the site administrator." instead of telling me the field is required. Adding a second fieldgroup will add the N/A option and automatically select it, which then returns a proper validation message, but if you do not add a second group you can see this "illegal choice" error.

- For consistency on validation messages t('%name field is required.' should be t('!name field is required.'

- Could you elaborate on that error message and include the group title as well?

markus_petrux’s picture

On a required radio button text field within an unlimited repeat multigroup, if I create a new node and do not leave the group empty but also do not select one of the available options, validation will tell me "An illegal choice has been detected. Please contact the site administrator." instead of telling me the field is required. Adding a second fieldgroup will add the N/A option and automatically select it, which then returns a proper validation message, but if you do not add a second group you can see this "illegal choice" error.

I think if would be easier to consider all fields non required when the form elements are built. Not just from delta > 0.

Fix would be:

-    // Make sure new fields after the first have an 'empty' option.
-    $field['required'] = $delta > 0 ? FALSE : $field['required'];

// Make sure new fields have an 'empty' option.
+    $field['required'] = FALSE;

For consistency on validation messages t('%name field is required.' should be t('!name field is required.' - Could you elaborate on that error message and include the group title as well?

hmm... I avail this oportunity to ammend the error displayed when the whole multigroup is required but there is no subgroup in use.

-        form_set_error('', t('Group %name requires one collection of fields minimum.', array('%name' => check_plain(t($group['label'])))));

form_set_error('', t('Group @name requires one collection of fields minimum.', array('@name' => t($group['label']))));

and the message you were refering to:

-        form_set_error($error_element, t('%name field is required.', array('%name' => $form[$group_name][$delta][$field_name]['#title'])));

form_set_error($error_element, t('!name field is required in group @group.', array(
'!name' => $form[$group_name][$delta][$field_name]['#title'],
'@group' => t($group['label']),
+        )));

Thanks for the feedback! :-D

netbear’s picture

Thanks for such great work!

jtjones23’s picture

subscribing and testing...thanks for working on this!

jdipper’s picture

Not sure if this is just me however I get the following error message when trying to submit a form which has a multigroup containing a date element.

warning: array_key_exists() [function.array-key-exists]: The second argument should be either an array or an object in date_elements.inc on line 48.

Interestingly, I only seem to get the error when there is zero records in the multigroup. As soon as I have one in there, the error disappears, even if there is a blank row.

I don't get the error on any date fields that I have as normal CCK fields.

Drupal and all my modules are on the latest version, and I applied the latest patches from both this discussion and http://drupal.org/node/196421.


markus_petrux’s picture

@jdipper #285: Could you please try the patch in comment #7 here: #324290: warning: array_key_exists() [function.array-key-exists]

@all: Here's an updated version of the multigroup module. :-D

Changes since lastest version, in comment #274:

  • Bugfix: red asterisk bug when pressing "Add more values" button (see comment #280 above)
  • Bugfix: required attribute for field set to FALSE always, not just when delta > 0 (see comment #282 above).
  • Bugfix: error messages related to required attributes consistent with FAPI (see comment #282 above).
  • New feature: Table display mode for subgroups has been splitted into a couple of variants. 'Table - Single column' renders all fields on a single cell. 'Table - Multiple columns' renders each field on a separate column (equivalent to previous table display mode).

Required and/or recommended patches:

Please, don't try on production sites! ;-)

Again, I'm attaching the content multigroup module in patch form, but also all the module files tar'd for easy the task of testing it.

Thank you very much to all those that have tried. Your feedback has been great! :)

Edited: Please, remove the underline after the word "tar" from the tar filename before extracting. It's the uploader that renames the file for some reason. The file name should be "content_multigroup-119102-286.tar.gz".

andrewmacpherson’s picture


drewish’s picture


jdipper’s picture

@markus_petrux #286 - Smashing! Works a treat :-).


KarenS’s picture

Sorry for disappearing for a while, but I've been totally buried. I plan to get back and try this out today or tomorrow (probably tomorrow) to try to move this along. I'll look at all the related code including the issue with delta values and the nested fieldgroup issue and see if we can get all or part of this committed.

markus_petrux’s picture

Great news! :-D

denislabonkink’s picture

Can't add content taxonomy(free tagging) in fieldgroup.
When clicking on Save, it shows the following message:
This change is not allowed. The field XXXXX handles multiple values differently than the Content module. Making this change could result in the loss of data.

markus_petrux’s picture

denislabonkink #292: I'm sorry, but not all widgets are supported by multigroup.

You'll see this more clearly when using multiple select widgets. When moved into a multigroup, the widget is transformed into a single select element for each subgroup, because each subgroup can only store a single value, one delta. This kind of transformation in the widget are not possible with freetagging elements. These elements allow you to enter more than one value per widget, and this is not possible under the context of a multigroup because each subgroup of fields is stored on its own delta row in the database.

denislabonkink’s picture

markus_petrux #293: Are there any plan to support multiple values per widget? It is critical for me.

By the way, there is a way to bypass your error message:
Create a multigroup.
Disable Content Multigroup module.
Add your multiple values widget(e.g freetagging field) to your multigroup. And save it.
Enable Content Multigroup module.

However, only the 1st value is saved as markus_petrux wrote.

markfoodyburton’s picture

I dont know, but I'm wondering if this is the same misconception I had about multigroup. Multigroup keeps in sync the multiple values of a set of fields. It does not 'combine' a number of fields into one. - for that - Markus has pointed me towards http://drupal.org/project/flexifield?

markus_petrux’s picture

markus_petrux #293: Are there any plan to support multiple values per widget? It is critical for me.

Such a feature is actually restricted by the way data is stored. One delta can only contain one value.

Though, I think it should be possible to write a custom field that is able to store more than one term per delta serializing the array of values, so that there's a string in the database to store them all. The problem then is that serialized information cannot be queried, at least easily, therefore there's no integration with views, etc.But if this doesn't matter in your case, a custom field that serializes the data would work. Though, I'm afraid this is outside the scope of this multigroup issue.

Gribnif’s picture

I have found what I believe is a bug in #286. I have a multigroup with two columns, each containing three text fields. If I enter text only into some of the rows in the second column, upon saving, these values don't match up to the correct values in the first column.

For example:

[foo] []
[bar] [something]
[baz] []


[foo] [something]
[bar] []
[baz] []

If I enter a single space into the empty fields in the second column, they work as expected.

Gribnif’s picture

In order to be consistent with other CCK fields, shouldn't the table headings generated by this module also have colons after them? Right now, my form looks kind of odd without them, and I have to manually go into each field and add the colon to the field label.

markus_petrux’s picture

#297: It seems that you're missing the required patch to CCK2 posted in #196421: Deleting unwanted multiple values / multiple values delta issues

#298: It was my intention to do not draw colons for field labels when the multigroup is rendered as a multiple column table, basically because this is how column labels are rendered in other Drupal tables. Example: http://drupal.org/tracker

@all: this is now being revised by KarenS, so there may be updates that change the way it has been implemented. A button to remove values may be added to CCK multiple valued fields, and that would be great for the multigroup module as the UI may end up a lot more intuitive. :) Discussion is taking place at #196421: Deleting unwanted multiple values / multiple values delta issues

marcvangend’s picture

May I use comment #300 to express my gratitude to all the people who are working so hard on this? It's great to see the progress that is being made. So, markus petrux, KarenS and all the others: Thanks!