This issue is related to #1877678: Exposed filter gets error class without submitting it.

The fix there makes 'always_process' dependent on the value of exposed_filter_applied(). But it also provides a new implementation of that function which uses get_exposed_input() to check if a filter has been applied (i.e. has a value or not).

The problem with better exposed filters is that it also uses its own implementation of exposed_filter_applied(), which checks if $view->exposed_input[] has a value. For my exposed form which has no required input (if that would matter) the check returns false (i.e. the array $view->exposed_input[] has no value), even if I submitted a value for the filter.
This leads to the form not being properly processed, since $form_state['input']['form_id'] would not be set in form.inc line 873, because $form_state['always_process'] is FALSE in form.inc line 868. Because the form_id is not set, the check in form.inc line 1834 would set $form_state['process_input'] to FALSE. This in turn would lead to the check in form.inc line 888 to fail, which means the form is not being processed. And there you go :)

So the fix would be to either also check get_exposed_input(), like the patch in #1877678: Exposed filter gets error class without submitting it does, OR to NOT have our own implementation of exposed_filter_applied() and just use the parent implementation which the patch in #1877678: Exposed filter gets error class without submitting it provides.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Sneakyvv created an issue. See original summary.

Sneakyvv’s picture

Status: Active » Needs review
FileSize
1.25 KB

Patch supplied.

Status: Needs review » Needs work

The last submitted patch, 2: better_exposed_filters-exposed_filter_applied-2631560-2.patch, failed testing.

Sneakyvv’s picture

Version: 7.x-3.2 » 7.x-3.x-dev
FileSize
1.2 KB

The issue also occurs in dev. Patch supplied for dev version.

Sneakyvv’s picture

Status: Needs work » Needs review

No idea why these tests fail. It seems like the failing of the tests is unrelated to this patch, so I'll boldly set the status back to "needs review".

klausdk’s picture

This patch should be more robust for future versions, as it only checks for the function name.

So it should not fail if the code or comments in the function is changed.

Neslee Canil Pinto’s picture

Status: Needs review » Closed (won't fix)

Hi, there will be no more future development for 7.x branch. If you see this issue in 8.x, feel free to file an issue. Closing this as Closed(wont fix).