Problem/Motivation
Alas, although #3347343: Add Views EntityReference filter to support better UX for exposed filters added the fancy new entity reference filter, we were not able to update EntityViewsData::processViewsDataForEntityReference() to provide that automatically for fear of breaking existing sites.
So, even if you're on a modern version of Drupal that supports the better filter for entity reference fields, you have to do wonky crap like hook_views_data_alter() to turn it on for every single field where you need it.
Steps to reproduce
- Install Drupal 10.4.5.
- Add some entity reference fields to a custom entity type.
- Create a view of those entities, and try to filter by the entity reference field.
- You get a sad, numeric-only filter, not the happy new thing with autocomplete vs. select.
Proposed resolution
1 line change to EntityViewsData::processViewsDataForEntityReference():
$views_field['filter']['id'] = 'entity_reference';
Remaining tasks
Land #3458099: Views handler loading should respect configuration
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
Issue fork drupal-3517303
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:
Comments
Comment #3
dwwOpened an MR with the 1-liner. Let's see what the bot thinks...
Comment #4
dwwBot is happy and green. I guess this is a new feature. 😅
I'm probably forgetting something about how this could break things for existing sites with existing views config. Especially while #3458099: Views handler loading should respect configuration is unresolved. But it's here for folks that want to try it out. Maybe I'm over-thinking it, and this is harmless for legacy sites.
Comment #5
scott_euser commented'Oversight' is not entirely fair :)
In #3347343: Add Views EntityReference filter to support better UX for exposed filters:
While those messages are just summaries of slack, we had a lot of discussion with @catch about it it and getting Entity Reference filter in without being used was agred to be the only realistic way to not have a breaking change for existing sites, so we had agreed to deal with the opt-in separately in follow-ups. The main candidate for follow-up was suggested to use #3458099: Views handler loading should respect configuration so that existing sites using numeric would respect the configuration and not automatically get swapped to entity_reference, but that turns out to be a big can of worms and ended up getting reverted.
For others stumbling across this issue, for now more sites are using https://www.drupal.org/project/views_core_entity_reference to opt-in to it, or you can opt-in easily yourself as described on that module homepage.
Comment #6
berdiryes, we IMHO need to restart #3458099: Views handler loading should respect configuration, the approach I suggested would give us a way to respect the config but in a constrained way (use the plugin in config, but only if it is in a list of supported plugins. Then we can add numeric and entity reference here and existing sites will continue with what they have and new sites will default to entity reference. and then issues to pick the plugin based on the list of allowed types in the UI as well as being able to deprecate some.
Comment #7
dwwRe: #5: hah, fair enough. 😅 Apologies for my less-than-tactful wording, and thanks for not taking it personally!