Problem/Motivation
Currently, if you have a view with an exposed filter, and you expose the operator for it, the label is hard-coded to "Operator"
. The only way to change it is to implement a hook form alter, which is not accessible to site builders, and will likely break if the configuration for the view changes.
An example use case for this would be when you have multiple operators exposed, and would like to have the labels be more explicit as to which one is is for which filter, so that the users can clearly identify them.
Proposed resolution
When a filter has Expose this filter to visitors, to allow them to change it and Expose operator enabled, display a new "Operator label" text field to configure the label for the Operator select element on the exposed filters form.
This will make it configurable via the UI so that site builders can configure it, and export it with the rest of the view.
This would work exactly how the Label for filters currently works. What ever text is configured will be used as the label for the operator select element.
Remaining tasks
- Accessibility review
- Commit
User interface changes
A new textfield element is added to the configure filter form, which displays only when both Expose this filter to visitors, to allow them to change it and Expose operator are enabled.
Configure filter form before
Configure filter form after
Exposed filter form before
Exposed filter form after
API changes
None.
Data model changes
New views data type schema operator_label
.
Release notes snippet
Views exposed filters that also expose the operator are now able to configure the label for the operator.