Field group functionality in core

[sirkitree]

Update 2023:

It has been decided that the field group module provides more options for field groups than we wish to include/support in core, so rather than move the entire module into core, we are planning to revamp the fieldgroup API and move certain types of field groups into core (groupings that already exist in core) and to leave others for the contrib module. The new fieldgroup API will become part of core's field + field_ui modules.

Group types planed for core:

• Fieldset
• Details
• Div
• Vertical Tabs

Group types that should remain in contrib:

• HTML element
• HTML5
• Horizontal tabs
• Multipage
• Accordion

The Field Group contrib module would simultaneously release a new minor version (that depends on this version of Backdrop core) where those group types are removed from the module, and all remaining types are updated to use the core field group API (which will be similar to what's there already). The current group API will also be removed from the contrib module.

Requirements for getting new fieldgroup contrib module in core:

• [ ] Integrate Fieldgroup API into field/field_ui modules
• [ ] Create group type for fieldset
• [ ] Create group type for details
• [ ] Create group type for div
• [ ] Create group type for vertical tabs

---

Original Issue: It would be pretty outstanding if we have field_group in core so that forms could be arranged a lot nicer with things like vertical tabs and such through the UI.

Requirements for getting fieldgroup contrib module in core:

• [x] Place the module into the core/modules directory
• [x] Move theme functions into field_group.theme.inc file
• [x] Remove all the field group help text and fieldset
• [x] Field Group Configure and Delete operations should use dropbutton
• [x] Field Group Configure form should use menu callback (move from an expanding section to a new page -- same as field settings).
• [x] Remove the t() function from all tests
• [x] Move display tests into field_group.display.test
• [x] Standardize on Field group for the UI and documentation (as opposed to Fieldgroup in some places).
• [x] Adjust very long lines to be under the 80 character limit for coding standards
• [x] Move display suite code to ds module: see https://github.com/backdrop-contrib/ds/issues/11
• [ ] Add description text for the div settings (what are "effect", and "speed"?)
• [ ] Combine the options for html_element and html5 and provide an upgrade path
• [ ] Replace the new stdClass(); in _field_group_get_html_classes().

User experience cleanup options:

• [x] N/A ~Remove the whole 'Fieldgroups' fieldset and help text~ (from previous iteration of module)
• [x] Remove the whole 'Fieldgroups' vertical tab (including the ability to clone from another display)

New features (options):

• Make field group containers collapsible
• Add a "clone" operation for a field group on the currently visible display
• Instead of having a separate 'Add new group' row below 'Add new field', just have 'Group' as an option under 'Select a field type', and the different group types (e.g. fieldset, vertical tab, etc.) as 'Widgets'.
• (is this a good idea?) remove the ability to change the group type from the overview page (why?)

---

Related issues:

• Switch to an "Add field" and "Add field group" action link (same as D8/D9):
• Separate "Manage fields" and "Manage form" (field group would not appear on "Manage Fields")

Issue advocate: @jenlampton

[quicksketch]

I agree, I think this would be a useful addition. I think putting it in core is about the only way to handle it cleanly. Considering the options available today (Field Group, Field Collection, Multifield, etc.) none of them work well because they have to make core work in ways it wasn't intended. Though if we change the way core works, then it may be possible to make this work more cleanly.

This may be a 2.x issue; I'm not sure how much API change would be required (if any) to implement this. Marking 1.x until we explore the options.

[klonos]

Yes please!!

[mikemccaffrey]

Wait, field groups have not been ported yet or merged into core? We should definitely get this done asap.

@klonos Can we keep this ticket limited to the functionality provided by Field Group, which just concentrates on organizing field, unlike Field Collection and Mulitfield, which are actually a type of field with their own data architecture?

[klonos]

@klonos

?? I think you probably meant to mention @quicksketch but yeah, I agree. ...unless Nate wants to tackle this in a single module in a "unified" way that binds all features together.

[mikemccaffrey]

@klonos I was just apologizing to you, since I was undoing the change that you made in adding Field Collection and Mulitfield to the issue title! But you are right, I should have added @quicksketch too since he was the first one to mention them all.

[MrHaroldA]

This is a real blocker for my Backdrop installs too. Not the field collection, or multi field modules, but the possibility to add vertical tabs, horizontal tabs, fieldsets, etc through the field ui.

The Field Group module is ridden with CTools and Features specific code though.

[biolithic]

@MrHaroldA would you prefer a new module reusing the ideas of Field Group or just a straight port replacing Ctools with our own functions?

[MrHaroldA]

Field group is big. Probably way too big. Also the UI is a bit weird when creating tabs; you have to create a tab container first.

Let's start small and slim, and gradually add features if there's a reasonable demand for it.

Adding fieldset support for example will give you a lot to work with; you could even theme them as horizontal or vertical tabs.

[serundeputy]

moving to 1.5 feel free to move back if someone wants to tackle it.

[vonnnew]

Hi All, I'm attempting my first Backdrop build now. I really need the Field Collection module. It doesn't appear to have been ported yet. Is this true? If not, I will attempt it but it will be my first attempt to port a module.

[herbdool]

Field collection hasn't been ported. At least I don't see it in the backdrop contrib list: https://github.com/backdrop-contrib/?utf8=%E2%9C%93&query=collection

Let's keep this issue focused on field group, however, which is for different purposes. I agree with @MrHaroldA about paring down field_group but it's also useful to keep it as close as possible with the Drupal 7 version for now. As far as I can tell, ctools is only being used to provide the CRUD functionality in the UI, which presumably could be replaced with Backdrop's CMI.

[jenlampton]

@vonnnew Field collection is going to be a doozy for your first port. I'd personally been checking out multifield instead since Field collection has some serious performance implications. Good luck!

also, since there is no PR for this yet, and this issue was bumped from the last release, I'm pushing this to 1.x-future

[laryn]

Found my way here on a search. To update RE the mentioned contrib modules:

• Field Collection: Not ported to my knowledge
• Multifield: Ported
• Field Group: Ported
• Paragraphs: Ported

[klonos]

Since 2015 (when this issue was first filed), there's a new player that's been gaining momentum: https://www.drupal.org/project/paragraphs

Paragraphs is the new way of content creation! It allows you — Site Builders — to make things cleaner so that you can give more editing power to your end-users.

Instead of putting all their content in one WYSIWYG body field including images and videos, end-users can now choose on-the-fly between pre-defined Paragraph Types independent from one another. Paragraph Types can be anything you want from a simple text block or image to a complex and configurable slideshow. ...

In fact, there's a note in the https://www.drupal.org/project/field_collection project page that says:

Paragraphs is likely to replace field collection for Drupal 8. Field collection is on its way to being deprecated. It is recommended to use paragraphs instead of field collection for Drupal 8 projects.

I agree with @mikemccaffrey that we should keep this issue focused in getting the field group functionality in core (a good candidate for 1.9 perhaps?), but I think that we should seriously discuss about the concept of paragraphs and getting that into core too. It would be a killer-feature to have for 2.0 I think.

[klonos]

I have recently created #3766 to track progress on what's cookin' for D9 ...it seems that https://www.drupal.org/project/field_union is where things will happen.

[quinnanya]

Would definitely support having at least field group, and ideally something more repeatable, in core. The need for that functionality has been haunting me since Drupal 5.

[ghost]

I just installed the Field Group module on my dev site to see how it works and get an idea of how it'd ideally work in core. Here's how it currently looks:

My thoughts:

• Instead of having a seperate 'Add new group' row below 'Add new field', just have 'Group' as an option under 'Select a field type', and the different group types (e.g. fieldset, vertical tab, etc.) as 'Widgets'.

• Remove the whole 'Fieldgroups' fieldset (I don't see the need for that much help text, and I've personally never used the Clone feature).

• Make a field group look and act more like the other fields by moving all configuration to a seperate page (i.e. remove the ability to change the group type from this overview page, and move Configuration from an expanding section to a new page (same as field settings)).

Based on my suggestions, here's how it could look:

[herbdool]

I've usually used the clone feature. If there's a way to preserve would be good.

[jenlampton]

This looks great. Can we add a clone link into operations for the field groups?

[klonos]

Can we add a clone link into operations for the field grpups?

Yes please! Would love that ❤️ ...although it may need to be a "clone from" and a "clone to" functionality. Could be a follow-up issue.

• Instead of having a seperate 'Add new group' row below 'Add new field', just have 'Group' as an option under 'Select a field type', and the different group types (e.g. fieldset, vertical tab, etc.) as 'Widgets'.

I'm not opposed to this, but wanted to mention that back in 2015 @wesruv has provided some mockups in https://github.com/backdrop/backdrop-issues/issues/779#issuecomment-141707916 and https://github.com/backdrop/backdrop-issues/issues/779#issuecomment-163844301 of how things could work if we switched to an "Add field" button, same as D8/D9:

UX studies by our Drupal brethren have shown that it is a much better workflow, and confuses people less than the current UI (and I prefer it too TBH, because it brings consistency in our UI patterns). In D8/9 they've separated the UI that allows adding and reordering fields into a dedicated "Manage fields" and a dedicated "Manage form display" form. So the "+ Add field" and a "+ Add field group" buttons there are in separate places. We might need to move to a UI that has the 2 "+ Add field" and a "+ Add field group" buttons side-by-side at the top-left. If you put it all together, and include @jenlampton's suggestion in @BWPanda's mockups, it would like this:

Remove the whole 'Fieldgroups' fieldset ...

👍

Make a field group look and act more like the other fields by moving all configuration to a seperate page...

Also 👍 ...UI consistency please. I would suggest that we eventually switch to using dialogs at some point, same as we've done in text formats UI in #1032, which I find to be a big UX++, as the user remains within context of the task they set off to do.

[jenlampton]

I don't know about this.. I find a LOT Of value in being able to see the fields that have already been added while adding a new one. I would hate to loose that behind a modal, or on a previous page. (This is particularly important on content types with lots of similar fields).

I also really like the ability to put the new field right where you want it (between other fields) when it is added, rather than needing to return at the end to order them.

I like consistency where it makes sense, but when you have different needs on different pages, the UIs should be different.

[klonos]

I find a LOT Of value in being able to see the fields that have already been added while adding a new one. I would hate to loose that behind a modal, or on a previous page.

Dialogs work fine that way when adding blocks to a layout. Just saying.

I also really like the ability to put the new field right where you want it (between other fields) when it is added, rather than needing to return at the end to order them.

Again, block placement works that way: new blocks are added to the bottom of any existing blocks in the same region; then the user needs to drag them to the desired place. But perhaps we could find a way that this works the same as the +/- buttons in option elements:

[jenlampton]

Dialogs work fine that way when adding blocks to a layout.

Sure, it's "fine". But I don't think it's as good as what we have today.

Again, block placement works that way: new blocks are added to the bottom of any existing blocks in the same region;

Yes, and this is also a pain point that we have learned to deal with. It's all "fine", but I prefer the better UI we have now and would hate to move backwards for the sake of consistency.

Can we move these thoughts to another issue? I don't want a UI rewrite to block getting Field groups in core!

[klonos]

Can we move these thoughts to another issue? I don't want a UI rewrite to block getting Field groups in core!

Sure can 👍

[olafgrabienski]

I don't want a UI rewrite to block getting Field groups in core

Agreed! So, back to @BWPanda's suggestion? Don't see it as UI rewrite but contrib integration:

Instead of having a seperate 'Add new group' row below 'Add new field', just have 'Group' as an option under 'Select a field type', and the different group types (e.g. fieldset, vertical tab, etc.) as 'Widgets'.

I like the idea to treat fields and groups in the same Ui. Unfortunately, some labels and descriptions don't cover the group use case, e.g. the following bold words:

• Add new field (Could be "Add new field or group". Or "Add new element"?)
• Type of data to store
• Form element to edit the data

[laryn]

Definitely in favor of adding this functionality in a more streamlined way. (I like "Add new element")

I will note that the Clone functionality at the bottom seems different than simply adding a clone option in the operations dropdown -- I've never used it, but it looks like it clones field groups from a different view mode into the one that you're looking at, not simply cloning a group from the current form to the current form.

[philsward]

FG works fine for minimal stuff. Not so great for more complex stuff. Wish FG was easier to deal with on bigger entities.

I think it might be easier if the FG containers were collapsible and you could drag one collapsed container into another collapsed container. Spit ballin.

[klonos]

Oh wow! 😅

[stpaultim]

We are approaching that final month before code freeze for version 1.21 and this is the issue that got the most votes in our priority survey last March that has not yet gotten into core (in fact, it was highest on the list at the time of the survey).

In our recent prioritization discussions, this issue was rated "Medium" difficulty and "Medium" impact. This could be the flagship new feature of 1.21. Maybe??

My understanding from reviewing this discussion is the following (this is my attempt to summarize the discussion so far):

1. This issue is NOT about multi-field or field collections. It IS about the ability to organize fields into groups "so that forms could be arranged a lot nicer with things like vertical tabs and such through the UI" or " possibility to add vertical tabs, horizontal tabs, fieldsets, etc through the field ui."
2. There seems to be a consensus (so far) that the goal would be a paired down (simplified) version of the Field Group module. It is my understanding, that we're looking to add this functionality, but do not plan to move the existing Field Group module directly into core. However, I think the goal is to try to reproduce the functionality as much as possible.
3. @BWPanda puts forward this specific suggestion for UI in this comment: https://github.com/backdrop/backdrop-issues/issues/647#issuecomment-674474016.

4. I'm reading interest in a "clone" function - possibly in the operations button.
5. @klonos made some suggestions that might be best treated as follow-up issues.
6. @philsward pointed out limitations of basic field group functionality when there are LOTS of fields involved. But, it's not clear to me that this was intended nor needs to slow this issue down?

NEXT STEPS:

In my opinion, this issue needs two things:

1. An advocate

AND/OR

2. Someone with the technical skills to create a first draft PR (to generate momentum).

QUESTIONS FOR DISCUSSION:

Would it be realistic to get this committed before feature freeze? Is anyone interested in taking some leadership on this issue?

[philsward]

To clarify my position re: @stpaultim

I don't think my concerns need to hinder any core inclusion.

Most use cases won't ever run into the bad UX of 30+ fields on an entity. Having a way to group is the first step to a better overall UX and eventually a better UI.