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!
/andreas

This issue was locked as requested by markus_petrux.

CommentFileSizeAuthor
#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
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

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.

Thanks,
Kaspar

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

subscribing

Terebinth’s picture

Subscribing

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
FileSize
12.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

Subscribe.

-Vctior
http://drupalsearch.org

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

Subscribink

j0rd’s picture

subscribing. Thanks for moving this forward. Desperately needed.

--
Freelance Web Designer

Anonymous’s picture

subscribing

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"...

Help!

lacitpo’s picture

subscribing

markus_petrux’s picture

subscribing

jeronimost’s picture

subscribing

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

subscribing

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

subscribe

graou’s picture

suscribing

gauravkumar87’s picture

subscribing

markus_petrux’s picture

Hi,

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

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

FileSize
17.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

OK:

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

FileSize
19.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

FileSize
21.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

FileSize
20.86 KB
26.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

Subscribing

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
FileSize
17.15 KB
190 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.

Cheers

Mark.

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

FileSize
22.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

FileSize
3.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.

Erin

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

FileSize
36.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

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. ');

Correct:
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?

Anonymous’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
FileSize
36.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
FileSize
35.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
FileSize
135 bytes
205 bytes
42.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

Hi,
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 :-)

Cheers

Mark.

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
Odd...

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 :-)

Cheers

Mark.

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 ....

Cheers

Mark.

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

FileSize
43.19 KB

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

markfoodyburton’s picture

That works :-)
THANKS!

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 ;-)

Cheers

Mark.

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

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....

Cheers

Mark.

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

subscribing

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

hi,

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

or is there an alternative?

thx!
melchior

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?

// EDIT
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! :)
melchior

daggerhart’s picture

subscribing

darrenmothersele’s picture

subscribing

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

FileSize
4.28 KB
3.44 KB
4.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

Hi,

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

Melchior,

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

subscribing

hass’s picture

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

obrigado’s picture

subscribing

jhodgdon’s picture

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

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

corneverbruggen’s picture

subscribing

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'),

to:

'#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'];

to

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

arhak’s picture

subscribing

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

Subscribe

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

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

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
FileSize
42.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

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

subscribing

markus_petrux’s picture

Status: Needs work » Needs review
FileSize
44.96 KB
43.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.
    unset($form['#multigroup_info']);
  }
  return $form;
}

/**
 * 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
FileSize
51.45 KB
56.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.

http://groups.drupal.org/node/17574

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

subscribe

(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

Hello,

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):

amount
integer, text field - min 1, max 9999, required
unit
text, select list, list of allowed values - default value set, required
order number
text, text field
description
text, text field
customer
node reference, auto complete text field - match: contains, reference by view
vendor
node reference, auto complete text field - match: contains, reference by view
comment
text, text field
price per unit
decimal, text field
sum
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

@#248

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?

Cheers

Mark.

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

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

@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?
Congrats.
Alex

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.

Cheers

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():

   $_POST[$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

subscribe
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.

Jack

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

subscribing.

jdipper’s picture

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

Jack

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

Bug:
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] []

becomes:

[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!

3duardo’s picture

I second that emotion!

Thanks to all of you for getting this far on this invaluable feature.

Anybody’s picture

Hey, really great feature!

Here are three things I'd like to mention (if already mentioned please don't care, I'm sorry then)
- It would be nice, if the automatical upload would start AFTER a new line is beeing added. Otherhands you always have to wait until a file is uploaded, before you can choose the next. This is just against the idea of AJAX.
- Default values are only set in the first line, not in later added groups
- If I upload a bigger file, a JS-Error appears

All in all I have to say THANK YOU for creating such a great module! It's really beeing needed.

If you need further information, please send me a mail.

Gribnif’s picture

#299 @markus_petrux: Duh. you are, of course, correct. Now that I've (correctly) applied that patch, the problem in #297 has gone away.

With regard to #298, I respectfully disagree. If I create a multi-value text field element (without multigroup), the table heading does have the colon, so not including them in multigroups is inconsistent, IMHO.

denislabonkink’s picture

@markfoodyburton: #295: Flexifield has the same problem. It can't save multiple value fields. See http://drupal.org/node/335490

@markus_petrux: #296

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.

If I understand correctly, are you telling me that CCK need to be redesigned/changed to provided a mean to hold multiple terms?
Disclaimer: I don't know drupal's code nor the "delta" that you are referring.

My goal is to be able to add unlimited groups, each containing a freetagging field. And a node is created for each tag through "Taxonomy Node" module.

markus_petrux’s picture

@denislabonkink #304:

When one field allows a single value, it is stored on a single column on the database where the key to that value would be the node id (simplified, because there's also the vid, the node revision id).

CCK is able to deal with multiple values per field. The widgets for those multiple values can be managed by CCK itself (example: text field with multiple values > 1), or managed by the widget itself (example: option widgets for text/number fields, freetagging, etc.). Since there may be multiple values per field, CCK creates a separate table per field where a delta is added to the key, so we can store each value on its own delta row (key now would be nid + delta). This gives us just one dimension of multiple values, and that's all CCK can do for us. It is not possible to store in the database multiple dimensions of values per field, by dessign.

In the context of the multigroup, all fields need to be multiple value, so that we can manage a single collection of values organized into subgroups in unison.

Without multigroup you would have:

field A - delta 0
field A - delta 1
field A - delta 2

field B - delta 0
field B - delta 1
field B - delta 2

freetagging field - deltas 0, 1, 2, ...

You can have any number of values per field. They are not synchronized to each other.

With multigroup, it's the same data, but rendered/edited differently:

Subgroup 0:
- field A - delta 0
- field B - delta 0

Subgroup 1:
- field A - delta 1
- field B - delta 1

Subgroup 2:
- field A - delta 2
- field B - delta 2

And the multigroup module keeps the deltas in sync for you. So you can create an receipt with a multigroup for ingredients, an order, etc.

However, we can only manage one dimension of multiple values. Note it's just the same data but managed differently.

Since the freetagging field is a multiple values field per definition. ie. you can enter more than one term per widget, then we cannot use it within the context of a multigroup because the multigroup itself needs a delta for each subgroup of fields, and we cannot store more than one term id on a single delta row in the database.

We cannot do the following:

Subgroup 0:
- field A - delta 0
- field B - delta 0
- freetagging field - deltas 0/0, 0/1, 0/2, ...

Subgroup 1:
- field A - delta 1
- field B - delta 1
- freetagging field - deltas 1/0, 1/1, 1/2, ...

Subgroup 2:
- field A - delta 2
- field B - delta 2
- freetagging field - deltas 2/0, 2/1, 2/2, ...

The only way would be if the second dimension that a freetagging field would need within the context of a multigroup was if the term ids for each subgroup were serialized, so they could be stored on a single delta row in the database. But that would have to be done with a custom module, there's nothing like this AFAIK.

I hope that it's clearer now where the limitation is.

cYu’s picture

That is a good explanation markus, thanks. When I first came to this issue I had the misconception that any standard fieldgroup that I could create would be able to be transformed into a multigroup, but the way this module piggybacks onto CCK as you've described doesn't allow this. For the same reason that a freetagging field cannot be in a multigroup you can also never have a set of checkboxes or a multiple value select in a multigroup fieldset. I still consider that original functionality as ideal, but without some sort of nested deltas in CCK or a serialized data hack I can see why it isn't possible.

Most recent testing looks good though. If #196421: Deleting unwanted multiple values / multiple values delta issues progresses to having checkbox remove support, would that mean that required fields could go back to behaving like required fields within multigroup fieldsets (radio buttons not have N/A, nodereferences not having a [none] option, etc.)? I'd like to see that in order to preserve consistency and avoid confusion for people configuring content types.

Anybody’s picture

Sorry, the JS-Error comes from CCK Image - Module. Hopefully they will fix it. Furthermore the upload-thing... so the only problem left is the thing with the default-value which might be easy to handle, isn't it?

pkej’s picture

Adding my support to #300 and of course subscribing.

pauline_perren’s picture

subscribing and testing

tlogan’s picture

When I set the style to be "tab" for a multigroup I get an error when clicking the "Add more values"...
warning: Invalid argument supplied for foreach() in D:\InetPub\wwwroot\drupal\sites\all\Modules\cck\modules\content_multigroup\content_multigroup.module on line 1256.

This is true regardless of field types in the multigroup or what options are selected.
The same multigroup works fine if the style is set to anything other than tabs.

Versions Installed
Drupal: 6.8
CCK Fieldgroup Tabs: 6.x-1.x-dev (2008-Oct-01)
Content: 6.x-2..x-dev (2009-Jan-11)
Content Multgroup: from post #286

RainbowArray’s picture

Subscribing. This functionality would be essential to a site I'm working on. Any thoughts on an ETA on when this might be rolled in? A week? A month? Several months? Not to pester, just so I can plan as to whether it will be feasible for me to put this into the site I'm working on. Thanks so much!

Anonymous’s picture

Subscribing and testing. Thanks to all for the hard work!

tombigel’s picture

subscribing and testing

markus_petrux’s picture

@those who are testing this feature:

First, thanks for checking and for all the feedback that you can provide. However, please note that this feature depends on a patch in CCK2 that's currently being rewritten, and also this feature is being rewritten...

What we're trying now is provide a method where fields in multiple value widgets will be removed by means of a 'remove' button provided in the user interface. Not by emptying items, as it is required now. That will hopefully turn multiple value widgets more intuitive to handle by the user, and once that 'remove' button thingy works for normal fields, it's going to be used here as well, for multigroups.

Please, check out the progress of: #196421: Deleting unwanted multiple values / multiple values delta issues ...there's already a patch there where the new 'remove' button can be tested with multiple value fields, so you can get an idea of where this is going...

naxoc’s picture

subscribe

konzepz’s picture

Hi all.

WEIRD: The module doesn't appear in the my modules list. Tried to edit permissions, change folders from all/modules to the core modules, reinstall over and over and nada -- the module just won't appear.

I tried offline testing, and it worked. But trying to apply it to a project - nothing seems to work. Any help? Anyone?

Thanks.

tombigel’s picture

Just to add on @konzepz description:

We are using the latest Aquia Drupal 6.8, with a lot of 3rd party modules installed.
I tried to upload a different module, just to check permissions, and it worked.

On my local machine and on another Drupal site the module was recognized.

The only difference I found between this site and other sites is the in the DB we changed the prefix of all the tables from "drupal_" to "as_".

Anybody’s picture

Made the same mistake... you have to copy it to: sites/all/modules/cck/modules ;)

Have fun with it.

poundy’s picture

subscribe

markus_petrux’s picture

Title: Combo field - group different fields into one » Combo field - group different fields into one (multi value fieldgroup?)
FileSize
17.23 KB
77.91 KB

Hi all,

Here's a new patch that works with the patch to CCK attached to comment #84 of this issue: #196421: Deleting unwanted multiple values / multiple values delta issues.

For additional indications, please check comment #286 of this issue, where the latest patch can be found.

I haven't had time to test this new approach with different widgets, so any help here is much appreciated. Thanks. :)

I'm also attaching the content_multigroup module on a tar file to help testing this. This tar should be extracted inside the cck/modules folder replacing the existing content_multigroup module with the one in this tar.

The tar file name should be renamed to "content_multigroup-119102-320.tar.gz" before extracting. It is the uploader here that adds an underscore after the work "tar" that needs to be removed before extracing.

Edited to mention that filefield/imagefield are not compatible with multigroup. I opened a feature request to the filefield issues queue to try to discuss about it, and as a place to provide potential patches to them. Please, see #367267: Compatibility issues with Content Multigroup

ingacosta’s picture

@markus_petrux, thanks a lot! It's a great module!

I tried it on my test site and it works great. But in my development site I have the following errors:

user warning: Table 'lobbi.content_field_personalidad' doesn't exist query: SELECT MAX(delta) FROM content_field_personalidad in /var/www/vhosts/example.com/subdomains/mysite/httpdocs/sites/all/modules/cck/content.module on line 2438.

It happens when I drag fields into/out of the multigroup and then click on 'Save'. In this case the field name is field_personalidad

Regards

markus_petrux’s picture

@ingacosta #321: Try applying the patch against the 6.x-2.x-dev version of CCK.

Roulion’s picture

i tried it... looks awsome. No problem for me.

However, i have a problem with view.
I have a content type "player" and each player belongs to different club depending on seasons (that's why i need this multigroup module)
I want to display on a view, for each club (my view argument) the list of players and the season when they were there.
If I add my "season" field is the field list, all seasons are diplayed and not the one which correspond to the club (which is on the same row).

I'm afraid this would require and evolution of the view module, would't it ?

inteja’s picture

awesome. subscribing.

Roulion’s picture

I have a problem now with imagefield module.. the upload doesn't work. When the page refresh afetr uploading a picture, the image field disappear as well as the textfield which is just above
I use the last cck-6-2.x-dev version

eMPee584’s picture

Markus just wanted to comment: while i didn't upgrade my live cck folder since you started work, yesterday i did so using your latest patches and after running the fieldgroup update my simple textfield multigroups on http://hfopi.org/wanted showed up flawlessly again! Didn't even have to resave the nodes, and no data loss! Thx for all your work! Surely a mind-twisting issue..

markus_petrux’s picture

@Roulion #323: Regarding views integration of multigroups... hmm... I haven't tested, but I think I understand what you mean. Well, the multigroup doesn't change anything in the database, it just helps to keep a few field deltas in sync. This is described a little in comment #305 above. So views integration depends on each field's implementation. However, it is possible that the existence of multigroups may need a different method to keep the fields in sync as well in views. Not sure, I haven't explored this. Maybe it could be resolved on a separate issue once this is in.

@Roulion #325: Regarding the problem with imagefield... hmm... I found something similar testing with filefield, and I'm looking into that as well. It seems to me that the ahah handler of the filefield/imagefield is fooled by the fact that the form structure has been changed by the multigroup. I'll try to debug that...

@eMPee584 #326: Thanks for the feedback. I'm glad it worked for you. :-D

Roulion’s picture

@markus_petrux - thanks a lot for your explaination about views. As faras i need, it's not critical, i could manage without the thanks to php customfields (even if it might be considered as a quick and dirty solution).
About the issue with imagefield/filefield, it's strange because when i set up the fieldgroup module, it was working... (3 days ago !!). Well I'm waiting for the sun... coming from your work

Roulion’s picture

I encounterd another issue with the last patch.
I have a multigroup with 2 text feld (one single an one multiple lines ). I use BUEeditor, and my fielgroup is displayed as a table. When i add a row, the BUEeditor disappear... Moreover, the helping text is not displayed.

If i disable the table display for my fieldgroup I encounter exactly the same problem with the BUEeditor...

markus_petrux’s picture

@Roulion #329: This is probably because BUEditor is not compatible with Drupal.attachBehaviors. I recently reported a similar issue for the View Bulk Operations module not working with editablefields where I explained this a little:

- #363478: Compatibility with Drupal.attachBehaviors (View Bulk Operations issue)
- #359435: Editablefields will not work if Views Bulk Operations is also active (Editable Fields issue)

I believe BUEditor has the same problem as it initializes itself using $(document).ready() rather than, for example, Drupal.behavior.BUEditor().

The 'Add more values' of multiple fields in CCK (and also here for multigroups) execute Drupal.attachBehaviors(new_content) after the new DOM elements have been attached to the page via the AHAH request, and that requires the content of these DOM elements to be compatible with that. This is explained in misc/drupal.js, IIRC.

iaminawe’s picture

subscribe

trogie’s picture

Exactly what I was looking for!! Very nice work!

One 'bug' I just found:
-not possible to attach a multigroup inside a standard group

psibrtyger’s picture

subscribe

rconstantine’s picture

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

@trogie

Once this patch is complete, I'll amend the nested fieldgroup patch to allow for that.

Update: I didn't need to make any changes. Multigroups can nest properly inside fieldgroups using my patch. I am now working to ensure that fieldgroups CANNOT be placed inside of multigroups because things explode when that happens and it just doesn't make sense anyway.

Edit: Done

apaderno’s picture

Title: Combo field - group different fields into one (multi value fieldgroup?) » Combo field - group different fields into one
eliosh’s picture

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

confirm patch 286.

Great work

hunthunthunt’s picture

Firstly - sincere gratitude to all those that have worked on this, it's sure to be a KILLER addition to CCK.

BUG REPORT - Jan 29 dev release.

Created a Multigroup containing an image, date and text field. After changing the order of the group using drag and drop, upon submission I get the following warning:

warning: mysqli_real_escape_string() expects parameter 2 to be string, array given in /Applications/xampp/xamppfiles/htdocs/uplands/includes/database.mysqli.inc on line 323.

rconstantine’s picture

Imagefield is known to not work yet and will require a patch of its own once this is done and confirmed to work with all standard field types.

BTW, for anyone who's following the nesting fieldgroups patch - something in it isn't playing nice with this patch or the 'remove' patch that this patch uses. I expect to find the cause tomorrow. I'll be gone this weekend, so we'll see when I can get this fixed. Definitely by the end of next week. I personally need all three patches playing nice within two weeks. I'll then turn my attention to fieldfield and imagefield.

markus_petrux’s picture

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

@eliosh #336: "confirm patch 286" ??? ...that latest patch in this issus the one in comment #320. :-o

@hunthunthunt #337: I'm aware that filefield/imagefield doesn't work well with multigroup. However, AFAICT, filefield/imagefield works well ok when not in multigroups with the patch in [#1227997] (see comment #93 of that issue).

markus_petrux’s picture

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

Oops! restoring title, sorry.

hunthunthunt’s picture

@ markus_petrux #339 Imagefield is actually working OK, the direct upload does not work but browse>submitting the form will add the image/s to the node. I couldn't get to the patch at #issue #1227997 - gave me a 404.

Thanks

markus_petrux’s picture

hmm... my bad, a copy/paste error. I meant comment #93 here: #196421: Deleting unwanted multiple values / multiple values delta issues

Anyway, I'm too busy now to look at this. I badly have time to try to monitor these issues. The problem may also be related to the date field, which is not stable yet. Try multigroup with simple fields provided by CCK itself, then add another field from a separate contrib module, and maybe that way we can isolate the problem.

nicholas.alipaz’s picture

This is a really long thread and I am not really sure which patches to apply for testing, could someone clarify please?

markus_petrux’s picture

Nicholas, please read #320. It contains the latest patch for multigroup, but it also gives references to the required patch to CCK itself, and also points to comment #286 where additional indications can be found.

nicholas.alipaz’s picture

I did read #320, but still couldn't quite figure out what was to be added.

From what I gathered, add the patch from post #80 (which is actually post #70, I think you typed the wrong #). If so, that patch only seems to apply 6 out of 12.

Then either apply the patch in #320 or merge the tarball you provided in #320 with cck/modules/content_multigroup

Is this correct? Will my 6 out of 12 errors b an issue on patch? I also tried getting the version of the module from just before Karen posted the patch as well, same results.

Thanks for the quick response.

markus_petrux’s picture

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

hmm... it seems there's too much info in several places. Let's see if I can sum it up a little.

This issue deals with the multigroup module, which was left unfinished when CCK 2.1 was released.

If you wish to help testing (I wouldn't recommend any other kind of use until it gets committed), then you need 3 basic things:

1) Install the latest development version of CCK 2, release 6.x-2.x-dev

2) Apply the latest patch in #196421: Deleting unwanted multiple values / multiple values delta issues. This is now located in comment #84 of that issue. Besides the patch, you need to get 2 icons that are attached to comment #75 of that issue. These icons should be uploaded to cck/images. This patch allows CCK keep delta items in sync when working with multigroups. It also changes the way users remove field values. To date an item in multiple valued fields is removed when it is emptied. After this patch, empty fields are not removed, you use a 'remove' button instead.

3) Apply the latest patch in this issue, the multigroup module (located now in comment #320 above). Alternatively, you can get the tar file, and just replace the contents of cck/modules/content_multigroup. Then in module administration, install the multigroup module, then you can start using it in content types (fieldgroups now have a type option: standard or multigroup).

In addition to this, there are a few issues affecting other contrib modules implementing CCK fields. Information on this can be found in comment #286 of this issue, the multigroup issue. Also, note that filefield/imagefield don't work with multigroups, yet (please, see #367267: Compatibility issues with Content Multigroup).

Hope that helps.

rconstantine’s picture

Good summary Markus.

nicholas.alipaz’s picture

yes, thank you. And as rconstantine said, "Good summary Markus"++

two2the8’s picture

Amazing work, folks! I'm excited to see it in action.

itaine’s picture

After I apply the cck-196421-84.patch to Content Construction Kit (CCK) 6.x-2.x-dev (2009-Jan-30) I get the following error:

Fatal error: Call to undefined function content_inactive_fields() in C:\wamp\www\_\sites\all\modules\cck\includes\content.admin.inc on line 102

anybody else seen this before?

markus_petrux’s picture

@itaine #350: content_inactive_fields() should be located at the bottom of your content.module script. If it is not there, then try getting latest development snapshot of CCK 6.x-2.x-dev.

itaine’s picture

FileSize
453.95 KB

yes before and after the patch the content_inactive_fields() function is located at the bottom of content.module:

>
 /**
 * Helper function to identify inactive fields.
 */
function content_inactive_fields($type_name = NULL) {
  module_load_include('inc', 'content', 'includes/content.crud');
  if (!empty($type_name)) {
    $param = array('type_name' => $type_name);
    $inactive = array($type_name => array());
  }
  else {
    $param = array();
    $inactive = array();
  }
  $all = content_field_instance_read($param, TRUE);
  $active = array_keys(content_fields());
  foreach ($all as $field) {
    if (!in_array($field['field_name'], $active)) {
      $inactive[$field['type_name']][$field['field_name']] = content_field_instance_expand($field);
    }
  }
  if (!empty($type_name)) {
    return $inactive[$type_name];
  }
  return $inactive;
}

yet I still get that fatal error: Call to undefined function content_inactive_fields() in C:\wamp\www\_\sites\all\modules\cck\includes\content.admin.inc on line 102

I checked the content.admin.inc file and from line 98 to 116 I have the following:

/**
 * Helper function to display a message about inactive fields.
 */
function content_inactive_message($type_name) {
  $inactive_fields = content_inactive_fields($type_name);
  if (!empty($inactive_fields)) {
    $field_types = _content_field_types();
    $widget_types = _content_widget_types($type_name);
    drupal_set_message(t('This content type has inactive fields. Inactive fields are not included in lists of available fields until their modules are enabled.'), 'error');
    foreach ($inactive_fields as $field_name => $field) {
      drupal_set_message(t('!field (!field_name) is an inactive !field_type field that uses a !widget_type widget.', array(
      '!field' => $field['widget']['label'],
      '!field_name' => $field['field_name'],
      '!field_type' => array_key_exists($field['type'], $field_types) ? $field_types[$field['type']]['label'] : $field['type'],
      '!widget_type' => array_key_exists($field['widget']['type'], $widget_types) ? $widget_types[$field['widget']['type']]['label'] : $field['widget']['type'],
      )));
    }
  }
}

don't know much PHP but all looks well, the function calls to a function that exist. I've attached my cck folder zipped in case it can help the help :) maybe a quick comparison with your working copy will reveal where I went wrong. Thank you for your time.

eMPee584’s picture

hey markus i found some php errors occuring on editing/previewing a node containing a multigroup, have changed the checks a bit the attached patch is against the content_multigroup module as of patch #320..

rconstantine’s picture

@352 - have you visited your module activation admin page lately?

rpanna’s picture

@itaine - I was having similar problems...The problem was that when I ran the patch it changed the owner / permissions on the patched files as well as changed the SELinux context (run "ls -Z" to view), as a result apache was unable to access the patched files, after resetting the permissions and SELinux context things worked fine for me... hope this helps

ellen.davis’s picture

Category: feature » bug

I have similar problems as described in comment 310. When using a multigroup with style tabs(cck_fieldgroup_tabs) you get the below error message when clicking on "Add more values""

warning: Invalid argument supplied for foreach() in /Library/WebServer/Documents/ucfserd1/drupal-6.8/sites/all/modules/cck/modules/content_multigroup/content_multigroup.module on line 1250.

Veresions Installed
drupal 6.8
cck-6.x-2.x-dev.tar.gz 2009-Jan-31 with cck-196421-84.patch from http://drupal.org/node/196421#comment-1210769
content_module content_multigroup-119102-320.tar_.gz from comment #320
cck_fieldgroup_tabs 6.x-1.x-dev

The section of code mentioned in the error message is

// Rebuild weight deltas to make sure they all are equally dimensioned.
foreach ($form[$group_name] as $key => $item) {
  if (is_numeric($key) && isset($item['_weight']) && is_array($item['_weight'])) {
    $form[$group_name][$key]['_weight']['#delta'] = $delta;
  }
}

The cck_fieldgroup_tabs adds another structure in $form. For example, for the group named group_achgrp:
$form[fieldgroup_tabs][group_achgrp][0][_weight]

Where cck_multigroup expects the _weight to be at
$form[group_achgrp][0][_weight]

These issues in CCK Fieldgroup Tabs issue queue discuss this futher
http://drupal.org/node/315015 Modified AHAH callbacks are needed for forms with CCK Fieldgroup Tabs
http://drupal.org/node/325049 More than one tab group / Nested fieldgroups

rconstantine’s picture

See this: http://drupal.org/node/300084#comment-1242992

for the latest of my efforts to get this patch, the row delete patch, and the nested fieldgroup patch all working together. I haven't looked at #353's patch yet to see if it still applies.

Regarding #356, this patch: http://drupal.org/node/325049#comment-1204939 together with the stuff in the above link, should solve the issues mentioned. I'm using all of this stuff together myself.

As I mention elsewhere, I'll roll proper patches next Monday.

paulludington’s picture

Subscribe.

escuriola’s picture

Hello. I only want to thanks all of you because this is just what I need for my new website. Just on time!

For your information, I am combining this feature with flexifield and content complete with freetagging and more... and everythings works! Awesome because few days ago (before the #346 comment) it doesn't do.

Once again, thanks to all Drupal community for this great work.

Mark Theunissen’s picture

Woohoo!! Thanks for the great work. Looking forward to this becoming core CCK functionality.

rconstantine’s picture

See http://drupal.org/node/300084#comment-1254063 for my latest. I should get a new patch here Friday. Once I do, feel free to alert any down stream modules that you'd like them to adapt if necessary. Many modules should be OK without changes. It depends on what they do specifically.

comicat’s picture

subscribe

cYu’s picture

If in fieldgroup settings you set that the multigroup is not required, you should be able to delete the initially created set of fields when creating a node, shouldn't you?

My use case is that I have a multigroup fieldset that is filled in with tasks during node creation and another fieldset which allows a user to enter in that they've completed a task as they come back later and continually edit the node. The first fieldset is required, the second is not. Right now I'm unable to delete the completed task fields during node creation, some of which are required, and so I'm unable to save the node without entering placeholder data.

rconstantine’s picture

I don't quite follow you. Screen shots maybe?

Gribnif’s picture

I'm using everything detailed in #384, and am having problems with a nodereference that uses a view to generate the list of allowed nodes. In the settings for the field, I have "Advanced - nodes that can be referenced" set to the view. This is the only field in the fieldgroup.

When I first arrive at the node creation form, things work as expected. But, as soon as I click on "Add more values", the fieldgroup redraws and now the only option in all of the select lists is "-None-". All of the data from the view is gone.

Gribnif’s picture

Make that, "I'm using everything detailed in #346".

(For some reason, I can't edit my own comment. It gives me a false error message about needing to specify a project.)

cYu’s picture

FileSize
35.72 KB
15.4 KB
33.2 KB

Picture1 shows the setting in Multigroup which I've unchecked for 'Required'. Picture2 shows how the field looks when there is more than 1 group, and the ability to delete a group. Picture3 shows that if you have a required field in a Multigroup which is not required, you are unable to delete that group and will still be required to have an entry.

In this case the logic is something like, if people are going to list additional contacts the Name field should be required for each of those contacts and Phone Number optional, but I'll make the fieldgroup not required so that they do not have to list any additional contacts.

ingacosta’s picture

Excelent module. It's very useful for me. But:
What about the original issue? Does it work now? What do we need? How can we help?

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?)

BartK’s picture

"This is relevant to my interests."

Quite a lively discussion here, about a feature I'd love to see added to CCK. Thanks for all the excellent work being put into this. :)

Subscribing and testing.

rconstantine’s picture

RE #367, I just noticed that myself. It looks like a multigroup becomes required when any one of its fields is required, which, I agree, is not what should happen. At this point, I'm not sure how best to address this. Perhaps Markus would know better where to start. However, I don't think it's a showstopper at this point; more like a README item to note.

rconstantine’s picture

I have produced an update here: http://drupal.org/node/300084#comment-1291350

I'll try to pull out the multigroup stuff as a single patch, but the problem is that it now uses new features of the nested fieldgroups patch.

rconstantine’s picture

Looks like the latest dev of CCK introduced a bug in this here patch. The following function needs to look like this:

/**
 * Add AHAH add more button, if not working with a programmed form.
 */
function content_multigroup_add_more(&$form, &$form_state, $group) {
  $group_multiple = $group['settings']['multigroup']['multiple'];
  if ($group_multiple != 1 || !empty($form['#programmed'])) {
    return FALSE;
  }

  // Make sure the form is cached so ahah can work.
  $form['#cache'] = TRUE;
  $content_type = content_types($group['type_name']);
  $group_name = $group['group_name'];
  $group_name_css = str_replace('_', '-', $group_name);

  $form_element = array();
  $form_element[$group_name .'_add_more'] = array(
    '#type' => 'submit',
    '#name' => $group_name .'_add_more',
    '#value' => t('Add more values'),
    '#weight' => $group_multiple + 1,
    '#submit' => array('content_multigroup_add_more_submit'),
    '#ahah' => array(
      'path' => 'content_multigroup/js_add_more/'. $content_type['url_str'] .'/'. $group_name,
      'wrapper' => $group_name_css .'-items',
      'method' => 'replace',
      'effect' => 'fade',
    ),
    // When JS is disabled, the content_multigroup_add_more_submit handler will
    // find the relevant group information using these entries.
    '#group_name' => $group_name,
    '#type_name' => $group['type_name'],
    '#item_count' => $form[$group_name]['#item_count'],
  );

  // Add wrappers for the group and 'more' button.
  // Add wrappers for the fields and 'more' button.
  $form_element['#prefix'] = '<div class="clear-block" id="'. $group_name_css .'-add-more-wrapper"><div id="'. $group_name_css .'-items">';
  $form_element['#suffix'] = '</div></div>';
  $form_element[$group_name .'_add_more']['#prefix'] = '<div class="content-add-more clear-block">';
  $form_element[$group_name .'_add_more']['#suffix'] =  '</div>';

  return $form_element;
}

Where the $form_element stuff at the end now conforms to them main CCK module's way of doing this. The problem was an open div.

rancky’s picture

Title: Combo field - group different fields into one » Multivalue field in multigroup

It looks like multivalue fields cannot be used in multigroups...

Do you know this limitation ? Is there a solution to have multivalues fields in multigroups ?

This is already a problem with "Flexifield" module.

hass’s picture

Title: Multivalue field in multigroup » Combo field - group different fields into one
markus_petrux’s picture

@rancky: read #305 above.

lpt6’s picture

subscribe

upupax’s picture

subscribe

markus_petrux’s picture

Here's an updated content_multigroup module that contains a small fix that seems to work better with filefield. For additional information on filefield compatibility with multigroup, please see #367267: Compatibility issues with Content Multigroup

It's just in tar format due to the complexity of the patch, and it saves me a little time (precious thing these days). I just changed the AHAH handler of the multigroup with the fix recently made to includes/content.node_form.inc as in this patch.

Please, see comment #346 above for further information on the status of this module.

nevets’s picture

I though I would try the module out, downloaded content_multigroup-119102-378.tar_.gz, unpacked in sites/all/modules and it does not show on the modules list so I can not enable it. Any thoughts on why this might be?

Thanks

markus_petrux’s picture

@nevets: Please, read #346 above, point 3.

jrosen’s picture

Hi,

I am having some trouble and am greatly confused on how to get content_multigroup to work with fieldgroup tabs. Just like post #310, I was receiving the error on line 1250.

I have tried to follow the thread of patches and file replacements that are mentioned in this discussion and also in:
http://drupal.org/node/300084#comment-1291350
http://drupal.org/node/325049#comment-1204939

So now, when I click on the "Add More Values" button, I get a popup window that says an HTTP 500 error has occurred. Looking in my error_log, this is the error:

Call to undefined function content_get_form_element() in
/sites/all/modules/cck/modules/content_multigroup/content_multigroup.module on line 689, referer: https:///node/add/resum

Anyway, it sounds like some of you have managed to get Multigroup and Fieldgroup tabs working right now. I have found it very difficult figuring out which patches I need to apply and to which base versions of CCK, Multigroup, Fieldgroup, AHAH, etc.

Can someone who has this currently working, provide a current "roadmap" of what needs to be applied and to what base versions? Or make available a current "dump" of their cck module folder that I could pickup?

All of your hard work is greatly appreciated.

Thanks!

eMPee584’s picture

yeah jrosen you're right the complexity of this has quite taken off so to speak.. that's why i haven't updated my cck since long - never change a working fields mod.
Just hoping that the fields in core sprint put something into D7 that is prepared to handle all this (nested) combo field stuff in a more sane manner...

clarkwolfe’s picture

I figured it out, stupid me.

markus_petrux’s picture

@jrosen #381: compatibility between multigroup and fieldgroup tabs depends on #300084: Nested fieldgroup

Roulion’s picture

I tried to implement the #378 patch in the last tar ball proposed by rconstantine here, but the multigroup doesn't work anymore.
I have a fieldet with my fiel like
Field 1 + "add more values" button
Field 2 + "add more values" button

And not a bunch of field 1 and 2 with a unique "add more values" button...

I just replace the content multigroup flder in the version of rconstantine...

andreiashu’s picture

It is sooooo sexy ! thanks petrux.
Testing. Everything works fine until now (just basic stuff for the moment, no views or other stuff involved).

After this gets into core we have to build a statue to petrux :)

(subscribing)

andreiashu’s picture

content-edit.js file is located under cck directory, but from content.module and content_multigroup.module is referenced as: drupal_add_js(drupal_get_path('module', 'content') .'/theme/content-edit.js') so it should in fact reside under cck/theme dir.
Not very sure if this relates to this issue.

markus_petrux’s picture

@andreiashu #387: The file content-edit.js is provided by the latest patch I posted to #196421: Deleting unwanted multiple values / multiple values delta issues

AFAICT, that patch correctly places the file in the theme subdirectory of CCK.

@all: In regards to nested fieldgroups and fieldgroup tabs... for the moment, the multigroup module should be modified by the patches in #300084: Nested fieldgroup

This is all a complex situation, but I believe we cannot do more than just try to keep moving in the hope that this is finally in a state that can be committed to CCK. That means:

1) It is stable enough.
2) It is compatible with as much CCK fields and related modules as possible.
3) ...nice for Fields in D7 core.

Most of these depend on a few people trying to work on this and trying to make this compatible with other modules (for example, filefield), on you trying to help reporting feedback, and finally CCK maintainers who have a better understanding of all implications of such a change to CCK2, etc.

pkej’s picture

#305 to add more dimensions would be to use somewhat of the same approach as flexifield. Let each multigroup set be a separate node created for that purpose alone. Then each node would be able to store other fields inside themselves.

Of course that's quite something different from how flexifield and multigroup works.

rconstantine’s picture

When I get a chance, I'll look at the changes in #378 and roll them in with the latest on the nested fieldgroup issue. I have a couple of people running my last zip file version through its paces. So far, they aren't reporting any problems with the patches.

I am seeing a CSS issue in IE7. Some multigroups are invisible when the page is loaded (in edit mode), but when you click the 'Add more values' button, both the new row and the original show correctly. I am NOT a CSS wizard/ninja, so I haven't figured this issue out yet. This maybe only occurs when the multigroup is inside a normal fieldgroup which is initially collapsed. If there is anyone with IE7 CSS debugging skills out there, I could use the help. It really seems to be the only issue so far.

I have to disagree with Markus about requiring that solutions for other modules be in place before these patches go into CCK dev. In my opinion, if we all want this and it works well, then this should all go in. As I have mentioned elsewhere, that dev release should then wait to become an offical release until more modules support the changes. So we just disagree on when downstream modules should be made to support these changes. I'm not sure where the CCK maintainers sit on this point.

But like I said, my team's testing so far has been positive. We aim to complete testing within the next two weeks. We're testing using 200+ fields on a single content type which includes one or two dozen multigroups and many nested fieldgroups. It's pretty awesome I must say.

Lastly, from what I can tell from what I've read about CCK in core, I think the only area of the nested fieldgroup module that may need changing is the way AHAH functions identify where to place the content generated. Right now I have two functions for that, one for finding and one for inserting the generated content. So I think we're either close or there already when it comes to Markus' three points.

Last week, yched said he'd finally have time to look at these patches some time this month. So I'm hopeful that that is the case. We'll see. But the longer these sit out here, the more they lose momentum and the harder it is for us who have worked on them to shoe-horn them into the latest dev, re-roll patches, etc.

BWPanda’s picture

I just setup a test site to test Multigroup, and all was working fine until I tried adding a Date field to it. I noticed the patch for Date but it seems Karen had already committed it...

The problem was that my Multigroup no longer had a button to add more values, but rather individual buttons for the different fields within it. Back on the 'Manage fields' page, there was no longer a field to choose whether you used a Standard or Multigroup fieldgroup... (see attached screenshot)

Is this a bug or did I do something wrong?

jrosen’s picture

Status: Needs review » Active

I have the same problem as #385

I applied the patches mentioned from #300084: Nested fieldgroup - comment #116 and #378 from this thread.

Now I have an "Add More Values" button after each individual field type in my Multigroup. In my Multigroup I have the following field types:
Text Field
Date Field
Location Field

If anyone has this stuff working, any help would be appreciated.

Thanks.

rconstantine’s picture

Regarding #385 where it seems my latest zip was used and then Markus' zip put on top, or something like that: it won't work. My latest zip includes changes to multigroup as well. My intention was for the row delete patch to get added to CCK dev first, followed by Markus' version of multigroup. Then, because I'm keeping my code up to date with his (except for the latest patch from him), the fieldgroup patch (which would include minor changes to multigroup) could be added to CCK dev last.

In other words, until I incorporate the latest changes from Markus into my zip, you have to choose to either use my zip and wait for me to add them, or use Markus' without using nested fieldgroups. You can't just drop in the tar from #378 on top of the nested fieldgroup#116 zip. You would have to do a diff of his multigroup folder and mine and understand which changes go where.

If, on the other hand, people are having issues with multigroup alone, I don't know what the problem could be as I haven't looked at the latest changes.

I should be able to roll a new, all-inclusive zip early next week.

rconstantine’s picture

It turns out the issue I mentioned in #390 is not a multigroup issue. It appears for regular multiple fields inside collapsed nested fieldgroups as well. I have yet to test whether it is restricted to 'unlimited' multiple fields or number-limited ones as well. So I'm assuming the issue is either with nested fieldgroups or a side-effect in CCK itself caused by nested fieldgroups. I'll move the discussion from here to there. Curse IE!!!

If anyone could download the zip of from the nested fieldgroup issue and then play with nesting multiple fields (regular or multigroup), that would be helpful. Hopefully someone can verify that they see the issue too.

eliosh’s picture

I try to follow all comments in this issue, but now i'm lost. (as said previously in comment n°393)
I understand that rconstantine's patches and those from Markus are incompatible at the moment, but solves different problems.
I'd like that someone give me a hand to use a multigroup problem i have: i need a very simple solution to create a multigroup with 4 single textfield in it, all required.

Can we have a new "summary" like comment posted by Markus (n°346) ?

Thanks a lot for this gr8 work

andreiashu’s picture

@eliosh: i read #320, applied those patches and everything works (almost) perfect. It also applies for your issue with the 4 textfields.

andreiashu’s picture

I stumbled a rather weird bug - if we can call it that way: if you have a hook_nodeapi that calls the dpm devel function then you'll get only 1 of the added multigroups values.
I've attached some screenshots to better explain what is the unexpected behaviour (in fact i'll attach them in the next comment because of a d.o bug).

I'm using the version of patches from the #320 comment.

andreiashu’s picture

Oki. so the first snapshot is the expected behaviour.
Second and third snapshots there is a module that has a hook_nodeapi in which it issues a call to dpm. The problem is that instead of 2 values of the multigroup, only 1 appears.
I tested with other types of CCK fields but they appear nonetheless. Only multigroup has this issue.

rconstantine’s picture

@andreiashu, do you get the same results with my zip as with Markus' tar?

andreiashu’s picture

@rconstantine can you please point me to the comment nr where you attached the zip ? sorry but this is a huge comment list :)

rconstantine’s picture

@andreiashu, sorry, I was referring to #300084: Nested fieldgroup - comment #116, which is an all-in-one zip including nested fieldgroups, multigroups, and the delete row patches that multigroups depend on. Note that mine includes the change noted in #372 of this thread, above. I don't know whether Markus' latest tar has the change from #372 or not, but it should because the problem should still exist - as I mentioned, there was a change to CCK that required this change. Although, I suppose if Markus' tar isn't based on the dev that included the change, then his wouldn't need it! Anyway, my zip includes all but the latest changes to multigroup and I will be adding those next week. Confused yet???

servantleader’s picture

FileSize
32.12 KB

I am using the zip from #300084: Nested fieldgroup - comment #116. Everything works great except the problem reported in #367, #370 above. But, the problem is worse than this. If I do not make the fields required, the groups save themselves in the database even though all the fields are blank. Bellow is a picture of what I submitted. It looked the same when I went back to edit the node. What we are missing is a piece of code that will check to see if all the fields in a multigroup are empty and flag the group for removal if they are. The comment on line 880 of content_multigroup.module states:

* We need to let the user enter an empty set of fields for a delta subgroup,
* even if it contains required fields, which is equivalent to say a subgroup
* should be ignored, not to be stored into the database.
* So, we need to check for required fields, but only for non-empty subgroups.
*
* When the form is processed for rendering, the required flag is enabled for
* all required fields, so the user can see what's required and what's not.
*
* When the form is processed for validation, the required flag is disabled,
* so that FormAPI does not report errors for empty fields.

The code should be there, but I don't think it is working. I am not familiar enough with this code to find what is wrong with this neat looking recursive function.

Thanks for any help.

servantleader’s picture

I figured it out. Here is a replacement function that fixes the problem from #367, #370, and #402 above.

/**
 * Node form validation handler.
 *
 * Perform validation for empty fields ignoring subgroups flagged for removal.
 * Note that FormAPI validation for required fields is disabled because we need
 * to accept empty fields that are flagged for removal.
 */
function content_multigroup_node_form_validate($form, &$form_state) {
  $type_name = $form['#node']->type;
  $groups = fieldgroup_groups($type_name);

  foreach ($form['#multigroups'] as $group_name => $group_fields) {
    $group = $groups[$group_name];
    $group_required = isset($group['settings']['multigroup']['required']) ? $group['settings']['multigroup']['required'] : 1;

	
    $non_empty_subgroups = array();
    foreach ($group_fields as $field_name => $field) {
      foreach ($form_state['values'][$field_name] as $delta => $item) {
        // Ignore subgroups flagged for removal.
        if (!$form_state['multigroup_removed'][$group_name][$delta]) {
          $is_empty_function = $field['module'] .'_content_is_empty';
          if (!$is_empty_function($form_state['values'][$field_name][$delta], $field)) {
			$non_empty_subgroups[$delta] = TRUE;
          }
        }
      }
    }
	
	if (!(count($non_empty_subgroups) == 0)) {
	    foreach ($group_fields as $field_name => $field) {
	      foreach ($form_state['values'][$field_name] as $delta => $item) {
	        // Ignore subgroups flagged for removal.
	        if (!$form_state['multigroup_removed'][$group_name][$delta]) {
	          $is_empty_function = $field['module'] .'_content_is_empty';
	          if ($is_empty_function($form_state['values'][$field_name][$delta], $field)) {
	            if ($field['required']) {
	              if (!empty($item['_error_element'])) {
	                $error_element = explode('][', $item['_error_element']);
	                array_shift($error_element);
	                array_shift($error_element);
	                array_shift($error_element);
	                array_unshift($error_element, $field_name, $delta);
	                $error_element = implode('][', $error_element);
	              }
	              else {
	                $error_element = '';
	              }
	              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']),
	              )));
	            }
	          }
	        }
	      }
	    }
    }
	
    if ($group_required && count($non_empty_subgroups) == 0) {
      form_set_error('', t('Group @name requires one collection of fields minimum.', array('@name' => t($group['label']))));
    }
  }
}

It first finds the non-empty fields. Then, if there are non-empty fields, it checks to see if there are empty required fields. Hope this helps. I would provide a patch, but I am not sure at this point what to patch it against. This is a modification of the zip file mentioned in the above comment.

markus_petrux’s picture

Status: Active » Needs review

For multiple valued fields, not in multigroups, when you have a non-required field, and this is not filled in the node edit form, you still get a record in the database with NULL for the field column values. That's way I coded the multigroup to still write an empty record, even if the fields are empty. My reasoning was that the multigroup should not alter the way data is stored in the database, only the user interface is what the multigroup changes.

When you create a non-required multigroup. If you need to allow the users to do not enter values, the fields it contains should be defined as non-required. If only a field in a multigroup is required, then the user should enter at least one subgroup of fields, even if the multigroup itself is not required. That's how I coded the multigroup.

Edit: Oh, I inadvertently changed the issue status. Anyway, I believe it is still need testing, no I leave it that way.

andreiashu’s picture

@rconstantine: the problem still exists with the zip archive from the #116 comment. If there is anything else to test please say :)

upupax’s picture

I had no problems with the patch 'till now, but I'm using a really easy group (one single line textfield and one multirow textarea).

himtuna’s picture

Please can someone save me from reading the 400 comments, and tell me how to go about with the working version of combo fields.

I have a date field(with mutliple instances allowed), however I would like to attach a text field corresponding to each date field explaining what the date contains.

excaliburst’s picture

Subscribing

- Ehm how do i actualle go about subscribing? Apparantly it's not enough to add a post with word 'Subscribing'.

How to subscribe pls.

upupax’s picture

@himtuna: have a look at comment-#346, there is a summary of what to do, but you have to check for later patches...

@excaliburst: it's enough to write something in a discussion to have it tracked in your tracking page (have a look to your profile to see the track link).

rconstantine’s picture

@servantleader, re: #402, I'm surprised by your screen shot. I haven't had any issues with multiple rows, though admittedly, I haven't tried to save several empty rows. I do agree with Markus, though, that the multigroup patch should not affect/change the current behavior of multi-fields. If a change should be made, I would think it should be made to the way CCK itself handles the multi-fields which would then trickle down to the multigroup patch. So the question then is, how do regular multi-fields behave in an environment without these patches? Can you save several blank rows? If so, then we need to leave things as they are. If not, and this only happens for multigroups, then we need to adopt the suggested changes.

himtuna’s picture

This happens to be tooo much out of knowledge, I'll better come afterwards when the cake is ready.
There is not even a single line that I can follow.
Can anybody tell me whats the status this module and how much time will it take for testing one(simple drupal enable stuff at the modules page)?

@upupax: thanks for the reply

yched’s picture

@himtuna : You can guess that there are no answer to your question. Both CCK maintainers are doing this on a volunteer time basis, and both of us have been really swamped with one or several of : 'fields in D7 core', work on other contrib module for Karen (date, calendar...), client work, personal life ... So *really* there was no time for us to take care of those patches.
It's unfortunate that they have been lingering for so long, I fully understand how painful it is for people to follow the evolutions and provide feedback, and I praise markus_petrux and rconstantine for their efforts and patience. I cannot answer 'when will this be committed to CCK'. No such question can be answered for any drupal module. All I can say is that I should be able to dedicate some time to this in the following weeks.

markus_petrux’s picture

There are 2 different packages. The one I posted in #378 and the one that rconstantine provides from the nested fieldgroups issue.

To test the multigroup only, then please get the tar from #378 of this issue. Also, please read the comments I refered to in that post.

To test the multigroup with nested fieldgroup, then you need to follow the nested fieldgroup issue. It will come with a modified version of the multigroup that's compatible with that addition.

I know this is not easy, but trying to follow support issues from these very long issues is not easy either. Hopefully, there will be a new release of CCK soon, and then CCK maintainers maybe can find a hole to digest these monster patches.

Edit: @yched, we posted at the same time, it seems to me. :-o

servantleader’s picture

FileSize
15.37 KB
21.66 KB

@rconstantine re: #410, The normal behavior (clean install of just drupal 6.10 + cck 2.1) is to delete extra added items if they are empty (see screen shots) at lest from a users perspective (haven't looked at the db). As we have added the ability to remove items with a button, we have lost the automatic removal of empty items which can add junk to our database if users do not remove items. (my code hack in 403 does not fix this)
re: behavior of required fields - It seems to be both useful and intuitive to allow for a required field without automatically making the whole group required (in the case of my project it is an absolute requirement). Even though it technically is making a required field not required (as markus_petrux correctly pointed out above), the combination of the required field and required group setting will allow for any behavior. In my case, I need to allow the user to not submit any groups, but, if they do, they must contain values in certain fields. Normal behavior can still be had by making both the field and the group required.

p.s. thank you all for your great work on this module, using it in its untested/in-development sate is far better then starting from scratch which was my only other alternative.

andreiashu’s picture

@#414: confirming what servantleader said.
And, again, thanks to all that work on this incredible task.

rconstantine’s picture

FileSize
477.77 KB

#414, what the heck? Are you saying you can create multiple blank rows and then are unable to delete them? I'll have to try that out specifically, but I'm pretty sure I tried that before and didn't get those results.

I agree with how you'd like required fields to work. In fact, I think I mentioned it in a previous post. When I get a chance, and if Markus hasn't addressed it yet, I'll fix that. I would love that feature in my application as well.

FYI everybody, I'm going through an issues listing that my co-workers came up with. Expect a new version soon.

andreiashu’s picture

@rconstantine i think that in #414 servantleader wants to point out that if you add N blank rows and hit save and then go and edit again the node all those N blank rows still exist/appear in the node edit form. The default behaviour in CCK would be to only appear the non empty ones + 1 or 2 empty. Of course you can manually delete those blank fields.

andreiashu’s picture

Another issue (don't know if this was already talked about) is that if you don't add any field into a multigroup the fieldset with the fields labels still appear on the view page of node.

markus_petrux’s picture

The fact that it is necessary to explicitly delete items is intentional, and it was discussed here: #196421: Deleting unwanted multiple values / multiple values delta issues

First, I coded it in the same way CCK works. But then it was suggested that it would seem more intuitive to do this with an explicit action from the user, with the 'remove' button.

With multigroups, subgroups of fields need to be in sync with each other in the multigroup. Each subgroup is a separate delta value, so it is not possible to keep CCK working as it does now (removes empty items). Rather, items that need to be removed need to be flagged somehow. See #305 on top of this page for another explanation on how multigroups work.

Also, if you have several fields on a multigroup with default values, or yuou wanted to remove a subgroups with fields that contain values, then you would have to empty all fields to tell CCK that you want to remove the subgroup. It's much easier to do so with a simple 'remove' button. Hence, items are only removed if the user press the 'remove' button. Otherwise, fields are recorded, even if empty.

netbear’s picture

I've started new topic instead of this one because it's too long. And tried to collect all latest work results, described by markus petrux. If that was not wize - sorry, but it's too difficult for people find info to test this module seems. So I propose to continue from this point in new topic here: http://drupal.org/node/397610

servantleader’s picture

@andreiashu - right, sorry for the confusion rconstantine. It is not a big issue. Getting the required fields to work the way I wanted was important. The function I posted above will make required fields work, but it is probably not the best way to do it.

jrosen’s picture

I just unzipped the code in #416 and it all seems to work great, except that when I click the "Add More Values" button, I get the following error message:

user warning: Unknown column 'parent_group_name' in 'field list' query: SELECT parent_group_name FROM content_group WHERE type_name = 'resume' AND group_name = 'group_resume_education' in /sites/all/modules/cck/modules/fieldgroup/fieldgroup.module on line 336

My Multigroup contains the following CCK Fields:
1. A text field
2. A Date field (with a From and To Date)
3. A Location Field

Besides the error message, though, it all works great: I can add another group, remove a group, edit a group, save a group, and view the values of the group. So if this error message didn't get triggered, all would be great.

Any help anyone can offer would be great.

Thanks,
Jason

markus_petrux’s picture

I'm about to prepare a new patch for the multigroup. Well, it will not include nested fieldgroup as it may come later from rconstantine. I hope a new patch and a new tar will help others review the whole thing.

...but I would like to first check if there are remaining issues here.

@andreiashu / @servantleader: If I understand you both correctly. servantleader's fix above is made to automatically remove subgroups of fields when all fields on a subgroup are empty. Please, correct me if this is not the case. Ok, if it is, then I believe this may not be desired in other use-cases where someone may need empty subgroups ready (possible if all fields in the multigroup are not required). On the other hand, when you want to remove a subgroup, all you need to do is press the 'remove' button. I don't really see why this is a problem. Could you please elaborate on your use-case? Maybe we need to add an option so it can work one way or another. But I would only add that, if it's really necessary.

@all - FYI: I'm quoting myself from another post in the CCK patch issue:

@rconstantine: One of the things you've mentioned somewhere on the past follow ups on these issues, I missed. It's that piece of code that fixes the wrappers for the Add more buttons. I believe you mean these changes applied to CCK recently: patch for changes to content.node_form.inc from 1.7.2.15 to 1.7.2.18. Well, I just applied those changes to my working copy of the multigroup and it's to working well. I'll post an updated version of the multigroup as soon as possible.

BTW, the issue with filefield has been moving thanks to quicksketch. It's not fully working yet, but it's been applied to their CVS project, and that's great news! :D

Is there anything else that need to be taken into account before rolling a new patch here?

markus_petrux’s picture

Ok, here's an updated version of the multigroup. The patch is against latest CCK 6.x-2.x-dev snapshot. I'm also attaching a tar file that can be used as an alternative to the patch. The patch really modifies a big part of the original content_multigroup module. The extension of tar file needs to be remaned to ".tar.gz" before extracting. The contents of this tar is aimed to replace the whole directory cck/modules/content_multigroup.

IMPORTANT REQUIREMENT: The multigroup module requires the latest CCK 6.x-2.x-dev snapshot AND latest patch in #196421: Deleting unwanted multiple values / multiple values delta issues. It can be found in comment #117 of that issue. That patch introduces 'remove' buttons for multiple value fields, and makes CCK work in a way that delta values are only removed upon user request, not when fields are left empty as it does now.

Don't forget to copy the 2 small icons in the previous path to cck/images directory that you should create.

That issue contains the history on why a 'remove' button has been added to CCK to allow users remove delta values rather than letting CCK to blindly prune them when they are empty. In summary:

- comment #39: a version of the patch that introduces a 'remove' checkbox for each delta value.
- comment #43: based on yched comments, a new version of the patch that doesn't add 'remove' checkbox, rather it uses internally a '_keep_empty' flag. Values are removed when left empty, which was based on the method to remove fields existing in official CCK 2.1 release.
- comment #53: previous patches included a bug fix for function content_max_delta() which is used only by content multigroup module. That fix was committed to CVS by KarenS.
- comment #73: rconstantine started to work from these patches to make them work with the nested fieldgroups patch.
- comment #75: based on further KarenS comments, the whole patch is fully rewritten and it now adds the 'remove' buttons again. It includes a couple of small icons and javascript behaviors to make it more easy and intuitive than ever. Also degrades gracefully when javascript is not available. :)

CCK maintainer comments on these patches:

- 196421#110 - February 17, 2009: KarenS said: "We've both been extremely busy. We're talking about issuing a new official release to pick up the latest changes and I think we both want to wait until after that release to add in anything that has any potential of breaking anything. Then we can take a look and see how much of this we can commit.".
- 300084#115 - February 27, 2009: yched said: "We intend to roll a 2.2 release in the very next few days. Not sure about Karen's agenda, but I'll try to dedicate enough time for the ginormous amount of work that went into these patches as soon as I can - which might still be another week or so.".

I would like to avail this oportunity to thank them for all the hard work they have put in CCK, and also for the help and hints provided to drive these patches to what we can see today.

Notes related to other CCK fields and uses:

- Note related to filefield/imagefield: Well, this is moving and you can follow the patches to filefield for compatibility with multigroups here: #367267: Compatibility issues with Content Multigroup. Updated: Good news! that patch seems to work, but it needs further testing with and without multigroups. Please, review and give feedback.

- The multigroup module can work with almost any CCK field. There are widgets that are programmed to manage their own multiple values (optionwidgets, content_taxonomy, etc). These need to implement a couple of content_multigroup hooks. Look at the following issue in the Content Taxonomy queue for an example: #350669: Add support for the content multigroup module?

- For those using Computed fields: see #349548: Conditional result for hook_content_is_empty() (patch and examples) AND #349555: Triggering Computed Field code on node preview (patch for node preview).

- Multiple value widgets such as multiple selects, checkboxes, freetagging widget of content_taxonomy can not work with multigroups. Multiple-selects and checkboxes are transformed to single-selects and radios boxes within the context of multigroups because each subgroup of a multigroup can only hold one value. Freetagging widget cannot work because it cannot be configured to manage single values. Please, see detailed explanation on why widgets on multigroup cannot hold multiple values.

- Nested fieldgroups: if you want/need to try this with nested fieldgroups / fieldgroup tabs, you have to follow updates on this other issue: #300084: Nested fieldgroup. Please, note that these patches are pretty complex and so it seemed to us that the nested fieldgroups patch would have to take what's been done for multigroups rather than the opposite way.

- Using drupal_execute to create nodes with multigroups programmatically: Please, see comment #83 on this other issue.

Please, don't try this on production sites. Note that there are no upgrade paths between dev versions of these patches.

bob.hinrichs’s picture

Thanks to all for your work on this much-needed module. Is this line 1490 in .module a bug? It apparently refers to a file that does not exist:

drupal_add_js(drupal_get_path('module', 'content') .'/theme/content-edit.js');

markus_petrux’s picture

@bob-hinrichs #425: The file is new and it is provided by the patch in #196421: Deleting unwanted multiple values / multiple values delta issues

That patch is required for the multigroup to work. Please, note I mentioned the multigroup requirements and additional notes in #424

Gribnif’s picture

@markus_petrux: I'm sure you've noticed that you're spending a lot of time telling people (like me) that they missed various requirements of the patch. Your instructions are quite good, I think it's the length of this discussion that contributes to the confusion.

How about creating a forum topic or book page containing everything in #424, which you can then update whenever a new version of the patch is made? Then, instead of posting a full message like #424, just attach the patch (for tracking purposes) and say "see this other node for installation instructions."

That might make it easier for people to always find the latest version. It would also mean that we'd only have to monitor one node for changes, and not read through all of the discussions about the details in this thread.

ellen.davis’s picture

drupal 6.10
cck_8.zip from http://drupal.org/node/300084 #116 (It looks like this already has patch from from http://drupal.org/node/196421 #117 applied, also included content_multigroup)
cck_fieldgroup_tabs.zip from http://drupal.org/node/325049#comment-1204939

With the above setup, when I edit a page with a multigroup, the behavior is:

Publication 1
  Author : a1
  Date :date1
  Title : title1
  Description: des1
Publication 2
  Author : a2
  Date :date2
  Title : title2
  Description: des2

I have one “Drag to reorder” and one “ Remove this item” for a Publication group. “Add more values” button is at bottom of the last group. Clicking this button will add another empty group. This is the behavior I expect and want.

If replace content_multigroup subdirectory with content_multigroup-119102-424.tar.gz, behavior changes:

Author:
 a1
 a2
Date:
 date1
 date2
Title:
 title1
 title2
Description:
 des1
 des2

I have “Drag to reorder” for each field (a1, a2, date1, date2, etc.). I have “Remove this item” for each field also. "Add another item" is displayed at each field. If I click on add another item at the end of the Author listing, I get a blank author input field.

rconstantine’s picture

@jrosen, you didn't run update.php which you should do any time you update a module. You'll find a link to it on the modules page. My patch adds a column to an existing table and is necessary for the nested fieldgroups patch to work correctly.

rconstantine’s picture

RE: #423, I think that your assessment of the issue of deletion is spot-on. I suggest that we get all of this into CCK the way things are and then see whether there is a strong need for an admin option later.

@davis4104, unfortunately, using the zip cck_8.zip is not compatible with later versions of multigroup as rolled by Markus. I adjust some of his code to accommodate nested fieldgroups. This includes how multigroups 'finds' where to insert added rows via AHAH, among other things. My latest zip is found here in this thread at #416 above. I mistakenly posted it here. That's what I get for having a zillion tabs open at once. Anyway, I will be doing another zip soon with the latest from Markus. Meanwhile, you can use cck_9.zip above. I think the only thing missing from it is what Markus mentions in -- wait a minute, I could've sworn there was somthing above that got added around the same time I did cck_9.zip. I don't see it now. Was it in the row delete module? Hmm. In any case, my next zip will include Markus' latest.

@yched, I just now saw your post at #412. I'm not sure how I missed it. Anyway, I for one can appreciate your lack of time. I myself have a dozen modules on D.O, most of which are still in D5 form and with growing issue queues. Fortunately, some now have co-maintainers, but working two jobs, plus family life with 2 small kids, church, and more makes it nearly impossible to stay on top of everything here. I'm just glad I am now using D.O at my day job. I expect to be able to update several of my modules to D6 soon! Thank you for your attention on all of this and for all of your efforts on D.O.

Brian@brianpuccio.net’s picture

This patch #119102-424: Combo field - group different fields into one works wonderfully for me, thanks.

jrosen’s picture

@rconstantine, thanks for reminding me to run the update.php script after applying the patch. The Multi-group functionality is working great now!

Thanks to everyone that has contributed and made this work as well as it does.

jthorson’s picture

The solution in #424 appears to be working well for me, after some limited investigation. My 'remove' checkboxes are set to invisible using default garland theme, but I was able to reveal them using Firebug. I've added the images from the multiple values delta patch, but I'm not 100% sure where they should show up (not appearing for me).

Now ... for bonus points ... if I could include a multi-select select list in each of the multiple entries within a multi-group ... (ie. each entry in a multiple value multigroup field could have it's own multi-select select list) ... I'd say it was perfect. ;)

markus_petrux’s picture

I have extended the explanations in #424 to remark the requirement of installing the patch and the images at #196421: Deleting unwanted multiple values / multiple values delta issues

Also extended the note about the limitations of multiple valued widgets in multigroups.

So, jthorson, please re-read carefully that comment. ;-)

derhasi’s picture

thanks for working on this module, great work!

... and I want to briefly add my thoughts about "multiple value" and "views" integration:

** for multiple values (like freetagging) we could use extended deltas, that are limited to maybe 100 000, and so each new multiple value in delta x will be x+(n*100 000)
example: delta 1 = val1, delta 100 001 = val2, delta 200 001 = val 3
this would restrict the values to a max group count of 100 000, and allow up to 9999 multiple values for each one (with int(10) )

** for a basic views integration for content_multigroup, I think the most simple way would be to create a general "views delta filter" that filters on the same delta-value of two defined fields: "WHERE field1.delta = field2.delta"

jthorson’s picture

The module is working well, but I seem to have run into a snag ... not sure if it's my own ignorance, or simply hasn't been built into the module yet ... but how would one go about rendering a multi-group table in a custom .tpl override file?

I managed to do it using the following:

print ($node->content['multigroup-name']['#children']);

... but I've got a nagging suspicion that there has to be a better way, which would allow me to override the default look-and-feel. Any thoughts?

Thanks for all the wonderful work on the module to date!

PS to Markus (#434): Yeah, I realize that multiple multi-valued widgets it isn't going to happen ... it was more a 'dream' statement than an actual request. :)

markus_petrux’s picture

@jthorson #436: regarding the theming issue... please, open the file content_multigroup.module. At the end, you'll find several theme_* functions, each one covers different uses and/or formatters that can be selected from 'Display Fields' tab, but you can override them to suit your needs as you would with any other theme function.

marcvangend’s picture

Markus and other contributers, it's great to see multigroups developing. I know that multigroups is not fit for production sites yet and I realize that, in good open source tradition, "it's ready when it's ready". Still I'd like to ask this: could I start developing a site using multigroups today? I understand that there is no upgrade path between beta versions, so I may have to put in some extra time when a new iteration arrives. But what I'm trying to figure out is: would it cost time, or would it save time if I start developing with multigroups today?

excaliburst’s picture

I have been following this (very lengthy) thread from its start. And anticipating the result with great admiration for you guys (including you Karen).

I experience a small hick-up though After upgrading CCK to 2.1 on my Drupal 6.10 I get strange behavior on fields that use the Autocomplete widgets module.

These fields get stripped of their content during save operations (and preview).

I use the latest version of Autocomplete Widgets 6.x-1.0.
http://drupalmodules.com/module/autocomplete-widgets

I need this module so the user can lookup values from an extensive list (and in the process I save having to fix a lot of TYPOs). So this is crucial for my site.

Another problem is that I employ 2 different Multigroups of fields. Strangely only the first one gets shown in the output form (when I look at the saved node). Everything below the first multigroup is not shown!

This must be a CCK bug.

Does anyone have an idea why this is - and how it can be fixed.

Any ideas as to how to fix these things?

I was sort of hoping that this version of CCK would enable me to place multiple fields on one row (the fields contained in my multigroup). I cannot see how this is optained. Is it supported in CCK2.1 or will it be later?

Morten

rconstantine’s picture

@excaliburst If you upgraded CCK after installing multigroups, then you probably wiped out a patched file. Re-install multigroups.

As for multiselect fields in multigroups, I think it will be possible but should not be attempted before what we have now is officially in CCK. One way to do this has been mentioned in #435. Another way would be to add another column containing sub-deltas, or super-deltas. This column could be used in one of several ways.

1) The value is a sub-delta, or child of the regular delta.
2) The value is the parent of the delta.
3) I had thought of another, but forgot it!

The table entries for one multigroup might look like this:

Delta    Sub-Delta
   0            0
   0            1
   0            2
   0            3
   1            0
   2            0
   2            1

And so on for the first case...

Delta    Super-Delta
   0              0
   1              0
   2              0
   3              0
   0              1
   0              2
   1              2

The values are obviously the same, with the columns reversed. The choice for which to use would be determined by the ease to update supporting code. If one of these could be implemented by only changing multigroup code, then that would be ideal.

And of course, there may be other ways to do this that some of you out there can think of. Please share any ideas.

markus_petrux’s picture

@marcvangend #438: It's hard to tell. We have to still see CCK maintainers spend the time to digest all this stuff, which is not simple. Hopefully, this will happen soon. In any case, speaking for myself, we have decided for our project to go ahead and use multigroups despite the fact it may not be part of CCK2. But that means I'll have to be prepared to spend as many time as it requires when the time comes. Well, I would say this might be the worst scenario. On the other hand, we have seen changes in filefield to offer forward compatibility with multigroup recently, and filefield is going to be part of D7 as well as CCK. Good sign. Another good sign is that CCK maintainers expressed their wish to spend some time on this after CCK 2.2 is released, which may happen sooner than later, etc. So it depends, but be prepared for an odd scenario.

@excaliburst #439 / Autocomplete widgets issue: If re-installing doesn't help, then please open an issue to the other module's queue.

@excaliburst #439 / Sub-deltas: hmm... if you haven't already, please read comment #305 on top of this page. The multigroup module does not change the way data is stored into the database, so we're tied to CCK "limitations". If we wanted to add sub-deltas, we would have to rewrite a lot of code in CCK itself, and I believe this is far beyond the scope of this issue, at least at this moment. As pointed in #305 another possible way would be to serialize sub-delta values in delta row, but that would be on the side of CCK field implementation. You could write such a field if you wish, and it would work as far as you store serailized sub-deltas in one delta row, and then unserialize them before further processing, at node load time or so.

jthorson’s picture

markus: (#437) Thanks for the suggestion, but I had already found the theming functions. Where I'm getting hung up is in determining just what they are expecting to receive in the $element variable. The overriding bit will come later ... right now I'm just trying to print out the multigroup table in my custom nodetype-node.tpl.php file. I'm thinking the snippet below should work, but I'm obviously passing the wrong argument, as it doesn't output anything.

print theme('content_multigroup_display_table', $node->content['multigroup_group_name']);

What specific object (from my $node variable, I assume) are the multi-group theme functions expecting to receive?

markus_petrux’s picture

hmm... theme('content_multigroup_display_table') doesn not exist in the latest multigroup patch.

Look at content_multigroup_fieldgroup_view() to see how the structures are built. This function is the implementation of hook_fieldgroup_view(), which is invoked by fieldgroup module from its implementation of nodeapi('view'). I hope that can give you an idea.

Probably, it would be a good thing to implement these theme functions as templates, so they can be easilly found and documented, I think. I wouldn't enter this road now until CCK maintainer can really chime in, so that we don't loose too much time rounding in circles, as there may be other pieces that they may wish to change once they "touch it". Another thing that I would do is split the code into several .inc files so that only the required code is loaded when needed. The multigroup is quite big PHP script, eating memory...

jthorson’s picture

Doh! Was looking at the unpatched code today to make that post ... missed the '_single' on the end of the function. Another 20 minutes wasted because I wasn't paying attention!

Thanks for the content_multigroup_fieldgroup_view() suggestion ... just what I needed to figure out the solution. The theme arguments were looking for $node->content['multigroup_groupname']['group'] as the passed argument. So, to output the multigroup field in a custom .tpl.php file:

print theme('content_multigroup_display_table_single', $node->content['multigroup_groupname']['group']);

Thanks a bunch! And again, excellent work on this module!

hass’s picture

Unsubscribe :-)

coltrane’s picture

Patch in #424 applies cleanly and works perfectly so far! Multigroup is pretty badass, I'm really looking forward to a CCK with this builtin.

Comments on the patch:

1) In content_multigroup_fieldgroup_form() line 612 of #424 patch $group_deltas = array_keys(array_fill(0, $group_multiple, 0)); could become $deltas = range(0, $max_delta); if the following line $max_delta = $group_multiple - 1; is moved above it. Same for hook_fieldgroup_view() line 1554 of the patch.

2) In content_multigroup_node_form_validate() I'm confused by

$error_element = explode('][', $item['_error_element']);
array_shift($error_element);
array_shift($error_element);
array_shift($error_element);
array_unshift($error_element, $field_name, $delta);
$error_element = implode('][', $error_element);

If you know the structure multigroup creates ([group][delta][field][value]) and it doesn't change you can skip exploding and shifting:

$error_element = implode('][', array($field_name, $delta, 'value'));

I'm working through a lot of logic but these minor things were easy to catch.

markus_petrux’s picture

@coltrane #446:

1) I already applied these changes in my working copy when you posted this in the other issue:

http://drupal.org/node/196421#comment-1362838

2) Nope, we cannot do that. And I will add a comment in the code to explain what happens.

$item['_error_element'] may contain 'group_name][delta][field_name][value', but also 'group_name][delta][field_name][nid][nid'. So we don't really know in advance how many elements a widget has. That's why I extract the first 3 indexes, and then add field name and delta.

jthorson’s picture

I've come across what's really a very minor quirk ... and maybe intentional ...

In rendering a multigroup in a node form, whatever text that has been entered in the 'help' field for the parent multigroup gets outputed twice - once before the multigroup table, and once after. Line 1484 of content_multigroup.module explicitly adds the $element['#description'] value to the $output variable (if it exists) ... but it seems that another function takes care of displaying it earlier in the processing, before control is ever passed to the theme_content_multigroup_node_form function.

This double-printing of the help text doesn't match the behaviour of a standard fieldgroup, though I suppose it is conceivable that some would want the help text both above and below a long multigroup table.

In either case, commenting out line 1484 got rid of the second copy.

markus_petrux’s picture

Status: Needs review » Needs work

@jthorson #448: Good catch. Thanks! :)

It was not intentional. This line was present in the original code of the multigroup for some reason, and I missed it was really redundant.

I'm getting rid of it in my working copy, and will try to update the patch (and the tar) some time on this week.

@KarenS/yched: One of the things I would also like to do is split the code of the multigroup in several .inc files, so that we don't add too much code for every page, only when it is needed. Probably, there would be one separate .inc for node/edit pages, and one for content type administration. Would you agree on this approach?

Roulion’s picture

#449 @Markus_petrux would that tar be OK with the last cck 6.2.2 module.

I hardly need the content multigroup and i use an old pack provided by rconstantine... (which gather content multigroup, nested fieldgroup and add/remove empty fields)... I think many peope are like me.

It would be nice if a new vesrion of these 3 features could be deliverered... Thanks in advance and Have a nice day.

markus_petrux’s picture

@Roulion #450: All patches are always against latest development versions (from CVS), which is what needs to be modified in order to be properly included in future releases. I'm afraid you'll have to wait until all these features are committed to CVS by CCK maintainers themselves.

We're all in the hope that now that CCK 2.2 is out, KarenS and yched can spend some time to review these mega patches and see what can be included. Please, read the comments in #424 above.

yched’s picture

re markus_petrux #449: +1 for split .inc files

coltrane’s picture

@Markus #447, ah my apologies, I missed that in http://drupal.org/node/196421#comment-1362838 where you said you've applied it to this patch as well, and thanks for the details on my patch comment 2, I appreciate your hard work on this.

+1 on splitting out into separate files.

coltrane’s picture

FileSize
8.24 KB

Attached is a simpletest case with two tests for multigroup. The second test gets failures at the moment though that I think are not the fault of multigroup module but of my method.

Also, Date module's field isn't compatible with multigroup so I started an issue and submitted a patch at #401326: Support empty values and multigroup

andreiashu’s picture

Hi petrux,
I updated multigroup module to the version you provided in comment #424. I tested it a bit more and some questions/problems appeared:

1. If i have a field into a multigroup that has a default value it won't work: on the edit form only the first instance of the field has the default value assigned to it, the rest that are added after it are blank.

2. how to use the '_error_element' value to set a form error in a validate function ? If in a validate function I do
form_set_error($form_state[$field_name][$delta]['_error_element'], $form['#field_info'][$field_name]['widget']['label'] . ' is invalid');
it won't work. I know that I'm doing something wrong but I don't know what.

Thanks,
andreiashu

rconstantine’s picture

@Markus - in the following, why do you have two identical lines a few lines apart?

function content_multigroup_field_overview_form_validate($form, &$form_state) {
  $form_values = $form_state['values'];

  $type_name = $form['#type_name'];
  $fields = array();
  $groups = array();

  $group = $form_values['_add_new_group'];<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<This one
  if (array_filter(array($group['label'], $group['group_name']))) {

    $group['settings'] = field_group_default_settings($form_values['_add_new_group']['group_type']);
    $group = $form_values['_add_new_group'];<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<This one

Commenting out the second one seems to be OK.

rconstantine’s picture

@markus - another question: I didn't see a problem with not having the following function. I'm actually not sure if this was something you had originally that I moved or took out, or if this is a new addition.

function content_multigroup_field_overview_form(&$form, &$form_state) {
  $options = fieldgroup_types();
  $options['standard'] = t('Standard');
  $options['multigroup'] = t('Multigroup');
  $form['_add_new_group']['group_type'] = array(
    '#type' => 'select',
    '#description' => t('Type of group.'),
    '#options' => $options,
    '#default_value' => 'standard',
  );
}

I thought there was a hook or some other means to populate the dropdown list - i.e. content_multigroup_fieldgroup_types()

rconstantine’s picture

@Markus - I changed the following function by moving a couple of things outside the loop

function content_multigroup_display_overview_form_submit($form, &$form_state) {
  $groups = fieldgroup_groups($form['#type_name']);
  // Find any groups we inserted into the display fields form,
  // save our settings, and remove them from $form_state.
  foreach ($form_state['values'] as $key => $values) {
    if (in_array($key, $form['#fields']) && !empty($values['parent']) && !empty($values['subgroup'])) {
      $group_name = $values['parent'];
      $group = $groups[$group_name];
      unset($values['subgroup'], $values['parent']);
      // We have some numeric keys here, so we can't use array_merge.
      foreach ($values as $k => $v) {
        $group['settings']['multigroup']['subgroup'][$k] = $v;
      }
      fieldgroup_save_group($form['#type_name'], $group);

      unset($form_state['values'][$key]);
    }
  }
  
  // Make sure group information is immediately updated.
  cache_clear_all('fieldgroup_data', content_cache_tablename());
  fieldgroup_groups('', FALSE, TRUE);
}

This seems to work the same to me.

rconstantine’s picture

@Markus - Sorry to bombard you, I'm just trying to show changes that work with the fieldgroups patch and which I don't think break anything if my patch isn't used that you can make to your own code base.

Here's another:

function content_multigroup_fieldgroup_form(&$form, &$form_state, $form_id, $group) {
  $group_name = $group['group_name'];
  if ($group['group_type'] != 'multigroup' || (isset($form[$group_name]['#access']) && $form[$group_name]['#access'] != TRUE) || empty($form[$group_name])) {
    return;
  }

The middle if condition allows access to be 'handed up' the parent chain so that a fieldgroup isn't hidden accidentally if a child should be shown.

In the same function, I changed this:

$current_item_count = isset($form_state['item_count'][$group_name]) ? $form_state['item_count'][$group_name] : max(1, count($group_deltas));
      while (count($group_deltas) < $current_item_count) {
        $max_delta++;
        $group_deltas[$max_delta] = $max_delta;<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<this line
      }

This allows for something later where the values need to match. I think I had come across a rare case where they didn't IIRC.

markus_petrux’s picture

@Ryan: Keep them coming. I'll look into these notes later, and will post a new patch including separation into several .inc files (probably one for view/edit pages and another one for the admin side) as pointed to by #449 and #452. I hope to do this at some time during this week end.

rconstantine’s picture

@Markus - I've got changes to content_multigroup_group_form and functions that call it, but I think those might depend on some new functions in fieldgroups which allow for finding the proper insert location for AHAH - I think you helped with those functions as I recall. I don't know whether you might want to look at content_multigroup_group_form and content_multigroup_fieldgroup_form and content_multigroup_add_more_js in my version below (later today) to see what you can incorporate now vs me patch as part of my patch. The change revolves around building an $element rather than modifying $form directly and copies the pattern from the rest of the CCK module.

It doesn't matter when these changes get in, so if you don't think you can get them in on your end, that's fine. My only concern is for our patches to drift away from each other since it's hard enough syncing with dev.

rconstantine’s picture

New all-in-one zip. Please test. http://drupal.org/node/300084#comment-1381830

rconstantine’s picture

@markus - That's a good idea about breaking the files up. I should do the same. That is now on my radar.

andreiashu’s picture

Another problem that I stumbled is that the '#access' property is ignored for fields that are in a multigroup.

markus_petrux’s picture

I was looking at latest suggestions before rolling a new patch.

@andreiashu #455:

1. If i have a field into a multigroup that has a default value it won't work: on the edit form only the first instance of the field has the default value assigned to it, the rest that are added after it are blank.

hmm... it seems to happen as well with multiple value fields not in multigroups. I tried to figure out where's the problem, and I would say it's related to the AHAH handlers. Well, it's not only a multigroup issue, so I would try to move this from a separate issue aimed to fix first the behavior of default values for multiple fields in CCK, then fix the multigroup.

2. how to use the '_error_element' value to set a form error in a validate function ? If in a validate function I do
form_set_error($form_state[$field_name][$delta]['_error_element'], $form['#field_info'][$field_name]['widget']['label'] . ' is invalid'); it won't work. I know that I'm doing something wrong but I don't know what.

It looks like you're doing custom stuff here, so it depends. Try looking at how 'error_element' is handled in hook_field('validate') of CCK fields such as Number... or lookat print_r() results from where you're coding. Not sure how to advice further than this. It depends on what you're doing I guess.

@rconstantine #456: Right, that line seems to be redundant. I'll fix that.

@rconstantine #457: hmm... I believe KarenS implemented both, content_multigroup_fieldgroup_types() and content_multigroup_field_overview_form() because otherwise, there's no group type selector in 'Manage Fields', but the right place to fix this seems to be content_field_overview_form() in cck/includes/content.admin.inc, where it blindly builds the 'group_type' element as hidden, but it should build a single-select when fieldgroup_types() returns more than one item. Now, I think this is a bug in CCK that could be managed from a separate issue. In that way we can count on it for the rest of the monster patches.

Edited: I have posted a patch to includes/content.admin.inc here: #409398: CCK Manage Fields not handling fieldgroup_types() correctly.

I'll look into the rest of the suggestions later.

Edited again: more suggestions reviewed follow, and I'll update this post unless a new comment is added.

@rconstantine #458: Ok, I have used an slight variation as cache_clear_all('fieldgroup_data', content_cache_tablename()); is already executed by fieldgroup_save_group(), so only need to reset static caches in fieldgroup_groups(), and only if we have modified something there.

@rconstantine #459: 1) Regarding group access... ok, I'll fix that. 2) Regarding $group_deltas... Nope, that array contains deltas, but the keys need to be from 0 to N. If you look at content_multigroup_fieldgroup_view() you'll see that the keys of this array are used to access the subgroup labels defined in the multigroup settings panel.

@rconstantine #461: Regarding the changes in content_multigroup_group_form(). Ok, I mentioned that perhaps these functions could be implemented in CCK on a separate issue (#196421), but yched mentioned those functions are not related to that (see comment #124 in that issue), so I guess this functions are introduced by nested fieldgroups patch, or from a completely separate issue. But I wouldn't add more issues since the nested fieldgroups patch will have to modify CCK and the multigroups anyway.

rconstantine’s picture

#464 - I think my fieldgroup patch addresses the access issue. At least, I do some additional #access processing. Can you give an example?

re: @andreiashu #455, I agree with Markus and have found the same issue on installs without this patch. For validation, if you're coding a CCK module, you don't need to account for the multigroup module. If you are adding a custom validation function for an existing content type's fields, then that is something you'll have to workout with print_r, devel module, maybe the drupal firefox plugin, etc. to see what your specific structure is.

@Markus re:#457: I think you missed the part where I said that I don't have the function at all and it works fine. Are you saying it has always been there? I don't think I removed it. Perhaps I wasn't clear on that point. Can you test what happens when you remove it from your version?

@Markus re:#459: Hmm, I can't seem to recall why I did that, so I'll make sure that whatever it is can be done another way.

@Markus re:#461: I agreed in that other thread. Fieldgroups will handle the changes to multigroups for those functions. I think the changes to the module file are easy to follow when viewed in a proper diff tool with coloring.

Thanks for your efforts. It's good to see these things finally working their way in. And thanks yched!

markus_petrux’s picture

@rconstantine #466 on #457: I didn't miss that, but I'm not sure why you don't have it. The function content_multigroup_field_overview_form() is present in original content_multigroup module, you can check this from any CCK release, stable or -dev. It's there, and I think it's simply part of the fieldgroup/multigroup stuff that was later changed, so it's not really necessary if the following patch is applied to CCK: #409398: CCK Manage Fields not handling fieldgroup_types() correctly.

If that patch is not applied, then it all works, except that there's no select element to choose the type of group in 'Manage Fields' panel, so it is not possible to add a new multigroup.

I'm in the middle of splitting stuff into separate .inc files, and I'll post updated patch and tar when ready. Probably tomorrow, it is now close to 4:00AM here. omg!

markus_petrux’s picture

Here's a new release of the multigroup module. It includes suggested changes since comment #424 where the previous release can be found.

This time I only attach the tar file because the patch is pretty big. The code has been splitted into separate .inc files. So there's almost no similarities from the original multigroup module shipped with CCK. The extension of tar file needs to be remaned to ".tar.gz" before extracting. The contents of this tar is aimed to replace the whole directory cck/modules/content_multigroup.

This version of the multigroup module requires latest CCK 6.x-2.x-dev snapshot + the following patches:

IMPORTANT REQUIREMENTS:
- Latest patch in #409398: CCK Manage Fields not handling fieldgroup_types() correctly.. It can be found in comment #2 of that issue. That patch fixes includes/content.admin.inc to correctly implement support for hook_fieldgroup_types(). Without this patch, you have no selector to add new multigroups to content types.
- Latest patch in #196421: Deleting unwanted multiple values / multiple values delta issues. It can be found in comment #127 of that issue. That patch introduces 'remove' buttons for multiple value fields, and makes CCK work in a way that delta values are only removed upon user request, not when fields are left empty as it does now.

Don't forget to copy the 2 small icons in #196421 to cck/images directory that you should create.

That issue contains the history on why a 'remove' button has been added to CCK to allow users remove delta values rather than letting CCK to blindly prune them when they are empty. In summary:

- comment #39: a version of the patch that introduces a 'remove' checkbox for each delta value.
- comment #43: based on yched comments, a new version of the patch that doesn't add 'remove' checkbox, rather it uses internally a '_keep_empty' flag. Values are removed when left empty, which was based on the method to remove fields existing in official CCK 2.1 release.
- comment #53: previous patches included a bug fix for function content_max_delta() which is used only by content multigroup module. That fix was committed to CVS by KarenS.
- comment #73: rconstantine started to work from these patches to make them work with the nested fieldgroups patch.
- comment #75: based on further KarenS comments, the whole patch is fully rewritten and it now adds the 'remove' buttons again. It includes a couple of small icons and javascript behaviors to make it more easy and intuitive than ever. Also degrades gracefully when javascript is not available. :)

CCK maintainer comments on these patches:

- 196421#110 - February 17, 2009: KarenS said: "We've both been extremely busy. We're talking about issuing a new official release to pick up the latest changes and I think we both want to wait until after that release to add in anything that has any potential of breaking anything. Then we can take a look and see how much of this we can commit.".
- 300084#115 - February 27, 2009: yched said: "We intend to roll a 2.2 release in the very next few days. Not sure about Karen's agenda, but I'll try to dedicate enough time for the ginormous amount of work that went into these patches as soon as I can - which might still be another week or so.".

I would like to avail this oportunity to thank them for all the hard work they have put in CCK, and also for the help and hints provided to drive these patches to what we can see today.

Notes related to other CCK fields and uses:

- Note related to filefield/imagefield: Well, this is moving and you can follow the patches to filefield for compatibility with multigroups here: #367267: Compatibility issues with Content Multigroup. Updated: Good news! that patch seems to work, but it needs further testing with and without multigroups. Please, review and give feedback.

- The multigroup module can work with almost any CCK field. There are widgets that are programmed to manage their own multiple values (optionwidgets, content_taxonomy, etc). These need to implement a couple of content_multigroup hooks. Look at the following issue in the Content Taxonomy queue for an example: #350669: Add support for the content multigroup module?

- For those using Computed fields: see #349548: Conditional result for hook_content_is_empty() (patch and examples) AND #349555: Triggering Computed Field code on node preview (patch for node preview).

- Multiple value widgets such as multiple selects, checkboxes, freetagging widget of content_taxonomy can not work with multigroups. Multiple-selects and checkboxes are transformed to single-selects and radios boxes within the context of multigroups because each subgroup of a multigroup can only hold one value. Freetagging widget cannot work because it cannot be configured to manage single values. Please, see detailed explanation on why widgets on multigroup cannot hold multiple values.

- Nested fieldgroups: if you want/need to try this with nested fieldgroups / fieldgroup tabs, you have to follow updates on this other issue: #300084: Nested fieldgroup. Please, note that these patches are pretty complex and so it seemed to us that the nested fieldgroups patch would have to take what's been done for multigroups rather than the opposite way.

- Using drupal_execute to create nodes with multigroups programmatically: Please, see comment #83 on this other issue.

Please, don't try this on production sites. Note that there are no upgrade paths between dev versions of these patches.

rconstantine’s picture

I think I found a bug. If one creates a set of fields in a multigroup, creates nodes, then adds a new field to that multigroup, errors abound. Perhaps when a new field is added, multigroup could back fill the new fields with empty deltas to 'catch-up' to the latest row in storage.

markus_petrux’s picture

@rconstantine #469: I have just tested this and it worked ok here. I had a multigroup with a radio buttons field, and an integer. I had nodes of that type created, then I added a 3rd integer field to that multigroup and I was able to edit existing nodes to update data, add values to the new fields, etc. No problems so far here.

Could you please describe what you did so I can try to reproduce it on my dev environment? Also what kind of errors you saw and where?

rconstantine’s picture

It's possible I've gotten out of sync with you despite best efforts, or I could have introduced the bug myself. I'll pursue that angle first. Thanks for looking.

rconstantine’s picture

I wrote a long message about the error, and then right as I was about to click on save, I realized I didn't grant perms on those fields to non-user 1 folks. My bad.

However, this does bring up a valid bug. The error I mentioned occurs when a user doesn't have permissions to edit that field. The columns in the multigroup still show up, which I think is why the error is thrown. So, multigroup needs to actively account for when a user can edit some fields in a multigroup, but not others.

Thoughts? The error is on the array_merge in the fixup function. Specifically the first arg isn't an array.

andreiashu’s picture

Markus: about

1. If i have a field into a multigroup that has a default value it won't work: on the edit form only the first instance of the field has the default value assigned to it, the rest that are added after it are blank.

I've opened up an issue here: #411558: Default value partially working for fields with multivalue

koala098’s picture

subscribe

markus_petrux’s picture

@rconstantine #472: Oh, I see what you mean. The multigroup should ignore fields if $form[$group_name][$field_name] is not set.

BTW, I believe the fieldgroup module would not have to invoke hook_fieldgroup_form() when the group has no accessible fields. If am I correct here, then this would be a bug that could be resolved and committed from a separate issue. ¿?

Edited: Please, ignore the attached file, it's an error on my side, sorry.

Edited again: Nah, ignore my second paragraph. That hook could be implemented by someone else, not just the multigroup, not sure for which purpose, but still...

Also, I noticed I was using a function that's only present in PHP5. array_intersect_key(). Too bad, I will have to change it because CCK2 should still be compatible with PHP4. :(

markus_petrux’s picture

Ok, now this is the multigroup module updated.

Changes since #468:

- Removed use of array_intersect_key(), compatibility with PHP4.
- Simplified rendering of 'remove' checkboxes.
- Minor simplifications in usage of $group_fields array around the node form related code.
- Hopefully fixed issue mentioned by Ryan in #469/472 about field access causing PHP errors. Thanks! :)

REQUIREMENTS: Please, read carefully #468 above for additional details.

talatnat’s picture

Status: Needs work » Needs review

phew! some thread, subscribing

koala098’s picture

Hello,
I am a little bit confused now.
I have installed #476 and activated in the module selection, but nothing happens. What have I to do additionally and where should the option "Mutltigroup" appear?

Agileware’s picture

@ koala098
- You have to do as instructed on #468 except if you use the most recent dev version you don't need the patch here - http://drupal.org/node/409398 - because it has already been committed.

I have tried the version at #476 and for my usage it is awesome.

Thanks.

excaliburst’s picture

I have been using the MultiGroups for 14 days now and must admit that this really rocks. I can group my fields and have more instances of groups if need be.

Very nice - Thanks guys.

I have found a bug though. When I make a view I get multiple of the nodes that have more than one MultiGroup... (klicked 'Add more...') The more moltigroups the wilder the exageration of duplicates...

Is this a known bug? Can it be fixed easily? If need be, I can post an export of my view.

I have read otherwhere that multiple instances of taxonomy will also create duplicates. This I have removed so no more than one instance per taxonomy is allowed. But I still get the duplicate. And just tonight it dawned on me that the number of duplicates are proportional to the number of multigroup instances I have in a node.

Any ideas as to how I get rid of this peculiar behavior?

Thanks

Morten E.

coltrane’s picture

The Views problem is limiting which values display from multi-value fields in a multigroup. We can limit the query with the solution in #435, basically “WHERE field1.delta = field2.delta” but we also need another plugin to handle display. Views plugins are new to me but I'm thinking a field plugin that is available for each multigroup. Ideally it extends existing field handlers and just adds association between deltas for all fields. I think this work should get it's own issue, yeah? I've begun prototyping but am far from having anything workable.

rjbrown99’s picture

FileSize
58.86 KB

Thanks to Markus and the others who have worked on this patch. I am encountering the following error with the tarball from #476.

array_merge() [function.array-merge]: Argument #1 is not an array in /usr/local/www/apache22/data/sites/all/modules/cck/modules/content_multigroup/content_multigroup.node_form.inc on line 429.

array_merge() [function.array-merge]: Argument #1 is not an array in /usr/local/www/apache22/data/sites/all/modules/cck/modules/content_multigroup/content_multigroup.node_form.inc on line 429.

array_merge() [function.array-merge]: Argument #1 is not an array in /usr/local/www/apache22/data/sites/all/modules/cck/modules/content_multigroup/content_multigroup.node_form.inc on line 566.

I am using 6.10, dev CCK from March 22, latest dev filefield and imagefield modules as of today March 25th. The multigroup is in use on a content profile node and the error appears when I click "save" to store the updated fields. The error appears in a group as shown above in the Drupal log. No error appears in the www/php error logs or Drupal logs.

My multigroup is an "education" field, where there are 3 fields in the multigroup. The fields are:
1) Text field for degree
2) Date field for years attended
3) Content Taxonomy for School Name (to select from a list/vocabulary)

I also receive an error right on the page if I click the "Add more values" to display a second multigroup entry. This produces two of the errors again, both on line 429.

Let me know if you need anything else and I'm happy to provide details or a login to my dev environment if you want to see it first-hand.

markus_petrux’s picture

@rjbrown99 #482: Thanks for the report. I'll looked into it, and it seems to happen on fields that the multigroup originally had, but at the time that part of the process is executed are not present in the form values array. The reason for this I still don't know.

One thing I would like to ask you, is that in your description you say the multigroup has 3 fields, but the last one (the content taxonomy field) is not visible in the screenshot. Are you doing something to hide that field?

wmostrey’s picture

I have tested the version in #476 with the latest filefield dev version and it works as expected! Thanks so much, this solution saved me so much time in custom development.

I do have an issue with the WYSIWYG module and its TinyMCE editor. When I add a new instance then the text in the other textareas gets cleared. So let's say I have multigroup consisting of a textfield and a textarea (with TinyMCE enabled). I create a new node and fill in some text in the first two textareas, and make them bold. If I now add another instance then a new textfield and textarea appear but the text in the 2 other textareas disappears.

rjbrown99’s picture

Ah interesting Markus. When I navigate to permissions, I have edit rights on for two of the three fields but not all three. That may be part of it and explains why it behaves differently with the admin user vs a non-admin user. Even though the fields form a multigroup, permissions on the /admin/user/permissions page are still controlled individually for each element and not as a group. This may be a part of the error - I'll modify and see if it helps. I'm not sure what you can do to fix that except throw up a different error when there is a permissions miss by the admin and/or also submit a patch for the permissions to control them as a single group.

Thanks for the feedback and great catch.

eliosh’s picture

FileSize
11.76 KB
90.41 KB

Hi markus,
i've followed instruction in comment #468, using tar in comment #476.

Now i have a problem: i can't remove element from neither multigroup nor normal multi value field.

For example, see attached image (example screenshot 1). HTML generated is as follow:


<td class="content-multiple-remove-cell"><div id="edit-group-stanzeappartamenti-0--remove-wrapper" class="form-item">
 <input type="checkbox" class="form-checkbox content-multiple-remove-checkbox" value="1" id="edit-group-stanzeappartamenti-0--remove" name="group_stanzeappartamenti[0][_remove]"/>
</div>
</td>

In screenshot "Example screenshot 2" you can see a normal "Text content multi value".

What can be the problem?

markus_petrux’s picture

@excaliburst #480 / @coltrane #481 Yep, views integration for multigroups might need a bit more love, but this could be worked out once the module is committed. TBH, I'm not really sure how to approach that. Another thing that could be done in the future is alter the logic in CCK that decides in which table a field lives so that all fields in a multigroup share the same table. Again, I wouldn't climb these mountains now. Otherwise, this will become a never-ending story.

@rjbrown99 #485: Thanks for confirming. I think I know where the problem is (in the multigroup) and will provide an updated tar when I have the time.

@eliosh #486: It might be a javascript error or conflict with something else in the page, or maybe that you have not completely applied the patch in #196421: Deleting unwanted multiple values / multiple values delta issues.

andreiashu’s picture

Hi Markus,
I just updated cck to the latest dev snapshot and multigroup to your latest patch version.
I stumbled a bug though.
When I click the "Add more values" button, it changes its id from something like "edit-group-tralala-add-more-1" into "edit-group-tralala-add-more".
Edit: I forgot to say that before updating CCK and multigroup this behaviour did not appear.

Edit2: the bug was coming from the delegator module of chaos tools. Very sorry for the false report.

andreiashu’s picture

I investigated some more and I think that the bug comes from CCK itself. I'll open a bug there.
My bad, the problem appears just on multigroup forms. For multivalued forms, it doesn't. So it still is a multigroup bug as far as I can tell.

Edit: the bug was coming from the delegator module of chaos tools. Very sorry for the false report.

coltrane’s picture

@markus #487 I'm not waiting on Views integration: #416154: Synchronized deltas Views integration: Filter on equal deltas in multigroups. And I think an associated delta filter is not limited to just multigroups so development can happen in parallel. I'd love your feedback on the approach. I wouldn't be this far without all your hard work (and others! /me looks at rconstantine et all) on this.

andreiashu’s picture

FileSize
646 bytes

Another minor bug: the number of header THs html elements is not the same as the number of TDs.
I attached a patch.

andreiashu’s picture

The bug described in #488 was caused by the delegator module. very sorry for the false report.

markus_petrux’s picture

@coltrane #490: Sweet. I'll try to check that when I have the time. Thanks for the link. :)

@andreiashu #491: Nope. I believe the output is generated correctly. Note that a colspan is added when needed. Try using an HTML validator.

Here's an example of a table for editing a multigroup when 'Multiple columns' option is enable in Multigroup settings:

<table id="group_xxx" class="content-multiple-table content-multigroup-edit-table-multiple-columns sticky-enabled">
  <thead>
    <tr>
      <th></th>
      <th> [...Field Label 1...] </th>
      <th> [...Field Label 2...] </th>
      <th class="content-multiple-weight-header">Order</th>
      <th class="content-multiple-remove-header">Remove</th>
    </tr>
  </thead>
  <tbody>
    <tr class="draggable odd">
      <td class="content-multiple-drag"></td>
      <td> [...Field Widget 1...] </td>
      <td> [...Field Widget 2...] </td>
      <td class="delta-order"> [...Weight Widget...] </td>
      <td class="content-multiple-remove-cell"> [...Remove Button...] </td>
    </tr>
    <tr class="draggable even">
      <td class="content-multiple-drag"></td>
      <td> [...Field Widget 1...] </td>
      <td> [...Field Widget 2...] </td>
      <td class="delta-order"> [...Weight Widget...] </td>
      <td class="content-multiple-remove-cell"> [...Remove Button...] </td>
    </tr>
  </tbody>
</table>

And here's another example when 'Multiple columns' option is NOT enable in Multigroup settings. See the colspan in the first TH cell.

<table id="group_xxx" class="content-multiple-table content-multigroup-edit-table-single-column sticky-enabled">
  <thead>
    <tr>
      <th colspan="2"></th>
      <th class="content-multiple-weight-header">Order</th>
      <th class="content-multiple-remove-header">Remove</th>
    </tr>
  </thead>
  <tbody>
    <tr class="draggable odd">
      <td class="content-multiple-drag"></td>
      <td><h3> [...Subgroup Label 1...] </h3> [...Field widget 1...] [...Field widget 2...] </td>
      <td class="delta-order"> [...Weight Widget...] </td>
      <td class="content-multiple-remove-cell"> [...Remove Button...] </td>
    </tr>
    <tr class="draggable even">
      <td class="content-multiple-drag"></td>
      <td><h3> [...Subgroup Label 2...] </h3> [...Field widget 1...] [...Field widget 2...] </td>
      <td class="delta-order"> [...Weight Widget...] </td>
      <td class="content-multiple-remove-cell"> [...Remove Button...] </td>
    </tr>
  </tbody>
</table>
koala098’s picture

@excaliburst and
@rjbrown99 :

How do you use taxonomy in multigroup? I thought it isn't possible?

andreiashu’s picture

@koala098: I think they use content_taxonomy

koala098’s picture

@andreiashu:
Yes, I use it, too. But when adding a content taxonomy field to a multigroup the message appears:
"This change is not allowed. The field ct handles multiple values differently than the Content module. Making this change could result in the loss of data."
What am I doing wrong?

andreiashu’s picture

@markus thanks for the explanation. But I still don't agree :) Maybe I patched CCK and multigroup incorrectly ?
In default garland theme you cannot observe this behaviour. But I went in firebug and manually set thead th {background-color:#CCCCCC;}
I attached the screenshots. It is with multiple columns enabled.

andreiashu’s picture

@koala098 - Sorry I can't help you with that (don't know). But I'm sure someone in here can.

markus_petrux’s picture

@koala098 #494: See the explanations on the multigroup above. There's a note about content taxonomy.

@andreiashu #498: I see your screenshots, but I cannot reproduce it here, also using garland. Well, in fact it should be the same HTML with any theme as long as you do not override any theme function of the multigroup module. If you do, then the problem might be there. Another possible cause could be related to caches, or maybe if you have several instances on the multigroup module in different directories.

If there's a problem in the theme of the multigroup we need to identify the real cause.

andreiashu’s picture

FileSize
380.7 KB

blah... d.o deleted my comment...

@markus: as far as i can tell the html rendered structure is the same as the one you provided in #493 - so it is the correct one. The problem is that the css classes 'content-multiple-weight-header', 'content-multiple-remove-header' and 'delta-order' have the property "display: none" (defined in content-module.css file). So this means that in thead you will have 5 th-es of which 2 ('content-multiple-weight-header' and 'content-multiple-remove-header') are hidden and in tbody you'll have 5 tds of which 1 ('delta-order') is hidden. So syntactically everything is fine but visually it isn't because of the css classes, or better yet the properties that those classes have.

And yes, my patch wasn't correct from this point of view but nonetheless the visual "bug" remains (at least on my installation). If no one else can reproduce this then this means it is something from my installation environment (but I tend to doubt that).

I attached a firebug screenshot.

My theme is clean (original garland).

markus_petrux’s picture

@andreiashu #500: Ahah! Good catch indeed. :-D

The fix for this will also affect the patch in #196421: Deleting unwanted multiple values / multiple values delta issues

In summary, it will be like this:

Changes in theme/content-module.css

-html.js .content-multiple-remove-header,
+html.js .content-multiple-remove-header span,

Changes in content.module:

-      $header[] = array('data' => t('Remove'), 'class' => 'content-multiple-remove-header');
+      $header[] = array('data' => '<span>'. t('Remove') .'</span>', 'class' => 'content-multiple-remove-header');

Changes in modules/content_multigroup/content_multigroup.node_form.inc

-      $header[] = array('data' => t('Remove'), 'class' => 'content-multiple-remove-header');
+      $header[] = array('data' => '<span>'. t('Remove') .'</span>', 'class' => 'content-multiple-remove-header');

Added to my working copy and I'll provide updated patches as soon as I have the time.

Thanks!

andreiashu’s picture

@markus: great :)
thanks

quicksand’s picture

Hello,

Confusion

I have installed #476,activated this module, but i can't see the option Multigroup at the creation of a new group.

I understand that the patchs are no longer necessary. Then What's the problem ?

Thanks

quicksand’s picture

Solved !

I had to install the last dev version of CCK.

Thanks

Agileware’s picture

You have to be using the dev version of the module.

If your dev version is from after the 24th of march you don't need the patch at http://drupal.org/node/409398 because it was committed then.

You still need the patch and two image files from http://drupal.org/node/196421.

All the info you should need is at #476 and #468 of this issue.

quicksand’s picture

Thanks Agileware.

My dev version is from after 24th of March (27th). Now i can see the option to select multigroup at the creation of a new group.

Now, how can i apply the patch in #127 at http://drupal.org/node/196421 ?

Thanks

rjbrown99’s picture

Status: Needs review » Needs work

Here's the process I use to roll an updated snapshot as of today on a FreeBSD box. This will get you an updated CCK, patched multigroup, latest filefield which supports multigroup, and the latest content taxonomy with support for multigroup. Your mileage may vary but this is my current process.

This does NOT include the fix from post #501, so if you want/need that you will have to manually add it.

#!/bin/sh
#
# Create dist directory
mkdir dist

# Download and extract CCK snapshot
echo "[ Downloading CCK ]"
wget http://ftp.drupal.org/files/projects/cck-6.x-2.x-dev.tar.gz
tar zxf cck-6.x-2.x-dev.tar.gz
mv cck-6.x-2.x-dev.tar.gz dist

# Download patch and icons
# http://drupal.org/node/196421
echo "[ Downloading graphics and patch ]"
wget http://drupal.org/files/issues/button-remove.png
wget http://drupal.org/files/issues/button-throbber.gif
wget http://drupal.org/files/issues/cck-196421-131.patch

# Copy images to new dir cck/images
echo "[ Copying graphics ]"
mkdir -p cck/images
mv button-remove.png cck/images
mv button-throbber.gif cck/images

# Apply patch to CCK
cd cck
patch < ../cck-196421-131.patch
cd ..
mv cck-196421-131.patch dist

# Download Filefield snapshot
wget http://ftp.drupal.org/files/projects/filefield-6.x-3.x-dev.tar.gz
tar zxf filefield-6.x-3.x-dev.tar.gz
mv filefield-6.x-3.x-dev.tar.gz dist

# Download latest content multigroup
wget http://drupal.org/files/issues/content_multigroup-119102-476.tar_.gz

# Install latest multigroup dist
rm -rf cck/modules/content_multigroup
cd cck/modules
tar zxf ../../content_multigroup-119102-476.tar_.gz
cd ../..
mv content_multigroup-119102-476.tar_.gz dist

# Download content taxonomy
wget http://ftp.drupal.org/files/projects/content_taxonomy-6.x-1.x-dev.tar.gz
tar zxf content_taxonomy-6.x-1.x-dev.tar.gz
mv content_taxonomy-6.x-1.x-dev.tar.gz dist

# Patch content taxonomy to support multigroup
cat <<EOF>> content_taxonomy/content_taxonomy_options.module
/**
* Implementation of hook_content_multigroup_allowed_widgets().
*/
function content_taxonomy_content_multigroup_allowed_widgets() {
  return array('content_taxonomy_options', 'content_taxonomy_select');
}

/**
* Implementation of hook_content_multigroup_no_remove_widgets().
*/
function content_taxonomy_content_multigroup_no_remove_widgets() {
  return array('content_taxonomy_options', 'content_taxonomy_select');
}
EOF

# Fix ownership - THIS WILL BE DIFFERENT FOR YOU BASED ON YOUR LOCAL USERS/PERMISSIONS
chown -R root:drupal cck
chown -R root:drupal filefield
chown -R root:drupal content_taxonomy

# Backup existing modules - USE WHATEVER YOUR LOCAL PATH IS INSTEAD OF MINE
BACKUPDATE=`date +%Y%m%d%H%M%S`
mkdir backup.$BACKUPDATE
cp -R /usr/local/www/apache22/data/sites/all/modules/cck backup.$BACKUPDATE
cp -R /usr/local/www/apache22/data/sites/all/modules/filefield backup.$BACKUPDATE
cp -R /usr/local/www/apache22/data/sites/all/modules/content_taxonomy backup.$BACKUPDATE

# Remove existing modules
rm -rf /usr/local/www/apache22/data/sites/all/modules/cck
rm -rf /usr/local/www/apache22/data/sites/all/modules/filefield
rm -rf /usr/local/www/apache22/data/sites/all/modules/content_taxonomy

# Move new modules into place
mv cck /usr/local/www/apache22/data/sites/all/modules
mv filefield /usr/local/www/apache22/data/sites/all/modules
mv content_taxonomy /usr/local/www/apache22/data/sites/all/modules

echo "[ Completed. Make sure to run update.php ]"
andreiashu’s picture

I think you changed the status by mistake :)

quicksand’s picture

Status: Needs work » Needs review

Hello,

I'm getting the following error when i try to group Content Taxonomy fields in a multigroup :

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

How can i solve that ?

Thanks

markus_petrux’s picture

@quicksand #509: It seems to me that you need to apply the patch to Content Taxonomy module as pointed to by #468, which is the last comment where I tried to summarize all the relevant information of this issue. Latest version of the multigroup, at this moment, is at #476 however, but that one points to the correct place.

@all: I'm about to upload a new version of the multigroup in a moment...

markus_petrux’s picture

Changes since #476:

- Hopefully fixed issues with fields where the #access attribute has been set to FALSE. ie. User does not have access to those fields.
- Fixed issue with missing header cell (thanks to andreiashu for pointing it out).
- Fixed theme functions for table formats. No output generated when fields are empty.
-
-

REQUIREMENTS: See comment #468.

Oops. I made a little mistake. Please, take the tar in #512.

markus_petrux’s picture

rconstantine’s picture

C'mon everybody! Test and report back! Let's get this sewn up!!!

andreiashu’s picture

Status: Needs review » Needs work
FileSize
8.8 KB
10.68 KB
23.19 KB

Oki, found one.

Steps to reproduce:

1. Create a new node type (lets say 'test_multi') that has 2 multigroups ('group_multi_1', 'group_multi_2') and 2 textfields ('field_text_1', 'field_text_2') - attached screenshot 'Multigroup_test_1_0.png'.
2. Assign each multigroup 1 textfield.
3. Add a new node (of type 'test_multi') and add 2 values for each textfield (like in the attached screenshot 'Multigroup_test_1_1.png').
Result: after you add that node, 'Text 2_2' does not appear. Also if you look into the DB you can observe something fishy (in my opinion): you'll have a table called content_type_test_multi which has 'vid', 'nid' and 'field_text_2_value' as columns. And you'll also have a table called 'content_field_text_1'. Isn't this wrong ?

//// Edit: I forgot to specify that I use the latest stuff that Markus uploaded in this issue and the other one with "Delete ... ". Also, something that seems important: I've used the default values for both textfields and multigroups for the test. Can anyone else confirm this bug ?

andreiashu’s picture

@Markus: I remember that I saw someone that uploaded a patch with the tests for multigroups (I think rconstantine was). I think it would be wise to attach those tests to your next tar so we can add to them when we find some new bugs. This way we could better be sure that the old bugs don't keep reappearing. Also, probably KarenS and yched would feel more confident committing this patch to core ;)

markus_petrux’s picture

@andreiashu et all: coltrane provided a simpletest case in #454.

If someone else can confirm that works with latest multigroup module in #512, then I'll include it from now on.

@andreiashu #514: The multigroup module doesn't affect the DB layer of CCK. It's CCK itself that decides which tables are needed for each field. If you have a multiple valued field, it needs a delta column in the table key and CCK creates a table for that field. So if a content type contains only multiple valued fields, you end up with a table per content type that's empty, and a separate table for each multiple valued field.

One thing that could be done at one point once the main multigroup module is in, is that we could try to alter the DB layer of CCK in a way that all fields in the same multigroup are stored in the same table. ie. a table for the whole multigroup.

andreiashu’s picture

@markus about #514 and your related answer in #516: apart from that curiosity of mine related to the DB stuff, that comment actually describes a bug in multigroup module :) I'll copy here only the stuff that relate to the bug:

1. Create a new node type (lets say 'test_multi') that has 2 multigroups ('group_multi_1', 'group_multi_2') and 2 textfields ('field_text_1', 'field_text_2') - attached screenshot 'Multigroup_test_1_0.png'.
2. Assign each multigroup 1 textfield.
3. Add a new node (of type 'test_multi') and add 2 values for each textfield (like in the attached screenshot 'Multigroup_test_1_1.png').
Result: after you add that node, 'Text 2_2' does not appear.
Expected behaviour: Text 2_2 should appear in the node view.

andreiashu’s picture

I corrected a little bit the test that coltrane provided in #454 and now it runs smooth ('94 passes, 0 fails, and 0 exceptions').

You need to have simpletest 2.7 installed.

After markus solves the bug described in #514 I'll add a test for it too.

MickC’s picture

@markus, thanks for your work here - specifically regarding your comments in #516, I believe the DB layer solution is what I'm looking for - effectively a table of multiple fields, rather than a group of tables for each individual field. Ideal for parent child relationships where the parent is a node, and the children are multiple entities relating to that node requiring additional data specific to the node context, without the need for another node layer.

The only other way to achieve this is to create another node layer, which can add complexity unnecessarily, including the redundant title and body. The node reference concept is great to avoid the redundancy, but limited to only one field at a time. Multigroup is a workaround, but ultimately an entire table of fields including the node reference is ideal.

Example:
Node type event, which can have a number of items relating to the event, each item being a node as well. In the one form, a user can create the event, then add each item as an autocomplete node reference, and add other fields particular to the item in the context of the event. Multigroup does enable this to happen, but it seems to me to be architecturally cleaner to have all these in the one table. That would provide the opportunity later to:
1) modify the edit form to be able to edit as a table / matrix style
2) enable more interesting / complex views using the fields from the table - views would have to be able to access all fields

I would be interested in your outlook on the feasibility of the same table solution and whether a near term or long term prospect.

quicksand’s picture

@ markus_petrux #510 : Thanks for your help. It seems to me that, the patch of content taxonomy module is old, i'm getting the following error when trying to patch content_taxonomy_options.module.old (file does not exist).

redijedi’s picture

subscribing

lefnire’s picture

subscribing & testing

rjbrown99’s picture

I had an interesting thought/comment regarding required fields. I have a multigroup called "Education" on a content profile node with three fields - one for school name, one for degree name, and one for dates attended. The Multigroup is not required, but each of the individual sub-fields IS required. The logic is that the user can optionally submit an education field, but in the event they elect to complete the education multigroup all three of the sub-fields would be required to complete the record.

Right now, with the behavior of the multigroup set to NOT required but the three sub-fields set as REQUIRED, I am unable to submit my changes as it fails validation when the sub-fields are not input. I hope that makes sense. Perhaps this is intentional but it's something we are going to have to work around on our side.

Thanks again to all for the efforts with this module.

marcvangend’s picture

rjbrown #523: That is a good one. To solve this properly, I think there should be an additional setting in a multigroup, like 'require complete rows'.

cYu’s picture

@#523 and #524, this is discussed in #363, #367 and #370.

eliosh’s picture

marcvanged #524: that will be great. I'm in the same problem here.

markus_petrux’s picture

Not sure to understand the problem. :-|

Now requirements policy in multigroups is implemented in the following way:

- Required option at multigroup level means at least one subgroup of fields in required.
- Required option at field level means if you create a subgroup, all required fields must be filed.

If you need the users to fill in all fields in a subgroup, then just made them required. Users will be able to remove the subgroups they don't wish. But if they add one, they need to fill in all fields that are required.

Is there anything missing? Is it not working like that? If so, it might be caused by the implementation of hook_is_empty() of certain fields.

servantleader’s picture

The problem is that one subgroup is created by default, so the users are required to click the remove button. This is non-intuitive. Web users are used to just leaving fields blank that do not apply to them. In #523 someone who did not go to college would just leave that section blank, but he would get a validation error and think that having an education was a requirement for using that website.

In my application, I want to hide the entire multigroup with javascript until they click the "I need child care for the conference" button. When they do, I want them to have to enter both the name and the age of the child, but I also want the form to validate when the multigroup is still hidden.

The way to solve this is to have the validation function first check for any completely empty multigroups and remove them before checking individual fields that are required. Hope this helps.

rjbrown99’s picture

FileSize
2 KB
14.79 KB

Markus,

My use case is that the required option at the multigroup level is off (so it is not required), and the three required options for the three fields are on (so they are required).

What I would expect to happen in this case is that the entire multigroup is optional, but in the event the users start entering information in one of the three fields, they are now all required.

What actually happens is that the multigroup itself is now required and the save of the content can not proceed unless information is entered for the field that is required.

Have a look at my attachments - the first shows the "Education" multigroup with three fields, School, Degree, and Start/End dates. The Education multigroup is not required, but the School field is required. When I try to save the site without inputting anything in School, Degree, or Start/End dates, I would assume that we could successfully proceed because the multigroup is not required. Instead, what happens is I receive the enclosed error message because the School field has not been entered.

The idea is that the behavior should allow the overall node content to save because the multigroup is not required.

markus_petrux’s picture

hmm... I see. So the problem is the first subgroup, which is always there, and when it contains required fields, users need to take action, either fill in that first subgroup or removing it explicitly.

On the other hand, there's a feature request in the queue that asks for a way to configure the number of elements rendered for multiple value fields that could also be applied here. If we had this here, we could use 0 for the number of default subgroups, and that would cover this issue. I think. Please, correct me if I'm wrong.

But... what do we show when no subgroup is rendered by default? Only the field labels (and descriptions)? What?

rconstantine’s picture

@Markus re#530: I see a couple of options here. I too have run into this problem. Of course, we shouldn't do anything that breaks the standard behavior of the new delete patch. But I think you'll agree that when a lone field is required and lives outside of a multigroup then it makes sense to not be able to delete the first row; whereas with the above examples, it would make sense to not store a first row when the group is not required and all fields are empty.

So, one option would be to check the first row and if it is empty, then not save it if the group itself is not required. Perhaps the 'required' controls could be moved from the field settings into the multigroup for central management?

Another option is the one you stated where the admin can set the minimum number of rows to display initially. However, would validation work in that case if the rows displayed is set to zero and the required fields work as they now do? Wouldn't the individual fields still expect at least one row and so work on the validation side of things need to be done anyway? If we can set the number of rows displayed to zero, all that should show is the 'Add another item' button, except that this message should be customizable for going from zero to one row, then switch back to 'Add another item' after we have at least one row.

Another option is to override/add another validation function to required fields inside multigroups which are not themselves required. This validation function would check if the field were empty and override the other validation function's results - i.e. validate the results even though they are empty.

I'm not sure which is the best/simplest to implement. There may be a better idea out there.

servantleader’s picture

That would work.
"But... what do we show when no subgroup is rendered by default? Only the field labels (and descriptions)? What?" - is should look the same as when someone removes all subgroups manually. It should probably add an"empty" css class so labels and descriptions can be hidden/displayed differently if desired.

Also, we could add an option "Remove empty subgroups" which would treat subgroups that have all empty fields as though the user had clicked the remove button as long as the subgroup itself is not required (even if there are required fields in the group). This would also prevent users from adding empty groups to the database (currently a user could add any number of empty groups, and that cannot be prevented without making individual fields in the group required).

rconstantine’s picture

@servantleader - it has already been decided that allowing empty rows is OK, so except perhaps in the case where there is only one row, that isn't going to be changed. See the patch on row deletion for more info on why. All we need here is some kind of conditional logic for 'required-ness'. I'm thinking now, that my first idea might be easiest - move the controls for required-ness to the multigroup module. Perhaps the asterisk could be placed next to the required fields by the multigroup module without actually setting the field element to required (thereby avoiding all of the automatic processing that occurs when that is the case). And on the back end during validation, the multigroup module could handle the check for required-ness and flag fields as necessary.

But I don't know the code as intimately as Markus, and perhaps this is something that should be a separate issue once this is in dev. In other words, maybe for now we should just say that if a single field in a multigroup is required, the whole row is.

servantleader’s picture

@rconstantine - Right. If I am reading the code correctly, we are already overriding the the 'required-ness' of individual fields in the function content_multigroup_node_form_validate() to disable FormAPI validation for required fields in the case of a group that is flagged for removal. All we need to do is add an additional condition that would also override required field validation when required.

The section of code I am looking at is:

        // Ignore subgroups flagged for removal.
        if (!$form_state['multigroup_removed'][$group_name][$delta]) {
          $is_empty_function = $field['module'] .'_content_is_empty';
          if ($is_empty_function($form_state['values'][$field_name][$delta], $field)) {
            if ($field['required']) {
              if (!empty($item['_error_element'])) {
                // Here we don't know the number of elements and subelements a
                // widget could have been added to the form, so we need to extract
                // components from the top, where we have group/delta/field, and
                // then push back field/delta on top of the list.
                $error_element = explode('][', $item['_error_element']);
RainbowArray’s picture

I've been following this project with great interest for several months now. I need this functionality for a couple of projects I'm working on, so I'm eager to see all of the great work on this become reality.

I think one thing to think about in the case where a multigroup is not required, but if a multigroup is used, the fields within it are required is to allow for the possibility that within a multigroup, there may be some fields that are required and some that are not.

For example, in the education example, perhaps a major might be required, but listing a minor might be optional.

I don't think you'd want it to be an all-or-nothing situation where once you fill out one field within a multigroup then all fields must be filled in.

It also strikes me that eventually the issue of multi-value fields within a multi-group is going to need to be solved. I've read the explanations as to why that won't work, but it seems that in theory there must be some way to eventually make that possible, even if it doesn't happen right away. I don't have a use case where that would be a problem, but somebody, somewhere is going to have a situation where they will need to do that.

Anyhow, thanks for all the great work. Hoping yched gets a chance to tackle getting deleting unwanted values into dev so that we can see move forward and get closer to being able to use this on production sites.

markus_petrux’s picture

@mdrummond #535: In regards to multiple value fields within the context of multigroups... there's currently a hard limitation here, because CCK database design, which can only deal with one dimension of multiple values per field. We just have, nid+vid+delta.

Once the basic multigroup functionality is in, there are probably more to do. For example, we now store fields in tables per content type, or per field, but we could have tables per multigroup rather than per field tables for fields in multigroups. Maybe then it is easier to approach a new dimension for multiple value fields in multigroups. Or when the multigroup is in, one could create widgets for multiple value fields that are serialized in the database, so that only one dimension is enough.

But I would say we first need to get this in... once we're one step further, we will be able to see much more... new opportunities to go even further are still unknown :)

@servantleader/rconstantine #534: Right. That's part of the code that deals with validation in multigroups. This was one of the more complex challenges I had to deal with. But maybe we don't need to touch that, if we can find the right way to generate the correct number of subgroup of fields. This is the key. I think we need to find a way that's easy to understand when configuring the multigroup, but also for users in the node edit form.

For example:

- We could add an option to configure the number of multigroups that need to be rendered when the number of repeats is set to unlimited.
- For this new option, if the multigroup is required, options would be from 1 to X, and when the multigroup is NOT required, options would be from 0 to X. The maximum number could be 10, for example.
- When set to 0, then in the node form, do not render widgets until the user requests them. The button could first read 'Add values', then when there are widgets, read 'Add more values' as always. The help text of the multigroup could be used to write instructions for the user.

Makes sense?

PS: On the other hand, now that yched is looking into this, I wouldn't be updating the multigroup module until the other issue is in. Ref: #196421: Deleting unwanted multiple values / multiple values delta issues. Reason is that CCK maintainers may wish to change all we've doing here, and since I don't have much time, I would prefer to see how things evolve. So I would suggest to drive the attention to the other issue in the hope to help that one to get in, and then we'll see what happens here.

MickC’s picture

@markus #536 - the "tables per multigroup" solution makes sense for reasons stated as per #519.
Seems cleaner, less joins, more performant, and could have multiple benefits - save node layers, transaction history, common reference data...

Maybe this is a more fundamental architectural improvement, then other issues like required/not-required and multuple values could be addressed after this.
Potentially multigroup tables could be the new CCK standard, and the current CCK single field tables retained for the exceptions.

I'm more of an analyst than a coder, so others please critique.

aries’s picture

subscribing

toemaz’s picture

subscribing and testing #512

aries’s picture

About #512:

  • It's not clear for me how can I convert a standard group to a multigroup. I changed it in the database directly.
  • When I'd like to attach an existing field to a multigroup, i receive the following error msg: This change is not allowed. The field Mértékegység already has 0 values in the database but the group Összetevők only allows . Making this change would result in the loss of data.
rconstantine’s picture

@MickC - I agree, but this, along with the required-ness issue should be addressed after this basic functionality is in dev.

yched’s picture

FYI : Beginnings of a discussion for 'complex fields in D7' - http://groups.drupal.org/node/21270.

markus_petrux’s picture

@#542: IMHO, that's a completely different approach to CCK itself. It is like telling FAPI could be extended with more and more element types (widgets), as complex as you wish, but CCK is a bit more than just widgets, so that idea will need methods to attach logic, storage, formatters, views integration, etc. to those widgets. FAPI is just a little part of the whole thing.

Agileware’s picture

I have a multigroup with three fields, a date field, an optionwidgets_select field and a nodereference_select field.

Depending on who is creating the node I want to hide the nodereference_select field.

With a normal single field I can set $form['field_nodereference']['#type'] = 'hidden' in a form_alter.

With this field in a multigroup this doesn't work (other changes I make to these fields in form_alter also don't take affect).

How do I go about altering fields within a multigroup during form_alter?

Thanks.

Agileware’s picture

On a separate matter...

If you set #access to FALSE on a field that is inside the multigroup the heading for that field still displays.
You also get an extra blank row appearing in the group that never gets used and can't be removed.

rconstantine’s picture

@Agileware Why are you hiding the field with form_alter? Why not just use field permissions? It's built-in to CCK. However, I think that the column title remains in that case, which is a bug. Try it out and let us know.

Agileware’s picture

Thanks for the idea. It completely slipped my mind.

It does have the same issues as I mentioned in #545 where the column title stays and you get the extra blank row.

Agileware’s picture

In the function theme_content_multigroup_node_form() in content_multigroup.node_form.inc if you change this part:

<?php
  if ($multiple_columns) {
    foreach ($group_fields as $field_name => $field) {
      $required = !empty($field['required']) ? '&nbsp;<span class="form-required" title="'. t('This field is required.') .'">*</span>' : '';
      $header[] = check_plain(t($field['widget']['label'])) . $required;
    }
    $table_class .= ' content-multigroup-edit-table-multiple-columns';
  }
?>

To be:

<?php
  if ($multiple_columns) {
    foreach ($group_fields as $field_name => $field) {
      if (array_key_exists($field_name, $element['#group_fields'])) {
        $required = !empty($field['required']) ? '&nbsp;<span class="form-required" title="'. t('This field is required.') .'">*</span>' : '';
        $header[] = check_plain(t($field['widget']['label'])) . $required;
      }
    }
    $table_class .= ' content-multigroup-edit-table-multiple-columns';
  }
?>

It fixes the problem with the column header.

Agileware’s picture

And...

In that same function at line 791 there is:

<?php
    foreach (element_children($element) as $delta => $key) {
    if ($key !== $group_name .'_add_more') {
?>

If you change this to:

<?php
  foreach (element_children($element) as $delta => $key) {
    if ($key !== $group_name .'_add_more' && is_numeric($key)) {
?>

It fixes the extra blank rows.

Agileware’s picture

Here is a patch. I've modified the second change slightly. I haven't fully checked whether or not this has any negative affect on anything else though.

lpt6’s picture

subscribe

---
My blog: www.his25.com
www.shuodui.com.cn

asips77’s picture

subscribe

bkildow’s picture

subscribe

Agileware’s picture

Here is another solution to the problem in #545.

This solution doesn't just hide the headings.

Before fields with #access = FALSE would not get put into the group.
This makes it so the fields are put into the group but the #access = FALSE is carried over when the field goes into the group. So the field is still not displayed but there is an entry for the field for each delta.

Having restricted fields that are required outside the group will cause problems when saving nodes.

zapscribbles’s picture

Subscribing

You guys rock, keep up the good work!

crea’s picture

About multi-value fields problem: it's actually very serious limitation, and there are many use cases when multiple value field is needed.

If multiple values in this way are not possible, wouldn't it be more reasonable to join forces at Flexifield module ? As I saw, they kind of half-fixed multi-value field problem already

rconstantine’s picture

@crea - per previous discussions, the limitation you site is simply not going to be tackled at this time. The current patches are quite large enough to deal with as they are. Solving "multiple values per row" will be done at a later time and several possible solutions have already been advanced to the participants here. It will require fundamental changes to CCK itself, not just multigroups so the changes will be non-trivial. Feel free to join in on the coding.

smithn.nc’s picture

Subscribing!

Squiggle already said it, but you all really do rock. :)

leovw’s picture

Subscribing

Ditto - Great work indeed

frankcarey’s picture

subscr-izzle

rjbrown99’s picture

Markus,

There have been a number of patches since #512 and I assume you may also have made some changes in the last few weeks. Would it be possible to roll a newer version for us to continue testing and/or move to an "alpha" test phase? It seems to be at a point were it might be stable enough to expand the test group.

Thanks again for all of your efforts.

rconstantine’s picture

@rjbrown99, I think Markus is going to wait for final decisions from yched before doing any more work on this as he has spent a lot more time than he had budgeted for in the internal project for which he produced all of this. In fact, he may leave all future work up to yched due to these same constraints. See the thread about the delete patch for more info. Perhaps chime in over there.

Miteto’s picture

Question - how does the multigroup change the themeable output - for instance there is a imagefield called image. So if the field is not in a multigroup one could use print $node->field_image[0]['view'] ; .
How do I get the same output as the above example when I put a field in a multigroup ? Don't get me wrong - I love multigroup and it's functionality.

macuhail’s picture

I dont see multigroup option. I have replaced the multigroup directory with the one in #512 and I am using the 6.x2.x-dev version of cck. However I dont see an option to turn a group into a multigroup when creating a new content type.

esend7881’s picture

Just wondering, which version of CCK will this feature be activated in?

I could actually use it, my current node is a bit cluttered with all my fields sequential. That is, I have fields that require MP3 files, PDF files, and text description, and to do all that, the fields are completely separate.

So when do we think this feature will be released?

markus_petrux’s picture

I'm very sorry, but I think it's a waste of time trying to keep this module up to date until the patch to CCK this module depends on is resolved in one way or another.

Please, note this is totally unsupported. It's just something that's not committed to CVS, which means it may change without further warning, and with no upgrade path at all between one version of the patch and another. Since this is very complex, it means it needs a lot of time trying to keep it up to date. And at this point in time, where the future of patch to CCK is unknown, it makes things a lot more complex here.

The hot spot is located here: #196421: Deleting unwanted multiple values / multiple values delta issues. And IMHO, there's little we can do here until the other patch is resolved in one way or another.

dboune’s picture

For those looking, note that you can locate this functionality in 6.x-2.2 and onward under the name content_multigroup. Navigate to the cck/modules/content_multigroup directory and view the README.txt file found there.

Do not expect this to be production quality. Limited use for me, so far, has been successful. Bug reports and patches are of course helpful. Submissions should probably consider that changes to the CCK core for support of this module, where they change the current handling of stored data, will not likely be accepted (see #196421: Deleting unwanted multiple values / multiple values delta issues). I'm still getting a grip on the details myself.

The title of this ticket should be changed as it is misleading, in my opinion. (A combo field being a textfield+dropdown wrapped in one, old definitions die hard; in addition, the current name of the representative module currently being "multigroup")

horaceho’s picture

Followed the README inside the 'hidden' content_multigroup module in CCK, finally I have this great module enabled.

When I check the datetime of the content_multigroup.module, it's 2008 Oct 22.

I know the 'latest' patches must be somewhere within this thread ;-) Which patch(es) I should not miss?

Thanks!

horaceho’s picture

The content_multigroup.module is kind of 'hidden' inside CCK. To enable it:

- download and "tar -zxvpf" CCK
- look inside the folder cck/modules/content_multigroup
- follow the README to enable it

Enjoy ~

macuhail’s picture

Thanks for the help. I was able to get the component working and it seems to work well. Do I still need to run the patch mentioned in #468?

If so, do I run the patch inside of the cck directory or inside of cck/content_multigroup?

lpt6’s picture

thx for all the effort and patches,

I have download #512 zip and uploaded to replace the original content multigroup folder under cck, however i cannot find the module in the admin module list, can anyone help ? thx

---
My blog: www.his25.com
www.shuodui.com.cn

marcvangend’s picture

@lpt6, as said only two comments before yours: follow the README to enable it. The name of that file is no coincidence...

ccshannon’s picture

subscribe

macuhail’s picture

I am still getting the following error when I attempt to place a content_taxonomy field in a multigroup: "This change is not allowed. The field label handles multiple values differently than the Content module. Making this change could result in the loss of data."

I am not sure that I have run the patch in #468 correctly (since a line was drawn through one link I assume that patch is no longer required). I placed the patch in the cck directory and ran: patch < file.patch.

I got a number of responses asking which file to use. Since I was not sure of the answer I simply skipped each section that generated that question.

What am I doing wrong?

Thanks for any help

lpt6’s picture

Hi Marc,

I have successfully enabled the module, but in no luck to change the group setting to multiple one(cannot find this changing option) to enable the function as stated in readme , many thanks if you can help.
---
My blog: www.his25.com
www.shuodui.com.cn

macuhail’s picture

I have been able to run the patches. However I am still having a problem with the content_taxonomy_options.module patch.

I get an error that says failed at 76.

Since the problem I have is getting the content taxonomy fields to work with multigroup, this seems to be the problem. Could someone post the contents of a working content_taxonomy_options file so I can try that?

Thanks

markus_petrux’s picture

Hey, the multigroup module shipped in the CCK package is not finished, buggy and most probably unsupported. I wouldn't recommend it, unless it's just for playing with it on a development environment.

No further work has been done on it by CCK maintainers. So the only evolution of it is the patch provided by this issue, a few comments above. Not remember exactly where.

But that patch is currently out dated, and this is because the multigroup module depends on the evolution of #196421: Deleting unwanted multiple values / multiple values delta issues. So please, read about it above, in this issue. Read the state of the other issue...

The multigroup module is dead until the other issue moves. That's sad news, but this is what real state of it, for the moment. And what happens from now on, depends on the CCK maintainers. It could be implemented in CCK itself, it could be other things... but anything it is, needs to know where the other issue goes.

PS: I just felt someone had to tell this.

macuhail’s picture

Below is the content of the .rej file created when the content_taxonomy_options.module patch fails:

***************
*** 76,79 ****
return $element;
}

- ?>
--- 76,91 ----
return $element;
}

+ /**
+ * Implementation of hook_content_multigroup_allowed_widgets().
+ */
+ function content_taxonomy_content_multigroup_allowed_widgets() {
+ return array('content_taxonomy_options', 'content_taxonomy_select');
+ }
+
+ /**
+ * Implementation of hook_content_multigroup_no_remove_widgets().
+ */
+ function content_taxonomy_content_multigroup_no_remove_widgets() {
+ return array('content_taxonomy_options', 'content_taxonomy_select');
+ }

Any ideas about why this is failing when apparently it has worked for others?

baldwinlouie’s picture

+1

Flying Drupalist’s picture

Subscribe!

Trunkhorn’s picture

subscribe

zio’s picture

subscribe

big_smile’s picture

I note that the Read ME file says this is not ready for production use.
If I use it with just the text widget (that has FCK enabled) and image field, will I be okay?
Or is it just not wise to use it on a live site at all?

marcvangend’s picture

@#583: There are some unsolved issues and regardless of the fields and settings you choose, nobody can guarantee that it will work on your site. There is also no guarantee that you will be able to upgrade your module to beta or final versions in the future, so in the worst case, you might have to migrate your data manually, or lose it. I will leave it up to you to judge what is wise and if you'll be okay.

markus_petrux’s picture

Status: Needs work » Fixed

Committed to CVS, the experimental branch tagged as DRUPAL-6--3

For further information, please read comments #236 to #244 of the "Deleting unwanted multiple values" issue.

rconstantine’s picture

Sweeeeeeet.

macuhail’s picture

I have installed the 6-3 dev branch, but I am still unable to add a content taxonomy field to a multi group. I continue to get the following message when I attempt to save such a field:

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

Any ideas about solving this. Do I still need to apply any of the patches with the 6-3 branch?

Thanks for any suggestions.

markus_petrux’s picture

Please, don't use this issue any more. Open a new one instead. You can choose the content_multigroup.module as the component associated to the issue, and you can choose the 6.x-3-x-dev version.

Status: Fixed » Closed (fixed)

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