Add field grouping to Drupal core

any [contrib] module wanting to group fields programmatically will have to depend on CCK contrib.

I don't care. The "move X into core" train has to stop. I do not see why fieldgroup.module must be in core. Contrib will continue to exist!

I tend to agree. If it turns out fieldgroup.module is the only thing left in CCK, it can always become its own project again.

Doesn't that make this a Wont fixer?

I agree that fieldgroup is not a primary need for core. Given the time constraints, this indeed translates to 'won't fix'

One remark, though: the need to support fieldgroup, even in contrib, has some structural impacts on a Field UI.
In D6, we tried and soon abandoned the idea of making content.module artificially unaware of fieldgroup.module.
If Field UI goes in core and Fieldgroup stays in contrib (both of which I +1), this means additional thinking and coding to allow the Field UI to be extensible.

Just saying before someone else raises the point: form_builder will *not* answer that, because fieldgroups also affect 'node' (object) display - even "worse": ideally, grouping should be per build-mode.

Again, crossposting to http://groups.drupal.org/node/23545 for Field UI challenges.

Ok, given this has agreement from both of the major Field API maintainers, I'm going to go ahead and mark "won't fix." This may be something we look at in a later Drupal version, but not for Drupal 7.

Just to note: Won't fixing this issue means won't fixing replacing profile module completely with the Field system.

"Won't fixing this issue means won't fixing replacing profile module completely with the Field system"

Not necessarily. It would just mean that some of the current D6 profile.module features would be provided by a contrib module.
It's very possible that "D6 profile -> D7 Fields" upgrade live in contrib too, for that matter.

I think it should be. It is too unconvenient without this module only.

@ayang23 : this decision won't change. Much too late now for D7. I also don't there's any good reason to ship it in core D8. Core just cannot include all the modules that are good to have. This one lives perfectly well in contrib.
Meanwhile : http://drupal.org/project/field_group

...as per Angie's comment back in #5. Re-opening so we can reconsider for D8.

I find myself repeatingly installing Field group in my D7 setups. It seems from the project's stats that one out of ten D7 installations use it.

"Core just cannot include all the modules that are good to have"
Still true. My .2 cents.

Hi,

grouping fields is very important to have in core.
Im not for integrating this module into core, but integrating the grouping functionality into the core field system!
The fieldgroup module works, but the user experience is not nice.

I created an Illustration how it could look like, at content types > manage fields tab:

Users can add/edit field groups. Fields could be attached to a group.

Groups should have the following properties:
Checkbox: "Required group"
Dropdown: "Number of values" (Maximum number of values users can add)

When creating a node (node/add/) users can add this group of fields as often as set in the group properties "number of values".

Illustration:

There is also another module (field collection) that can group fields but it is circular and the user loses the clarity.

We definitily need this in core! :)

Re #13: What you are describing is exactly the field_collection.module. I don't know what you mean by "circular", but if you think such functionality belongs in core please open a new issue for that. This one is about fieldgroup.module. The two are definitely related, but each one serves a distinct purpose, so let's not meddle the two together. :-) Thanks!

i already opened an issue. it was closed because of duplicate of this one. The problem with field collection is that it is not in the manage fields tab.

the two are very very different in concept.

field collection creates an entity with fields, and couples it another entity (like node, user, taxonomy, etc)

it does not add the functionality of creating a group, with a fieldset, accordion, tabs or multipage, where fields can be moved into, which is what field group does.

perhaps both could be added yes. i thought on merging both, but then i remembered, sometimes you want a clear separation of the two functionalities, to get more flexibility, and in some cases, field collection is simply not possible to use (core node/user/taxonomy fields for example).

didn't found the issue, please reference it

Re #15: sorry that that happened, but the person who marked that issue duplicate was clearly wrong. Please re-open that issue and link it from here. Thanks!

i reopened it:
#1337130: Group fields

Status update?

Ain't going to happen in D8

Might warrant looking if we should investigate if Multifield module is a good fit for D9 core.

Could theoretically be done in a minor release.

Is fieldgroup stable enough to go in core?

Let's update the issue summary and then we can ask product managers for the approval.

@andypost
I think it would be better to provide a proper issue summary before we get the product manager involved. IMHO we could also first talk with the field and field_ui system maintainer ...

There's no issue summary update on the proposed direction (there are at least 3 directions proposed in the comments), so nothing to review atm. Feel free to re-add the tag at that time, however.

Moving this to ideas issue queue.

Adding the "idea template" to the issue summary, it provides a simple format to outline what the actual idea is why it would be a good idea. Short answers to the 4 questions will help us compare and weigh ideas for their relative impact. Thanks!

The Field Group module has come a long way since this idea issue was opened 12 years ago. Time to reconsider adding to core ?

+1 for adding Field Group to core. It's such a basic site builder tool, which the position as #10 most installed module. It is enabled on ~44% of Drupal 8/9/10/11 sites (182,000/412,000).

Alternatively, #2844302: Move Field Layout data model and API directly into \Drupal\Core\Entity\EntityDisplayBase could also solve this?

@ressa Field layout solves a different problem.
I agree field group should be in core, where it can be done much cleaner than in contrib.

The Ideas project is being deprecated. As discussed in a core committer meeting issues that are adding modules are being moved to the Drupal CMS project for discussion.

Field group is already included in Drupal CMS.

From a functional perspective, it is fine to have field group as part of Drupal CMS.

From an architectural perspective, the structure of entity form and view display should support grouping out of the box, so that field_group does not need the acrobatics that it currently does.

We should either reopen this and move to core queue, or create a follow-up issue.

@donquixote fair enough!

Totally agree with #44 still 16 years later :D Would simplify many things, not only frontend-wise, but especially in (entity) forms.

Probably to make it true it needs to resolve #1875974: Abstract 'component type' specific code out of EntityDisplay and then even SDC elements can be used as wrappers

@andypost: That would be fabulous!

We just ran into an issue which is tightly coupled to the "parent" integration in core for fieldgroup, that needs to be partly solved in core for that reason to fix the major bug in field_group: #3539083: Field UI: Parent-child relationships not properly updated when fields are moved via drag-and-drop (Field Group)

With field_group in core we wouldn't have such logical problems. (Maybe you could have a look at the blocking core part @andypost?)

Thank you!