Original report

I would like to be able to show/hide a group of fields (according to the documentation it's supposed to work).

I've created a fieldset with all fields that will be dependent but this group field is not in the list of dependent. How can a dependee affect a group of dependent fields ?

Thanks!

Remaining tasks

Follow-up issues

Please create new tickets for these (unless they already exist), and add links to them from here. Thanks!

CommentFileSizeAuthor
#253 Tab_without_data-drupal-states.png33.39 KBethanbb
#253 Element_with_data-drupal-states.png64.05 KBethanbb
#242 conditional_fields-support_field_group-1161314-242.patch29.12 KBmparker17
#241 interdiff.txt1.1 KBmparker17
#241 conditional_fields-support_field_group-1161314-241.patch29.57 KBmparker17
#238 conditional_fields-support_field_group-1161314-238.patch28.68 KBmparker17
#229 conditional_fields-support_field_group-1161314-229.patch28.44 KBcolan
#229 interdiff-1161314-226-229.diff607 bytescolan
#227 example.gif1.21 MBnuez
#226 conditional_fields-support_field_group-1161314-226.patch28.32 KBcolan
#221 interdiff-1161314-211-221.diff1.19 KBcolan
#221 conditional_fields-support_field_group-1161314-221.patch26.11 KBcolan
#211 interdiff-208-211.txt988 bytesergonlogic
#211 conditional_fields-support_field_groups-1161314-211.patch25.45 KBergonlogic
#208 interdiff-203-208.txt30.36 KBergonlogic
#208 conditional_fields-support_field_groups-1161314-208.patch25.12 KBergonlogic
#207 conditional_fields-support_field_groups-1161314-207.patch42.43 KBergonlogic
#206 conditional_fields-support_field_groups-1161314-206.patch39.37 KBergonlogic
#205 conditional_fields-support_field_groups-1161314-205.patch34.49 KBergonlogic
#203 conditional_fields-support_field_groups-1161314-203.patch18.67 KBergonlogic
#199 conditional_fields-support_field_groups-1161314-199.patch1.04 KBergonlogic
#197 conditional_fields-fieldgroup-support.patch1005 bytesagudivad
#196 conditional_fields-fieldgroup-support.patch1.17 KBagudivad
#194 conditional_fields-fieldgroup_fieldset_support-1161314-194.patch731 bytesAndrew Answer
#182 conditional_fields-fieldgroup_fieldset_support-1161314-182.patch737 bytesTLWatson
#166 fieldgroup_support-1161314-166.patch729 bytesyogeshmpawar
#162 hide_empty_fieldsets-1161314-162.patch728 bytesAnybody
#161 hide_empty_fieldsets-1161314-161.patch707 bytesAnybody
#160 hide_empty_fieldsets-1161314-160.patch309.75 KBAnybody
#152 fieldgroup_support-1161314-152.patch29.5 KByogeshmpawar
#147 conditional_fields-fieldgroup_support-1161314-147.patch21.82 KBsdsheridan
#146 1481050265.1191.gif29.45 KBTechNikh
#143 conditional_fields-fieldgroup_support-1161314-143.patch20.67 KBsdsheridan
#142 conditional_fields-fieldgroup_support-1161314-142.patch20.89 KBsdsheridan
#131 hide_empty_fieldsets-1161314-131.patch708 bytesanrikun
#130 hide_empty_fieldsets-1161314-130.patch715 bytesanrikun
#128 condfield.jpg36.25 KBgiupenni
#124 conditional_fields-fieldgroup_support-1161314-124.patch16.45 KBjproctor
#123 conditional_fields-fieldgroup_support-1161314-123.patch16.9 KBjproctor
#111 conditional_fields-fieldgroup_support-1161314-111.patch15.5 KBbgilhome
#101 interdiff-1161314-99-100.txt10.79 KBbgilhome
#101 conditional_fields-fieldgroup_support-1161314-100.patch16.87 KBbgilhome
#100 interdiff-1161314-94-99.txt10.65 KBbgilhome
#99 conditional_fields-fieldgroup_support-1161314-99.patch14.15 KBbgilhome
#94 conditional_fields-fieldgroup_support-1161314-94.patch11.4 KBbgilhome
#91 conditional_fields-fieldgroup_support-1161314-91.patch11.37 KBbgilhome
Command icon 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:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

peterpoe’s picture

Title: Fieldgroup do not appear in the list of dependent » Fieldgroup support
Component: User interface » Compatibility w/ other modules
Category: bug » feature

This functionality is still missing from Conditional Fields 7.x-3.x. Please follow this issue for announcements when it will be implemented.

pgorecki’s picture

subscribe

Martin Mayer’s picture

subscribe

Shadlington’s picture

Subbing

MrPhilbert’s picture

Subbing too.

clashar’s picture

+1

stevebab’s picture

subscribe

thomasLausZ’s picture

Assigned: Unassigned » thomasLausZ

subscribe

Shadlington’s picture

I don't think you meant to assign it to you - unless you intend to fix this yourself?

thomasLausZ’s picture

No, you are right, but can't change it back.

Shadlington’s picture

Assigned: thomasLausZ » Unassigned

That's because I fixed it for you :)

jackbravo’s picture

subscribe

jackbravo’s picture

I was taking a shot at implementing this and found that under current implementation this seems almost impossible. The conditional_fields table saves only the field id, which is a number. Based on this number there is no way of knowing whether it is a regular field or a group field.

What I think is that in order to implement this the conditional_fields table should change to store the field name instead. Or add another column that specifies if this is a field or a group field.

What do you think?

Also, this only would apply to the dependent field, as no dependee can be a field group.

AtomicTangerine’s picture

sub!!!

Fanaile’s picture

Subscribing;

chalee’s picture

+1 subscribing

restyler’s picture

subscribing

drupov’s picture

subscribe

misxooo’s picture

subscribe

Coupon Code Swap’s picture

+1

this would be very useful.

peterpoe’s picture

Field group support is not a small task, it will probably take some time. In the meantime, consider using the Field collection module, which already works (almost) perfectly with Conditional fields.

#14: You're right, it would be necessary to change the schema by adding a 'dependent_type' or 'dependent_module' column that identifies the type of dependent (field or fieldgroup).

jackbravo’s picture

Wow! I didn't know about field_collection. But looks pretty nice. Hope to try it soon.

vasike’s picture

subscribe.
Field collection it's a good tool, but why should we build new entities when just some grouped fields are needed.
I think this is a very needed feature and more than nice to have.

jaxpax’s picture

+1

Tobias Englert’s picture

sub

that0n3guy’s picture

sub

JordanMagnuson’s picture

+1 For this.

jackbravo’s picture

@davidlerin there is now a follow button at the top you know =)

-ds-’s picture

This feature would be great!

I have a huge form with 100+ fields that are dependent on each other and I would really like to display them using tabs split into their categories etc rather than on one massive long page as not all fields are needed depending on the initial selection.

Rontero’s picture

I found that Conditional Fields module does actually work with Fieldgroup module. I use vertical tabs for sorting all my fields. Unless both dependent and dependee are in the same tab, dependencies work.

mrfelton’s picture

@Rontero - what do you mean 'it works'? Im using Accordion groups to group fields, and these accordion groups not available for selection by conditional fields. Accordian are much the same as vertical tabs in terms of the implementation - it's just a different widget on the fieldgroup. How exactly re you using vertical tabs with conditional fields?

Rontero’s picture

@mrfelton I'm using conditions on fields not on accordions etc. As long as yoour dependent and dependee are in the same group, Conditional Fields module works.

Example from my site:

I have Drupla Commerce installed for adding products to my site.
Case: Select the appropriate country (the manufacturer is based in) after user selects maker's name.

  1. Product group called basic info (type: vertical tab)
    • Field 1: Maker's name (field type: select list)
    • Field 2: Maker's country (field type: select list)

First field is dependee and second is dependent.

After constructing such a form, in manage dependencies tab i made proper dependent/dependee selections and as a rule used fields with a value / has value.

I hope this helps.

Fanaile’s picture

@Rontero;

True, even if the two fields are not in the same field group the dependencies work. For example, one client's site has registrants choose individual or group registration type. If they choose individual several conditional fields will be shown and vice versa if you choose group.

But what he wants and what I'm trying to get working again is that the entire field group will be shown or hidden pending the choice. Otherwise even if I set each field to show or hide pending the choice, the field group still shows - with the label for it - just none of the individual fields do.

bryancasler’s picture

I'm looking for the same solution as Fanaile

Golem07’s picture

@Fanaile: This is exactly what I am in need of, too. Please let us know in case you solve this in any way.

rwilson0429’s picture

Yes, getting the

entire field group will be shown or hidden pending the choice

would be a great feature that's needed.

carlmcdade’s picture

In D7: It would be better to use a parent/child situation. A new field that is the field id of the field_group table as the parent_id. start gathering the children and see if they all have the same parent. if so then show the parent.

Tony Finlay’s picture

Very interested too, has there been any movement on this or will there even be any attempt to implement the feature?

yannickoo’s picture

Oh, no activity here ;(

sgurlt’s picture

sub

warmth’s picture

Any way to display or not an entire group using CF?

funkytraffic’s picture

+1 subscribing

bitcookie’s picture

For now you can kinda do this with javascript. We haven't tested this too much, but have it running on one of our sites.

First, make a javascript/jquery function to hide empty fieldsets

Drupal.mymodule.cleanupFieldsets = function() {
    
    $("fieldset").each(function(){
      var fieldset = $(this);
      
      fieldset.show();
      
      var wrapper = fieldset.find(".fieldset-wrapper");
      if(wrapper.height() == 0){
        fieldset.hide();
      }
      else{
        fieldset.show();
      }
    });

  }

Then, bind a change event to every form widget in your node form to fire the cleanup function

  $('input, select').change(function(){
    Drupal.mymodule.cleanupFieldsets();  
  });
friera’s picture

+1

aze2010’s picture

subscribing

mahyarsbt’s picture

subscribe

i test "field collection" and "fields group" modules with conditional field on profile 2.
but not works

Please support fieldset feature.

miccelito’s picture

@Fanaile #34:

For example, one client's site has registrants choose individual or group registration type. If they choose individual several conditional fields will be shown and vice versa if you choose group.
But what he wants and what I'm trying to get working again is that the entire field group will be shown or hidden pending the choice. Otherwise even if I set each field to show or hide pending the choice, the field group still shows - with the label for it (---)

I have just tested these modules together
Conditional Fields 7.x-3.x-dev
Field collection 7.x-1.0-beta5

in purpose to see if it solves the issue mentioned in this thread with still showing labels for fieldgroups with hidden fields.
And as far I can see from my test, it works!
I did try with fields at admin/config/people/accounts/fields

nevergone’s picture

And since then?

vlooivlerke’s picture

Would it not be better to have conditions for field groups?
Then you can show/hide entire field groups and its fields with 1 simple field condition.

If the field has value then show field group

Maybe this will have to be an add-on module

EDIT:

Wait, I want to hide an empty fieldset if the fields in the fieldset are not visable due to the field condition.

Shiraz Dindar’s picture

hey folks, if you want to show/hide a whole fieldgroup conditionally:

you have to use the hook_field_group_build_pre_render_alter()

Simply :

function your_module_field_group_build_pre_render_alter(&$element) {
  $element['your_field_group']['#states'] = array(
    'visible' => array(
      ':input[name="field_checkbox"]' => array('checked' => TRUE),
    ),
  );
}

This works perfecly. If the group A is in an another group, do this

$element['groupA']['groupB']['#states'] etc....

Courtesy of bobylapointe over at stackpoint.

Works well.

Perhaps conditional fields would implement it as such.

pmichelazzo’s picture

This code didn't work for me. Also I receive this message:

Notice: Undefined index: #id in drupal_process_states() (line 4664 of /Users/me/Sites/tests/includes/common.inc).

ryantollefson’s picture

I finally got this working - similar to #51 & http://drupal.stackexchange.com/questions/14635/hide-a-cck-fieldgroup-us... (but with added if statement to prevent errors I was getting with other modules.

function your_module_field_group_build_pre_render_alter(& $element) {
  if (isset($element['your_field_group'])){
	$element['your_field_group']['#states'] = array(
		'visible' => array(
		'#edit-field-name-und' => array('checked' => TRUE),
		)
	);
	}
}
vlooivlerke’s picture

Issue summary: View changes

Before I try this code, just a stupid question.

Does this code show/hide the fieldgroup using JavaScript in real-time or only after a node save?

And settings like speed and fade options would be a bit more complicated I guess.

ryantollefson’s picture

Does this code show/hide the fieldgroup using JavaScript in real-time or only after a node save?

And settings like speed and fade options would be a bit more complicated I guess.

This shows/hides in real time, but doesn't use javascript, though I'm sure it could be done... perhaps look at: https://drupal.org/node/304255 or http://drupal.stackexchange.com/questions/6960/how-to-add-jquery-plugin-...

arthitst’s picture

+1 subscribing

akolahi’s picture

I'm willing to pay for development of this functionality. Send me a note if interested.

Thanks.

gintass’s picture

Here is one workaround for this problem that might help someone. I just tested and it worked.

As stated above conditional fields module supports field collections created by Field Collection module, but not field groups created by Field Group module.

Instead of adding field group with a bunch of fields directly to the content type you can add it to a field collection. Then you can apply conditions to that field collection and control visibility of all the field groups and fields inside this field collection.

mastoll’s picture

@gd1008, moving fields from a field group to a field collection does not work if you are using Display Suite for node display. The conditional aspect of the node edit form works fine. The field collection doesn't display in the node view. Have looked at Display Suite and Conditional fields for a solution - none. I don't know where it's easier to address: Field Group, Field Collection, Conditional Fields, or Display Suite. It's a convoluted and interesting interplay between the modules.

rollingnet’s picture

I tried to apply the #51 and #53 patches, but without success.
Can someone confirm that they work and how?

ryantollefson’s picture

These aren't patches, but are meant to be used as a custom module. It's really a work around, but yes it does work just fine.

You should be able to paste the code into "your_module.module". Next rename the field_group and field_name parts to match your actual fields. Then just create "your_module.info", put it all in a folder in your modules directory and enable it.

Either use the code from #51 or #53 (not both).

mauzeh’s picture

#44 does not work for the case of horizontal or vertical tabs. If you want to hide a tab instead of a field group, use this Javascript snippet:


(function($){

  var cleanupFieldsets = function() {

    $("fieldset").each(function(){
      var fieldset = $(this);

      // Find out if the fieldset contains only elements that are hidden,
      // regardless of the fieldset itself being hidden.
      var countShownSubFields = 0;
      $(fieldset).find('div.form-wrapper').each(function(){
        if ($(this).css('display') === 'block'){
          countShownSubFields++;
        }
      });

      var data = fieldset.data();

      // Horizontal tab support
      if (data && data.horizontalTab) {
        if (countShownSubFields === 0) {
          fieldset.data('horizontalTab').item.hide();
        } else {
          fieldset.data('horizontalTab').item.show();
        }
      }

      // Vertical tab support
      if (data && data.verticalTab) {
        if (countShownSubFields === 0) {
          fieldset.data('verticalTab').item.hide();
        } else {
          fieldset.data('verticalTab').item.show();
        }
      }
    });
  }

  $(document).ready(function(){
    cleanupFieldsets();
    $('input, select').change(cleanupFieldsets);
  });

})(jQuery);


apmsooner’s picture

I tried some of the jquery examples above and couldn't get them working for me so I came up with my own implementation that does work and additionally adds prev/next links to navigate through the tabs to combine multi-page functionality with vertical tabs. I still consider myself a jquery novice so I'd sure appreciate any feedback to the below code as if there are ways for better optimization. Functionally... it works quite well though.

(function ($, Drupal) {

    Drupal.behaviors.customNav = {
        attach: function (context, settings) {

            $(".vertical-tabs-pane", context).once('epic').each(function () {
                var fieldset = $(this);
                var countHidden = 0;
                var countVisible = fieldset.find('> div.fieldset-wrapper > div.form-wrapper').length;
                var data = fieldset.data();
                $(fieldset).find('> div.fieldset-wrapper > div.form-wrapper').each(function () {
                    if ($(this).css('display') === 'none') {
                        countHidden++;
                    }
                });
                if (data && data.verticalTab) {
                    if (countHidden === 0 || countHidden !== 0 && countHidden !== countVisible) {
                        fieldset.data('verticalTab').item.show();
                        fieldset.addClass('not-empty').removeClass('empty');
                    } else {
                        fieldset.data('verticalTab').item.hide();
                        fieldset.addClass('empty').removeClass('not-empty');
                    }
                }
                // create navigation dynamically
                $(fieldset).prepend("<div class='form-navigation top clearfix'><a href='javascript:void()' class='prev-tab'>&#171; Previous</a><a href='javascript:void()' class='next-tab'>Next &#187;</a></div>");
                $(fieldset).append("<div class='form-navigation bottom clearfix'><a href='javascript:void()' class='prev-tab'>&#171; Previous</a><a href='javascript:void()' class='next-tab'>Next &#187;</a></div>");
            });

            $('.vertical-tabs-pane.not-empty').each(function () {
                var next = $(this).nextAll('.vertical-tabs-pane.not-empty');
                var prev = $(this).prevAll('.vertical-tabs-pane.not-empty');
                var prevTab = $(this).find('.prev-tab');
                var nextTab = $(this).find('.next-tab');
                if (prev.length === 0) {
                    prevTab.hide();
                } else {
                    prevTab.show();
                }
                if (next.length === 0) {
                    nextTab.hide();
                } else {
                    nextTab.show();
                }
            });
            $('a.next-tab').click(function () {
                var nextTarget = $(this).closest('.vertical-tabs-pane').nextAll('.vertical-tabs-pane.not-empty');
                nextTarget.data('verticalTab').item.find('a').trigger('click');
            });
            $('a.prev-tab').click(function () {
                var prevTarget = $(this).closest('.vertical-tabs-pane').prevAll('.vertical-tabs-pane.not-empty');
                prevTarget.data('verticalTab').item.find('a').trigger('click');
            });


            $('input, select').change(function () {
                cleanup();
                cleanupNav();
            });


            var cleanup = function () {
                $(".vertical-tabs-pane").each(function () {
                    var fieldset = $(this);
                    var countHidden = 0;
                    var countVisible = fieldset.find('> div.fieldset-wrapper > div.form-wrapper').length;
                    var data = fieldset.data();
                    $(fieldset).find('> div.fieldset-wrapper > div.form-wrapper').each(function () {
                        if ($(this).css('display') === 'none') {
                            countHidden++;
                        }
                    });
                    if (data && data.verticalTab) {
                        if (countHidden === 0 || countHidden !== 0 && countHidden !== countVisible) {
                            fieldset.data('verticalTab').item.show();
                            fieldset.addClass('not-empty').removeClass('empty');
                        } else {
                            fieldset.data('verticalTab').item.hide();
                            fieldset.addClass('empty').removeClass('not-empty');
                        }
                    }
                });

            };
            var cleanupNav = function () {
                $('.vertical-tabs-pane.not-empty').each(function () {
                    var next = $(this).nextAll('.vertical-tabs-pane.not-empty');
                    var prev = $(this).prevAll('.vertical-tabs-pane.not-empty');
                    var prevTab = $(this).find('.prev-tab');
                    var nextTab = $(this).find('.next-tab');
                    if (prev.length === 0) {
                        prevTab.hide();
                    } else {
                        prevTab.show();
                    }
                    if (next.length === 0) {
                        nextTab.hide();
                    } else {
                        nextTab.show();
                    }

                });
            };



        }
    };

})(jQuery, Drupal);

Anyone can try this out by pasting the entire script into a .js file loaded in your theme or module or you could just paste it into a rule with the js injector module. I hope someone finds it useful and willing to make it better as it took alot of time for me to research how to do this.
FYI: The main reason why some of the example scripts above weren't working for me is because they were counting .form-wrapper with display:block. This led to inaccurate count for me because .form-wrapper wouldn't be explicitly set with display:block unless conditional fields triggered it so my method is to do a total count of .form-wrapper and compare it to a count of .form-wrapper with display:none. I also had to explicitly look for the first level of .form-wrapper only because in the case of using field collections, there would be several divs within that also had class of .form-wrapper which would totally screw up my count.

apmsooner’s picture

Corrected pasted code in #63 as i had an extra unnecessary div in the selector.

Anybody’s picture

Sadly this important feature is still missing. Is there any work in progress?

apmsooner’s picture

@Anybody,

I think its a little complicated to provide as a fieldset setting as hiding tabs would have to react to field change events and i don't know if a setting like that can account for the specific change events to trigger the function to hide fields unless it provided a field to input selectors that got passed to the javascript. Even so, while my script in #63 works for me, i only accounted for vertical tabs and in my case i only have one level of vertical tabs. If someone put fieldgroups within fieldgroups, i think that could add alot more complexity to try to figure out how to loop through and find hidden fields... and additionally performance could be an issue as number of fields and fieldgroups grow. In the meantime, you could certainly adapt my script above to your needs and get the functionality you need now.

apmsooner’s picture

Technically someone could add a checkbox to the fieldset settings form labeled "Hide hidden fields" that would render a class for the fieldset that could be evaluated in script similar to what i posted but really.... thats not even completely necessary as you can already specify classes to your fieldsets now so you could just change .vertical-tabs-pane in my script to something more generic and that would probably work wouldn't it? You could certainly take out all the navigation stuff from my script and just hide/show fieldgroups on the change events. It actually now makes better sense for me to make my class in the script more generic as there are certain vertical tab groups that i know will always have fields that aren't hidden so no use running the script for nothing.

NancyDru’s picture

The code in #51 and #53 does not work for me (7.28). As a matter of fact, if there is no ID defined in the field settings, it causes several problems.

This would be a great feature to have, but I leave here in 3.5 weeks, so I suspect I'll never see it.

apmsooner’s picture

@NancyDru, why not just do it in jquery? #63 could be modified with conditions to check the type of fieldgroup it is and thus not be specific to vertical tabs. Maybe i'm missing something but i'm not sure i understand the dire need to have it in a module. Just curious.

NancyDru’s picture

A) I am not a javascript person.
B) There is already some code similar to this in their custom module. It just doesn't work.

Grimreaper’s picture

Thanks for code in #63.

imclean’s picture

#51 looks to be on the right track. See also: #1053174: hook_form_alter form state problems

There's some good example code in that other issue. You shouldn't have to write a line of javascript to get this working.

imclean’s picture

For #51 to work and not get the error in #52:

  1. Assign the fieldset an ID, either in "manage fields" or code
  2. Add the class "form-wrapper" to the fieldset, either in "manage fields" or code

Once the above 2 tasks have been completed, you can use something like this example code:

/**
 * Implements hook_field_group_build_pre_render_alter()
 */
function MY_MODULE_field_group_build_pre_render_alter(&$element) {
  // Check for your form
  if ($element['#form_id'] == 'MY_FORM_edit_form') {
    // Apply state information to fieldsets
    $element['group_FIELDSET'] += array(
      // Hide FIELDSET if  CHECKBOX is checked
      '#states' => array(
        'visible' => array(  
          '#edit-field-CHECKBOX' => array('checked' => FALSE),
        )
      )
    );
  }
}
NancyDru’s picture

Ian, a fieldset already has "form-wrapper" and an id. Maybe my problem is that I am triggering on a two-value radio, not a checkbox.

imclean’s picture

NancyDru, maybe it's the base theme we use but our fieldsets don't have an ID or necessary class. Radios should work but you need to use the "value" condition instead of "checked". We use the below method:

/**
 * Implements hook_field_group_build_pre_render_alter()
 */
function MY_MODULE_field_group_build_pre_render_alter(&$element) {
  // Check for your form
  if ($element['#form_id'] == 'MY_FORM_edit_form') {
    // Apply state information to fieldsets
    $element['group_FIELDSET'] += array(
      // Hide FIELDSET if  RADIO option two is selected
      '#states' => array(
        'invisible' => array(
          '#edit-field-RADIO' => array('value' => 'two'),
        )
      )
    );
  }
}

For multiple options (OR):

/**
 * Implements hook_field_group_build_pre_render_alter()
 */
function MY_MODULE_field_group_build_pre_render_alter(&$element) {
  // Check for your form
  if ($element['#form_id'] == 'MY_FORM_edit_form') {
    // Apply state information to fieldsets
    $element['group_FIELDSET'] += array(
      // Hide FIELDSET if  RADIO option two, four or six is selected
      '#states' => array(
        'invisible' => array(
          '#edit-field-RADIO' => array(
            array('value' => 'two'),
            array('value' => 'four'),
            array('value' => 'six),
          ),
        ),
      )
    );
  }
}

https://api.drupal.org/api/drupal/includes%21common.inc/function/drupal_...

imclean’s picture

Ok I see the potential problem with Conditional Fields.

Multipage Fieldgroup states appear to override the custom states set above. Related fieldgroup issue was marked as a duplicate of this one: #1518026: Support for "Conditional Fields" module, field group remains visible when fields have been hidden using drupal form states.

dnlmzw’s picture

Rewrote some of the code found in example #63, to make it work with horizontal panels. Paste the code into a .js file and load it in your project to make it work. Not well tested, but works for me.

(function ($, Drupal) {
		Drupal.behaviors.customNav = {
				attach: function (context, settings) {

					function cleanUp () {
						$(".field-group-htabs-wrapper", context).each(function () {
							
							var wrapper = $(this);
							var groupEmpty = true;

							$(".horizontal-tabs-pane", wrapper).each(function(){

								var fieldset = $(this);
								var countHidden = 0;
								var countVisible = fieldset.find('> div.fieldset-wrapper > div.form-wrapper').length;
								var data = fieldset.data();
								
								$(fieldset).find('> div.fieldset-wrapper > div.form-wrapper').each(function () {
										if ($(this).css('display') === 'none') {
												countHidden++;
										}
								});

								if (data && data.horizontalTab) {
									if (countHidden === 0 || countHidden !== 0 && countHidden !== countVisible) {
										groupEmpty = false;
									}
								}

							});

							if(groupEmpty) {
								wrapper.hide();
							} else {
								wrapper.show();
							}

						});
					}

					cleanUp();

					$('input, select').change(cleanUp);
				}
		};
})(jQuery, Drupal);
benmmc’s picture

I tried others here, but none of them worked, so I wrote this very generic JS that basically looks inside each fieldset for form-item class elements, and determines whether they have been hidden or not. If a fieldset has any non-hidden items, it shows the group. Otherwise, it hides it.

The :not() selector is necessary because some widgets have the form-item class for individual choices, as opposed to one element with the form-item class for each field. I may have missed some widgets, but this selector covered all the widgets I was using.

$('select#edit-field-whatever-und').change(function() {
			$('form.node-whatever-form fieldset.fieldset').each(function() {
				hide = true;
				$(this).find('.form-item:not(.form-type-radio, .form-type-checkbox, .form-type-date-select, .form-type-managed-file, .form-type-date-select .form-type-select)').each(function() {
					if($(this).css('display') != 'none'){
						hide = false;
					}
				});
				if(hide == true){
					$(this).hide();
				}else{
					$(this).show();
				}
			});
		});
eMuse_be’s picture

subscribe

milos.kroulik’s picture

I tried to apply solution from #78, but it didn't work. Maybe I've done something wrong - is there anyone, who tried it?

tomvv’s picture

#63 is great for hiding of empty tabs, thanks.

System Lord’s picture

+1

eMuse_be’s picture

+1

Parkes Design’s picture

+1

axe312’s picture

Please do not write "+1" to the issue, instead use the "Follow" button on the right upper area of the issue.

Since this issue is needed by so many people, it might be smart to fund some money to fix it? https://www.drupalfund.us/

kitzinger’s picture

+1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1

!!!!!!!!

System Lord’s picture

I have to agree with ktzinger. The "Follow" feature doesn't tell anybody that I'm having similar issue. Maintainers react to volume of concern (issue comments) not to who's following. What if someone commented "I'm having the same issue." Would you tell them to stop posting that and use "Follow" ? In my mind "following" could simply mean a member is curious about a topic and don't have an issue or comment. Which to me means if everyone used "Follow" the maintainers would not have any indication that there is bigger issue than it appears.

I've been wanting to say that for months! :) Thank kitzinger!

apmsooner’s picture

If someone wants to try to create a patch that includes settings that would implement code similar to #63 as a setting.... that would be a big plus and would push this closer to an actual addition to the module. It would of course need to accommodate other types of tabs rather than just vertical but it seems as though it could be a setting added within each field group parent container to hide/show child tabs if fields are hidden.

Otherwise, feel free to use/modify that code for your needs as a workaround. There are several confirmations that it works...

kitzinger’s picture

@apmsooner - yes yes yes we get it, we have read the posts about the code, we can see the code above, but that is not a resolution and not why we are posting. :D We are posting to keep the thread alive so that, hopefully, some day soon, the maintainer or a possible contributor will see our outcries and maybe devote some highly appreciated time to help. Of course they are not obliged, and there is a code posted above, but it would be lovely if the feature was available in the bare module! ... just being a bit cheeky, but nonetheless.....

Hope you are not offended in any way, that is certainly not the intention! Of course I am still very grateful for the module

jlbellido’s picture

Subscribed

bgilhome’s picture

I've implemented an approach to add fieldgroups as a dependent. In the conditional_fields_element_after_build function, as well as any field that is saved as a dependent, any field that is a child of a fieldgroup saved as a dependent also gets the dependency attached. NB currently only includes first-level children.

Tested with 'visible' state but in theory could use other states eg. 'required'.

Also in conditional_fields.js I've added the js from #51/#53 above to hide empty fieldsets on load and form input/select click. Currently only works with field_group display types that output a fieldset tag. This should probably also be extended to bind to input change events, eg. text inputs.

As is, this would probably break if there were field_groups with the same numerical ID as any field IDs. Maybe the 'dependent' column in the conditional_fields table could be changed to VARCHAR and any field group IDs prepended with eg. 'group_'?

The patch also includes the start of another approach using hook_field_group_pre_render_alter that could be used to add states to the fieldset itself (instead of the child elements).

apmsooner’s picture

@bgilhome,

One thing i see with your javascript in that patch is that like some of the other code submitted here:

+      $fieldset.find('.form-wrapper').each(function(){
+        if ($(this).css('display') === 'block'){
+          countShownSubFields++;
+        }
+      });

This assumes the style exists for display:block to get the count however, if there are fields within the fieldset that are not affected by conditional fields, they will not be explicitly set with display:block so your countShownSubFields variable won't include those and thus render the fieldset hidden when it shouldn't be. My code in #63 does a count on hidden and compares to total count to determine if group should hide/show. Also, in cases like field collections, .form-wrapper may exist multiple times within the field so again, my jquery targets with specificity to only count the first instance, otherwise, again your count could get thrown off. Just my $0.02.

bgilhome’s picture

@apmsooner, sure, that js is a little janky - it might be best to use the hook_field_group_pre_render_alter in the patch to add some #states rather than trying to bind to input click/changes and count fields.

bgilhome’s picture

Small fix to set $groups as an empty array if none present in conditional_fields_dependency_add_form.

djween’s picture

Hi,

Thanks for the patch in #94. I received this after I patched...

Notice: Undefined index: dependent in conditional_fields_element_after_build() (line 312 of /xxxx/xxxx/xxxx/xxxx/sites/all/modules/conditional_fields/conditional_fields.module).

Thanks

davidczadilek’s picture

@djween
just patched it myself today and it works just fine
i have a rather complex set up of dependencies by now, so i suppose you either made some mistake while patching or you had a different base
@bgilhome
thanks for the patch. does not work right though

  • only fieldsets are hidden - group fields module also allows divs and other forms of grouping
  • fieldsets with non-hidden "form-wrapper" elements are hidden. addressfield and datefield modules do not have these classes - so they are hidden by default with that patch (#94)

I'm still trying to figure out an alternative way - trying to see how the module shows/hides single fields in the first place - but I havent quite figured it out yet (have only worked with drupal for a few days so far). But if i find a better solution - i'll surely post it.

jrb’s picture

@pmichelazzo
@NancyDru

I was having the same problem as in #52. It wasn't working, and I was getting this notice:

Notice: Undefined index: #id in drupal_process_states() (line 4664 of /includes/common.inc).

The key to fixing it was here:

https://www.drupal.org/node/1053174#comment-9153819

You need to add the #id directly to the fieldgroup array, not as an attribute. Once I did this, it worked as expected.

My function ended up like this:

/**
 * Implements hook_field_group_build_pre_render_alter.
 */
function mymodule_field_group_build_pre_render_alter(&$element) {
  if (!empty($element['group_slideshows'])) {
    $element['group_slideshows']['#id'] = 'group-slideshows';
    $element['group_slideshows']['#states'] = array(
      'visible' => array(
        'input[name="field_allow_slideshows[und]"]' => array('checked' => TRUE),
      ),
    );
  }
}
davidczadilek’s picture

Found another Problem - third-level and higher field groups are not hidden (programmatically).
There's already a ticket in the field-group module, but I think it's this module's part to handle this.

I'll leave it for now - maybe using a workaround to have only second level conditional fields, as I currently have no time to look into it more closely.

Some info that's interesting as well - the fields within that displayed third level group (actually all fields from that form) are all hidden per user role/permissions on the path the problem occurs on.

bgilhome’s picture

I've implemented this a different way, patch attached. Instead of showing/hiding empty fieldgroups via JS, I've used the hook_field_group_build_pre_render_alter (which runs after form's after_build is done) to manually call conditional_fields_element_after_build() for any fieldgroup elements and fieldgroup children elements, and conditional_fields_form_after_build() after that.

This way, #states can get appended to the fieldgroup elements themselves, as well as children of fieldgroups. For fieldgroup dependents using visible/hidden states, the #states gets appended to the fieldgroup element. For fieldgroups dependents with other states, the #states get appended to each (first-level) child of the group.

Although the correct #states are appended, currently the show/hide functionality is not working on the fieldgroup element. Not sure if some js needs to be re-attached or something.

This patch relies on a patch to the field_group module to correctly update the #array_parents for each child of a fieldgroup, to include the fieldgroup parent/s: https://www.drupal.org/files/issues/field_group-update_array_parents-249... in https://www.drupal.org/node/2494385
It uses the updated #array_parents when reprocessing elements with conditional_fields_element_after_build() to get the nested form field in conditional_fields_form_after_build(). NB in conditional_fields_attach_dependency() I've set the 'field_parents' and 'parents' keys to #array_parents if available, I couldn't see any reason not to, perhaps someone can tell me!

bgilhome’s picture

FileSize
10.65 KB
bgilhome’s picture

Some more progress, now the element validate callback is called for each fieldgroup dependent and the form, so that states js is attached to the new dependent fieldgroup elements. Fieldset fieldgroups are shown/hidden fine but plain divs are not - elements of type '#markup' don't get processed for states.

Patch and interdiff from patch in #99 attached.

EDIT: sorry, patch/interdiff should be numbered 101. This patch relies on field_group patch https://www.drupal.org/files/issues/field_group-update_array_parents-249... to update #array_parents & #field_parents on form elements nested in fieldgroups.

bgilhome’s picture

Status: Active » Needs review

The last submitted patch, 91: conditional_fields-fieldgroup_support-1161314-91.patch, failed testing.

The last submitted patch, 94: conditional_fields-fieldgroup_support-1161314-94.patch, failed testing.

The last submitted patch, 99: conditional_fields-fieldgroup_support-1161314-99.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 101: conditional_fields-fieldgroup_support-1161314-100.patch, failed testing.

The last submitted patch, 101: conditional_fields-fieldgroup_support-1161314-100.patch, failed testing.

The last submitted patch, 101: conditional_fields-fieldgroup_support-1161314-100.patch, failed testing.

bgilhome’s picture

Previous patch doesn't apply to current 7.x-3.x head, updated patch attached.

bgilhome’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 111: conditional_fields-fieldgroup_support-1161314-111.patch, failed testing.

david.czinege’s picture

I applied the #111 patch, but it cause a fatal error on the node add form:

Notice: Undefined property: stdClass::$array_parents in conditional_fields_field_group_build_pre_render_alter() (line 244 of /.../conditional_fields/conditional_fields.module).

Warning: array_merge(): Argument #1 is not an array in conditional_fields_field_group_build_pre_render_alter() (line 244 of /.../conditional_fields/conditional_fields.module).

Recoverable fatal error: Argument 2 passed to drupal_array_get_nested_value() must be of the type array, null given, called in /.../conditional_fields/conditional_fields.module on line 245 and defined in drupal_array_get_nested_value() (line 6771 of /.../includes/common.inc).

bgilhome’s picture

Hi @david.czinege, you'll need to also apply the field_group patch https://www.drupal.org/files/issues/field_group-update_array_parents-249... which provides the array_parents property on the group.

alejandrovaquero’s picture

Patch #111 does not work for me when using with Inline Entity Form module:

Notice: Undefined index: #form_state in conditional_fields_field_group_build_pre_render_alter() (line 221 of /var/www/html/sites/all/modules/contrib/conditional_fields/conditional_fields.module).

Fingerlinck’s picture

God! The issue was started on May 18, 2011.

Nique’s picture

While it would be convenient to be able to show/hide an entire fieldset through one dependency, at this point I would be quite content if I could just make the fieldset label not show up unless and until at least one of the fields within that fieldset is made visible.

I am willing to create a separate dependency for each field within the fieldset, but I really don't want a whole bunch of childless fieldset labels cluttering up my node/add form ... spreading confusion and alarm amongst my content creators.

shevgeny’s picture

+1 subscribe
very necessary!

Syntapse’s picture

subscribing. is there a definitive solution to this issue pending and are there plans to update the module?

milos.kroulik’s picture

The patch mentioned in #115 doesn't apply to the latest dev, neither applies the latest patch from the corresponding issue: https://www.drupal.org/node/2494385

EDIT: #97 works fine as a workaround, if anybody needs it

jproctor’s picture

Patch in #111 doesn't find nested field groups. In my case it was possible to move the inner group outside its parent, set it as the dependent on a conditional, then move it back in.

jproctor’s picture

My problem in #121 wasn't actually the nestedness, it was that the field group was created by a feature and was never in the database: it didn't meet the conditions that Field Group module felt was necessary to create a row in the field_group table, and CTools was capable of faking it with the code in the feature. However, CF assumes a numeric dependent id, so patch #111 (and its predecessors) tries to use the id of the row in the field_group table. Loading the featurized conditional field into a clean db failed because the feature stores the correct identifier of the group, but there was no db entry for it so the CF table had a record with a dependent id of 0.

I rerolled #111 against current 3.x-dev and added code to conditional_fields_features_rebuild() to force creation of a field_group row so we can properly create the dependency.

This patch still needs work. Field groups without rows in the db (true in my case whenever there's only one field group in the content type and it was created by a feature) still can't be dependents: the loop that creates the $fieldgroups variable in conditional_fields.admin.inc (lines 233-236 in patched current 3.x-dev) still blindly assumes there's an id field, so can only show one field group (possible to have more than one on the content type if they're nested, but both field groups' id are null so the second overwrites the first) and ends up outputting a select option with a null value in the config form. Probably the thing to do is change that to key on the group identifier and then update conditional_fields_dependency_add_form_submit to recognize when it gets a group identifier and force a save like my hook_features_rebuild() code does.

Wouldn't be a terrible idea to write some tests for all this stuff, too, and add a little "if (module_exists('field_group'))" to keep it from breaking the current tests.

jproctor’s picture

I just had a "how did this ever work" moment with #123 (and its predecessors): on a non-field-group element before the patch, it was finding array('field_foo') as the $dependent_location and worked correctly; after the patch, it was getting array('field_foo', 'und'), which wasn't working. Possibly something else changed in the new version of Field Group module?

Attached patch removes the proposed change to line 514. It still works for me (in my dev environment, anyway) for field-group and non-field-group dependents alike.

Anybody’s picture

Status: Needs work » Needs review

The last submitted patch, 123: conditional_fields-fieldgroup_support-1161314-123.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 124: conditional_fields-fieldgroup_support-1161314-124.patch, failed testing.

giupenni’s picture

FileSize
36.25 KB

#124 patch breaks user/NID/edit page.

anrikun’s picture

You may also review patch at #1903226: When hiding all fields in a fieldset, the fieldset remains, but is empty. it should be hidden too. that hides fieldsets unless one of their fields is visible.

anrikun’s picture

Status: Needs work » Needs review
FileSize
715 bytes

This is the continuation of patch at #1903226: When hiding all fields in a fieldset, the fieldset remains, but is empty. it should be hidden too. as that issue was just marked as duplicate.
This new version should work with nested fieldsets too.

anrikun’s picture

FileSize
708 bytes

Sorry, there was a useless part.
New version here.

sketman’s picture

Patch #131 is working for me, thanks!

sketman’s picture

Status: Needs review » Reviewed & tested by the community
graytoby’s picture

Status: Reviewed & tested by the community » Needs work

Patch #131 is incomplete. It only covers the single case when fieldgroup type is set to fieldset. This has to work for all types.

forestmars’s picture

Patch in #131 is not working for me using 7.x-3.0-alpha2 or 7.x-3.0-dev.

Not sure why, if it was working per #132/#133.

Field group is of type fieldset. No errors in console.

SerkanB’s picture

#131 works for me using 7.x-3.0-alpha2, but indeed doesn't work with groups other than fieldsets.

But if you just have fieldsets... it's great :D thx.

danthorne’s picture

#131 didn't seem to work for me. I ended up just writting a bit of jQuery to target exactly what I wanted to hide:

        if ($('#edit-field-ad-type-und-704').is(':checked')) {
            $('fieldset.group-price').addClass('hide');
        }

        $('.group-ad-type .form-radio').click(function () {
            if ($('#edit-field-ad-type-und-704').is(':checked')) {
                $('fieldset.group-price').addClass('hide');
            } else {
                $('fieldset.group-price').removeClass('hide');
            }
        });
dodozhang21’s picture

Sub...

MatthijsG’s picture

#131 works, but not with -dev

If the fieldset has an description & is open, description and title is showed.
When collapsible, the fieldset react as expected.

Question, why only fieldset? I use mostly Div.
-edit: this patch is not in the latest -dev. I needed the latest dev, because the date-module gave some trouble (theme hook not found etc etc). Updating from Recommendend to -dev helped. But when installing the latest dev, the patch isn't working anymore .. argh

MatthijsG’s picture

When the patch 131 is installed, it breaks the CSS from TAC (and maybe CSS from other modules). See this issue (closed) https://www.drupal.org/node/2816543

Wait, what .. now it's working good with the patch :-( I'm confused right now .. apparentely it's not breaking the CSS and i was wrong.

- edit 2 : however, patch #131 removes the date-field

igonzalez’s picture

+1

sdsheridan’s picture

+1 on this for sure.

I was reviewing the patch in #124, and thought we needed a bit more regarding separating groups. The problem with the patch as I see it is there is a potential collision between field instance IDs and group IDs (i.e., a field instance and a group can have the same ID). So, we still need to differentiate between field and group dependents for this to work properly.

Without adding a column to the table, there is a way to use an attribute in options to do it. I've attached a patch against the latest dev (which includes the portions of the patch in #124, including the ones I had to do manually - the .module ones). This patch:

  1. incorporates the changes of #124;
  2. adds a 'group' attribute to the options array if the dependent in fact refers to a group, maintained through both the add and edit forms for a dependency;
  3. modifies the function conditional_fields_load_dependencies to explicitly separate the fetching of the dependent items and determine if they are field instances or groups, appropriately populating the correct one;
  4. modifies the function conditional_fields_entity_view_alter to hide entire groups upon display; and
  5. introduced functions conditional_fields_hide_group and _conditional_fields_get_all_progeny to aid the hiding.

The hiding on display works, but for some reason, I can't yet get the form to show and hide groups based on a dependee. Has anyone else got that to work?

Shawn

sdsheridan’s picture

Whoops... left out a column in conditional_fields_load_dependencies. The attached fixes that. Also, was getting an undefined field_name error, so changed function conditional_fields_form_after_build to avoid that. However, still not getting my show-hide behaviour on the form... :(

Shawn

guidot’s picture

Status: Needs work » Needs review

Changing to "needs review" to feed testbot.

Status: Needs review » Needs work

The last submitted patch, 143: conditional_fields-fieldgroup_support-1161314-143.patch, failed testing.

TechNikh’s picture

FileSize
29.45 KB

The patch "conditional_fields-fieldgroup_support-1161314-143.patch" resulted in below error as reported by Drulenium visual regression test. Complete report at http://drulenium.org/projects/drupal-module-conditionalfields-7x-3x-desk...

sdsheridan’s picture

sdsheridan’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 147: conditional_fields-fieldgroup_support-1161314-147.patch, failed testing.

hkdorama’s picture

Would be great if somebody got it working. This module really needs this feature...

yogeshmpawar’s picture

Assigned: Unassigned » yogeshmpawar
yogeshmpawar’s picture

Assigned: yogeshmpawar » Unassigned
Status: Needs work » Needs review
FileSize
29.5 KB

Thanks @hkdorama, I have worked on this patch to get apply to latest 7.x-3.x branch.
Used #147 for reroll the patch.

Status: Needs review » Needs work

The last submitted patch, 152: fieldgroup_support-1161314-152.patch, failed testing.

iurisampaio’s picture

Yogesh,
Your path doesn't work successfully.

It would be great if we have the feature/conditional as following:
if hide/show the group field, then all elements must inherit hide/show property.

Best wishes

roflcopterDorrie’s picture

Patch #153 applies nicely to dev however it is throwing fatal errors for me.

Notice: Undefined property: stdClass::$array_parents in conditional_fields_field_group_build_pre_render_alter() (line 238 of conditional_fields/conditional_fields.module).

I looked through the arrays and group doesn't have an array_parents property in my case.

$parents = array_merge($group->array_parents, array($field_name));

The structure of my fields are:
- Vertical tabs group
- Vertical tab
- Field

Hope that helps to debug it

jordanddisch’s picture

Applied patch #152 to 7.x-3.x-dev. I was only able to apply the dependent to a horizontal tab with one tab. After applying the field was not recognised inside as a dependent and showed "()".

Upon editing a node with the field, the edit page gave me an error "The website encountered an unexpected error. Please try again later."

jordanddisch’s picture

joelstein’s picture

I had the same "array_parents" error, but reading a bit further up, it looks like this patch depends on a patch to Field Group: #2494385-11: Should #array_parents be updated in field_group_fields_nest()?

Anybody’s picture

Patch #131 works good as quickfix, but sadly it hides hidden date fields (which have fieldsets as parents).

I solved that problem by adding a check for .field-group-fieldset:

// Hide fieldsets unless one of their fields is visible.
$(document).bind('state:visible', function(e) {
  if (e.trigger) {
  var $wrapper = $(e.target).closest('.fieldset-wrapper');
    if ($wrapper.length) {
      $wrapper.parents('fieldset').show();
      do {
        $wrapper = $wrapper.closest('fieldset.field-group-fieldset').toggle($wrapper.children('.form-wrapper:visible').length > 0).closest('.fieldset-wrapper');
      } while ($wrapper.length);
    }
  }
});
Anybody’s picture

Patch #160 based on #131 as quickfix attached.

Anybody’s picture

FileSize
707 bytes

SORRY #160 is broken due to a git mistake I made. Correct quickfix version based on #131 concerning problem in #159 attached.

Anybody’s picture

Status: Needs work » Needs review
FileSize
728 bytes

I need holidays...

Status: Needs review » Needs work

The last submitted patch, 162: hide_empty_fieldsets-1161314-162.patch, failed testing.

delacosta456’s picture

hi the patch failed for me too

diff --git a/js/conditional_fields.js b/js/conditional_fields.js
|index 6853f84..a4615b9 100644
|--- a/js/conditional_fields.js
|+++ b/js/conditional_fields.js
--------------------------
Patching file js/conditional_fields.js using Plan A...
patch unexpectedly ends in middle of line
Hunk #1 FAILED at 141.
1 out of 1 hunk FAILED -- saving rejects to file js/conditional_fields.js.rej
yogeshmpawar’s picture

Status: Needs work » Needs review
FileSize
729 bytes

Updated patch because #162 failed to apply on 7.x-3.x branch.

delacosta456’s picture

hi @yogesh-pawar, i just apply the patch and it successfully applied .. however i can't see any of my fieldset group in both dependent and dependee list ?

AaronMcHale’s picture

#166 works for me, thanks for the patch :)

AaronMcHale’s picture

Status: Needs review » Needs work

If a field group fieldset is collapsed by default on a form, even if it has visible elements inside it this patch will cause it the fieldset to be hidden from the form.

delacosta456’s picture

hi @AaronMcH yes .. trully..
A work arround that worked for me , was to also set a kind of "visible" visibility rule for those field ,,, and so they stay visible with the fieldset while others a hidden...

Fool2’s picture

My standard node form is messed up from applying only #166... Fieldset with standard node fields is automatically hidden when I open the page. This might be because there are no dependencies set on any of those fields.

totolearn’s picture

Same situation as #167, applied the patch #166 but not fieldgroup listed neither dependant nor dependee

yazzou’s picture

Same for me...it appears nowhere

mocasalter’s picture

Same. Applied the patch from #166, still not seeing fieldgroups.

Edit: Or maybe the patch does kind of work? Fieldgroups aren't listed in the Dependency dropdowns, but if all of a group's fields are hidden by conditionals, then the group itself is also hidden. Without the patch, the group title and container still show even if its fields are all hidden.

karltud123’s picture

subscribing

djdevin’s picture

Yes, that's what the patch in #166 does.

So if you set all your fieldgroup's fields to be conditional, the fieldgroup will disappear if there are no visible fields inside. Seems to work very well here!

oschuetze’s picture

Could you please also add similar code for grouping via "div"? Something like

// Hide field-groups unless one of their fields is visible.
$(document).bind('state:visible', function(e) {
  if (e.trigger) {
    var $group = $(e.target).closest('.field-group-div');
    if ($group.length) {
      $group.show();
      $group.toggle($group.children('.form-wrapper:visible').length > 0).closest('.field-group-div');
    }
  }
});
museumboy’s picture

Patch #166 worked for me however I needed to change

$wrapper = $wrapper.closest('fieldset.field-group-fieldset')

to

$wrapper = $wrapper.closest('fieldset.form-wrapper')

There is no 'field-group-fieldset' class called on my fieldset for some reason. Look at your html to see if the class exists.

Of course I could leave this code as-is and just add 'field-group-fieldset' as a class to anything I wanted hidden.

museumboy’s picture

Is there a nice way to rehide the fieldset if the child field is no longer checked?

museumboy’s picture

I've encountered two issues with #166.

1. This doesn't work if you're using a multipage group form. That is because the multipage is itself a fieldset. To better select the correct fieldset in #166 I've added changed:

var $wrapper = $(e.target).closest('.fieldset-wrapper');
to
var $wrapper = $(e.target).closest('fieldset.hideme .fieldset-wrapper');

I additionally have to include the fieldset.hideme class in the lower line:

$wrapper = $wrapper.closest('fieldset.hideme').toggle($wrapper.children('.form-wrapper:visible').length > 0).closest('.fieldset-wrapper');

This will only work if you add the class hideme to the fieldset in manage fields.

2. The fieldset will only disappear when you uncheck your dependant field if the Effect is set to show/hide. It will not disappear if you've selected fade in/Fade Out.

If you want the fieldset to fadein change this line:

$wrapper.parents('fieldset').show();
to

$wrapper.parents('fieldset').fadeIn();

I hope this helps anyone troubleshooting.

shenzhuxi’s picture

With current conditional_fields module, If DEPENDENT is a required field, it can be skipped if it's not visible by DEPENDEE (https://www.drupal.org/project/conditional_fields/issues/1561272).
With patch #152, if DEPENDENT is a field group with required fields in it, the form will not pass the validation if the fields are not visible.

To make patch #152 pass the test, you need to put field_group module to conditional_fields.test file
parent::setUp('conditional_fields_test', 'list', 'text', 'number', 'taxonomy', 'image', 'field_group');

TLWatson’s picture

FileSize
737 bytes

Here is a patch along the lines of #166. The way I wrote it:

  • Places the binding in a more appropriate spot in the file
  • Due to placement, will currently work with either alpha2 or dev
  • Shows all parent fieldsets if the trigger value is true, which fixes the "can't unhide" problem
  • Applies to all parent fieldsets (checks all child fields irrespective of hierarchy - if one field is made visible, you want all its parents to be visible too)
  • Checks for all show/hide element types compatible with conditional fields

It is written for the fieldset group type, dependent on the 'field-group-fieldset' class (which is on fieldsets by default, but you are able to remove). Unfortunately there is no catch-all element or class that will work for every fieldgroup or setting.

miksha’s picture

@TLHenriksen I have applied only your patch and the behavior I get is next: When I have few fields under fieldset, and e.g. one of them is hidden based on field condition that is outside of the fieldset, whole fieldset is not shown at initial form view. Then when I check option that triggers the hidden field to be shown, the fieldset and the rest of the field are shown. Choosing another option then hides only field that should be hidden from within the fieldset, and fieldset and the rest of the fields that should always be visible, remain visible as they should.

yzan’s picture

Hello,
+1
This module will become bigger the day of adding this feature ...
Good work!

calefilm’s picture

hello @miksha,

It would be helpful if you were more precise in your setup... with actual field labels and fieldgroup labels and outcome of each input. Thanks

W01F’s picture

+1 for D8 support for the same

Publishing Future’s picture

+1 for D8 support for the same

Pancho’s picture

Version: 7.x-3.x-dev » 8.x-1.x-dev
Status: Needs work » Active

Why is this feature request still in the D7 branch anyway?

tim-diels’s picture

Latest patch (#182) is working but you need to make sure the class 'field-group-fieldset' is present on the fieldgroup. I had to add them myself trough the view display, as latest version of fieldgroup does not prints out the class or this is project specific. So not sure if the patch is 100% correct, but working for me.

geefin’s picture

Is this working with Vertical Tabs? I've done all the patches and sub-patches and I receive no errors, no console errors and can set the dependencies. However, it doesn't show/hide the vertical tabs, only fieldsets and individual items.

coreteamvn’s picture

#51 and 53 didnt work, but the suggestion in #97 (adding the id) finally worked

justcaldwell’s picture

#182 worked great for me (thanks @TLHenriksen!), and applied to -alpha5 just fine. (I couldn't replicate the problem described by @miksha in #183)

I'm using field_group-8.x-3.0-beta1. Seems like that version does output the field-group-fieldset class by default, because I didn't have to add it (re: #189).

marieAscomedia’s picture

I'm using field_group-8.x-3.0-rc1 and conditional_fields-8.x-1.0-alpha5 and I'm not able to see any group in the 'target field' on the page 'manage dependencies' of my content type.
I have tried to adapt patch #152 but it doesn't change anything.
How do you achive that ?

Andrew Answer’s picture

Re-rolled patch #182 to the last version of module and tested it with field_group-8.x-3.0-beta1. Important note: if you use "required" fieldset you have class "field-group-fieldset", but if you disable "required" checkbox, you need to add that class in Extra CSS classes.

colan’s picture

Status: Needs review » Needs work

This behaviour isn't very intuitive, having to select each field group's children in the "Add new dependency" field. It also gets very complicated with nested field groups.

Can we redo this to actually list the field group names for selection in the "Add new dependency" field?

If this should really be done in the other module, then let's add any missing hooks that would be needed.

agudivad’s picture

Uploaded patch for alpha6 version.

agudivad’s picture

ergonlogic’s picture

On complex entity forms, the Conditional Fields configuration can quickly get unwieldy. To @colan's point, it's unintuitive to have to set conditions on each field inside of a field group, to achieve what should be fairly straight-forward. Does the Form States API not work with field groups, or something?

At least when it comes to visibility, it seems to me that we should be able to just set the desired states on field group fields. If this doesn't achieve the goal of also controlling the visibility of child elements, we should be able to iterate over those elements in ConditionalFieldsFormHelper::afterBuild() and apply the same state to the field group's children.

I guess the first step would be to confirm the behaviour of the Form States API when trying to set the visibility of a field group.

ergonlogic’s picture

In the attached patch, we basically just add groups to the list of fields available in the "Target field" and "Control field" lists. We also had to tweak the validation callback a bit, since group objects aren't full fields, and thus don't have an isRequired() method.

colan’s picture

ergonlogic’s picture

Title: Fieldgroup support » Field Group support
Status: Needs review » Active

Since the tests for #199 pass on the D8 stable release, and fail similarly for a JS-only patch (#197), I'm pretty sure those failing tests are not directly related to anything in this patch.

In a offline discussion w/ @colan, we agreed that it'd be worthwhile to try to implement some form of "inheritance" for fields inside of field groups. Basically, the way this would work is as follows:

  1. current behaviour: field_group elements cannot be selected as either a "target" or a "control" field.
  2. behaviour w/ patch from #199: field_group elements can be selected as either a "target" or a "control" field.
  3. proposed behaviour: when a field_group element is selected, provide a checkbox with something like "This element contains other fields. Apply these settings to the contained fields instead of this one."
  4. proposed re-factoring: instead of natively supporting field_group elements (using module_exists()), turn that into a hook that'll allow any module to register new type of "target" and/or "control" fields.
ergonlogic’s picture

I added #3099051: Conditional Fields support for the hook implementations in field_group that'll be needed for the re-factoring mentioned in #201.

ergonlogic’s picture

This patch moves the generation of the list of fields into a hook, and then implements the hook on behalf of the core Fields module. This will allow a similar patch in #3099051: Conditional Fields support to do likewise for field_group.

colan’s picture

Status: Needs review » Needs work

Code looks good; here are some minor formatting notes:

+++ b/conditional_fields.api.php
@@ -0,0 +1,49 @@
+ * @param string $entity_type
+ *   Name of the entity type being configured.
+ * @param string $bundle_name
+ *   Name of the entity bundle being configured.
+ * @return array Fields provided by this module.
+ *   Keyed by machine name, with field labels as values.

Would be good to add a line break before the `@return`.

+++ b/src/Form/ConditionalFieldForm.php
@@ -61,12 +82,15 @@ class ConditionalFieldForm extends FormBase {
+  public function __construct(Conditions $list, EntityFieldManagerInterface $entity_field_manager, EntityTypeManagerInterface $entity_type_manager, UuidInterface $uuid, ModuleHandlerInterface $module_handler) {

Let's break this up; one per line.

ergonlogic’s picture

@colan I've fixed the style issues, per your comment.

Currently that behaviour remains mostly unchanged from #199. That is, instance of group fields can be selected as both dependent and dependee in conditional field relationships.

The only visible change since then is the addition of an "Inheritance" field on conditional fields config forms. This is basically just a checkbox labeled "Propagate settings to fields contained within this one.". Its description reads "This element contains other fields. Apply the settings in this form to the contained fields instead of this one."

That said, under the covers, I've refactored how dependencies are resolved to be OOP, while maintaining identical behaviour and data structures. With that now in place, we'll finally be able to move on to implementing the behaviour that the new setting promises.

The last patch, from #203, failed to apply, since it builds on the patch in #3077803: Make ConditionalFieldsFormHelper class instantiable. As such, the patch attached here includes those changes, until such time as that's merged into the 8.x-1.x branch.

For those following along at home, you can use the issue-3099051 branch from our fork of field_group, along with the issue-1161314 branch from our fork of conditional_fields, to test the new behaviour.

ergonlogic’s picture

This patch (finally) introduces the inheritance of Conditional Field settings to fields contained within Field Groups. It introduces 2 hooks useful for enabling this functionality (along with their corresponding _alter() hooks):

/**
 * Build a list of available fields.
 *
 * Fields that use the Field API should be available to Confitional Fields
 * automatically. This hook provides a mechanism to register pseudo-fields
 * (such as those provided by Field Group.)
[...]
 */
hook_conditional_fields($entity_type, $bundle_name) {
[...]
}

/**
 * Return a list of fields contained within a given field.
 *
 * Various modules provide fields that themselves contain other fields (e.g.,
 * Field Group, Paragraphs, etc.) This hook allows those modules to provide the
 * logic necessary to determine which fields are contained within such a field.
[...]
 */
hook_conditional_fields_children($entity_type, $bundle_name, $field) {
[...]
}

I'll upload a patch to #3099051: Conditional Fields support shortly that implement these.

Next steps are to get some testing/feedback, and add a couple enhancements that I've noted as @TODOs in the code:

// @TODO Add setting to allow the conditional field to apply to the parent.
[...]
// @TODO Add setting to allow recursion on those fields that'd support it?
[...]
// @TODO Fix that [inheritance] currently overrides whatever settings already exist in the [inheriting] field's config.
ergonlogic’s picture

This patch resolves the remaining TODOs listed in #206. That is fleshing out inheritance behaviour.

I also traced how and when dependencies are resolved, and determined that the we currently always call this with a bundle. As such, I was able to simplify the code somewhat. The legacy code implied that we'd sometimes be returning all dependencies for an entity type, or even all dependencies across all entity types and bundles. Should we ever need this functionality, we can now build it up by iterating over individual bundles,

ergonlogic’s picture

I re-rolled this patch to apply atop the one in #3077803: Make ConditionalFieldsFormHelper class instantiable, as that should be merged soon. The inderdiff I've uploaded here compares the current patch against the one in #203.

  • ergonlogic committed 35edf15 on issue-1161314
    Issue #1161314: Add setting to allow recursion on those fields that...
  • ergonlogic committed 48681e3 on issue-1161314
    Issue #1161314: Add hook to determine the fields that should inherit...
  • 5f7162f committed on issue-1161314
    Issue #1161314: Merge branch '8.x-1.x' into issue-1161314
    
    Resolved...
colan’s picture

The other issue is now in, and this one now passes tests. This still needs manual testing, but here's a code review.

  1. +++ b/conditional_fields.api.php
    @@ -0,0 +1,111 @@
    + * Fields that use the Field API should be available to Confitional Fields
    

    Typo.

  2. +++ b/conditional_fields.api.php
    @@ -0,0 +1,111 @@
    +  // Do something with the children fields.
    

    "children" -> "child"

  3. +++ b/config/schema/conditional_fields.schema.yml
    @@ -56,3 +56,16 @@ conditional_fields.settings:
    +        propagate:
    +          type: string
    +          label: 'Propagate settings to fields contained within this one.'
    +        apply_to_parent:
    +          type: string
    +          label: 'Apply these settings to the this (parent) field also.'
    +        recurse:
    +          type: string
    +          label: 'Apply these settings to group fields contained within this one.'
    

    Shouldn't these be boolean?

  4. +++ b/src/DependencyHelper.php
    @@ -0,0 +1,273 @@
    +    $this->module_handler = \Drupal::moduleHandler();
    

    Dependency injection would be nice, but let's save that for a follow-up.

ergonlogic’s picture

Fixed typos (#1 & #2).

Re. #3, No, 'string' is correct there. I know it's counter-intuitive, and this had me scratching my head for a while. But values of checkboxes are an array of strings, where 'checked' is represented by the key name, and unchecked is 0.

Re. #4, agreed, it'd be nice, but can come later.

liquidcms’s picture

This sounds awesome guys; but can someone suggest what is all required here? I assumed the forks of both modules pointed to in #205 is updated with all the patches. Using these i had expected to see my Field Groups listed under Manage Dependencies -> Target Field.. but no luck.

Is there some other combination of forks/patches required here?

colan’s picture

  1. Either:
    • Update this module to the latest on the Dev branch and apply the above patch, OR
    • Switch to the issue-1161314 branch instead.
  2. Apply the latest patch from #3099051: Conditional Fields support to that module.
  3. Report back here after trying it. :)

Those forks aren't necessary anymore as @ergonlogic is now a maintainer and can push branches.

liquidcms’s picture

Thanks Colan, yes, getting -dev for both and applying latest patch to each, does work. :)

Getting 2 forked versions doesn't work.

liquidcms’s picture

Perhaps i spoke too soon. I was just happy to see the Field Group listed in the Targets; but when adding a dependency i get:

Notice: Undefined index: group_additional_coverages in Drupal\conditional_fields\Form\ConditionalFieldForm->validateForm() (line 170 of modules/contrib/conditional_fields/src/Form/ConditionalFieldForm.php).

but does seem to be working. :)

liquidcms’s picture

I am now seeing this Notice on the main Manage Dependencies page, the dependency setting page as well as the node entity form.

Notice: Undefined index: 9f8deb7c-f0df-422f-a95c-4f8fcc478a2c in Drupal\conditional_fields\DependencyHelper->getInheritingFields() (line 144 of modules/contrib/conditional_fields/src/DependencyHelper.php).

liquidcms’s picture

also, this doesn't work for ORed fields.

2 different Control fields (checkboxes) set to show a field group as visible; but only 1 of the set of checkboxes shows the field group.

liquidcms’s picture

Status: Needs review » Needs work
Kris77’s picture

This is what I did:

As well as @liquidcms, when adding a dependency I get this Warning/error:

"Undefined index: group_xxxxxx in Drupal\conditional_fields\Form\ConditionalFieldForm->validateForm() (line 170 of modules/contrib/conditional_fields/src/Form/ConditionalFieldForm.php)."

but it still works.

  • fcf05f8 committed on issue-1161314
    Issue #1161314 by colan: Ensure that there's a field instance before...
colan’s picture

This latest patch fixes #215/#219.

Things seem to work well in my tests, but we're not using OR (#217).

Temporarily setting to Needs Review to trigger the testbot, but this needs to go back to Needs Work afterwards.

As this now works for our purposes, we won't be doing any more on this right now. So, anyone else, feel free to continue the work here for fixing #217 (or anything else that may not be working yet).

As this refactoring lays the groundwork for handling other types of groups (e.g. Paragraphs), we should postpone those other issues on this one. I'll do that for the ones I can find, but please do so for any others I've missed.

colan’s picture

Issue summary: View changes
Status: Needs review » Needs work

Added "Remaining tasks" to IS.

kreatIL’s picture

Finally got the patches working, which is the latest patch from #3099051: Conditional Fields support and the latest patch from this issue.

Now I see the Fieldgroup elements of the form display in the list for the target field. But the Fieldgroup elements of the frontend displays are still missing. In Drupal 7 there was no separation between edit form and frontend displays. But the functionality of this module was there for Fieldgroups also on the frontend side.

@colan, @liquidcms, @ergonlogic, @all:
What else would have to be done to be able to address the Fieldgroup elements on the frontend displays as well?

colan’s picture

-

colan’s picture

#223: When you say "frontend displays", are you talking about what shows up on the content View tab (not the Edit tab), that which is controlled by the Manage Display tab in Structure -> Content types?

If so, that's a separate issue: #3009641: Fields that are hidden on node form show up on node display.

colan’s picture

Here's a reroll for the latest HEAD (and today's new alpha release). Sorry; there's no interdiff as the different baselines are causing the command to fail.

As I started working with nested field groups, I ran into this, which you may notice if you're doing the same thing. This was happening in the previous patch as well:

Undefined index: 03496505-9758-4154-9133-7ac8e713255d+group_machine_name in Drupal\conditional_fields\DependencyHelper->getInheritingFields() (line 144 of /path/to/drupal/web/modules/contrib/conditional_fields/src/DependencyHelper.php)

I'll dig into it shortly.

nuez’s picture

FileSize
1.21 MB

I've tested this and with the two patches mentioned above for both modules it seems to work correctly with field groups in just one level.

However it doesn't seem to work entirely when there are multiple levels of groups, e.g:

- Tabs
-- Tab A
--- Control field 'test' (select list with Yes/no)
-- Tab B
--- Target field

I create one dependency with target field 'Tab B' and the control field 'test'. I check all the boxes for propagating the settings to the fields contained within the tab.

After selecting the right option in the control field, the target fields appear in the field group 'Tab A'

I hope the screenshot helps.

colan’s picture

Issue summary: View changes

Updated remaining tasks in the IS.

colan’s picture

Assigned: colan » Unassigned
Issue summary: View changes
FileSize
607 bytes
28.44 KB

This should fix #226.

nuez’s picture

Thanks for the work on this!

I've also found that when you create a target field group of type 'HTML Element' with 'Show label' set to TRUE (H3 element) that the label always shows, even though the rest of the field group is hidden.

colan’s picture

#230: Please add that to the issue summary (IS).

However, it's starting to look like there are a lot of edge cases and this issue is already quite long. Maybe we should rename it to "Add basic Field Group support", commit the above patch (assuming there are no major problems and someone other than me RTBCs it), and then we create a follow-up meta issue for everything else? Thoughts? Otherwise, we're never going to get this in.

Squiggles’s picture

This feature is a Godsend! Thank you, and looking forward to the stable release.

delacosta456’s picture

hi @colan

i agree with your idea.

colan’s picture

Title: Field Group support » Add basic Field Group support for ANDing conditions
Issue summary: View changes

Thanks for the feedback.

Please create new tickets for the follow-ups I've listed in the IS. I've narrowed the scope here.

Let's see if we can get tests working, and then we can commit. There are some failures related to this issue (I may have used some too-recent PHP features), but the branch is also failing. See #3134183: Functional JavaScript tests are failing for details; help from front-end folks would be greatly appreciated.

See https://www.drupal.org/pift-ci-job/1676469 for what's left to fix here.

nuez’s picture

I don't understand enough of the patch provided in #229 to really properly review it, but I've found the following:

  1. +++ b/conditional_fields.module
    @@ -225,56 +248,14 @@ function conditional_fields_element_after_build($element, FormStateInterface &$f
    +  static $dependency_helper;
    +  if (!isset($dependency_helper)) {
    +    $dependency_helper = new DependencyHelper($entity_type, $bundle);
    

    This assumes that the only one DependencyHelper for one entity type and bundle is needed per request.

    If we are to support inline_entity_form we need to change this so it's statically cached for different entity types / bundles.

    See https://www.drupal.org/project/conditional_fields/issues/2856720#comment...

  2. Failing tests: It looks like ConditionalFieldDateTimeTests::testVisibleValueWidget() is failing, but it also fails without the patch. So probably unrelated.
    ConditionalFieldTextTextareaTest::testVisibleValueXor() fails in the testbot but not locally. I doubt if it's related.
colan’s picture

Issue summary: View changes

Thanks for the review. Updated IS.

nuez’s picture

DesignWork’s picture

I can help with the testing, what is needed?
Is this patch already applied to dev?

Cheers

Dirk

colan’s picture

Please test and review the code. Once successful, then we can commit it. Thanks!

mparker17’s picture

Looks like Testbot is running with Drupal core's minimum system requirements (as of 8.7.0), i.e.: PHP 7.0, which doesn't support nullable argument specifiers, e.g. ?string

So here's a patch that is compatible with 7.0. I added a docblock to the function so development environments will know the argument must be null|string.


Anyone who wants to help, please read / review the patch and provide feedback, and also test the patch and report if it works. If it passes your code review and tests seem to indicate it is working, then you can mark it as RTBC and the module maintainer(s) can commit it.

mparker17’s picture

Not exactly how I got that wrong; but here's the patch from #241 re-rolled onto commit 1d4c7ac

Since this is a re-roll with no changes, there is no interdiff.

sassafrass’s picture

Thank-you to all for contributing! Very much appreciated!

I am testing using the following:

Drupal core 8.9.8
Field Group 8.x-3.1

In my composer.json:

"drupal/conditional_fields": "1.x-dev@dev"

"patches": {
            "drupal/conditional_fields": {
                "Add Fieldset support": "https://www.drupal.org/files/issues/2020-10-09/conditional_fields-support_field_group-1161314-242.patch"
            },
  • I am not seeing any options in the Target Drop Down for Fieldset Groups; groups can't be selected.
  • Fieldset Groups have the class field-group-fieldset automatically being applied as expected.
  • Configuring all fields in the Fieldset to be dependent on the Control field works as expected for the individual fields only, but not for the group as a Fieldset. In other words, the fields show/hide as expected but the Fieldset is unaffected.
josephleon’s picture

I tested the patch from #242 and everything worked. I had a field group of type "Details" which had 2 "Controlled by" fields. One was a select list and the other was a text field, both pointing to the field group using the AND condition. When I select the proper value and input data to the text field the field group will show. Initially the field group is hidden.

josephleon’s picture

@sassafras I see you are using a dev version of conditional fields. In my composer.json I am using "drupal/conditional_fields": "^1.0" and it works. Also my patch is setup differently from yours:

"drupal/conditional_fields": {
                "1161314-242: Add basic field group support for ANDing conditions": "https://www.drupal.org/files/issues/2020-10-09/conditional_fields-support_field_group-1161314-242.patch"
            }

Also have you updated composer?

josephleon’s picture

Status: Needs review » Reviewed & tested by the community

  • colan committed 0f0da2a on 8.x-1.x authored by ergonlogic
    Issue #1161314 by ergonlogic, bgilhome et al.: Added basic Field Group...
colan’s picture

Issue summary: View changes
Status: Reviewed & tested by the community » Fixed

Thanks all!

I'm fine with moving that final future-proofing subtask to #2856720: Support for Inline Entity Form, as that's where it's actually needed. Comment added over there.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

welly’s picture

I'm wondering if this only works on certain field group types because the "Detail" field groups I'm using doesn't display in the "target" select list.

I think I must be misunderstanding what this patch does but I was under the impression that the "target" drop down would list field groups as well as fields and you could trigger the visibility of the group based on another field?

Kris77’s picture

@welly you have to apply this patch for field_group module: https://www.drupal.org/project/field_group/issues/3099051

fmcmullen made their first commit to this issue’s fork.

ethanbb’s picture

Is this still a problem for some field group widgets, specifically tabs?

I'm using Conditional Fields 4.0.0-alpha1 and Field Group 3.2.0. I selected a group displayed as tab as the dependent and a field from another tab as the dependee, and under inheritance I have "Propagate settings to fields contained within this one" and "Apply these settings to the this (parent) field also" selected.

This is what I see in the inspector - content of the tab is hidden with the data-drupal-states attribute (first image). But the tab itself has no such attribute (second image).