As a reaction to the high interest rate in the multigroup feature of CCK i propose to open a discussion and gather a team to get this job done. I can volunteer on this one and i guess i'm not alone as long as a proper attention is drawn to this case. This is a feature request along with a request of proposals. More details here: #690140: Status of CCK3 and plans for D7 and here: #494100: State of the multigroup module. Anyone willing to get involved please react.

Thank you
Alex Andrascu


bakr’s picture

I am keeping an eye on this post...
I really wish I could contribute, and eagerly waiting for this feature.

Unfortunately, no PHP expertise.

Damien Tournoud’s picture

Title: State of the CCK 3.x multigroup module » Multigroup support
Version: 7.x-dev » 8.x-dev

Maybe for Drupal 8. For Drupal 7, multigroup support is contrib material.

Alex Andrascu’s picture

Please tell us if this an official statement or just another comment. I really wish to think that there are many things to happen in the 7.0 - 7.99 lifecycle of the D7 (at the end of the day this is the opensource platform that we all want to be the best one). So let's not be so itchy about D8 allready. Unless you have a pretty solid reason against this feature please note that I'm still volunteering for the D7 implementation of the CCK 3.x branch (and that's not just for the sake of it).

kmadel’s picture

What about getting a stable Drupal 6 branch for CCK 3 and then porting that to the already in development CCK 2 for Drupal 7? Is that the idea?

tstoeckler’s picture

Version: 8.x-dev » 7.x-dev

I just read through #690140: Status of CCK3 and plans for D7 and it seems the issue is not (at least not primarily, and definitely not for D7) of moving Multigroup to core, but whether D7 Fields API is actually compatible with the Multigroup module (in contrib). There are some substantial differences in CCK2 and CCK3 related to #196421: Deleting unwanted multiple values / multiple values delta issues, specifically the Multigroup module knowing when fields are empty. chx mentioned in #690140: Status of CCK3 and plans for D7 that there is a hook_field_is_empty that might be of importance.

I think this issue just needs:

Either: One of the CCK maintainers to say: "Yes, Multigroup will work with D7 Fields, no problem!"

Or: One of the CCK maintainers to state the 'problem' / 'difficulty' with Multigroup and then let of the Field API guys say: "Yes, we can do that." or "Ehh, no. Sorry!"

Only in the last case is there anything that needs to be done here and it can be discussed only when we know what the problem is.

tstoeckler’s picture

Title: Multigroup support » Figure out whether Fields API and Multigroup module can coexist
Component: field_ui.module » field system
Category: feature » task

Re-titling / -categorizing

Alex Andrascu’s picture

I agree with tstoeckler hoping (praying actually) that we will see that kind of answer in the near future. In the mean time kmadel made a point up at #4. As for my point i think we should draw markus_petrux attention and maybe ask him if he's willing to accept any kind of sponsorship or other form of help to get this further. As a member of this community and intensive user of CCK3 (i've developed an ERP wich is heavily based on multigroup feature and is runing in a production env allready) I'm willing to contribute in anyway i can to see this branch/fork up and running.

Damien Tournoud’s picture

Multigroup in CCK3 is basically a hack. This said, I don't see any reason why someone could implement "meta-fields" in Drupal 7, ie. fields that package other fields. One way of doing that is to dynamically merge the columns of those fields (which feels already less hackish then CCK3), but there are other solutions, like defining a dynamic entity per-multi-group.

Damien Tournoud’s picture

Project: Drupal core » Content Construction Kit (CCK)
Version: 7.x-dev » 7.x-2.x-dev
Component: field system » General

And if all the point is to attract's Markus attention, let's move this one back where it belongs.

KarenS’s picture

@Damien, the current implemention is indeed a hack, it was the only realistic way to get it working in D6. For D7 I would rewrite this completely. Instead of creating this as a fieldgroup (the hack) it can be done as a 'fieldable' field. In other words, create a field that is a fieldable entity so you can attach other fields to it. In theory this should be possible. Barry Jaspan and I had discussed this as we were working on the Fields in core work and both of us feel like it should be possible to do it that way. But you never know until you actually try to write the code, which no one has had time to do.

I would absolutely not try to port the existing method to D7. I'm not sure it would work and I'm very sure it's the wrong solution. Anyone who wants to work on this should try to do it as a 'fieldable field'. If you run into problems making that work, let's hear what they are and work through them.

jrao’s picture

Ok, am I right to assume that once a Drupal 7 contrib multigroup module based on field API is demonstrated to work, then CCK3 for Drupal 6 can be freed from jail? If so, I can contribute some time to look into this issue, although I'm pretty new to CCK and field API, so it may take some time.

tstoeckler’s picture

For CCK 3.x to get out of "jail" =), as you say it, we need:

  1. The (yet to be written) Fieldable fields module.
    This will possibly show that Field API is not flexible enough for that (ie that either we will have to commit core patches or Fieldable Fields for Drupal7 will have to implement hacks), but no one knows that until someone actually writes that code.
  2. An upgrade path from CCK 3.x
SeanBannister’s picture


BenK’s picture


bomarmonk’s picture


emilyf’s picture

subscribe. as D7 approaches and more and more of my clients need multigroup support, it seems more and more pressing to know if an upgrade path from cck3.x is going to exist. thank you to everyone who is participating in this discussion and trying to get some answers.

seehat’s picture


John Pitcairn’s picture


Kipp Elliott Watson’s picture

Issue tags: +CCK, +fieldable fields, +multigroup


obrienmd’s picture


markdorison’s picture


kukle’s picture


Einkahumor’s picture


PeiPeiH’s picture


mdrummond’s picture


WorldFallz’s picture

fyi the hotspot for this topic seems to currently be at #939836: combofield / fieldentity / field-collection / embeddables

jared12’s picture


johnbarclay’s picture

I did some work along these lines creating a compound field that dynamically worked with other field types (link, image, and a text field). With all the different processors and the namespaces of the sub fields it got pretty complex quickly. I think a fieldable entity would be a much less convoluted approach.

I do think the fieldset ui would be a great interface for this though. That is, first have the usercreate a fieldset and add whatever fields and configure their widgets and settings. Then have a little button off to the side of the fieldset configuration that said "turn me into a single compound field".

alasda’s picture

I'd be interested in your approach and some code snippets if you're willing to post them somewhere.

jessepinho’s picture


yched’s picture

Status: Active » Fixed

I think we can close this thread.
We now have a pretty clear vision of how a 'multigroup' solution can work in D7 (see #939836: combofield / fieldentity / field-collection / embeddables),
and have tried to make sure core's Field API provided the required flexibility (see #942310: Field form cannot be attached more than once).

Watch out - still pre-alpha code, far from ready yet, though. But the future is bright :-)

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

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