In previous versions of CCK, I've been able to create a like-named fieldset across multiple content types. A practical application of this is that I have a host of fields that represent denormalized data that I do not want to expose to the user. So, I throw them into a group called something like "Hide Me", and then have some code that hides the fieldset and child fields.

In RC10, an error is throw stating: "Add new group: The group name group_hide_me already exists." I've reviewed the data in content_group and content_group_fields and the content type I'm trying to add the group to does not have any groups associated with it.

Looking through the code, fieldgroup.module:374 loads all of the groups and then a foreach is done twice, forcing unique group names across all content types. Marked this as a bug since unique group names has not been enforced in previous releases. If this is intended, it would be helpful to update the documentation that comes with CCK to state that a group name must be unique.


KarenS’s picture

Yes, group names were only unique by content type in D5, so this is probably a bug, unless yched thinks this is something we should change and was coding it that way on purpose.

However, there may be easier ways to do what you want in D6. Update to the -dev version and you'll see there is now an checkbox option next to each field in the Manage fields screen to exclude it from the $content value that goes to the node template ( #300368: Easier node templating : Let fields be excluded from $content). Or use the Content Permission module to prevent elements from showing up in either the form or the view.

yched’s picture

Hm, right. I changed that in
I cannot remind for sure whether this was a conscious move :-(

OOH, I really don't like the difference with field names : a field name is a unique id, while the D5 behavior means the (group name, content type) pair is the unique id. Not consistent, confusing.
OTOH, simply changing the validation rule as I did leaves existing duplicates in place. This means we cannot rely on group name uniqueness unless we automatically de-dupe group names in an update function (probably by adding _0, _1, ... suffixes), which will possibly break users custom code or theming, and is not too user-friendly since group names cannot be changed.

Do 'multigroups' introduce new constraints regarding group names uniqueness across content types ? If not, we might be better off switching back to the previous behavior...

KarenS’s picture

I wish we had made them unique from the beginning, but we didn't, and it does seem pretty late in the game to change that and break all the things that it would break.

Multigroup won't care one way or the other at this point. But multigroup is more like a field, so uniqueness might become an issue. Multigroup could still have its own code to require multigroup names to be unique. There are no legacy problems there, so we could enforce that from the beginning.

I can think of all kinds of pros and cons for requiring groups to be unique, but I'm not sure any reasons for changing this are important enough to break current behavior.

yched’s picture

Status: Active » Fixed

I reverted to D5 behavior (group names unique inside content types).
This also affects multigroups for now. If we want to enforce cross-type unicity for multigroup names, we'll need to adapt fieldgroup_validate_name()

Anonymous’s picture

Status: Fixed » Closed (fixed)

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