Contrib.social

Nested field groups improperly display as "Disable" in the admin UI

Open on Drupal.org →
Created on 16 January 2023, almost 2 years ago
Updated 13 June 2024, 5 months ago

This is a great module but a bit buggy when trying to work with it on content type fields form-display admin ui.

There are workarounds but it gets extremely confusing when trying to layout a node/add form especially when there are lots of fields and needed field groups.

If you add a field group and it is top level (things seem ok) however when nesting especially with tabs "even when they are working" they end up in the "Disabled" section of the form display while in the admin interface. And it appears it doesn't matter what you do after rearranging them once you save they go right back to the disabled area! However they actually work if you go to node/add/content_type your working with.

Tabs and tab are even more frustrating and the only way to get them positioned properly (because they are always in the disabled area of the admin ui) you have to set everything by weights to get them to order properly or they just rearrange the fields under them alphabetically when viewing the layout from node/add "which took me a bit to figure out."

I looked through the issue queue but couldn't find another listed issue and patch referring to the same situation and why I've opened this as a bug report here. If there is an existing patch to get nested field groups to display (above the disabled area in the admin ui) in their proper order while designing the content type in form-display layout please direct me to it.

I'm currently working with latest Drupal 9 (9.5.1 to be specific) PHP version 8.1.13

To reproduce go to admin/structure/types/manage/some_content_type/form-display:
- then add a field group type "tabs" and in the fields manage form display drag it from disabled somewhere up in the form (as long as it's top level this one will stay where you put it.)
- then add several field group types "tab", now drag those from disabled to be nested under the "tabs" field group previously created and move some fields to be nested under each "tab"
- then save
- Now all the "tab" groups will be placed back in disabled (and if you didn't set weights on your fields and they weren't originally in alphabetical order - your fields will be reordered alphabetically under the "tabs" group without any "tab" groups, the "tab" groups will also be reordered based on the fields that "were" in them.

However if you then visit the node/add/some_content_type page to create said content the 'tab's will be where they should be - so they are working for the most part. If you then show weights on the fields form-display page you can get them ordered just right.

That's just tabs - I also found the same thing happening when nesting other field groups like HTML elements as div's (whatever group is nested always returns to the disabled section of the admin ui) even though they are displayed in the correct place on the node/add page.

I'm currently berried in trying to migrate a huge Drupal 7 site with an insane amount of customizations to Drupal 9 so I can't just stop and work through this module to try and create a patch (and probably won't be for the next 3 to 6 months for how much needs to be done on the site in question) if this is still a problem when I'm done I will be happy to contribute - in the meantime if anyone else has a solution for this please let me know.

This is such a great module I wish it was part of core so it would get more attention...

If anything else is needed, like screen shots let me know - I can provide those and other data if it would be useful!

🐛 Bug report
Status

Active

Version

3.4

Component

Miscellaneous

Created by

🇺🇸United States sidgrafix

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment almost 2 years ago →
    🇪🇸Spain sergioitdo

    +1 on these, we experience same problem twice. thank sidgrafix for share the details.

  • Comment over 1 year ago →
    🇪🇸Spain sergioitdo

    Any news on that?

  • Comment over 1 year ago →
    🇺🇸United States erutan

    I can reproduce this on Drupal 9.5.9 - using an accordion I have two accordion items that are in the disabled area at the bottom, but the edit page renders properly / as intended as of what it looked like before I saved the manage form display.

  • Comment over 1 year ago →
    🇺🇸United States sidgrafix

    @erutan thank you.. patch for 9.5.9 works! I didn't know there was a core issue regarding this, it didn't show up in my searches before initially opening this ticket.

    At first I didn't think it helped!

    Here are some things to note, after adding patch rebuild cache and when you first visit a content types form-display (it will still look like it is broken) and why I initially thought it didn't do anything.

    Click show row weights upper right corner of form-display, if they aren't already displayed (so you can verify the next steps by weight order, making sure they end up in the right place).

    Then in the disabled section for each tab, accordion item and/or nested group change each "Region" (dropdown-select)
    from 'Disabled' to 'Content'. If everything is working correctly as you change each from Disabled ajax will run and update the form putting that field_group/item where is belongs - to verify check the weights. When done make sure to hit "Save" and the form-display will reload and everything will be exactly as it should! Moving forward any changes made (moving or adding field groups, tabs or accordion items) should work as expected.

    @sergioitdo -> try the patch erutan suggested. Post back if it works, no point leaving this open if a core issue can resolve it! If it works for you, then this can probably be tagged with that core issue and closed as a duplicate.

  • Comment over 1 year ago →
    🇺🇸United States erutan

    Glad it worked for you too! I found the core patch in another related issue here https://www.drupal.org/project/field_group/issues/3085858 🐛 Drag and drop acts weird, sometimes not resetting the parent, or even clearing the region value Needs review and figured it might fix this. :)

    This probably falls under the general umbrella of "Drag and drop acts weird" especially since the same core patch fixes both.

    I cleared caches, then just moved accordion items to their correct location, saved, and then they stayed in place iirc.

  • Comment 5 months ago →
    🇵🇰Pakistan Ahmed.Raza

    I am facing the exact same error unfortunately links to patches in #4 didn't work for me. Drupal 10.2.6

  • Comment 5 months ago →
    🇺🇸United States sidgrafix

    @ahmed.raza try this patch https://www.drupal.org/files/issues/2023-12-26/3089151-51.patch (it's the one I've been using) it's a core patch and solves most if not all field group display issues especially when field groups are nested.

    - Here is the main issue thread for that patch:
    https://www.drupal.org/project/drupal/issues/3089151 🐛 TableDrag JS :first-of-type issues Needs work

    Hoping someday it gets merged into core as it not only affects field groups, but pretty much anything using table drag to adjust layout.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024