How's the status of CCK3 and when do you expect to release it?
We (the current maintainers of CCK, I mean) are discussing this issue internally. Meanwhile, please use this issue to monitor the evolution of CCK3: #494100: State of the multigroup module
Note that CCK3's purpose was to change the base code in CCK to support multigroups. Other than that, it is exactly the same CCK as in CCK2. Both branches get the same patches (we're taking care of that, adapting patches to CCK2 for CCK3 as needed), so both versions are equally up to date.
The main concern is that Drupal 7 is almost here, and I haven't had the time to work on D7 to make sure there's an upgrade path from CCK3/Multigroups to D7/Fields in core. This is because I'm still focused on D6 stuff, and pressured by daily job (trying to close the gaps on a project that has been taking me around a year and a half already), enough to have close to no time to spend on D7 matters, sadly, unfortunately. :(
So... if we release CCK3 stable, there's going to be a lot more sites using a version of CCK where its upgrade path to D7, in regards to Multigroups, is uncertain at this moment.
So the problem, IMO, is not to offer a stable release of CCK3, but to get someone with enough time to ensure Multigroups have an upgrade path to D7.
Somehow, I feel guilty in regards to this situation, because it was me how pushed to get a working Multigroups for CCK/D6, and I thought I was going to have to time to involve myself enough in Fields in core to help on this. However, time passes quickly, and I'm stuck to spend almost all my spare time on my daily job too, so I really can't work towards D7 at this moment.
Maybe it is time to turn the Multigroup idea into a real community project. I can try to help, but I cannot carry the torch right now.
thank you very much for your feedback.
are you working as freelancer and would a donation help to proceed development?
Because I am struggling with flexifields which has an issue with filefields ( http://drupal.org/node/583852 ).
I have the impression that doing it within cck with multigroup would be better anyways.
But if you know someone who can alternatively help me with the issue above, would be great too :) I pay if needed.
It's really a nice thing that you're asking for help. I'm sure the community can help this project with coding / testing if you're asking. At the end of the day it's our common goal and all of us want / need this new thingy (multigroup) done.
Better title. Also, I'm marking the following issue as a dup: #693832: Multigroup for 7.x
Subscribing and hoping we can rally community help....
I hereby declare my availability to help on releasing a 6.3 and porting this to D7. I do have some good (not flawless) php/mysql knowledge and i am getting aquinted with Drupal API as i develop. I can allocate 4 to 5 hours weekly (more if it's really needed) for this project. Also it would be quite nice (or quite necessary) to team up with others.
Don't blame yourself, Marc. You are doing great job, and I think a lot of people appreciate it. I also want to thank you for all work you do in different Drupal projects.
Instead, let's blame general Drupal upgrade treadmill. Kind of sucks to not have some feature in D6 because you can't port it to D7. Given that many people using D6 now don't even care about D7, something is very wrong. I always need to pass the link to CCK 3.x package manually, because people can't find it themselves. So who are we going to trick ? Noone. Or ourselves.
I somehow agree with that.
I installed CCK 3.x and it is working so far.
Thanks a lot for your efforts Markus!
Especially the multigroup feature is really great!
Intuitive and less hassle as flexi-fields.
yes, I also think that CCK 3.x is hard to find for the broader public (incl. myself)
How about posting it under Development releases at the module´s frontpage?
Would be easier to download and possibly generate more community feedback.
Thank you so much!
Unfortunately I can't help, because my php skills are too basic.
But I can help with testing and translations (DE/JP)
On my wishlist for CCK 3.x "multigroup within multigroup": http://drupal.org/node/300084
The multigroup feature is great!
I am using it on a production site and it would be a great loss if it is not ported to D7.
I won't start working alone but i volunteer to join a team :). Preferably with a skilled leader.
I can't volunteer time right now, but I just wanted to say that I support this project. CCK has always been a vital part of Drupal for me.
Please state the type/form of support. It will help to know.
I think you will have to contact those that are involved in Fields in core for D7 to sync efforts. The multigroup is not trivial, technically, and it might need something from core, which is where I'm not really sure.
For example, CCK3 itself differs from CCK2 because Multigroup needs to control which items in a multigroup are marked for removal, because the deltas need to be in sync. While CCK2 shifts empty deltas, CCK3 knows the difference between an empty element, and one that has been marked for removal. That's the key, and then it is Forms API nightmare to get it done.
Was it CCK2 that was molded into 'Fields' in D7? Isn't D7 in lockdown now?
Thanks markus. I've opened a feature request there #695636: Figure out whether Fields API and Multigroup module can coexist. All people interested in this should react (get involved) somehow. Otherwise we're loosing the odds.
Does a picture of what's been done and what needs to be done to roll this to D7 exist anywhere? Even a rough picture?
there is a hook_field_is_empty so fields in core know whether something is empty or not.
I don't know if this is where to raise issues with this potentially great module?
If a user creates/registers a new account with a multigroup in the content profile page, they receive the following error messages :-
Invalid argument supplied for foreach() in /<my-site-path>/modules/cck/content.module on line 926.
array_keys() [<a href='function.array-keys'>function.array-keys</a>]: The first argument should be an array in /<my-site-path>/modules/cck/content.module on line 926.
Reading this (and many other!) articles, and putting 2 and 2 together, I realised I recently upgraded CCK to cck-6.x-3.x-dev.tar.gz on Dec 29th. I rolled back to cck-6.x-2.6.tar and the problem went away.
It seems that CCK Multigroup cck-6.x-3.x-dev.tar.gz does not work with content profile during a new user registration initiated by the user. I have about 5 different versions of 6.x.3 (different dated versions up to and including to 26th January 2010 - the latest dev I can find) and none of them work. Only when I use a 6.x.2x branch - where multi-groups are not a feature - is all the data captured on the profile page that was entered during the registration process.
It seems to be to do with the user not having a record at the point of registration, because the multi-group data capture works for registered users. Maybe multi-group records are stored in a temporary table or in memory - keyed on uid - which could be undefined during registration...?
This could be such a good module...
BTW the whole confusion about official releases, D7, etc. is doing you a great dis-service... For what its worth, my advice is to get D6 CCK3 working asap, and let D7 come when its ready. I, for one, don't see myself upgrading to D7 for at least a year, and I'm sure the vast majority of others, with stable live websites, won't be rushing into it either...
Re: @michael38walker: "I don't know if this is where to raise issues..."
Please, open a separate issue. Also, see: Issue queue handbook.
I have created #705486: CCK3 and Content Profile module (new registrations)
Although it is a fantastic feature, I think CCK3's multigroup function is evolving into a problem:
Currently there are about 7'600 Drupal sites using 6.x-3.x-dev (and counting), see http://drupal.org/project/usage/484068.
#1 says that both branches (6.x-3.x-dev and 6.x-2.x-dev) will be kept equally up to date. However, they aren't in synch anymore, because there wasn't any commit to 6.x-3.x-dev since January. So, is 6.x-3.x-dev still supported and do CCK's maintainers plan on releasing a stable 6.x-3.0 release?
CCK3 is primarily about the multigroup feature, but it remains unclear if and how multigroups can be supported for D7 (see #695636: Figure out whether Fields API and Multigroup module can coexist). Can we expect a multigroup module for D7, including an upgrade path from CCK3 to D7?
It will certainly take several months until the first stable release of D7 and at least until then the number of people using CCK3 will most likely continue to rise.
I know, 6.x-3.x-dev was always marked as 'experimental' and has never been an officially supported release, but there was so much buzz around the multigroup feature in CCK3, that many people considered it safe to use it in production. Maybe that's just their fault. But the risk is, that we will end up with thousands of extremely unhappy Drupal users who are stuck with D6, because there is no upgrade path to D7 when it comes to CKK3's multigroup feature.
If we want to prevent such a situation (which we probably will), I think one of the following steps is needed:
Personally I think, if there is no solution regarding multigroups (module) for D7 and the upgrade path from CCK3 any time soon, it is better to say "CCK3 is no more, there will be no upgrade path for multigroups and we don't know for sure if this feature will ever be available for D7" to stop an increasing number of people from using CCK3 and running into foreseeable frustration when upgrading to D7.
I vote for 1 and 3. 2 isn't a real option, in my opinion, just because I'm one of those optimistic experimenters who planned on these features being maintained and supported.
I vote for 1 :-)
I know I can't run my site without multigroups. Have been using the 3.x-dev for almost a year and have had no problems.
Unfortunately, without a multigroup module for D7, I'll be stuck with D6 for the foreseeable future.
I know, for our purposes, we've planning on having the D3 multigroup module taken to it's logical development endpoint and become stable. It would be a great loss to us, and many others, if this project were canned.
We had to implement the dev version for the multigroup feature for one of our clients, so unless there's a viable alternative in D7 this client will be stuck on D6.
Subscribe. I'm one of those who figured CCK3 would eventually go stable and so have used it in several projects (and can image requiring multigroup support in future projects one way or another). I'd love to see option 1 in #26 happen if possible.
Add another to the need of multigroup functionality that CCK3 provides. We will remain on D6 until we have a better alternative. Thanks for the great module so far!
I think that the 3.x dev urgently needs to be updated in order to be in sync with latest 2.x (at least as much as possible). Please see the related post #3 in #717608: Cannot save 'Group Multiple Values' option in Views 3.x
Each multigroup should be an entity as those are readily fieldable. Add a multigroup_entity_reference to the original and you got somewhere. EntityFieldQuery wont be able to query these removed-by-one fields but oh well. Views bound to SQL will work.
Watching. We're using CCK3 multigroups in production.
I have been doing a significant amount of work into getting nested fieldgroups and multigroups working.
It is in my interests to help get cck multigroups into drupal 7 and I am willing to help make it get there.
On that matter, I am currently writing up some notes on areas where and how I believe cck should be improved for scalability and possibly performance purposes.
I would like to see HTML5 forms support like placeholder and new input types.
Subscribe. The lack of multigroup-like functionality in D7 will keep our company from starting new projects using D7.
All you people who write subscribe and whine "I can't use D7 in production", why dont you help implementing #53? Even if multigroup functionality arises it'll be useful to have a somewhat generic entity module. awesomerelationship module can take care of referencing. It also needs help. So who volunteers to help with coding? Contact me either via contact form or come to IRC for guidance.
Just so I understand you right. in #53 you are proposing that:
1. We create a new entity type, 'grouping'
2. When we start to configure a multi group we are effectively creating a new entity type
3. Under the hood we are using entity references to define the members of a multi group.
This actually squares a little with what I did instead of multi groups on a D7 site, creating a separate node type and having node reference to define what is 'in' the parent node.
It seems doable, and a good use of entities.
I know this very well, I am working on this http://drupal.org/project/cck_field_rename which support multigroup feature now. Also, I am using CCK 3 for several production sites so far I found no serious issue, except with Views 6.x-3.x-dev because Views 3 need quite lot of work to complete (CCK 3-dev working fine with Views 2 stable version)
@markus_petrux: the multigroup is brillian feature and we may release 6.x-3.0-alpha1 because I see no big issue on current 3.x dev version. The database model was ok.
Since the Database Model was ok then I think we need to release 6.x-3.0-alpha1 then create a to do list for next aplha2 and so on, and leave 'nested fieldgroups' issue after alpha1.
@markus_petrux: after checking the Database Model with DB Normalization method I found your DB Model need optimization, here are the unsuficient things:
A. Tables and Fields
Suppose we have 200 fields in multigroup, so we need:
- 200 tables !
- 200 x 4 fields (vid, nid, delta, fieldname_value) = 800 fields !
B. Master Detaill UI
We can not create a master-detail UI, i.e, using Delphi or VB, without LEFT JOIN each tables! Why LEFT join? Because CCK 3 don't save NULL values. We can solve this using "dataset" of Delphi/VB but very difficult to accomodate INSERT and UPDATE task!
Now using DB Normalization:
Suppose we have an PURCHASE ORDER form:
Header: PO Code, PO Date, Supplier Code
Detail (multigroup): Product Code, QTY, Unit, Price
With Normalization we need only 2 tables!
1. Table Master/Parent: content_type_po_master
2. Table Detail/Child: content_type_po_detail
So, for 200 fields in multigroup we only need:
1. 200 tables --> reduce to 2 tables
2. 200 x 4 fields =800 fields ---> reduce to vid+nid+delta + 200 fields = 203 fields
3. And the good news: you can use Delphi/VB master-detail UI directly!
What do you think? Changing this Database Model is not difficult since our CCK UI already handle this multigroup quite well.
@drupal-id.com: It should be possible, but it's quite tricky. Please, look at #520956: Add a new storage method for fields in multigroups
Note that the approach chx mentions in #53 is basically what bjaspan started with http://drupal.org/project/combofield, back in DC Paris in 09/09 :
'fieldable fields' - fields whose values have fields,
or, put another way, a field type whose values are fieldable entities,
or, put another way, a field type whose values are ids of entities that have fields,
or, put another way, a 'ghost-entity reference' field (a reference to an entity that has no existence of its own on your site, other than to hold values for a sub-part of a node),
or, put another way, more or less what we did using noderef before multigroups existed, only without cluttering your site with dumb nodes...
The code there was mainly proof of concept and is most probably largely stale now, but it is begging for someone to grab the wheel.
@yched, @chx: The idea of a 'ghost-entity reference' field is perfect, but does it present a paradigm shift that will make it harder to create an upgrade path to D7?
Is there actually a D7 multigroup module in development somewhere or is it still kind of waiting on the release of CCK3 and a clear upgrade path from D6?
subscribing. would cck's 3 multigroup be the best way to represent recipe ingredients in D7 or should I look somewhere else ? (at least to get it done in the next 4-5 months) each ingredient in the recipe should have a nodereference to a food, and a quantity. tnx !
@drclaw - "combofield / fieldable field / ghost-entity reference / whatever you name it" is indeed a paradigm shift. As a wild guess, a migration script should be doable from Mutigroup's formulation, although probably not fully trivial to write.
For what it's worth, it appears that several separate attempts for a D7 combofield have been started independantly. #939836: combofield / fieldentity / field-collection / embeddables is an attempt to coordinate.
Why don't we use something like nodereference + weight field to get an effect similar to multigroup?
The structure is already there: Create a type B with all the fields that should be in the group, and a nodereference to type A.
Or "entity reference" for D7 ?
The unclear/missing parts are:
1) Form: Add, edit and delete referrer nodes/entities from a widget in the node edit form. Ideally in a tabular way, such as with multicrud.
2) Display: Make a list / view of referrer nodes available as a displayable field. This can already be done with display suite + custom fields, or views attached to node displays.
A solution like this is not that far away, and it requires no changes at all to CCK's field storage.
@donquixote : This is exactly the plan for D7, and is taking shape in #939836: combofield / fieldentity / field-collection / embeddables .
Not easy on the 'widget' side, and some core work is still needed to make that possible, but I'm confident that we'll get through this.
Once http://drupal.org/project/field_collection gets more advanced, a data migration script from D6 multigroup to D7 field_collection should be doable. Just a matter of putting the right delta values on the right 'entity'.
Could we do the same in D6 ?
The field items would all be nodes, so this could cause some overhead.
The widget does not exist yet - I always had the idea that multicrud could be the solution, but atm I have other priorities.
Well, as you point, nothing prevents you to use nodereference in D6. Possibly combined with the awesome 'edit and reference' / 'create and reference' features in http://drupal.org/project/noderelationships.
Feel free to explore other ways, but this won't happen in CCK.
Nodereference can't be valid replacement for multigroup functionality in D6. There are entities which closely tied to their parent nodes. For example, if you had a job site, you wouldn't work history entries as independent nodes: not only they are unique for every worker, but also they have no meaning outside of the parent node (e.g. worker profile).
noderelationships nodereferences are in the wrong direction. The real thing would be a reference from the "child" node to the "parent" one. And crud widgets in the "parent" node.
The idea would be to not show anything where the child nodes would appear as something independent: No links to the full node page, etc. There is still some overhead I imagine. Not sure how severe it is.
@crea : this is of course the burden and limitation of the noderef-based solution. Which is why the D7 solution won't be based on nodes, but on transparent 'ghost entities'. No dummy nodes cluttering the node space.
@donquixote : "not parent --> child but child --> parent". Does not stand, the 'multi-field' is on the node, so it stores something on the node, not the other way around. Most of the needs go the other way (I'm on a node and I want to access its data, including those held by a sub entity), and getting the reverse is just a query.
Anyway, as I said above, this discussion happens elsewhere, folks :-). Please read the other thread if you have views on the topic, let's not rehash it here.
@yched (#84): I started this here, so I post one finishing comment.
"parent -> child" makes sense for the form widgets and for displaying the field. "child -> parent" is the correct way to store a one-to-many relation (one parent, many children) in the database, and this can only be achieved with a "child -> parent" nodereference.
We need new widgets that support "parent -> child" editing for "child -> parent" nodereferences. The above mentioned module does not do that.
@donquixote : no, and that's not how CCK has been doing it for the past 3+ years.
one-to-many = a multivalued nodereference field, with ids of children. Having them on the parent lets you define an ordering. Then views, or custom queries, or modules like backreferrer, let you retrieve the
parent(s) of a given child.
You're not editing a sub-entity to make it point to a parent, you're editing the parent. Thus the parent holds the value. Period.
As I posted on another of the multigroup issues, I am working on getting a stable version of multigroup working for a client now. We need this functionality and there are lots of sites using it now. The solution I will work on is finding the simplest possible way to get the current architecture working, it is way too late to re-architect the whole thing.
I have never made any guarantees that you can use any kind of field in a multigroup, I said from the beginning that it was likely to be something that would only work for fields that were not hard-wired to the 'normal' structure of cck fieldgroups, which includes the 'core' fields like text, number, nodereference, etc. and a few others. We won't solve the problem of not being able to have a multiple value field inside of a multigroup -- that just doesn't fit the current module. Changing it to store the fields all together in a single table may sound like an easy thing to do but it is not, it is very hard. It is really too hard to attempt this late in the D6 cycle. The D7 cycle is when modules will most likely be able to this in more creative and flexible ways. If someone finds a way to do it and submits a patch, I might change my mind and try to incorporate it, but I have no plans to go that direction.
There are several things in progress now for D7 that might be targets for a migration of the D6 multigroup. Hopefully one or more of them will try to ensure that there is a migration path from D6 multigroup into their modules. AFAIK none of them are far enough along yet to do that. The fact that there are several projects taking different approaches gives me some confidence that one or another of them might be a good upgrade 'destination' for D6 multigroup.
I am developing a web site for a church and have been able to do everything I need to with CCK2 and Views2 EXCEPT the member directory where I need a multigroup field for children:
first name birthday age(computed) (birthday and age will not be viewable except by administrators).
for n number of children per record.
It appears my choices are:
1) Upgrade the site to CCK3 and hope that a migration path to Drupal 7 exists if - and when - it would need to be migrated (at least a year).
2) Create a sub-domain for the directory with a second drupal installation and CCK3 and open the directory in a new window.
The site will have moderate traffic at best but needs to be quite stable.
Due to the small number of multigroup fields I am not overly concerned with the additional tables CCK3 would create.
I would appreciate advice / comments from anyone who has used (is using) CCK3 regarding stability versus using CCK2 as well as the most current thoughts regarding long-term multigroup functionality in Drupal 7.
Thank you . . . Mike
Taking a look at usage stats for CCK3, I see :
Week starting Count
November 7th 12,856
In issue queue, I actually count 12 open critical issues for CCK3 (which a lot less than D7 core alpha1 release...)
With so many installations, it would be great to have some sort of roadmap.
It also seems there is A LOT of work being done in many different directions. From what I could read here and in other (oh so many!) issues/forums/websites/etc. there is a lot of proposals of doing it and CCK3 sounds to be a way to get the efforts focused, but the question still is unanswered : what is the "best practice" ?
Finally, there is quite a bit of duplication between this thread and #494100: State of the multigroup module which are getting unreadable, I would suggest to close them both and start a new "clean" issue. I think that would need to be done by maintainers since there a link to 494100 in the release page of CCK3 and this new issue would benefit a lot from having a clear status update...
FWIW, we are now pretty confident that there can be an equivalent to the "multigroup" in D7, and that an upgrade path is possible (that is, when someone writes it...).
Not locking D6 users on a short-lived solution without any possibility to move to D7 was the main reason (at least the main I'm aware of) not to roll a CCK 3.0 release.
I'm not familiar with the current status of the multigroup functionnality and the CCK 3 branch, and markus_petrux will see how he prefers to deal with that, but as far as I'm concerned, rolling a 3.0 release (possibly even just an alpha) sounds fine.
I agree, a 3.0 release would be great.
If CCK3 is stable (as I have been lead to believe), then please publish an official 3.0 release, even if it is not the "recommended" release. This will be a big help in motivating other module maintainers to support it.
If CCK3 is not stable, then please let us know.
I'd like to updgrade to cck3 from cck2, but can't seem to figure out how to do it. Do I need to disable all of the cck dependent modules, then delete the old cck folder from the sites-->modules directory, then copy in the new folder, and run update.php?
Will I lose any content/data if I do this?
I just put the site in maintenance mode, replaced the CCK folder in the modules directory, and ran update.php. Worked fine. If you disable the modules first, there won't be anything for update.php to update.
I wasn't able to see the cck module in the update list, but I disabled all the cck modules, replaced the cck directory and now I have multigroups. Here is a post of my experience: http://drupal.org/node/982786
update.php is only going to update modules that are active. Here are instructions for updating contrib modules. They say explicitly that you should not disable the modules you are updating.
Subscribe. Waiting for the official 3.0 release, thanks!
I'm going to close this issue, I'm not sure of any benefit to keeping it open. It is kind of unusable at the moment because it covers so much territory.
I think the relevant questions are:
1) Why don't you create a release? I'm working on that now, trying to clean up all the multigroup issues like this one.
2) What is the upgrade path from CC2->CCK3? None, just swap the code, enable the multigroup module, and see if there are any updates to be run.
3) What happens in D7? Not sure yet, lots of projects still evolving but it looks like one or another will be able to pick this up.
4) How do you go backwards from CCK3->CCK2? You may be able to just swap the code if you have simple fields but there could be problems. Going backwards is never a supported path and no one has time to test and debug a 'downgrade' path.
Automatically closed -- issue fixed for 2 weeks with no activity.
...you've already asked this question in #991542: Port Nodereference explorer to Explorer module for Drupal 7 Jansel. Anybody that wants to leave a reply, please do so there. This issue here has been long fixed and thus closed.
This issue has no child issues.
Drupal is a registered trademark of Dries Buytaert.