Problem/Motivation
We use custom_field to create multivalue fields, containing a bunch of properties / subfields.
While this allows site editors to add rather complex multivalue data, it is a challenge for them to reorder the items, once created.
In some cases we are using modals for content editing, which makes it even more challenging.
Example:

A video of me trying to reorder the items for a custom_field field with a bunch of subfields, is available here:
https://www.drupal.org/files/issues/2025-08-18/custom_field_reorder_issu...
For example the Paragraphs module seems to provide a better UX for this, with Collapse (all) / Edit (all) buttons:
By default the editing experience would be similar, with all fields exposed:

Clicking "Collapse all" gives us the following:

This allows for easy reordering, and subsequently editing a specific item.
| Comment | File | Size | Author |
|---|---|---|---|
| closed.png | 141.08 KB | svendecabooter | |
| open.png | 173.47 KB | svendecabooter | |
| custom_field_reorder_issue.mp4 | 1.81 MB | svendecabooter | |
| Screenshot from 2025-08-18 16-19-17.png | 175.76 KB | svendecabooter |
Issue fork custom_field-3541876
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
apmsooner commentedThis is already supported. Just go to the form display settings and change the wrapper to details and uncheck the box "Show open by default?"
Comment #3
svendecabooterYeah I have set it up with "Details" wrapper currently.
Would be good to allow for 1-click collapsing / expanding though, to easily switch between "editing" mode and "reordering" mode.
Comment #4
apmsooner commentedOkay, that makes sense. We can perhaps add setting to handle this and maybe its possible with #states or custom js.
Comment #5
apmsooner commentedComment #7
apmsooner commentedComment #8
svendecabooterI have tested this MR.
One issue I noticed:
The "Collapse all" button is shown for all variations of the "Wrapper" setting, where it only actually does something when the "Wrapper" setting has been set to "Details". Probably the button needs to be hidden in the other scenario's, unless collapsing those is also possible?
Furthermore it would be nice if we could optionally select a (text) property of the custom_field field that functions as the details label, instead of
Item (1), Item (2), etc...
But I guess that should be a followup issue?
Comment #9
svendecabooterComment #10
apmsooner commented@svendecabooter,
I've fixed the issue you noted and also styling for the button where text was wrapping. Please retest and also if you don't mind testing the "autocollapse" setting as well. Just uncheck the "Show open by default?" setting to see that.
Thanks
Comment #11
apmsooner commentedAnd... yes this would need to be a followup feature. I'm for the idea also but I think it could be a little complicated as we would need to narrow the allowed types and how they are output as well as figure how to account for unsaved items as we're not dealing with entities as in the case of paragraphs.
Comment #12
svendecabooterCreated a follow up issue for the last comment: https://www.drupal.org/project/custom_field/issues/3556431
Comment #13
svendecabooterI have also tested the "Show open by default" and "Auto-collapse" functionality.
This seems to work as designed.
However, it seems the auto-collapse setting can still be manipulated, even if "Show open by default" is checked.
In the form display settings, if "Show open by default" is checked, then the "Auto-collapse" setting disappears.
However, you can uncheck "Show open by default", then set "Auto-collapse" to on or off, and check "Show open by default" again.
The settings checkbox disappears, but the setting remains saved and does seem to impact the form, depending on if it was last set to on or off.
So either both checkboxes should remain visible and work independently of each other, or the "Auto-collapse" should be automatically set to "Off" if "Show open by default?" is checked...
Now the behaviour is a bit confusing.
Comment #14
svendecabooterComment #15
apmsooner commentedThank you for catching that! I've updated to account for the auto collapse logic only being applied when default wrapper setting is closed.
Comment #16
svendecabooterTested again, and works as expected.
I just added an extra logical check to the "Auto-collapse" field widget summary, to only show it when it's relevant.
Looks ready to me!
Comment #17
apmsooner commentedComment #19
apmsooner commented