Skip Navigation

[Resolved] Hiding filter labels if no choices are available

This thread is resolved. Here is a description of the problem and solution.

Problem:
How to hide filter labels if there are no options (checkboxes) available to filter by?

On the client site a View includes filter controls which in some circumstances may not have any available options, and the filter label should be hidden in such circumstances.

Solution:
Some custom JS needs adding which effectively checks the filter markup to determine whether a given label is followed by a filter control or not and can hide the label accordingly.

Examples are given below (the exact code will depend on the filters and their settings).

This support ticket is created 6 years, 5 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 7:00 – 14:00 -
- 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 15:00 – 16:00 -

Supporter timezone: Europe/London (GMT+00:00)

This topic contains 2 replies, has 2 voices.

Last updated by scottL-3 6 years, 5 months ago.

Assisted by: Nigel.

Author
Posts
#953776
Screen Shot 2018-07-23 at 1.34.45 PM.png

Tell us what you are trying to do?
I have two filters for color and shape that use custom taxonomies on products. Not all product categories use these taxonomies. I have one product category view that displays products from the category of the current page (it is used on product category archive pages).

Views only shows terms that will result in products being found. That is good.

I'd like to not show the label ("Colors" or "Shapes") for a group of checkboxes if there are 0 checkboxes shown.

Is there a built-in way to do this with Views?

If not, is there a way to hook the ajax events that prevent terms with no associated products from showing and use that to hide / show the label(s)?

Is there any documentation that you are following?
Couldn't find anything about this in the documentation or support forums.

What is the link to your site?
hidden link (this page has products using the terms so if you show the filters, you'll see checkboxes).

hidden link (this page has products that don't use the terms so if you show the filters, you'll see the labels for Shape(s) and Color(s) but there are no checkboxes. There should not be checkboxes so that part is okay. The problem is that the labels still show, confusing the user. It looks like something is broken, not like there aren't any relevant filters to use. We'd like to suppress the labels in this case.

#954380

Nigel
Supporter

Languages: English (English ) Spanish (Español )

Timezone: Europe/London (GMT+00:00)

Hi Scott

I'm not sure why you are adding a View to the product category archive rather than just adding custom search directly to the custom archive, which is what I've done in my local test, but I think you should find the same if you add a View to the custom archive.

The markup for filters with checkboxes looks like this in my example:

<div class="form-group">
	<label class="js-target">Colors</label>
	<div class="checkbox"><label for="color-yellow"><input type="checkbox" id="color-yellow" class="js-wpv-filter-trigger" name="wpv-color[]" value="yellow">Yellow</label></div>
</div>

Note that where the filters are inserted I have added a class "js-target" to the label(s) I will want to hide.

So the solution is fairly simple, you just need to check whether such labels are followed by a div.checkbox or not, and if not hide the label.

Here is the basic solution for when the page loads.

( function( $ ) {
	$( document ).ready( function(){
		
      let checkbox = $('.js-target + div.checkbox');
      
      if ( checkbox.length == 0 ) {
        $('.js-target').hide();
      }

	});
})( jQuery );

I wasn't sure whether the situation would arise where you might also need to do the same when applying other filters and the results update, but if you do you can use the custom JS event js_event_wpv_parametric_search_form_updated (which you can insert boilerplate code for using the Frontend events button in the custom JS section).

You would effectively need to duplicate the above, but also show the label if checkbox.length > 0 in case it had been previously hidden.

If you get stuck with that let me know.

#954410

Thanks Nigel. I have br's after my labels followed by inline-block (horizontal) checkboxes so had to modify your selector slightly and I need to treat the two filter options separately and then hide the show / hide filter link if there are no options so I expanded your example a bit by adding a class of "hide-if-empty" to the show / hide link (the entire filter is in a div that is hidden by default so hiding the show / hide link takes away the ability to show the filters if there are none):

( function( $ ) {
    $( document ).ready( function(){
      let checkbox1 = $('.js-target1 + br + div.checkbox');
      let checkbox2 = $('.js-target2 + br + div.checkbox');
      if ( checkbox1.length == 0 ) {
        $('.js-target1').hide();
      }
      if ( checkbox2.length == 0 ) {
        $('.js-target2').hide();
      }
       if ( (checkbox1.length == 0) && (checkbox2.length == 0) ) {
        $('.hide-if-empty').hide();
      }      
    });
})( jQuery );

This is working well for our need.

In my case, a given category either will or will not have values for either filter option (shape or color) so I'm not worried about unhiding the label if a choice in one option causes choices to become available in the other option. When one option has choices the other always has at least one choice so there's no need to dynamically hide and unhide the color and shape labels based on user interaction. It is just a matter of what product category is being displayed.

The only reason I'm using a view instead of adding the search to the archive directly is because I use the view elsewhere and didn't want to have to synchronize changes between two different solutions in different parts of the site.