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

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-43.patch"
			},

#29

+1 fixed the drag and drop issue in D10 too

On Drupal 10.1.5, the drag'n drop works.
BUT the created structure is unstable.

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 🐛 Child fields moved from disabled groups retain parent relationship Active in combination with the core patch from 🐛 Field UI: Parent-child relationships not properly updated when fields are moved via drag-and-drop Active .

If the feedback is good, I'll close this issue as a duplicate of 🐛 Child fields moved from disabled groups retain parent relationship Active , 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 🐛 Child fields moved from disabled groups retain parent relationship Active 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 🐛 Field UI: Parent-child relationships not properly updated when fields are moved via drag-and-drop Active

I'm not sure if it was really off track, as far as I can see. It's been a while since I've found the energy to dive into this one as it's tricky :) There are basically two problems (in core) with tabledrag:

- not changing the parent, tracked in 🐛 TableDrag JS :first-of-type issues Needs work . Some people report that it fixes the issue.
- (re)setting the region value, tracked in 🐛 Tabledrag is resetting the region value if items are nested Needs work - but it might be obsolete by the previous one.

Again, it's been a while, so I feel like there's actually too many issues open now, which makes it even more off track :)
Ideally, we can fix this in core. But I would be ok if we are able to fix this in field group, without having to rely on a core patch.
(it would be even better if FG just goes into core of course haha)

Note: I'm less involved nowadays, but I know this issue is tracked in couple of other issue, so I'd rather leave this one open as the 'canonical', thoughts?

(There was also a conflict of DS which gets in the way in although that should have been fixed already by 🐛 DS resets all the rowHandlers to field Fixed though)

Rereading everything again, I'm still rather a fan of fixing this in tabledrag JS and see if we can get 🐛 TableDrag JS :first-of-type issues Needs work forward (if possible of course), where, afaics, the fundamental problem lies. Only fixing it in core for field ui, would still leave problems for other UI's (although I'm not sure how many other's have nesting and multiple regions, but oh well).

Also 🐛 Nested field groups improperly display as "Disable" in the admin UI Active is a duplicate - where someone also reports that 🐛 TableDrag JS :first-of-type issues Needs work might fix things.

Will debug some during the weekend to get a clearer view.

@swentel if you're able to give a bit of time over to a review of 🐛 TableDrag JS :first-of-type issues Needs work 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 🐛 Tabledrag is resetting the region value if items are nested Needs work 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 🐛 Field UI: Parent-child relationships not properly updated when fields are moved via drag-and-drop Active ? There is already similar logic in field_ui for changing regions, so why not simply do the same when changing parents?

Apparently this happened from #3204862: Backport tabledrag.js for Drupal 8.8+ → . This is annoying. Not everyone uses Gin, or will use Gin in the future if it's in core (we often don't for instance).

Darn, this is annoying. It's likely safer to go forward with 🐛 Child fields moved from disabled groups retain parent relationship Active then yes. We really don't want to add a dependency on an admin theme for this.

• Re: dependency: tabledrag library is added by drupal_attach_tabledrag() which is a helper function in core.
• Re: region value which are nested: this is probably (but I'll try to confirm over the weekend), in combination with Display Suite. It's been too long since I created this issue.