Caused by #1881910: Exposed filters exclude each other.
If an exposed ajax filter is a checkbox then when it's checked the following $_REQUEST can be observed:
array(
'q' => '/views/ajax',
'date' => array(
'value' => array(
'date' => '07/04/2017'
),
),
'checkbox' => array(
'value' => array(
0 => '1',
),
),
);However when it's unchecked the following $_REQUEST can be observed:
array(
'q' => '/views/ajax',
'date' => array(
'value' => array(
'date' => '07/04/2017'
),
),
);
As you'll notice jQuery Form ajaxSubmit doesn't send back $_REQUEST['checkbox'], which was fine before because we defaulted to using $_REQUEST so the filter would be unchecked, the view would be generated, and it would update correctly.
However now it defaults to the remembered session data (which would be checked), then it's overwritten by $_REQUEST['checkbox'], which doesn't exist, so nothing happens, and the view is generated with the filter checked (when the user has just unchecked it) and is updated incorrectly.
I'd like to suggest that #1881910: Exposed filters exclude each other should be reverted.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | views_2867734_regression_single_ajax_12.patch | 1.7 KB | daniel korte |
| #4 | views_2867734_regression_single_ajax_4.patch | 3.24 KB | juhog |
Comments
Comment #2
alisonHi! has anyone else reproduced this issue? I haven't yet, I don't think I have any views with this configuration, but I'm interested to know if the issue has been confirmed by others. (In other words, I hereby bump this issue with my comment lol.)
Thank you!
Comment #3
sokru commentedWe faced this issue when updating from 3.15 to 3.16 and I can confirm that reverting commit #1881910: Exposed filters exclude each other fixed this issue.
Comment #4
juhog commentedWe ran into to this problem.
Indeed it seems like reverting the changes of https://www.drupal.org/node/1881910 fixed the situation for us as well.
Here's a patch which reverts the changes.
Comment #5
mustanggb commentedComment #6
mustanggb commentedComment #7
damienmckennaComment #8
damienmckennaAlternatively, instead of reverting that change, lets build up more tests to cover the additional scenarios and then work out how to fix the problem.
Comment #9
damienmckennaRemoving this from the list for 3.18.
Comment #10
mustanggb commentedWhy not bump it to the next release then?
Comment #11
damienmckennaSorry, but this needs test coverage first.
Comment #12
daniel korteRe-rolled. Also, the test created in #1881910: Exposed filters exclude each other can be kept I assume, no?
Comment #13
donquixote commentedI came here looking for issues about "get_exposed_input()".
What strikes me is the use of "empty()" in the condition.
This means if you use
$view->set_exposed_input(array())to pass in an empty array, then later in get_exposed_input() the empty() check will return FALSE, and the results are filled from $_GET.So to actually force the exposed filters to be empty, you would have to pass an array with dummy values into set_exposed_input(), e.g. like so:
The correct thing here would be to initialize the ->exposed_input with NULL instead of array(), and then check !== NULL instead of empty().
But this ship has sailed. Due to the total lack of encapsulation, changing this now would likely have side effects on 3rd party code.
I don't know if this affects the issue that is discussed here, but wanted to mention it anyway.
Comment #14
jkingsnorth commented-posted on wrong issue, apologies-
Comment #15
jkingsnorth commentedComment #16
jkingsnorth commentedThis is related to / duplicate of: https://www.drupal.org/project/views/issues/1080164#comment-14166030