Problem/Motivation

Using "field_group" to sort the fields into tabs leads to inaccessible options in the sidebar when creating/updating a node.

See attached screenshot.

Steps to reproduce

  1. Install Drupal 8.8.0-rc1
  2. Install Claro, set as admin theme
  3. Add, enable "field_group" module 8.x-3.0-* (or 8.x-3.x)
  4. Go to "manage form display" of basic page bundle
  5. Add a "Tabs" field group, add one Tab and place the body field in it
  6. When creating a basic page, most options in the sidebar are not accessible any more, when the screensize is bigger 85em (drupal/core/themes/claro/css/components/vertical-tabs.pcss.css:345)

The crucial part here is that you should have a VerticalTabs element on the node edit form (the core/drupal.vertical-tabs library should be attached).

Why is this happening?

Claro (similar to the Seven theme) changes the $form['advanced'] element's type from vertical_tabs to container. This isn't a problem for Seven theme, since it uses the same details template in every case, even for rendering the VerticalTabs items.

But Claro distinguishes Details elements based on their context, it uses different CSS classes for "accordion" items for instance, and for VerticalTabs items, it also uses an another, specific template: details--vertical-tabs.html.twig.

The problem is that at the moment the node form is altered in claro.theme, the VerticalTabs element is already processed by ClaroPreRender::verticalTabs(), so the details elements rendered inside the node edit form's sidebar will use the details--vertical-tabs.html.twig template.

So when a(n another) VerticalTabs elementis added to the node edit form, Drupal will add the claro/vertical-tabs library as well (with core/drupal.vertical-tabs). And Claro's vertical-tabs.css hides the vertical tab item's details summary for viewports that are wider than 85em. This is why and how this bug happens.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Comments

maacl created an issue. See original summary.

sd9121’s picture

Assigned: Unassigned » sd9121
maacl’s picture

Found a related issue. This shows what happens when the "display: block" property is removed.

huzooka’s picture

Re #3:

#3093189: Fieldgroup vertical tabs is only partially related to this: it happens with field_group 8.x-1.x.

This bug happens with field_group 8.x-3.x, but it can be reproduced even without Field Group.
You only have to add an another vertical tabs to the node edit form.

@sd9121,
Right after that this issue was reported, I tried to debug what's happening, and it ended in a patch that worked for me.
I guess you already spend some time working on this, but I don't want NOT to add this patch.

Could you please check that it fixes the bug? (You can use it even as a starting point of your patch.)

maacl’s picture

@huzooka I can confirm the patch fixes the bug I described in the issue summary.

lauriii’s picture

Status: Active » Needs review

It seems like #4 could use a review

bnjmnm’s picture

Status: Needs review » Needs work
Issue tags: +Needs issue summary update

Doesn't look like the patch actually needs work, but changing status for visibility.

This all looks good but could use an issue summary update - it took a bit to figure out why the problem was happening so the eventual committer would probably benefit from the same info. It would also be nice to include steps to reproduce that don't require field_group.

huzooka’s picture

Issue summary: View changes

Re #7:

IS updated.

lauriii’s picture

Status: Needs work » Needs review
Issue tags: -Needs issue summary update
bnjmnm’s picture

Assigned: sd9121 » Unassigned
Status: Needs review » Reviewed & tested by the community

The updated issue summary does a great job explaining the conditions causing the bug. This still looks like good solution.

lauriii’s picture

lauriii’s picture

Status: Reviewed & tested by the community » Needs review

It seems like the root cause of the problem is that we are using #group for organizing the accordion items, which is later used for determining whether the element should be in the vertical tabs or not. I'm wondering if we could use something else for grouping the accordion items so that we wouldn't have to process these elements in the vertical tabs pre-render?

pasqualle’s picture

I confirm, the patch solves the problem with missing elements in the sidebar.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

sj.suraj’s picture

Status: Needs review » Reviewed & tested by the community

The patch solves the issue here. Worked nicely. Thanks.

bnjmnm’s picture

Status: Reviewed & tested by the community » Needs work

Switching back to Needs Work. Comment #12 brought up a concern that switched this to Needs Work, and that should be addressed before making this RTBC again. This can be addressed with a new patch or possibly just a discussion as to why the current patch is sufficient.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

joelpittet’s picture

This seems to be related to this fix for hidden menu items with a simple fix on what groups get classes.
#3177415: Vertical Tabs CSS classes applying to non-vertical tab detail element groups

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

danflanagan8’s picture

Status: Needs work » Closed (outdated)

I can no longer reproduce this issue on 9.2.x and I'm going to close it as outdated.

This issue appears to have been fixed by #3177415: Vertical Tabs CSS classes applying to non-vertical tab detail element groups and #3219340: Vertical tabs with #parents are broken in Claro. If I revert those changes, I can reproduce the bug. But it looks like nothing more needs to be done here.

Thanks all!

danflanagan8’s picture

Issue tags: +Bug Smash Initiative