Grouped exposed taxonomy term filters do not work because the group key is added to the query and not the taxonomy ID

Adding a tag, please have a look at other issues with this tag, as they might have similar problems.

I'm also having an issue with a grouped filter on a taxonomy term. I am using a taxonomy term reference field.

I looked at the other issues with the "Hybrid Filters Follow-ups" tag and I thought this was the best place to post.

When I set the filter on the view, I get no results, no matter which item I choose. If I choose 'any', the filter works as expected.

Additionally, when I change the 'field identifier' in the more settings, eg from "field_name_of_field_tid" to "myfield", I get *all results*, plus the following PHP notices:

Notice: Undefined index: field_name_of_field_tid in views_handler_filter_term_node_tid->exposed_validate() (line 258 of /path/to/drupal/sites/all/modules/views/modules/taxonomy/views_handler_filter_term_node_tid.inc).
Notice: Undefined index: field_name_of_field_tid in views_handler_filter_term_node_tid->exposed_validate() (line 259 of /path/to/drupal/sites/all/modules/views/modules/taxonomy/views_handler_filter_term_node_tid.inc).

Both errors repeat.

It appears that the handler is trying to validate the exposed filter form against the name of the field instead of against the name of the field identifier. 'field-name_of_field_tid' isn't a key, but 'myfield' is.

I love the idea of doing this in views instead of some hook_form_alter magic and I hope this helps you track down the issue.

Having the same issue; According to the sql log:

AND (taxonomy_index.tid IN ('1', '2', '3')) AND (taxonomy_index.tid IN ('1', '2', '3')) AND (taxonomy_index.tid IN ('1', '2', '3')) )

When selecting 3 different taxonomy groups.

If i select only one of the boxes it gives 1,0,0.

Seems like the transition from the taxonomy groups to the actual terms isn't done properly. I think each of those index.tid references should contain the actual taxonomy id's of the term groups. Shouldn't be hard to fix i just don't know yet where to find it :)

For now an easy solution might be to use hierarchial terms, and using the uper ones to get the grouping, though i can imagine this is no solution for everybody. According to the post above me it might be a taxonomy issue instead of a views one, but I think the "bad" code should be somewhere in this grouping exposed filter part...

Changing to bug report since it looks like a bug now.

Confirmed exactly the same issue here. When configuring a view to use exposed grouped filters of taxonomy terms the view incorrectly assigns the delta of the group as the term ID in the query. I imagine the query should instead be adding each of the terms within the chosen group.

I've tracked the issue down to line 242 in views_handler_filter_term_node_tid.inc. The issue is that $this->validated_exposed_input is returning the delta of the exposed filter group rather than an array of tids. $this->value actually has the correct array but gets overridden by the incorrect $this->validated_exposed_input.

The problem is that validated_exposed_input gets set in the validation handler exposed_validate() and that is using the form_state['values'] array which is only aware of the delta as convert_exposed_input() hasn't run yet. So either the form_state['values'] needs to be correctly populated or we just ignore the validated_exposed_input in accept_exposed_input() if its a grouped filter. Attached is a patch that does that check in accept_exposed_input().

To me it doesn't seem like the best way to do it but I don't know how to get the full tid array into form_state. If there's a better way...

Updated the title as I believe this issue to be taxonomy related rather than a problem with grouped exposed filters generally.

This doesn't feel like a critical bug.

Indeed, certainly not critical. Did you get a chance to look at my patch dawehner? We're using it on a production site and it fixes the issue for us.

This particular part looks great. You know in germany, to not be yelled at/cussed at is praise enough ;)

Currently not on my actual computer, but I'm wondering whether there should be some code that handles the is_a_group case?

I have the same issue as 'calebtr' (comment #3). I apply your patch but it's working only in case when is chosen one term. I f a choose two ore more it doesn't work.
In views with enabled SQL is appear follow message (see attached image):

Strange as the patch enables multiple grouped terms for me. I think we need an example view to test with to get to the bottom of this.

I use selectbox and it began working after:

1. Checked 'Allow multiple selections';
2. Apply;
3. Unchecked 'Allow multiple selections';
4. Apply;

Thanks for your patch.

I can confirm #14. I don't have time at the moment to suggest an alternate patch, but that allow/unallow step does fix it for me. The single difference is the grouped filter WHERE clause changes from -

(field_data_field_tags.field_tags_tid = '1', '2')

to -

(field_data_field_tags.field_tags_tid IN ('1', '2'))

Here's the exported View I was testing.

Patch in #7 Worked for me. I did not have to do what #14 did to get select box to work.

This is actually a correct fix, if there are continued problems, they are actually different bugs.

In views::_build(), there is an is_a_group() check surrounding a call to convert_exposed_input(). That is where the numeric group IDs are converted into tids, and they shouldn't be overridden.

#7 worked for me, thanks!

+1 for #7 also worked for me, also had the issue #12 where #14 fixed it

+1 for #7 also worked for me, also had the issue #12 where #14 fixed it

Confirmed #7 fixes this for single terms.

#14 confirmed workaround for the issues that arise with multiple items. Also confirmed #15 - the issue is due to the sql:

(field_data_field_tags.field_tags_tid = '1', '2')

which sql reports as a cardinality violation.

#14 worked for me to,
dev version of the views module with patch #7 and the trick of #14 from hugronaphor works.

Thx!

#14 workd form me too. I'm wondering though, how permanent this hack is.

I had the same problem described in #15. Not with the taxonomy term filter but with the organic group bundled role filter. Multiple selection with grouped filters added as "=" and not as "IN" clause. It's also a general problem with groped filters.

The solution described in #14 worked form me to solve the problem.

I made a diff from the exported view before and after #14. There was only the following line added in the export:

$handler->display->display_options['filters']['name']['expose']['multiple'] = TRUE;

I use an exposed filter with multiple terms selected. Patch from #7 did not work until I used #14 instructions. Now everything seems OK although this does not look like a permanent fix.

#25 and #27, what is not permanent about this? Other than it being a patch and not committed in the module? Do you have suggestions on how to make it better?

tanc, thanks for working on this.
did you see #14 instructions? Settings are not supposed to change by checking and then unchecking. That is why I am afraid this is not permanent. Ideally, the patch should work without #14.

The patch from #7 worked for me.

#14 was needed to get grouped filters to work which existed before I applied the patch, a new filter group on the other hand did not need the workaround from #14.

The actions described by me in #14 is just resetting the grouping if you created the filter already(without applying the patch).

Wow - thank you for this. I thought I was losing my mind. Commenting here not just to express my appreciation, but to stay apprised - thanks again!

#7 worked, but in my case one of the groups has multiple terms, and the remaining only one each.

When i try to do as stated in #14, the option for "all" doesn't show up and since it's the default option, throws a "Illegal choice" error.

Any idea when this might be committed, I'm also coming across this bug and the patch seems to be RTBC. Many thanks.

7: taxonomy_grouped_filters-1810148-7.patch queued for re-testing.

Committed and pushed to 7.x-3.x

dawehner, I created a similar patch a while back in a new issue for D8 views in core: #2098641: Grouped exposed taxonomy term filters do not work

Added the patch from #2098641: Grouped exposed taxonomy term filters do not work. Not sure if this is the best thing to do? Should I reroll/rename the patch for this issue?

7.x is still broken or became broken again.
Grouped filter query still uses "=" equals operator for multiple tids, instead of switching to "IN" operator.
This throws an error like "SQLSTATE[21000]: Cardinality violation: 1241 Operand should contain 1 column(s)"

What's the protocol for changing the version on this issue?

Here's a patch to views_many_to_one_helper that fixed the issue for me in D7.
I'm sure this is not the correct approach, but I haven't seen adverse side effects so far.

Needs tests.

I am having the same issues as described in this thread for over a year and I have tried everything except the patch to try and fix it. It has gotten worse now because I hae the BEF set as links and it is being presented as a dropdown no matter how i tinker with the settings

This is the core queue, moving to D7 won't help. You can open a D7 issue in the views issue queue.

Re-created this issue in Views queue.
#2224601: Grouped exposed taxonomy term filters do not work

I'm going to mark this back to needs review and re-queue the patch from #38 to see if its still valid after all these months. I think the issue might have been polluted by D7 problems, but lets see about fixing the D8 issue.

Re-rolled patch against HEAD to incorporate PSR-4 change.

I need to go delete that tag...

CNW since this needs tests.

#49 fixed combined exposed taxonomy filters for me when applied manually on Drupal 8.x.4 dev. Thanks a lot!

Rerolled.

The patch in the comment #58 works fine for me, thanks!

I have the same setup then the OP, but #58 doesn't solve my issue: when I select one of the grouped filter, the view results are empty and shouldn't.
Note that I have a multi-value field... this could be the origin of the problem

For DuneBL and others who are getting "empty" results after following the above, try to tick "Reduce duplicates" on the taxonomy filter element (only available in the UI AFTER you add the filter, I believe).

I needed to use the same taxonomy term filter in two different filter groups, and this was the missing configuration element in my case.

Same problem here with Drupal 8.6.3. Patch at #58 solves.

@veleno
Do you think you are able to write a test for this?

For some reasons I couldn't reproduce the described bug on D8.7, but then again I only looked into it very briefly and may not have the same configuration. However, would someone check whether #2429699-141: Add Views EntityReference filter to be available for all entity reference fields fixes the problem? TaxonomyTermTid is completely rewritten there.

same problem for me in 8.7.3. the patch #58 not work for me, nobody has found a solution? thx

+++ b/core/modules/taxonomy/src/Plugin/views/filter/TaxonomyIndexTid.php
@@ -307,8 +307,11 @@ public function acceptExposedInput($input) {
+      if (!$this->isAGroup() && isset($this->validated_exposed_input)) {
...
+        // This is a group so provide the group values.

This assumption seems wrong if it is not a group and $this->validated_exposed_input in not set. Looks like this should not be an else but and elseif

Same issue with views 8.6.17. The generated SQL looks as this:

... WHERE ((group__field_country.field_country_target_id = '1')) ...

it should be something like target_id IN('43', '41', '8', '52', '51', ...)

Same issue over 8.8.x

I'm not sure, if my problem is related to this bug, but to me, it seems similar:

In a nutshell, I can't seem to get grouped exposed taxonomy term filters to work with Drupal 8.7.6. However, in contrast to what has been described by some in this thread, the grouped filter simply doesn't seem to work at all. So, I'm not getting "empty" results, but the grouped filter always behaves, as if "Any" was selected.

I even applied the patch from #58, but that didn't change anything. Any idea, what else I could try?

Seems like this may depend on #2559961: ManyToOneHelper ignores group configuration for some cases getting fixed?

Also ran across this issue and the patch in #58 corrected it for me in 8.9.1. Can now correctly use grouped values for taxonomy terms in a views filter. Thanks!

Re-rolled D7 patch to match the latest version.

Patch from #58 seems not working if "Allow multiple selections" is enabled in the exposed filter settings. I guess this is a possible reason why the patch is not working for everyone.

Drupal 7 version patch is here: https://www.drupal.org/project/views/issues/2977851

#58 works for me in Drupal 9.1.8.

Re #66:

would someone check whether #2429699-141: Add Views EntityReference filter to be available for all entity reference fields fixes the problem? TaxonomyTermTid is completely rewritten there.

The (much) later patch #389 there does not solve the problem, but maybe the follow-up task there will in the future: "have TaxonomyIndexTid use this entity reference plugin".

Re #68:

This assumption seems wrong if it is not a group and $this->validated_exposed_input in not set. Looks like this should not be an else but and elseif

Would this be better? It still works for me. But it feels like it should have a final else in it.

    $rc = parent::acceptExposedInput($input);
    if ($rc) {
      // If this is not a group and we have previously validated input then override.
      if (!$this->isAGroup() && isset($this->validated_exposed_input)) {
        $this->value = $this->validated_exposed_input;
      }
      // If this is a group then provide the group values.
      elseif ($this->isAGroup()) {
        $this->value = $this->group_info;
      }
    }

I was having a problem with the patch from #58. I found that it was short circuiting and exiting before it reached the patched code. After adding a check to make sure it's not a group before exiting if no value is set, it started working as expected.

Fixed custom command fails of patch #82.

There are many open issues that try to solve this problem. Let's try to merge everything together and push this forward.

As a first step, I'm updating the issue summary and listing duplicated issues here.

I opened a merge request with the test, made by @mohit_aghera (all kudos to him!) in #2662978: TaxonomyIndexTid::acceptExposedInput() resets the plugin value incorrectly.. It should fail, so we're safe here.
The next commit should contain a fix and should make tests green. I'm leaving "Needs work" and will try to push it soon.

In the meantime, we can close duplicated issues and transfer issue credits here:

• #2662978: TaxonomyIndexTid::acceptExposedInput() resets the plugin value incorrectly.
• #2049603: Exposed Group Filter assigns incorrect tid to SQL Query

#3244750: views group filters with taxonomy list not working looks also similar, but I asked for confirmation and marked it as postponed.

Transferring credit from duplicate issues @Matroskeen pointed out

Pushed one more commit with the actual fix, so now it's ready to review.

I started with throwing away some methods including validateExposed, but I noticed other filter plugins are doing approximately the same.
I ended up taking a few lines from \Drupal\user\Plugin\views\filter\Name class, that's why I think that's the safest way.

I still have no clue why values are usually assigned in validateExposed method (acceptExposedInput would make more sense, no?) of plugin, but I think we can stick to this approach at least to fix this bug.

The merge request is ready for review.

This looks great. Following what \Drupal\user\Plugin\views\filter\Name does makes sense.

Looking at \Drupal\user\Plugin\views\filter\Name, it has special handling for 'All', and the description for the grouped taxonomy filter says "Leave blank for all.", so I was wondering if we needed special handling for that here too. But that doesn't actually work at all, the field won't validate when left blank, and that seems like a separate issue to me. Quick search didn't turn up an existing issue, but might need a bit more effort to try and find one or other wise we probably need to open one, should be easy enough to test by expanding the test coverage we are adding here.

@lendude, thanks for RTBC, but I'd like to take a look one more time after digging the "Username" filter issues, that I faced in #2576927: Grouped exposed taxonomy filter fails validation for autocomplete widget.
I'll move back to RTBC if I don't have any other suggestions :)

The fix still looks good, but I did some changes to the test.

We already had a test for the filter plugin, so I think we can use that one instead of creating a separate test class. I also simplified it a bit, and on my local environment it failed in the same way without the fix itself:

There was 1 error:
1) Drupal\Tests\taxonomy\Functional\Views\TaxonomyIndexTidUiTest::testExposedGroupedFilter
Behat\Mink\Exception\ResponseTextException: The text "zx1mNAfk" was not found anywhere in the text of the current page.

It's ready for review again. Hopefully, won't take long before going RTBC again 🤞

Merging the tests into an existing test sounds fine.

Uploading current MR diff as patch that can be used in composer projects.

Applied the patch from #101 to a Drupal site on 9.2.11. Everything works as expected.

+1 RTBC

Hiding patches as there's an MR

Adding issue credit.

Committed 8581df9 and pushed to 10.0.x. Thanks!

Backported to 9.4.x

Mammoth effort here, thanks for breathing life into it @Matroskeen and all those who contributed.

I just ran into a very similar bug and my search led me here.
wow. it's 10 years old!

my problem was:

on content type, I select a single taxonomy within a hierarchy for 3 content items.

then, in the view, I try to use "is one of" with that single taxonomy => it returns all.
(Drupal 9.3.7)

is that the same bug ?

The code that was pushed live for this seems to only work if you're using the default filter identifier.

$identifier = $this->options['expose']['identifier'];

Line 350: TaxonomyIndexTid.php

This returns the same value no matter what the actual identifier is (by default it's _target_id). In the short term it would be easy to change this code to something that returns the correct value, but really it seems like $this->options['expose']['identifier'] should be returning the correct value as well.

#109 :
Status: Fixed » Closed (fixed)
Automatically closed - issue fixed for 2 weeks with no activity.

what sense does it make to mark bugs as "fixed" after 2 weeks of inactivity ?
this bug seems still unfixed and still alive.

It gets moved to Closed (fixed) after two weeks of inactivity AFTER it got fixed, it got fixed in Drupal 9.4.x. The title here was a bit bad, insinuating that this would magically fix al possible issues you could have with grouped taxonomy filters. I've updated the title to better represent the fix.

If you still think grouped taxonomy filters need more work, open up a follow up with steps to reproduce your issue on the latest version of Drupal and add a comment here to the new issue so people that worked on this issue might help with the follow up.

ok thanks!
I described my problem above, I was not sure if it belongs in this issue or not.
I will re-test it at some moment using the latest version and report back if the problem still occurs.