Install
Works with Drupal: ^10.3 || ^11Using Composer to manage Drupal site dependencies
Alternative installation files
Release notes
Fixes the exposed filter widget and hands the validation of its value back to core.
Changed behaviour — read this if you use dependent filters
A value in the query string that is not in the filter's current option set is
no longer silently dropped. Core reports it ("The submitted value N in the ...
element is not allowed") and Views does not build the view, which is what
already happened for every other exposed filter with an option list.
This matters for filters whose options are built from another filter or from
the view arguments: an old bookmark or link can carry a value that no longer
fits the rebuilt option list, and such a page now shows the error instead of
results. The exposed form is still rendered with the correct, rebuilt options,
so a valid value can be picked and submitted again. With the AJAX cascade
active the situation does not arise, because the dependent filters get their
value updated before the form is submitted; without JavaScript the error shows
up whenever the controlling filter changes.
Fixed
- The exposed widget lost its state after a reload: with Better Exposed
Filters checkboxes every box came back unchecked, because the filter rewrote
the raw user input and renumbered its keys while checkbox widgets look their
input up by option key. The filter no longer touches the raw input at all.
#3618298: Exposed checkbox/radio filter loses its "checked" state after filtering (with Better Exposed Filters)
Internal
- valueForm() builds on InOperator::valueForm() instead of assembling its own
widget, so the option list, the single/multiple handling, the '- Any -'
fallback and the operators that take no value are core's job again.
- The plugin settings moved from valueForm() to buildOptionsForm().
- The entity type manager is injected instead of an entity storage, as
PHPStan asks for.
- Test coverage for the exposed widgets, which had none: the state of BEF
checkboxes and of a multi-value select after a reload, and the rejected
value on a plain and on a dependent filter.
No database updates and no configuration changes are needed.
Thanks to @mauriciopieper for reporting the bug and diagnosing it correctly.