Configurable views filters to allow for different widgets

🐛 Media author views filter should use the user_name plugin Needs work is another similar one

Is it possible to break up the scope of this a bit? Make the plugin_id configurable, e.g. select entity_reference plugin, numeric plugin, etc for an entity reference as first step. Then make widgets as a second step. Then make the individual widgets as a separate issues?

The issue summary here is from before we realised views wasn't respecting plugin ID configuration. Now that issue exists I think your step #1 of making the plugin ID configurable is plenty here. e.g. if the result of this issue is being able to choose between numeric and entity ref plugins for entity reference filters that sounds great. Then we can have a followup for anything else.

Okay great thanks.

I guess first step is still to decide how a Views Filter Plugin says its available for which fields in which tables. BEF seems to just let you select any plugin and rely on the site builder to choose sensible options but I expect that would not be good enough for Core and the Views Filter Plugin should have some mechanism to say whether its appropriate for a particular field within a particular table, and not show up e.g. in a radio or select element if its not usable.

So as an example we have field_types that FieldFormatter annotation uses, e.g. see core/lib/Drupal/Core/Field/Plugin/Field/FieldFormatter/DecimalFormatter.php which has

#[FieldFormatter(
  id: 'number_decimal',
  label: new TranslatableMarkup('Default'),
  field_types: [
    'decimal',
    'float',
  ],
)]

But this is more based on field type whereas hook_views_data/hook_views_data_alter allow control per source data table, per column within the table (or other type of course).

With some sort of annotation, hook_views_plugins_filter_alter() could then add their own supported tables/fields so the change record and other documentation can just document that I guess? To make this less of a breaking change, I expect we can auto-default to whatever hook_views_data/hook_views_data_alter spit out as the filter plugin ID.

Going this route means though that there would not be the same separation that e.g. the field plugin system has which I think the current (outdated) issue summary suggests with filterwidget, at least I don't think this sets us up for that.

Yeah BEF you end up with a long list of irrelevant filters that won't work with the field you want to filter on which is not a great UX.

I think this is where we run into limitations of the views data structure, it's an arrayPI based around database tables and not properly integrated with the entity/field API at all, except that we generate that API from the entity/field data.

Not sure what's best, but one possible idea would be to add an extra key to views data, maybe the field type plugin ID or the typed data ID, and then allow filter plugins to declare which plugin IDs they're compatible with. Something like that? This wouldn't allow the specific views data definitions to customize which ones are configurable, but it would allow a module providing a new plugin to integrate with any field/typed data types it wants to.

Tagging for subsystem maintainer review because this is another one that could really use feedback from @lendude.