Fix upgrade path to account for DS regions

Can confirm we have a similar problem, but with any fields, not just references. Even two text fields won't stay inside their field group.

We're also experiencing this issue on one of our clients' sites. We are on the latest rc1 version.
Attached is a screenshot. All fields are supposed to be in the details element at top of page but it just hangs open and the fields render below. No errors or whatnot.

Nevermind, this fixes my issue. Update to latest paragraphs and should work!
https://www.drupal.org/project/field_group/issues/3056860

I have the same problem when updated field group to 3.0-rc1 from 1.0 but for any field. When I retrieve back to 1.0 everything work as expeceted.

I have the same issue. Updated paragraphs and nothing happened.

The form didn't break for me, but the content type's form display did. I can't rearrange anything anymore.

Reverting to 1.0 fixes this for now.

I had the same problem that affected sub-groups (e.g.: tabs that are supposed to be grouped into a tab group). It turns out in my case that under Field Group 1.x, the sub-groups had not previously defined the DS region they belonged it (getting that from the parent group). Evidently, 3.x now requires that all groups define the region (?), so the update tried to guess which region to put the sub-groups in (field_group_update_8301) and got it wrong. It put them all in the content region. I have a few content types that use very custom Display Suite layouts that have custom regions they belong in.

In order to fix this, I had to export config, go through my yml files and find every sub-group that got the new region definition and change it to the region I want it to end up in (the parent group's region), then re-import config. It was a bit of a pain, but it worked.

And now when I made a change to the view mode, it looked fine until I saved and exported config. It moved all my field groups to the "hidden" region. I had to go in and discard a bunch of changes to my commit and re-import to get everything looking right. Very strange. Could this be a bug in DS similar to the one in paragraphs?

So I opened this last night: https://www.drupal.org/project/ds/issues/3082200. My gut still says this is a Field Group problem, but I'm wondering if Display Suite might be throwing a curveball that Field Group isn't expecting.

Moving to critical - there are a bunch of issues related with drag and drop, assigning, PHP notices (the famous 'undefined index "name") etc. Going to try and fix them all at once here.

So one problem with drag and drop is that if you move a field or a field group outside a group above the group, the parent is not reset.

So this seems more like a core problem. Going to try and figure out whether I can reproduce this with core it self.

Display Suite might be throwing a curveball that Field Group isn't expecting.

So the problem is that the upgrade path should probably take DS into account. In case DS is enabled for a display, the DS third party settings contain the regions where the fields belong in, including the existing field groups. So that would be one way to fix that.

I've changed the title to fix the upgrade path in this issue and opened #3085858: Drag and drop acts weird, sometimes not resetting the parent, or even clearing the region value for the drag and drop problem.

Adding related issues.

This should fix the update to account for DS regions.
It also moves the update to an update post hook as that's safer to use the API there.

Fixes a tiny little bug in assigning regions on field ui submit and with DS enabled, and the logic in the post update hook is better too now.

Re-categorising as Task. still critical though got get this as right as possible :)

Assigning to zuuperman as well to get a last look at this. I think it's fine. If this on is in we can tag rc2 imo, maybe even 1.0?

I'm having the same issue as #8 running:

- Drupal 8.7.6
- field_group 3.0.0-rc1 (with Paragraphs 1.9.0)

The patch in #18 worked for me: it added a `content: region` to every field_group group in every entity_form_display config after running update.php (as expected).

After applying the patch and running update.php, the manage form display screen looks as it did before the update to 3.0.0-rc1 (with fields in their correct groups), and I can save/change the order of fields on the manage form display screen again.

Reviewed and committed the fix to dev. Important, make sure you export config after performing the update. Otherwise importing config will just reset it back to the wrong version.