When form contains #vertical_tabs and the tabs are located within the parent without the usage of #group they will not show up. In order for tabs to be displayed at least one tab has to have #group specified. I think this can be related to #601644: Vertical Tabs requires group to be specified before tabs.
Comments
Comment #1
Anonymous (not verified) commentedComment #2
Anonymous (not verified) commentedstill present in d8a8
Comment #3
Anonymous (not verified) commentedIf the details/vertical tab children are placed within the vertical_tabs element and they have #group set it still does not work. There has to be a child/vertical tab/details outside of the vertical_tabs element with #group set, then it works.
Comment #4
Anonymous (not verified) commentedDrupal 8 Beta 11 still has this issue. If the helper elemen mentioned in #3 is not used NOTHING is displayed.
Comment #5
Anonymous (not verified) commentedStill issue in head.
Comment #6
Anonymous (not verified) commentedComment #7
Anonymous (not verified) commentedbump
Comment #8
Anonymous (not verified) commentedThe issue comes from the
\Drupal\Core\Render\Element\RenderElement::processGroupmethod and the tabs are being hidden in\Drupal\Core\Render\Element\VerticalTabs::preRenderVerticalTabs.I think in the processGroup the issue is that there are entries like:
which are childless entries and therefore the preRenderVerticalTabs() will not show anything.
Adding the "nothing" from my example above will result in something like:
which will tell the preRenderVerticalTabs() that there are children and they are visible so display the tabs properly.
The preRenderVerticalTabs() fires first so there is no time to set the #group for each child details automatically and I think that is the flaw in the workflow.
Comment #9
Anonymous (not verified) commentedComment #10
joelpittetDoing a bit of triage, is this still a problem in the latest release?
Comment #11
Anonymous (not verified) commentedStill present in rc1.
Comment #12
joelpittet@ivanjaros this really needs a better description of the problem. The issue summary is unclear to what the problem is. Can you describe steps to reproduce this problem and maybe a test to prove it's not working as expected?
Until otherwise this issue is normal and not major.
Providing a patch to resolve this issue would be great too but a better summary of the problem would really help resolve this. Also the title could be more clear too. eg "is not specified outisde", outside of what?
Comment #13
Anonymous (not verified) commentedOK, try this:
result: nothing is being displayed.
result: group 2 and 3 are displayed
result: group 3 is is displayed
result: nothing is displayed
result: all groups are properly displayed
result: group 2 and 3 are displayed
result: all groups are displayed
result: dummy group is displayed
result: group1 and dummy group are displayed
and so on...
Comment #17
marcvangendI'm seeing some weird behavior regarding the #group property. It seems similar/related to what Ivanjaros has found, so I'm setting this back to active. Hopefully we can get this issue going again.
My situation:
I needed to add two form elements to the 'author' group on a node: one 'checkbox' and one 'email'. I assumed this would work:
This did indeed work for the checkbox, but not for the email field. The email field was rendered on the left side of the form, outside the vertical tabs. When I changed
'#type' => 'email',to'#type' => 'textfield',, it worked as expected.I suspected that the
processGroup()method had something to do with this, so I tried:This caused the email field to be rendered twice; on the left side and in the vertical tab. I don't know why. I also tried messing with the #parents property, but that didn't help.
Eventually, this did the trick (nesting the email form element inside
$form['author']):This shouldn't be necessary (other elements inside the author vertical tab are not nested in
$form['author']either) but at least I found a workaround.I think it's clear that something is pretty broken here, but I'm not sure where to start fixing it.
Comment #30
luke.stewart commentedCan confirm the behaviour in 13 still present in Drupal 10.
Found #1856178: '#group' Form API property only works with <details> elements which appears to relate and down the rabbit hole further we have #1168246: Freedom For Fieldsets! Long Live The DETAILS..
This details a solution that includes 'Use details everywhere we're (ab)using fieldsets currently. (including vertical tabs)'
Suggesting that perhaps vertical tabs shouldn't be used for this behaviour.
If we look at the author example in #17 we see that the side bar where the author lives no longer uses vertical tabs.
Grepping the core code base for 'vertical_tabs' we still see reference to vertical tabs in various places. And if we check the documentation in the comments for
web/core/lib/Drupal/Core/Render/Element/VerticalTabs.php
we get usage which suggests that having to specify the group and not use a child element is how these elements are suppose to work.
Given this I think this is closed works as designed. Apologies if I have misunderstood.