Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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
Comments
Comment #1
bakr CreditAttribution: bakr commentedI am keeping an eye on this post...
I really wish I could contribute, and eagerly waiting for this feature.
Unfortunately, no PHP expertise.
Comment #2
Damien Tournoud CreditAttribution: Damien Tournoud commentedMaybe for Drupal 8. For Drupal 7, multigroup support is contrib material.
Comment #3
Alex Andrascu CreditAttribution: Alex Andrascu commentedPlease tell us if this an official Drupal.org 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).
Comment #4
kmadel CreditAttribution: kmadel commentedWhat 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?
Comment #5
tstoecklerI 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.
Comment #6
tstoecklerRe-titling / -categorizing
Comment #7
Alex Andrascu CreditAttribution: Alex Andrascu commentedI 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.
Comment #8
Damien Tournoud CreditAttribution: Damien Tournoud commentedMultigroup 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.
Comment #9
Damien Tournoud CreditAttribution: Damien Tournoud commentedAnd if all the point is to attract's Markus attention, let's move this one back where it belongs.
Comment #10
KarenS CreditAttribution: KarenS commented@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.
Comment #11
jrao CreditAttribution: jrao commentedOk, 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.
Comment #12
tstoecklerYup.
For CCK 3.x to get out of "jail" =), as you say it, we need:
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.
Comment #13
SeanBannister CreditAttribution: SeanBannister commentedsub
Comment #14
BenK CreditAttribution: BenK commentedSubscribing
Comment #15
bomarmonk CreditAttribution: bomarmonk commentedSubscribe
Comment #16
emilyf CreditAttribution: emilyf commentedsubscribe. 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.
Comment #17
seehat CreditAttribution: seehat commentedsubscribe
Comment #18
John Pitcairn CreditAttribution: John Pitcairn commentedsubscribe
Comment #19
Kipp Elliott Watson CreditAttribution: Kipp Elliott Watson commentedsubscribe
Comment #20
obrienmd CreditAttribution: obrienmd commentedSubscribe.
Comment #21
markdorisonSubscribe
Comment #22
kukle CreditAttribution: kukle commentedsubscribing
Comment #23
Einkahumor CreditAttribution: Einkahumor commentedSubscreeb!
Comment #24
Anonymous (not verified) CreditAttribution: Anonymous commentedSubscribe
Comment #25
RainbowArraySubscribe
Comment #26
WorldFallz CreditAttribution: WorldFallz commentedfyi the hotspot for this topic seems to currently be at #939836: combofield / fieldentity / field-collection / embeddables
Comment #27
jared12 CreditAttribution: jared12 commentedSubscribe
Comment #28
johnbarclay CreditAttribution: johnbarclay commentedI 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".
Comment #29
alasda CreditAttribution: alasda commentedI'd be interested in your approach and some code snippets if you're willing to post them somewhere.
Comment #30
jessepinho CreditAttribution: jessepinho commentedSubscribing.
Comment #31
yched CreditAttribution: yched commentedI 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 http://drupal.org/project/field_collection - still pre-alpha code, far from ready yet, though. But the future is bright :-)