Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Can anyone else reproduce this?
When managing form display, if you have several 'Tab' groups nested inside a "Tabs" widget (horizontal or vertical) - one tab is always stuck as the default, regardless of it's order among the other fields or if you've explicitly set it to "Closed" and another to "Open".
Then, if you remove that group, another unwanted tab becomes the default. The only workaround is to swap the fields between the tab you want and the tab you don't, and then rename both groups (so the descriptions no longer match the machine names).
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | wrong-default-tab-3066522-12.patch | 3.91 KB | nils.destoop |
| #7 | wrong-default-tab-3066522-7.patch | 2.15 KB | sleepingmonk |
Comments
Comment #2
weseze CreditAttribution: weseze as a volunteer commentedExperiencing the exact same issue...
I've tracked it down to: (HorizontalTabs.php)
which only seems to return 1 group, instead of all of them. So it always marks that group as default.
Comment #3
weseze CreditAttribution: weseze as a volunteer commentedUpping the prio because this is realy very annoying and there is no workaround.
Comment #4
jeroendegloire CreditAttribution: jeroendegloire at Calibrate commentedThis happens when I updated field group. I have deleted the group that this issue causes and created a new one. The new group hasn't this issuue
Comment #5
weseze CreditAttribution: weseze as a volunteer commented@jeroendegloire I tried recreating the group but the problem persists... I'm also running the latest version. The problem occurs both after updating an existing site or creating a new site from fresh up-to-date modules.
Comment #6
sleepingmonkWhen it loads `$groups` from `$form_state`, the data doesn’t have the values it’s looking for so default tab isn’t set correctly. I’m just ignoring $groups and pulling the data from somewhere it already exists in that function.
The proper way to handle it might be to go further back and see why the data isn't populated in $form_state.
This patch seems to solve our use case for Horizontal tabs. Vertical tabs doesn't seem to work the same way and working on Tabs.php didn't seem to have an effect.
This will take more work but here's a start for consideration.
Comment #7
sleepingmonkComment #8
weseze CreditAttribution: weseze as a volunteer commentedPatch is working fine for us
Comment #10
Kasey_MK CreditAttribution: Kasey_MK commentedPatch #7 works for us with a set of horizontal tabs nested within another set of horizontal tabs. Drupal 8.7.7, field_group 3.0.0-rc1. Thanks!
Comment #11
nils.destoop CreditAttribution: nils.destoop as a volunteer and commentedThe patch works for horizontal tabs on a normal node form. But it does not work:
- when the form is loaded as an inline entity form
- For vertical tabs
Comment #12
nils.destoop CreditAttribution: nils.destoop as a volunteer and commentedThis version works for me with:
- horizontal tabs
- vertical tabs
- horizontal tabs in inline entity form
- vertical tabs in inline entity form
Comment #13
trafo CreditAttribution: trafo commentedI'd say that you also need to sort element children:
Element::children($array, $sort = TRUE)That helped me at least in case of horizontal tabs (HorizontalTabs.php):
For some for me unknown reason tab groups in tabs group are in order that you added them and not the order in which you ordered them in Manage form display.
Comment #15
nils.destoop CreditAttribution: nils.destoop as a volunteer and commentedOk. I added the sort option + also removed the old code. This is committed to dev.