Problem/Motivation
After updating to v4.0, one of the nested field groups on a node does not display even though it is not empty.
After reviewing the differences between v4.0.0 and v8.x-3.6, I found that the changes in Nested groups render on other entity forms (or when fields are inaccessible) when they shouldn't were the cause.
The code loops through an array that starts with the fields, then groups. For each of them it checks if it's in the group list that was passed. If it is, it checks the $empty_groups_indication array to see if that group is set as an empty element. In order for a group to not be an empty element, one of its children (field or group) needs to have come before it in the list. In the case of nested groups, if a group from the middle of the nest comes first, none of it's children will have set its $empty_groups_indication entry to false. Then, the next part of the code that would set its parent group to false (not empty) does not run field_group.module, line 1063. That parent then is never set to not empty, causing it and its children not to be displayed
Example structure:
Tabs Group 1
--Child Group (Tab)
----Field
--Child Group (Tab) <--- At the end of the process this group considered empty, but it has children with fields
----Tabs Group 2 <--- After all the fields, this group is checked first. It's 2 child groups have not run yet, so it is treated as empty. The next bit of code to set the parent to not empty doesn't run.
------Child Group (Tab)
--------Field
--------Field
------Child Group (Tab)
--------Field
--------Field
--Child Group (Tab)
----Field
The order the field groups are processed in is determined by the array returned by Element::getVisibleChildren($element). Most of the time, it returns the children in an order that works with the process of marking groups as empty. Sometimes it does not.
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | 3266900_field_group_hierarchy_bug_fix.patch | 5.33 KB | artyom hovasapyan |
| #12 | 3528436-12.patch | 7.26 KB | weseze |
Issue fork field_group-3528436
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
alorencComment #5
alorencI was able to replicate the issue consistently.
I created the following nested group hierarchy:
- Level 1 (parent of Level 2)
- Level 2 (parent of Level 3)
- Level 3 (contains the body field)
I then reorganized the structure using the Field Group UI:
- Level 3 becomes the top-level group
- It contains Level 2
- Which contains Level 1
- And Level 1 contains the body field
I exported the configuration and noticed. The weight values were correctly updated. However, the field order in the YAML config remained unchanged, still reflecting the original nesting order.
It looks like the Field Group module builds the field group hierarchy based on the order of items in the YAML configuration file, instead of relying solely on the weight and parent_name properties.
This becomes problematic when reversing the hierarchy (e.g., changing a parent into a child or vice versa), because it can impact the visibility of the element
Comment #6
alorencThe function field_group_remove_empty_form_groups expects that groups are ordered from parent to child
Added an additional function which orders groups.
Comment #7
alorencComment #8
redneko commentedThank you for the work alorenc.
I tested the fix on the site were I found the issue. The missing field group and its children are now displaying, and I did not find any evidence that this fix caused any new issues. I tried making new nodes with different configurations of field groups and found everything to work as expected.
The coding itself looked good to me, but I am not confident in this area. I will leave this issue in 'Needs review' so someone else can check that, and also corroborate that the fix works.
Comment #9
weseze commentedCan confirm this issue.
When updating our setup to 4.x a lot of our field groups disappeared.
The MR fixes this mostly, but not entirely. 1 edge case remains for us. (this was working in the previous version)
Consider this setup:
This will not render anything, while I expected it to render fully since the subgroup is marked to render if it is empty (which it is).
It might look like a weird setup, but we use this in combination with the option to render a custom html-tag instead of an actual "group of fields". Also this is an extremely simplified example. Our actual setup contains dozens of nested field groups and a lot of custom classes and javascript processing...
Comment #10
weseze commentedI have tried to fix this locally, but I am not sure this is entirely correct...
If you change this:
to this:
it seems to work correctly (for me)...
Comment #11
steinmb commentedIf we define #9 as a valid config, then the tests needs to be updated to fail on this type of config. Personally I have I never created such a config and my knee jerk reaction to it is, its sort of a hack.
Comment #12
weseze commentedI understand it is a bit weird, but perfectly possible... And, for us at least, it is very very handy feature to be able to put html tags with classes in the form without custom code.
Attached is an updated patch that fixes this use case.
Comment #13
refsAfter reading through the issue, I believe that the MR for 3266900 - Hiding empty field groups in form display is not working should resolve the problem. Probably needs a rebase.
The code from 3266900 is based on
field_group_remove_empty_display_groups()and also takes show_empty_fields into account.Comment #14
benstallings commentedComment #16
le72I have exactly same situation as described in "Problem/Motivation". Still see the problem. The nested fieldgroups dissapear. Why this issue is closed? Where is the fix?
Comment #17
le72Comment #18
artyom hovasapyan commentedThe patch from #3266900: Hiding empty field groups in form display is not working fixes this issue.