if Dependent filters are used twice in a view it gives the error.

generalredneck → credited SocialNicheGuru → .

THis is the original issue reported, Adding a duplicate and it's "related" issue posted by SocialNicheGuru.

I'm also having this problem.
Is there any easyfix while we wait on an update for the package?

It would be very much appreciated, since it is a very old issue that was supposedly fixed.
Thanks

I worked on this for a while. Mostly I'm trying to understand what the code is trying to accomplish and do. I was able to set up a successful test case. I'll write a test module to build out the scenario later. For now I'm adding a sql dump of a clean D10 install with everything set up... The filter is trashing all the "Exposed" options... for that matter it doesn't start with any... so options['expose']['identifier'] is never set and the form for all that is never built out. This is because the filter is trying to not be TREATED like an exposed filter. according to the comments this is something about compatability with BEF.

see:
https://git.drupalcode.org/project/views_dependent_filters/-/blob/f3842a...
and
https://git.drupalcode.org/project/views_dependent_filters/-/blob/f3842a...

I even got the code to forcibly pass the validation rules by creating and making ViewsDependentFilter::validate() look like this

  public function validate() {
    $old = $this->options['exposed'];
    $this->options['exposed'] = FALSE;
    $results = parent::validate();
    $this->options['exposed'] = $old;
    return $results;

  }

and the first instance created is still the only one that is used and I haven't followed down that thread yet to see why.

@marceloP,
In regards to your statement. this issue has never been fixed for the drupal 8 version of the module.

Additionally, the log you provide is a different error message than the one reported here. I'm assuming you are having both the reported error in the description AND PHP warning you are seeing on Line 98 of the filter plugin.

If so, see if this Merge Request I'm putting up fixes the first and you still experience the latter. If so, make another issue and we will see if we can rectify why $handler->definition['handler'] is not set for you.

Everyone else, this needs review.

I fixed 2 issues...
1) the error message yall were seeing
2) when using multiple dependent filters, the $form[$element]['#states'] array was being built incorrectly.

Before

I set up my rules so that if I selected V1Term1, vocab2 filter would show. if i selected V1Term2, vocab3 filter would show. without the second fix, the later rules would combine... so vocab3 would show up on either v1Term1 or V1Term2 selected... and that's not what I had put in my settings.

That broken behavior is shown here:

After I made the fix, vocab1 now swaps out vocab2 and vocab3 as expected

Thanks for the quick response and the quickfix.
Your merge request indeed fixed my issue!

Yeah you caught this issue while I was actively working on it. Talk about Timing! I'm a new maintainer to this project and I have to split my time between multiple ones, so I'm trying to get this into a spot where we can coast for a minute.

Thanks a lot! I have tested the MR and it works with two dependent filters now! Great work!

In case i use this together with the Selective Better Exposed Filters-module ( https://www.drupal.org/project/selective_better_exposed_filters → ) it throws a 'selection not allowed' when a controller filter is changed while a controlled filter has already a selection made. The dblog-error is ajax related but even when ajax in views is off and 'auto-submit' in BEF is deactivated, the error still occurs, now 'illegal choice'. I guess the selected value of the controlled filter needs to be reset, when the controller field changes.

How can i help to debug this? How to find out which module causes this?

Thanks for testing the issue.

Those are good questions. What I would do is set a breakpoint at the error message (most likely in the views module) and get the stack trace from there. If you can't/don't have xdebug set up, consider using debug_print_backtrace(). That will give you an idea where to start debugging. If it has any call to the code from this module... We can work from there.

Another thing you can do is take a screenshot of the view or give me a .yml of the view. I can likely recreate it from there.

I'm assuming this is only on 2 or more dependent filters? If not we need to make a separate report... I'm tempted to ask you to do that anyway because it sounds like a compatibility issue and this one badly needs a fix. It would be helpful to known if this happens before this fix too.

UPDATE: It's all fine. I had configured a non-taxonomy field (text as list) as a controller (and controlled) dependent filter. And in combination with BEF and SBEF it was throwing the error. Changing this to a taxonomie reference field fixed everything!

Ok I came in off the email and didn't read the edit.

I think that there's something to explore here. Maybe we try it on a text field... So are you saying it only happens with bef and sbef enabled?

Merging what we have for now. Will look into what else needs to happen.