The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
When a field group contains child fields, moving those child fields to the ground level (content region) does not properly update the parent-child relationship. The field appears visually on the "ground level", but programmatically still have the disabled group as its parent.
Proposed resolution
Update the drag and drop javascript.
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | 3538795-MR120-10.diff | 1.83 KB | anybody |
| #9 | 3538795-child-fields-moved-9.patch | 1.83 KB | grevil |
Issue fork field_group-3538795
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:
changes
Comments
Comment #2
grevil commentedComment #4
anybodyComment #5
grevil commentedComplete, utter bullshit, sry. I'll reset the MR immediately.
Comment #6
grevil commentedComment #7
grevil commented#3085858: Drag and drop acts weird, sometimes not resetting the parent, or even clearing the region value suggests using the patch in #3087608: Tabledrag is resetting the region value if items are nested, but this doesn't do the trick and here is why:
I think, the MAIN problem is, that Drupal core nor field_group have any logic, when the parent changes. Neither when manually setting the parent or drag and dropping. Inside "onChange, in drupal cores field_ui, "regionChange" is being called, when the region changes and the same happens inside "onDrop" (for the drag and drop behavior).
But there isn't any logic for when we manually (or via drag and drop) change the parent.
In Drupal core, this doesn't matter, changing the parent without field_group enabled and saving, simply resets the parent again and that is fine, since there is no "real" parent logic in Drupal core. Only regions. But field_group heavily relies on the parents.
This seems like a regression in core, but I couldn't find the proper issue yet. Basically, core should provide the same logic as with changeRegion, or we need to manually implement it in field_group.
Comment #8
grevil commentedOk, parts of this issue need to be addressed in core, see #3539083: Field UI: Parent-child relationships not properly updated when fields are moved via drag-and-drop (Field Group).
Comment #9
grevil commentedAlright, that's it! Unfortunately, this change won't do anything as long as #3539083: Field UI: Parent-child relationships not properly updated when fields are moved via drag-and-drop (Field Group) is not merged, so I'll postpone this issue. For now.
Feel free to use the attached patch in combination with the core patch from https://www.drupal.org/files/issues/2025-07-31/3539083-field-ui-parent-c..., to test the fixes!
Comment #10
anybodyStatic patch attached until this is merged. See the important notes in #9!
Comment #11
grevil commentedJust a quick note, "Gin" provides their own tabledrag.js, meaning instead of using the patch from #3539083: Field UI: Parent-child relationships not properly updated when fields are moved via drag-and-drop (Field Group), this one is required instead: https://git.drupalcode.org/project/gin/-/work_items/3542075
Though, it doesn't work perfectly yet, when moving a group as a subgroup in other groups, the subgroup that got moved in, is suddenly disabled.
Comment #12
grevil commentedNot necessary anymore! #3613588: Field UI Manage Display tabledrag copies parent field machine name into region when nesting (invalid region saved), seems to have fixed all our problems!