The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
When this module's filter (entityreference_filter_view_result) is exposed and its widget is rendered as checkboxes via Better Exposed Filters, the filtering itself works correctly — but after submitting the form, the previously-selected option no longer shows as checked, and any "active filter" tags/pills that read the checkbox state don't appear either.
In EntityReferenceFilterViewResult::valueForm(), after computing the correct selected value, the code does this:
$user_input[$identifier] = $default_value;
$form_state->setUserInput($user_input);
This directly overwrites the form's raw user input while the form is still being built. Core's own filter base classes (e.g. ManyToOne, used by the standard taxonomy filter) never do this — they only set #default_value on the element and let Drupal's normal Form API pipeline handle the rest.
Because this happens partway through the form build, it collides with how Better Exposed Filters (and Drupal core's Checkboxes element) later read/rebuild that same raw user input, so by the time the checkboxes actually render, the selection information has been lost — even though the value was computed correctly a moment earlier.
Steps to reproduce
1. Create a view with a filter using this module's plugin.
2. Expose the filter and set its widget to checkboxes (e.g. via Better Exposed Filters).
3. Load the page, select an option, submit.
4. Results are filtered correctly, but the checkbox for the selected option is not shown as checked.
Proposed resolution
Remove that block entirely. The element's #default_value (already set right above it) is sufficient — this matches the pattern used by core's own filter classes and fixes the checked-state issue without affecting how the actual query filtering works (which goes through a separate code path, acceptExposedInput()).
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | entityreference_filter-exposed-checkbox-default-value-3618298-2.patch | 715 bytes | mauriciopieper |
Issue fork entityreference_filter-3618298
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
mauriciopieper commentedHere is a patch with the suggested change.
Comment #5
maximkashubahi @mauriciopieper
Thanks for finding the bug and for the patch, it does fix the reported
problem.
The precise cause is that the value was written back through
computeEffectiveValue(), which returned array_values(array_intersect(...)) and
so renumbered the keys. Checkbox widgets look their raw input up by option key,
so a renumbered list leaves every box unchecked. Keeping the keys fixes the
checked state.
I kept the input rewrite rather than dropping it, because it is what keeps the
dependent filters usable. Their option list is recomputed on every request from
the controlling filter's value and the view arguments, while the submitted
value still comes from the URL — so it is easy to submit a value that is not in
the option set just built for it: open an older URL, let the dependent filters
rebuild, submit. Core rejects that value in
FormValidator::performRequiredValidation() ("The submitted value N in the ...
element is not allowed") and Views aborts the build on an exposed form error,
so the page comes back with an error message and no results.
In the MR the rewrite is therefore narrowed instead of removed: valueForm() now
extends InOperator::valueForm(), and the rewrite lives in alignExposedInput(),
which runs only when input exists, keeps the submitted keys and writes back
only when the value actually changed. New tests cover the checked state of BEF
checkboxes and of a multi-value select after a reload, plus a stale dependent
value being dropped instead of breaking the view.
Comment #6
maximkashuba@mauriciopieper, could you check the merge request against your setup, please?