Hide group if all fields are hidden by javascript

+++ b/field_group/src/FieldGroupFormatterBase.php
@@ -154,6 +154,7 @@ public static function defaultContextSettings($context) {
     $classes = array();
+    $classes[] = 'field-group';

any reason to duplicate?

Re-rolled

Doesn't work with horizontal tabs, all tabs are hidden.

Tested with the latest dev version (072bf212d8e13aa242a4e274e5a4837a0e0ffc5e)

Fixed the issue about all tabs hiding + I also noticed that on Accordion Items the Field Group title wasn't hiding. Including both changes in the attached patch.

I applied the patch in #9 to Field Group 8.x-3.x-dev (i.e. 8.x-3.0-beta1+21-dev) but nevertheless groups that only include fields which are hidden by conditional fields dependency are still visible. The field groups are of type "Details".

Patch in #9 seems to work onlywith field groups of type html. However, if I set the _first_ field group to "html", the following field groups with hidden fields of type "details" are hidden as well.

Whereas the patch #9 solves the problem for fields hidden by "conditional fields" module, the problem still persists for fields hidden by "field states ui" module.

Yep, it needs own classes which both modules could use

Thanks for everyone's time with this!

I applied the patch and it works great for initial page load, but if I apply the correct condition for the fields to become visible, and then undo the condition (in my case unchecking a boolean field) - the fields once again disappear but the empty fieldset group is still shown.

Is this still an issue after #2986455: Empty fieldgroups are showing in forms

I believe this is still occurring, specifically, for Tabs (as mentioned in the referenced issue in #16). That's the behavior that I've experienced. When Conditional Fields makes a field "invisible" and that field is the only field in a tab, that tab will still be shown.

If a Tab has no fields in it (i.e. removed using the form display manager), then the tab will not be shown. That is the bug that was fixed successfully in Issue #2986455.

even without Conditional Fields, with the patch in #9 as well as the patch from #2986455: Empty fieldgroups are showing in forms, i still get empty sidebar details tab showing: https://www.screencast.com/t/JR4Tyo8W

I changed FG type to simple fieldset instead of details sidebar.. and this still doesn't work. https://www.screencast.com/t/eg5UXCqAp

Any luck on Drupal 8.8.4?

Updated patch in #9 to work with Drupal 8.8.6 and a refactor of some code into FormatterHelper.php

Probably doesn't fix the use case the #9 patch didn't but fixes the issues I have on my site.

I can't seem to apply the patch in #21.

I'm having this issue on a multilingual site. I have a content type of which some fields are not translatable. These fields are only visible on the original translation (this is how Drupal core works). For my use case, these untranslatable fields all happen to be in the same field group. When translating a node of this particular content type, the field group still renders although it being empty.

The function responsible for setting the form elements #access key for untranslatable fields to FALSE is located at ContentTranslationHandler::entityFormSharedElements() provided by content_translation module. This is run via a #process callback.

The function responsible for tracking down and removing empty fields group is called field_group_remove_empty_form_groups(). This is also run via a #process callback.

The issue is that the field_group #process callback runs before the content_translation #process callback.

The patches proposed earlier are trying to hide empty field groups through JavaScript. Taking the above into account, I believe running field_group_remove_empty_form_groups() as late as possible (eg. in an #after_build callback) gives you the best chance of having empty field groups correctly being removed. The patch attached implements this.

I can confirm that this fixes the content_translation issue.

As for the Conditional Field module: I'm not using it, so I can't validate if this patch also fixes that issue. If not: the issue is probably of the same nature (Conditional Field doing its thing after field_group_remove_empty_form_groups() has already run).

The patch in #23 works good, but not perfect. I think it's also way better than hiding using javascript.

The process method is replaced by an after-build: field_group_form_process_after_build . The doc-block needs a little more update: an after-build has a return-value :)

What does not work is nested groups that are empty: these still force the parent group to be visible, because their access is never set to false. I think this is because the after-build is only run once for the whole form. Perhaps this after-build needs to be recursive? (and do a depth-first check: the deepest child first, then bubble back up).

#23 does not work for our use case, because we are using states to hide the field, so it has to be in JS.

#21 does not work for nested field groups, because they don't have the field-group class (it is overridden by field-group-child-field). The attached patch fixes that.

1. +++ b/field_group.libraries.yml
   @@ -26,7 +26,7 @@ formatter.accordion:
   +    - jquery_ui_accordion/accordion
   

   Does not apply anymore.

2. +++ b/src/Plugin/field_group/FieldGroupFormatter/Fieldset.php
   @@ -43,7 +43,7 @@ class Fieldset extends FieldGroupFormatterBase {
   +      $element['#attributes']['class'] = array_merge($element['#attributes']['class'], $classes);
   

   We should keep the original thinking method here. As you can see, they add the class array. Default there are is no class array. So checking would be better and then merge or add.

#25 makes a good point that groups may be hidden in javascript, which would require a javascript-only solution.

For the server-side solution, to solve groups hidden on the server-side (most commonly by content translation), #3069365: Emptiness check in field_group_remove_empty_form_groups() does not account for empty containers contains something that looks good to me.

I suggest this issue focuses on hiding groups when they are hidden by javascript, if that's needed.

Sorry, I'd misinterpreted that other issue, although it is indeed a server-side change. #3127179: Empty group due to hiding fields on translation form are not hided now has a patch for the server-side issue, and matches #23's report of content_translation causing the issue.

I think that #25/#26 are targeting only accordions.
I tested it without luck on a details group rendered by the default olivero theme.

Here is the rendered html of my "not hided" group

<details class="field-group required-fields field-group-details js-form-wrapper form-wrapper olivero-details accordion-item" data-drupal-selector="edit-group-cc" id="edit-group-cc">
    <summary role="button" aria-controls="edit-group-cc" aria-expanded="false" aria-pressed="false" class="olivero-details__summary">My Title<span class="summary"></span>
    </summary>
    <div class="olivero-details__wrapper details-wrapper">
        <div class="field-group-child-field js-form-wrapper form-wrapper" data-drupal-selector="edit-field-my-field" id="edit-field-my-field">
        </div>
    </div>
</details>

As you can see, there isn't any .accordion-item class

Note: The field (in the group) has been hidden by setting the '#access' key to FALSE in the regular form_alter

Tested the patch with 3.2 and it doesn't seem to work with tabs.

I have one field group marked as a tab and adding the condition to it, hides the fields inside it but it doesn't hide the actual tab.

I checked that there is no change in the HTML code.

Looking at the patch, it seems like its only triggering for elements with the class .accordion-item where as the tabs have the following HTML structure:
<li class="horizontal-tab-button horizontal-tab-button-1 last selected" tabindex="-1" data-horizontaltabbutton="1"><a href="#edit-group-researcher-profile"><strong>Researcher profile</strong><span class="summary"></span><span id="active-horizontal-tab" class="visually-hidden">(active tab)</span></a></li>

I confirm the patch is not working with horizontal neither vertical tabs.

This is the JS version for tabs working, but we should find the way to work with all group elements.

      $(document).ready(function () {
        $(context).find('.field-group .js-vertical-tabs-menu-item').each(function(index) {
          hideGroupIfEmpty($(this), index);
        });
      });

      $(document).bind('state:visible', function(e) {
        $(context).find('.field-group .js-vertical-tabs-menu-item').each(function(index) {
          hideGroupIfEmpty($(this), index);
        });
      });

      // Check group's child fields state and hide/show group.
      function hideGroupIfEmpty(group, index) {
        var group_empty = true;
        $(context).find('.field-group details.field-group-child-field').each(function (i, el) {
          if (index == i) {
            if ($(el).css('display') !== 'none') {
              group.show();
            }
            else {
              group.hide();
            }
          }
        });
      }

housekeeping....

I'm changing status to 'needs work' based on comments posted over the course of the last year; I'm guessing it was meant to be changed earlier

My attempt to get it working for all field group formatters, inspired by previous patches.

I went a slightly different route and provided a field group js function to hide a field group and its tab (if applicable). Then each formatter is required to call the function during its process or attach function and provide the function parameters as needed. The formatter is also required to bind to the `states:visible` event.

Preliminary manual testing has been done on tabs, accordion items, fieldsets and details.

This really needs tests written, which is beyond my current scope.

Thanks for the work, this did the trick for me and looks good. I added this also to the HTML element.

Apologies for the error in code. Fixed in new patch.

Re-rolled patch 36 for module tag 8.x-3.4 and added semi-colons at the end of let variable declarations.

I am providing an updated patch and have also pushed to the issue fork.

This should resolve the Drupal 10 issues.

This patch is nice and working well except if we are adding fields in an empty group in the hook form_alter.
I am using the following function to add $form[$field_name] to a group (id=$group_name):

function addToGroup(array &$form, string $field_name, string $group_name)
{
  /** @var EntityFormDisplay $form_display */
  $form_display = $form['#process'][1][0];
  $form[$field_name]['#group'] = $group_name;
  $field_group = $form_display->getThirdPartySettings('field_group')[$group_name];
  $field_group['children'][] = $field_name;
  $form_display->setThirdPartySetting('field_group', $group_name, $field_group);
  }
}

If I add $form['field_to_add'] in a group which is empty but which have the option "Display element also when empty" checked; then the group is not displayed.

To summarize, there are 2 issues:
1-The patch doesn't take into account the option Display element also when empty
2-The patch doesn't take into account any element added to the group in the form_alter hook

The patch works correcly on initial load, but it does not seems to work correctly when detecting a change.
We have a fieldset containing 3 fields that can be shown/hidden depending on when another checkbox field is checked (we use conditional_fields for this).
The field group is initially hidden but if I make the fields visible then hide them, the field group is not hidden and is displayed empty.

This seems to happen because when Drupal.FieldGroup.hideGroupIfEmpty() evaluate the display property of the fields, the last does not have none yet. So it might be some kind of race condition that makes it check the field too soon.
If I do something like this, then it works correctly:

diff --git a/formatters/fieldset/fieldset.js b/formatters/fieldset/fieldset.js
index 7349be4..3a2f052 100644
--- a/formatters/fieldset/fieldset.js
+++ b/formatters/fieldset/fieldset.js
@@ -34,7 +34,9 @@
         if ($(e.target).hasClass('field-group-child-field')) {
           let $group = $(e.target).closest('.field-group-fieldset');
           if ($group.length !== 0) {
-            Drupal.FieldGroup.hideGroupIfEmpty($group, null, true);
+            setTimeout(function () {
+              Drupal.FieldGroup.hideGroupIfEmpty($group, null, true);
+            }, 500);
           }
         }
       });

(This is obviously not the way to the fix the problem, but it helps demonstrate it.)

Patch failed on field_group 3.6 and Drupal 10.3

Hello everyone,
Re-holl of patch field_group-2978747-40.patch (8.x-3.0), now covering the module version 8.x-3.6.

Unfortunately I can confirm the behavior described by #42 working only initially.

Would MutationObserver be an acceptable solution for #42? One would need to observe subtree, childList, and attributes.

I will create a new branch in the issue fork based on 2978747-hide-group-if.

You can take a look at https://git.drupalcode.org/issue/field_group-2978747/-/tree/2978747-hide-group-with-mutation-observer for my solution for #42.

There don't seem to be any tests implemented for this issue?

Updating to new major version.

Not only is there an issue with the code only working initially, I also experienced issues with it not working with nested groups. To fix these issues I implemented a different approach.

We need to ensure that when the state:visible event is fired we not only set the visibility of the closest field group but we continue up the DOM to set the visibility of parent field groups. This is easier to handle with one state:visible event listener in the field_group.js than one for each field group type.

Because each field group type might need to do different things when its children are all hidden vs when a child is visible, once we have determined the current visibility of the field group children we need to hand off what is done to the field group to the js file for the different types.

I have updated the Issue Summary with my proposed resolution. Given the significant changes to the previous version and the merge conflict issues in updating the old solution branches, I have added a new 2978747-hide-group-4.x and opened a MR.

I have also added preliminary testing for this bug.

@tgauges: Interesting concept with the MutationObserver, although I am wondering if it is more than what is needed in this instance? Given the new approach, what does it do better?

I can confirm the last / new approach from 2978747-hide-group-4.x works fine. thank you!

@tame4tex MutationObserver is a catch-all solution which also can work if the DOM is mutated by something other than the Drupal Form API #states property.

In my opinion you are correct: It is probably more than what is needed. I think it's enough to react to changes caused by the #states property.

I have pushed a couple of fixes to the MR due to issues encountered.

`Display element also when empty` setting was not being respected. I have now added a test for this and fixed the bug by adding a css class
if this setting is enabled and then checking for that class in the logic.

I also encountered a weird bug in Safari 18.x where it was ignoring the style attribute on the element being hidden/shown by states and instead determining the display value to be "none" when it was actually "block". I have adjusted the code to specifically check the style attribute on the element first and only get the computed style if the style attribute display value is empty.

I have switched the status back to Needs Review due to these changes.

Should this work with forms loaded via ajax? I've applied the patch to the 4.0.x branch but it hasn't made any difference.

In my case, the target fieldset and controlling fields are within a paragraph type. When adding a new paragraph the fields are correctly shown or hidden while the fieldset wrapper is always visible.

Ignore the above, I'm having patching issues.

Adding a patch file with the rebase above for 4.0.0

Confirming patch on #62 comment worked good. Tested on D11.2.8 and PHP 8.3.

Bear in mind that the option Display element also when empty should be disabled into the Group Tab for get it to work properly:

Thanks!

I am using Drupal 11.2.10 and field group 4.0.0.

I have a field group inside a paragraph. There are a few fields under that field group and I am using #states to show/hide those fields on the change of value of another select field.

When a value in the select field hides these fields, it works fine and the field group also hides as there is no other field to show in the field group. But as soon I make a selection in the select field that has to show the fields under the field group, the fields show but there is no field group as it never existed.