some exposed filters aren't triggered correctly

+++ b/entityreference_view_widget.moduleundefined
@@ -214,6 +214,11 @@ function entityreference_view_widget_field_widget_form(&$form, &$form_state, $fi
+      foreach($exposed_input as $key => $value){
+        if ($key != 'submit'){
+          $view->set_exposed_input = $exposed_input[$key];
+        }

set_exposed_input is a function, and it overrides all exposed input. Maybe it's better to unset $exposed_input['submit'], then assign that to $view->exposed_input?

I have the same problem!!!

I created a vocabulary to categorize my products, applied to the product display node type through term reference.

In my view:

• an exposed filter based on taxonomy term NAME: works correctly
• an exposed filter based on taxonomy term TID (through a select option): doesn't works!

Thank you for resolving this

I tried both #2 and #4 and neither works for me.

I think this bug would be marked as major because using taxonomy to classify nodes is a basic operation in Drupal (everyone uses to do this by Drupal design), and a "simple" exposed filter based on taxonomy that doesn't do its job is a BIG problem.

Thank you very much for your work

There's more to it than this. The code snippet touched in the above patches is only the ajax call. But the non-ajax (first form load) has the same issue.

Issue #1: on first form load (i.e. not the ajax call), there can be a mismatch between the view results and the widget values which are displayed.

• The view results are filtered with existing input, from a past run (whenever that may have been).
  
  (for completeness: entityreference_view_widget_plugin_exposed_form::render_exposed_form() => views_exposed_form() => view::get_exposed_input() gets the filter values from your $_SESSION)
• The widget values however, just display the default values for the form. (This is because our ...::render_exposed_form() only returns $form and throws away $form_values.)

These things should be matched up. I believe the displayed element values should be made to match the exposed filter values - which is also the easiest. See patch.

Note: security alert. I have not checked whether $form_state['input'] is unsafe and $form[element]['#default_value'] should be safe. Anyone knows this by heart?

Issue #2: the problem mentioned earlier.

We haven't been more specific than "it doesn't work". The problem I am seeing stems from the fact that the filter value (retrieved from the $_SESSION) is not valid anymore (i.e. a taxonomy term has been deleted in the meantime). I am going to assume that the above reported problems do not have anything to do with taxonomy items per se, but with 'invalid values'.

These invalid input values would generate an form-error message on first error load -- and they are not fixed by ajax reloads, unfortunately. Which is why no results ever show up.

(Detail: $view->build() calls $exposed_form->render_exposed_form() ==our code, which calls drupal_build_form() => drupal_retrieve_form() => $callback==views_exposed_form() => view::get_exposed_input() , which sets $form_state['input'] with the original, still invalid values from the session, and form validation breaks off the build() and the session values aren't updated either. Unless $view->exposed_input is set already.)

So the original patch fixes this issue #2.

....and while we're at it, let's fix related issue #3 that form errors from the ajax call should be caught and displayed above the view results (and not at whatever next page view).

Conclusion: I can only assume that this fixes the original reported problem, not know for sure. Please test.

@bojanz: I noticed the following comment:

// For some insane reason, the view won't display any results
// without the drupal_build_form() call.
$form = drupal_build_form('views_exposed_form', $form_state);

I don't know the when/why/how of this comment. But if the "not displaying any results" is only happening in some cases and happens to be caused by a combination of #1 (your $_SESSION values were polluted) and #3 (you didn't get any message about the resulting form errors)... then maybe the drupal_build_form() can be scrapped? idk...

i also have this problem

i'm using tid field with relationship to parent as exposed filter in taxonomy view.

2 displays:

1. simple page. http://medstream.krypton.vps-private.net/reference (works fine)
2. Entity Reference View Widget.

attached entity reference view widget to content type, it's displayed, but exposed filter doesnt work.

i have applied latest patch from, but withour any visible result.

same problem

I committed #6. Hopefully that will help.
We can explore additional fixes in this same issue.

@roderik
Yeah, that code in #7 was always a hack, and we might be able to avoid it.

I've just upgraded but this commit doesn't resolve my issue (see #5).

Still taxonomy filter doesn't have any effects in the widget, instead it correctly works as usual in my view (in another page display for example).

Thank you very much for considering concentrating efforts on this.

Ha. I got this same error on another site yesterday. And then discovered that deleting just one line of code fixes it. But I changed comments too.

(Internally it's a different bug than in previous patches... but I guess working here is not more confusing than opening another issue.)

in-depth / @bojanz:

- reason: the views_handler_filter_term_node_tid works in a slightly nonstandard way**. It stores values on exposed_validate() - and accept_exposed_input() will return FALSE (and thus not filter anything) if exposed_validate() is not run beforehand.

- The easiest way for doing this is to build the form and let views_exposed_form_validate() run, which is the standard validate handler of the form.

- That wasn't done because you set $form['#validate'] = array();. The form builder will only run the standard validate handler if !isset($form['#validate'] ), which is the default situation in our case.

- So I deleted that line. It seems the most logical to me, though you can also opt to run views_exposed_form_validate() yourself if there are reasons for that... I don't know of any.

- This means there is now another reason to keep running drupal_build_form(). I documented it. Please check; I might use too detailed comments. (I usually write long comments for these cases where otherwise reasons are unclear.)

**... ok I'm guessing. Not that I know about logic/assumptions of Views code setup; I only got my Views 'expertise' by hours and hours of step-debugging...

YEAH patch in #12 works for me!

Now also my taxonomy exposed filters do their job correctly!

Thank you very much!

Thanks, roderik!

Committed. Just in time for alpha2.

After updating to the latest version, in order to use the taxonomy selection widget, there are layout errors. The selection widget is now above the browse view, and all checkboxes went out of the selection widget to be below the exposed filter:

I will open a separate issue for that.