Skip Navigation

[Resolved] Taxonomy filter doesn’t contain all items

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

Problem:
What does the Custom Filter ShortCode attribute hide_empty do, in a View displaying a Custom Filter for a Taxonomy?

Solution:
https://toolset.com/forums/topic/taxonomy-filter-doesnt-contain-all-items/#post-590257

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
- - 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00
- - - - - - -

Supporter timezone: Asia/Ho_Chi_Minh (GMT+07:00)

This topic contains 10 replies, has 2 voices.

Last updated by yvesM 6 years, 5 months ago.

Assisted by: Beda.

Author
Posts
#588687

Hi,
I have a taxonomy filter (dropdown singles select) included in a custom archive for a custom post type.
The purpose is to have all possible options of the taxonomy shown.
I see that the content of the dropdown filter is limited to the filter conditions set. (for a test I enlarged the selection and saw all the possible items).
I found some article
https://toolset.com/forums/topic/display-parametric-search-select-field-without-resizing/
When I add the filter for the taxonomy the option (hide_empty) is not available.

I also see in wpv-control there is the option hide_empty, but setting this to true or false doesn't change a thing.

How can I create a taxonomy dropdown filter option with all the items of the taxonomy, no matter the other filter conditions.

#588763

That thread is related to a Post View, not an archive.

And, it is an older post.

Nowadays you will insert the Taxonomy Custom Filter, and then in the Custom Search Settings you will choose "Let me choose individual settings manually".
There, follow with "Which options to display in the form inputs > Always show all values for inputs"

That is the same on Views and Archives.

This will allow you to see all options even if the terms are not attached to any post.

#588777

Thanks for explaining that difference.
I found the options.
Only thing that now it is all or nothing?
Can we make a choice on which inputs to show only the related or all options?

Other things is what I still see...
I use the taxonomy (locations) for 2 different custom post types (events and jobs).
I thought with this behaviour, that the show all options, would show only all available options for which i'm building the view.
I'm building the view for events, and not all locations are associated to the events. Some to events and some only to jobs.
But the taxonomy (location) only applying to the events, also show in the location taxonomy filter dropdown, when selecting the show all option...
Any approach for that?

#588788

That was always an "all or nothing" setting.
It was never possible to only show a "few" chosen terms.
That will also not be possible in future, as it is not what a custom search is intended for.

When a Post Type has a Taxonomy attached, it will either display all those terms, or only the ones where you attached posts (of the currently queried one).

#588804

That's clear, and I can just agree with this approach.

What I meant was not for 1 individual filter control all or nothing, but applying to all controls in the filter.

for example I have 4 filter elements in the filter
I want to show all items for control 1 & 2, and for control 3 & 4 only the ones used.
In the past with the shortcode hide_empty option, this was possible.
With the today custom search setting, you have to choose whether you want all options for all 4 controls or only the ones used for all 4.

#588805

I understand.

The hide_empty still works just fine.
I tested with Tags and Categories:

<div class="form-group">
	<label>[wpml-string context="wpv-views"]Categories[/wpml-string]</label>
	[wpv-control-post-taxonomy taxonomy="category" type="select" default_label="jj" url_param="wpv-category" hide_empty="true"]
</div>
<div class="form-group">
	<label>[wpml-string context="wpv-views"]Tags[/wpml-string]</label>
	[wpv-control-post-taxonomy taxonomy="post_tag" type="select" url_param="wpv-post_tag" hide_empty="false"]
</div>

I get exactly only used categories and ALL tags.

In Custom Select Fields as example you can never show all possible options as they first need to be saved somewhere.
Hence those Fields always display only the existing ones.

Does this not work for you?

#588813

Thanks for doing the tests.
I didn't try it that far.

What takes priority?
The custom search settings or the hide_empty setting at the shortcode level.
I think if no hide_empty specified, the custom_search settings are applied.
...

#588910

Hi,

It came clear where I had a wrong understanding of the hide_empty.
It is exactly what is says (hide the empty ones, where no post attached to).
So I got confused, because I use the taxonomy (categories) for multiple custom post types (events, posts, jobs).
And I'm building one screen for that 1 custom post type (events).
My intention here is to only show the taxonomy (category) items that apply for the events.
So in case the taxonomy is not assigned to an event, but to one of the two other, it shouldn't show in the filter control.

How can I achieve this?

#589482

I confirm that this happens, but in my opinion this is a BUG.

If I say, a View queries Post Type A, and it should show only terms assigned to some of those posts, well, then that is what I expect.
I do not include the OTHER Post Type in this View, but still the Terms of the shared Taxonomy are handled as if they would be added to this very same Post Type, which is simply wrong, at least from the User point of view, it might be reasonable from the Query Point of View (since we just check where the term is used, not if that also matches the post type)

The reason is most likely performance. But - no matter what, it is not what you expect when you use the Plugin.
So, I need to report this.

I have no solution to provide. It would mean to change the core code or apply Custom Code, which somehow defeats the entire purpose of Toolset.

Please allow me and my Team to figure out a reliable solution.

Thank you for your patience.

PS:
The solution is to NOT use hide_empty attribute, but the global settings in Custom Search Settings > Which options to display in the form inputs:
- Show only available options for each input

This will do the exact expected job. But it is a GLOBAL setting, as we already discussed.
This is the only solution that I can provide by now.

#590257

OK, I have a clear answer on some details here.

I debugged this and want to share the exact results with you, I believe you will not have trouble understanding the details even if technical.
Please ask me any thing if something is not clear.

1. The "hide_empty" Attribute was introduced in Toolset Views Version 1.5.0:

New: hide_empty option for parametric search filtering by taxonomy

2. It is never mentioned to be added to the GUI at all in our changelog, which at first surprised me, but probably it was there since the begin of the attribute's life:

                        /*
                        'hide_empty' => array(
                            // @deprecated in 2.4.0
                            'label'            => __( 'Hide empty', 'wpv-views'),
                            'type'            => 'select',
                            'default'        => 'false',
                            'options'        => array(
                                                'false'    => __( 'Show', 'wpv-views' ),
                                                'true'    => __( 'Hide', 'wpv-views' ),
                                            ),
                            'description'    => __( 'Hide empty terms.', 'wpv-views' ),
                        ),
                        */

3. It is not in the GUI in 2.5.1 obviously as it's commented now + has a @deprecated in 2.4.0 notice

4. Cleary it still exists and is working in the code:

$atts = shortcode_atts(
            array(
                'taxonomy'    => '',
                'url_param'    => '',
                'type'        => '',
                'default_label'    => '',
                'format'    => '%%NAME%%',
                'orderby'    => '',
                'order'        => '',
                'output'    => 'bootstrap',
                'hide_empty'    => 'false',
                'style'        => '',
                'class'        => '',
                'label_style'    => '',
                'label_class'    => ''
            ),
            $atts
        );

5. There are also more note that this is deprecated:

Legacy: hide terms without assigned posts

We can conclude that the attribute does exactly what it says (as you also confirmed earlier).
It is deprecated hence new features will not be added to it. It will work "as is".

The attribute does exactly what it promises:

hide terms without assigned posts

It does not mention "current queried post type" or similar, and hence not intended for this particular need.

The only way to accomplish what you need is with the global settings as mentioned earlier:
Custom Search Settings > Which options to display in the form inputs:
- Show only available options for each input

What we can do is allow more control on that setting. But this will require some Development work, and I am not sure we will implement this.

I can ask, if you agree that this would solve the issue for you?

#590655

Hi Beda,
Thanks for all the time and effort you've taken to sort this out to the bottom.It's great to share this kind of knowledge, which helps me a lot.
To overcome the issue of the filter not being attached to the post type, I've created a separate taxonomy for the events, event-location. Which in fact makes sense to have them split up.
When I want to list both events and other things for a location I can build a query to list posts and one to list events.
Only need to merge the two different taxonomies in a way...
But that's another discussion.

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.