Given a page containing two displays of the same view
And each of this displays have exposed filters
And the displays are configured to use AJAx
When I click on reset of display B
Then the filters of display a get reset
When I click on reset of display A
Then the filer of display A get reset

I expect the filters of display B reset when I klick on reset of display B.

As far as I could figured out, the display that gets the reset applied is always the views default display.

In views_plugin_exposed_form::reset_form() the variable $this->view->current_display always contains this default display or at least the first display that got rendered.

#3 example_for_1881884.tgz2.47 KBcorvus_ch
Members fund testing for the Drupal project. Drupal Association Learn more


dawehner’s picture

corvus_ch’s picture

I first thought this too. But I agree they are related. I do not expect to solution of either of those issues to fix the other but they may depend on each other.

The difference is that [#1881910: Exposed filters exclude each other] is dealing with two displays of two views while this issue is with two displays of the same view.

corvus_ch’s picture

2.47 KB

So this is how this can be reproduced.

Install the attached feature .

Log in. Go to /foo an apply a filter to Content A then to Content B. Then refresh the page to prevent [#1109980: Exposed Form Reset button Inherits the page display URL when using as a block and AJAX].

Now klick on Reset of Content B. The filter of Content B is still set but the filter of Content A was reset instead.

I have reproduced this with Drupal 7.16 and Views 3.5 as well as with Drupal 7.18 and Views from latest git.

Berdir’s picture

Status: Active » Closed (duplicate)

It is the same problem as the issue referenced in #2. There's a bug in the panel/view configuration, which is using the same identifier for both title fields, that does not work, can not work. If you change the second to title_2, then the patch in the other issue fixes this.

What happens is the following:

views_exposed_form() calls $form_state['input'] = $view->get_exposed_input(); .

In there, in the current code, if there's *anything* in $_GET except q/page, the Session data is ignored, so $form_state['input'] is missing the title value. Later on in views_handler_filter::accept_exposed_input(), it returns FALSE because $value === '', triggering the unset($session[$this->options['expose']['identifier']]); in store_exposed_input() below.

The source problem and the fact that the other patch works can be reproduced in a very simple scenario:

1. Create a single view with a single exposed filter
2. [x] Remember the last selection
3. Now go to the view and filter by some value
4. Refresh the page, the value is still there in the exposed filter.
5. Append ?exposed_value_destroyer=weeee to the URL
6. The exposed filter is now empty.

Will try to write a patch for this in the other issue.

Berdir’s picture

Issue summary: View changes

Also true for non AJAX.