Problem/Motivation
There was a regression for our use case with an update to 7.x-3.25 in Issue #3185587. The update changed the default behaviour for the <select>
lists in exposed filters.
When using the reduce
option in the exposed filter UI, labelled "Limit list to selected items", previously it would default to All
for the view when no filters were selected. After 7.x-3.25, the select list now defaults to the last item in the list, since every option is now give the attribute selected="selected"
except for the All
option, which should be the one that has it.
Steps to reproduce
Requires at least views
and i18n
.
- Create a taxonomy and fill it with terms
- Create a content type
- Enable Multilingual support on the content type (with either translation or field translation)
- Add a new "Term reference" field to the content type for the taxonomy created above
- Create a view for content of the type created above
- Add a filter for the translated field
- Expose the filter to visitors
- Choose "Limit list to selected items" and choose only a few terms in the select box
- Save the filter, then the view
At this point, when you load the page for the view, the last item in the select list in the exposed form will be the default, despite the fact that all the content is visible.
Proposed resolution
I may be incorrect with this, but I believe adding an additional check to the newly introduced if statement should resolve the issue, as follows:
<?php if (empty($form['#default_value']) || !empty($this->options['expose']['reduce'])) { $form['#default_value'] = 'All'; } ?>
I will attach this as a patch to this issue.
Does anyone foresee an issue with adding this check? I'm likely missing some use case.
Comment | File | Size | Author |
---|---|---|---|
#2 | exposed-select-list-default-3255520-2.patch | 825 bytes | .bert |
|
Comments
Comment #2
.bert CreditAttribution: .bert commentedPatch attached that checks for the existence of the
reduce
option in the exposed filter.Comment #3
DamienMcKennaThanks for the detail report and for working out a possible fix.
Comment #4
DamienMcKennaComment #5
DamienMcKennaLet's add test coverage for this scenario.
Comment #6
djdevin#3185587: Select filters in exposed blocks don't use their default value also broke Location because its default value was -1 which is not empty.
But I think Location is to blame, the filter has a default of -1 when it should really take it from $this->value
See #3316893: Province filter broke against Views 7.x-3.25