Drag and drop acts weird, sometimes not resetting the parent, or even clearing the region value

It works but randomly fails for me(

Looks related
- #3062742: Drag-and-drop reordering doesn't work if the region content is nested in other elements
- #819816: (Needs tests) Reordering multivalue file and image field uploads is broken

Also related changing JS-lib for sorting and looks #1491406: Improve the reordering and reparenting UI if any term has a multiple hierarchy affected by the same

Looks idd tabledrag related. If you make the js files of field_group and field_ui empty, the region is still lost when moving my tab. The region is always lost when you make a group a lvl 2 group. As long as the group stays in the root, the region is not lost.

The issue seems to be related with the options given to tabledrag. When you drag something to a parent, it receives .field-name as source element, while this is the source element for parent, not for region.

If I remove the source in EntityDisplayFormBase, or set the source to field-region, everything is working on the manage form for fieldgroup. But on the display management, it is still broken in combination with DS due to js errors.

Created #3087608: Tabledrag is resetting the region value if items are nested for core

Also created #3087612: DS resets all the rowHandlers to field for an issue with DS.

Hi, I noticed some issues with tabledrag selectors recently, and I think they may explain the problem here. The following code from tabledrag:1092 uses the selector tr.draggable:first-of-type to grab the first row of the table, but that fails if you have a non draggable first row (which on the node form display is the No field is displayed row).

        // Use the first row in the table as source, because it's guaranteed to
        // be at the root level. Find the first item, then compare this row
        // against it as a sibling.
        sourceRow = $(this.table)
          .find('tr.draggable:first-of-type')
          .get(0);

I think I've found a few similar errors in #3089151: TableDrag JS :first-of-type issues. From my manual testing the patch there fixes the problem here, but frustratingly I can't get the automated test to drag the second row up above the first (although I can move a row up in the weight test...).

I'm tentatively setting the status to needs review despite there not being a patch here, not 100% sure what the best approach is.

Thanks!

i saw this post #3064890: Notice: Undefined index: name in Drupal\field_ui\Element\FieldUiTable::reduceOrder() (line 228 of /var/www/html/docroot/core/modules/field_ui/src/Element/FieldUiTable.php) which is closed as a duplicate, possibly of this issue (but mentions another related to DS, which is not my issue).

It does seem as though Field Group latest (-rc2) is broken. I see on a node form display page that i do have FGs set up and working correctly; but trying to add a new one and i get the reduceOrder error reported in the original issue, plus i can not move it out of disabled.

I see that up until a couple weeks ago i was using -rc1; so perhaps that is why i have working FGs placed on my form. Although, i tried now going back to -rc1 and although the reduceOrder error does not show, i still cannot place the FG and i get a new error (guess due to db change required for -rc2 update).

Not sure if any point in going back to try 1.x version.

Glad to see this is marked as Major as Field Groups must be one of those "Drupal 8 release blocker" sort or modules, I would think.

Just a quick update: the patch in #3089151: TableDrag JS :first-of-type issues seems to fix the first issue described in the IS and shown in the gif, and since #2769825: Cannot swap tabledrag rows by dragging the lower over the upper row in tests the tests work as well. I'm not sure whether it addresses this from the IS:

• Tabs also sometimes act weird.
• I was able to get to a state as well where no region value was set for a field, becoming empty.

or this from #23:

Notice: Undefined index: name in Drupal\field_ui\Element\FieldUiTable::reduceOrder() (line 228 of /var/www/html/docroot/core/modules/field_ui/src/Element/FieldUiTable.php)

@AndyF, yes, the 2 core patches in #24, against 8.8.0, fix my issue. :)

For anyone facing a similar problem, here's a hint. I had field groups configured as "region: hidden" in my config yml files, despite they had "enabled" children. So that on the entity form display edit form, those groups appeared twice, in the content region and in the hidden ("Disabled") region. I changed their config to "region: content" and it fixed my ordering/weight/tabledrag problems. No other patch needed for me.

Hi

Same problem on a fresh D10 and dev version of the module... Can't save my groups with correct order or children, they save them random in template

Same problem too on a D10. I'm not abled to save the changes after order or children, they items stay on the same place.

@sergioitdo have you tried applying the following patch to core?

https://www.drupal.org/files/issues/2023-02-08/3089151-45.patch

"drupal/core": {
	"drag n drop": "https://www.drupal.org/files/issues/2023-01-10/3089151-45.patch"
},

#29

+1 fixed the drag and drop issue in D10 too

Once patched, on Drupal 10.1.5, the drag'n drop works.
BUT the created structure is unstable: i.e. tabs don't stay nested as designed when re-opening the form edit page.

Just in case anyone comes to this issue from google, here is a screenshot with some instructions on how to manually set the weights if drag and drop is not working for you.

https://www.drupal.org/files/issues/2025-04-28/2025-04-28-17.27.27-field...

Hey everyone, it feels like this issue got a bit off track. The issue summary including the video seem to be unrelated to the patch that is suggested as a potential fix here.
Since I wanted to preserve the conversation here, I created a separate issue, targeting the same issue. Feel free to test the patch from #3538795: Manage Display: Child fields moved from groups to "ground level" retain parent relationship in combination with the core patch from #3539083: Field UI: Parent-child relationships not properly updated when fields are moved via drag-and-drop (Field Group).

If the feedback is good, I'll close this issue as a duplicate of #3538795: Manage Display: Child fields moved from groups to "ground level" retain parent relationship, otherwise we can keep it open as a follow-up issue and adjust the issue summary. Until then, I'll set it postponed.

I agree this is probably fixed by the MR in #3538795: Manage Display: Child fields moved from groups to "ground level" retain parent relationship now, please try the patch over there and close this as duplicate, if it's fixed. The other fix is definitely the cleaner one, combined with the core fix from #3539083: Field UI: Parent-child relationships not properly updated when fields are moved via drag-and-drop (Field Group)

@swentel if you're able to give a bit of time over to a review of #3089151: TableDrag JS :first-of-type issues I could summon the courage to get back in on the dev side. I backed off a bit because it was getting at best cursory reviews, but it'd be neat to take it over the finish line... assuming tabledrag hasn't completely changed in the meantime at least (: Completely understand if you don't have time btw, jus thought I'd mention it.

First off, I am shocked, that field_ui doesn't have a direct dependency on tabledrag.js. I was already wondering how changing the behavior of tabledrag.js would affect field_ui.js, since there is no dependency between the two.

Second, I couldn't replicate #3087608: Tabledrag is resetting the region value if items are nested at all, which got me wondering why. Turns out, the gin admin theme (which we use on all projects) provides its own tabledrag.js override, see https://git.drupalcode.org/project/gin/-/blob/5.0.x/js/overrides/tabledr....

Since gin will replace claro in the future, see https://www.drupal.org/about/core/blog/drupal-core-will-adopt-gin-admin-... and claro is currently the only theme using drupal cores tabledrag.js I wouldn't waste time fixing a file which will probably get replaced by its gin counterpart anyway.

I would suggest fixing it in gin instead, but I am still unsure what's wrong with the approach in #3539083: Field UI: Parent-child relationships not properly updated when fields are moved via drag-and-drop (Field Group)? There is already similar logic in field_ui for changing regions, so why not simply do the same when changing parents?

@swentel thanks for your valuable feedback. Maybe you could then help with #3539083: Field UI: Parent-child relationships not properly updated when fields are moved via drag-and-drop (Field Group) and #3538795: Manage Display: Child fields moved from groups to "ground level" retain parent relationship so we can get this fixed asap?