Notice: Undefined index: country in views_dependent_filters_handler_filter_dependent->exposed_form() (line 267 of ...

Same here :

Notice : Undefined index: type dans views_dependent_filters_handler_filter_dependent->exposed_form() (ligne 267 dans /var/www/localhost/www/sites/all/modules/views_dependent_filters/views_dependent_filters_handler_filter_dependent.inc).

Type filter field is the depend exposed field.

I have the same problem when I use Search API module. Is very fine without this module

I got the same problem.
I exposed in block for Search with Search API.

It looks like, no issue for this one.
Nobody is careing

I'm afraid that I no longer have much time at all to look after this module, as I am no longer working on the project it was initially developed for.

Cab you debug and do some of the work towards figuring out where the problem lies?

This worked for me.

Patch in #6 removed the error for me.

Thanks

The patch in #6 removed the error for me as well. Thanks @kyletaylored.

I had a similar issue with using this module with search API. The patch #6 removed the error, and still works as intended. @kyletaylored ++

#6 worked for me as well. I think this is RTBC.

Nevermind, it most likely needs to be rerolled for the current dev.

The patch from #6 seems to contain an mistake that kills the module:

if (!isset($form_state['input'])) {
   // Get the input for this filter.
   $input = $form_state['input'][$identifier];
   ...

This conditions is always false (since at that stage there exists $form_state['input'], at least empty), and therefore the code inside never works (and hence does not throw an error), and dependent filters aren't killed when they should.

Here's another patch that must fix the issue preserving module functionality.

Man, what was I thinking 2 years ago... Sorry, I was a little green. Haha.

#13 looks much better.

Patch got rid of the error messages, but it didn't solve the problem, which is that when a user visits the view for the first time the form_state input is empty, so the view results don't reflect the filter settings.

In-case it matters my exposed filters form is in a block.

So here is my take on it, if a value hasn't been set through the exposed filter it uses the default value instead, which is the value the exposed filter will use anyway.

views_dependent_filters_handler_filter_dependent.inc

     function exposed_form(&$form, &$form_state) {
       ...
       // Get the input for this filter.
-      $input = $form_state['input'][$identifier];
+      if (isset($form_state['input'][$identifier])) {
+        $input = $form_state['input'][$identifier];
+      }
+      else {
+        $input = $form[$identifier]['#default_value'];
+      }
       ...
     }

And a patch of #16.

Patch #17 fixes the problem.

With this patch I now get

Notice: Array to string conversion in views_dependent_filters_handler_filter_dependent->exposed_form()

in this line:

      $intersection = array_intersect($input, $controller_values);

I suppose this is because of this:

      // Convert values for non-multiple filters to an array.
      if (!$this->view->filter[$filter_id]->options['expose']['multiple']) {
        $input = array($input);
      }

If $input is already an array, then array($input) will be a nested array, which blows up array_intersect().

In my case, the filter is NOT configured as "multiple", but Views still stores an array as the default value.
- Filter type to expose: Single filter
- Required: Yes
- Operator: "Is one of"
- Expose operator: No
- Value: Checked "Category 1", "Category 2", "Category 3" (out of 7 categories)
- Allow multiple selections: No
- Remember the last selection: No
- Limit list to selected items: Yes

The view is a search API view, and the filter is for "content type".

I would say this is a bug in Views.
Or maybe it is caused by bef or vefl, which I also have enabled.

See also #2704545: views_handler_filter::exposed_form() is messed up.