Add Views EntityReference filter to be available for all entity reference fields

I'll have a crack at this.

I'm a bit lost with this one but maybe these comments are useful.

+++ b/core/modules/entity_reference/src/Plugin/views/filter/EntityReference.php
@@ -0,0 +1,82 @@
+    // @todo How to get a FieldDefinitionInterface (required by
+    // getSelectionHandler) without a bundle? `$configuration` contains
+    // `entity_type` and `field_name` parameters.

I thought we could use FieldAPIHandlerTrait for that which has a method getFieldDefinition but it seems this object is not complete enough to get the selectionHandler.

I also wonder how this should behave. in D7 "target bundles" is a field setting but now it seems this it's a field instance setting.

"target bundles" : see #2064191: Fix the 'target_bundle' field setting - 'target_bundles' are not validated when entity_reference is enabled

This seems like a feature request to me, not a bug? It's okay not to have feature parity with D7 contrib modules. Views doesn't either.

The point is that you can do that with taxonomy term references*. And we want to replace them with ER, so we lose that feature, and I think this is important.

We also had criticals around the regression that it was not possible to expose list fields as exposed filter, nobody there said that's not a regression because views was contrib in 7.x :)

* Not in the same way, instead, the filter plugin asks you if you want autocomplete or a select. That seems actually like the preferred option to me?

This is what I was talking about:

Shouldn't we just port this behavior to the entity reference filter plugin, no need to make it configurable per field type?

So see #1847596-223: Remove Taxonomy term reference field in favor of Entity reference from @berdir. For taxonomy, there will be no change. I think it's acceptable for core to ship without this feature of D7 entity reference, and so I think that makes this issue a feature request (and therefore targeted for 8.1.x or later if we do decide to add it to core). If there are other regressions please add more detail here. Thanks!

I'm confused, what does that have to do with this issue?

The 'target_bundle' setting is a red herring, it is not used by anything anymore - see #2064191-4: Fix the 'target_bundle' field setting - 'target_bundles' are not validated when entity_reference is enabled

Since it's a task, not a bug, it think this should be done at 8.2.x-dev.

I'll try to reroll #24 for being applied to 8.2.x-dev

There's a contrib module over at Entity Reference Exposed Filters. I haven't looked at the code so I'm not sure if it would help with what we're trying to do here.

There's also a blog post over at Entity reference filter with Drupal 8.

I hope the "render views filter as select list" feature gets looked at again and will do my best to help provide any information and even potentially patches if I can find the time. Initially I tried patching the Drupal code base with the patch in #24 but it no longer applies due to changes in core. Hoping to reference the related changes in an effort to coalesce the related changes and make it easier both for myself and others to take a stab at a patch.

Two files referenced in the patch were removed via #2429191-189: Deprecate entity_reference.module and move its functionality to core and the committed patch might provide some insight into integration areas.

Edit: the commit is 97823b5a

It appears the original issue title appears more correct, as it seems to be purely a views exposed filter issue, not necessarily a TaxonomyIndexTid filter. That said, it also appears the TaxonomyIndexTid filter does provide somewhat of a roadmap to get there through entity reference and views configurations.

Similarly, as I was looking to re-roll the patch in #24 to D8.2.x, information in the entity_reference module is deprecated in 8.x. I can reroll a patch that recreates a similar structure, but I don't think that's the correct path to go down in terms of down the road given the deprecation notice. It seems like a short-term, non-commitable fix. (Am I wrong? Is it something that will just need a forward-port in a couple of years?)

Would the right way to go be adding a pluggable module in core/modules/views/src/Plugin/views/filter, or even adding code to an existing plugin, as most views filters are placed? There is also other code that exists to provide appropriate exposed taxa filters, but seem to be generally contained within the core/modules/taxonomy module. Many parts of the taxonomy module are deprecated as well, along with removal in D9.x.

I am not a particularly adept coder, although I can read it understand it; reproducing it is a different story. (I can try, but it is open to all sorts of scrutiny; I welcome the scrutiny because it will help me to get better.)

I am lost as to what to do or where to focus, or how best to approach it. Any guidance would be appreciated.

Re-roll against 8.2.x

Fixed incorrect schema

I have patched Drupal using #36.

Go to the field you want to update and under field setting is the familiar checkbox.

Flush the caches.

Then update the exposed filter in your view.

Pretty sure this can RBTC?

I've attached a new patch based on #39 (see interdiff) to support references between entities of different types (#39 used entity_type where I believe target_type was intended).

I've also changed getValueOptions to support not having any bundles selected (my entities don't have bundles!). I'm not sure about that should that be supported? I have to override getSelectionHandlerOptions() to make the filter work without bundles:

  /**
   * Helper method to get selection handler options.
   *
   * @return array
   *   Array of options matching SelectionBase options.
   */
  protected function getSelectionHandlerOptions() {
    $options = ['target_type' => $this->configuration['target_type']];

    // Don't filter on bundles.
    $options['handler_settings']['target_bundles'] = NULL;

    $options['handler_settings']['sort'] = $this->options['sort'];
    return $options;
  }

Note that target_bundles needs to be NULL, not [], in order to show all entities instead of no entities (that's how Drupal\Core\Entity\Plugin\EntityReferenceSelection\DefaultSelection works).

Not sure why we're not actually doing the same as TaxonomyIndexTid as suggested in #9/#10. The current behavior of having an exposed field for the ID never makes sense.. why not add the autocomplet-or-list setting that TaxononomyIndexTid uses too? We have generic entity autocomplete..

Tagging.

As Berdir said so did I. Brought big part of the functionality from the TaxonomyIndexTid. Removed the possibility to select the target bundle types, seems to me weird, but it can be readded if you think it can be useful. Now it detects from the displayed entities the possible target bundles. Also removed from the entity reference field the setting to allow for views filtering, so now it's by default enabled. Coding standard fixes.

With this patch the filter can be select or autocomplete. This seems to work with nodes, but a lot of work is still left. Also this patch needs cleanup: config schemas.

About the problem with too many entities: I think we shouldn't disallow the filter, but rather alert the user about possible problems. As I see, it can only have problem with the select type, but the user should decide whether he wants select or autocomplete as he will know how many target entities will be possible.

Did not create the patch properly. Also I did not update the tests so this will break.

Fixed referenced entity type always node and added support for entities that don't support bundles. Other minor improvements.

It works for nodes and users. I don't quite understand why for files the core_field_views_data is not called. Can someone enlighten me. How are they special. I notice that for file and image reference fields in the views filter list they don't display independently, but rather all their fields.

I need some guidance and feedback to continue work on this.

Since target bundles are not options anymore, at least for now.

Thanks, this is a good start, great to see progress on this. I'll try to look into that file problem you mentioned.

For now, reviewed the patch.

1. +++ b/core/config/schema/core.data_types.schema.yml
   @@ -582,6 +582,13 @@ field.storage_settings.entity_reference:
          label: 'Type of item to reference'
   +    additional_behaviors:
   +      type: mapping
   +      label: 'Additional behaviors'
   +      mapping:
   +        views_select_list:
   +          type: boolean
   +          label: 'Render Views filters as select list'
    
    field.field_settings.entity_reference:
   

   I think this is no longer needed as we no longer need that setting? Also for file and image.

2. +++ b/core/modules/views/src/Plugin/views/filter/EntityReference.php
   @@ -0,0 +1,413 @@
   +
   +  /**
   +   * In memory cache of the possible referenced bundles for the entity type.
   +   *
   +   * In case the entity type does not support entity bundles this will be an
   +   * empty array.
   +   *
   +   * @var array
   +   */
   +  protected $referencedPossibleBundles;
   

   why do we need an in memory cache of this information?

   \Drupal\Core\Entity\EntityTypeBundleInfo::getBundleInfo() is already statically cached, if we use that, then we don't neeed this IMHO

3. +++ b/core/modules/views/src/Plugin/views/filter/EntityReference.php
   @@ -0,0 +1,413 @@
   +  /**
   +   * In-memory cache for the entity type ID of the referenced entity.
   +   *
   +   * @var string
   +   */
   +  protected $referencedEntityTypeId;
   

   this also seems not necessary, we just save two methods calls, a method can be useful for this but a static cache seems overkill.

4. +++ b/core/modules/views/src/Plugin/views/filter/EntityReference.php
   @@ -0,0 +1,413 @@
   +  /**
   +   * Validated exposed input that will be set as value in case.
   +   *
   +   * @var array
   +   */
   +  protected $validatedExposedInput;
   

   not sure what's special about this filter that it needs a property for this, I guess this was taken over from the public property of the other class (which I suppose also means it would be hard to deprecae the code there and extend from this. But we could still deprecate it eventually)

5. +++ b/core/modules/views/src/Plugin/views/filter/EntityReference.php
   @@ -0,0 +1,413 @@
   +    $entities = $this->selectionPluginManager->getInstance($this->getSelectionHandlerOptions())->getReferenceableEntities();
   

   this is only needed for the else case, we should not need to load all entities for autocomplete?

6. +++ b/core/modules/views/src/Plugin/views/filter/EntityReference.php
   @@ -0,0 +1,413 @@
   +    $targetType = $this->getReferencedEntityTypeId();
   

   we don't (yet) use camelCase for local variables I think.

7. +++ b/core/modules/views/src/Plugin/views/filter/EntityReference.php
   @@ -0,0 +1,413 @@
   +      if ($this->value && !$this->value['all']) {
   +        $entityArray = $entityStorage->loadMultiple($this->value);
   +      }
   +      else {
   +        $entityArray = [];
   +      }
   

   and we usually don't put the type in variables, this could just be $entities when the code above moves to the else. or $default_entities or something like that.

8. +++ b/core/modules/views/src/Plugin/views/filter/EntityReference.php
   @@ -0,0 +1,413 @@
   +        '#title' => $this->t('Select %entity_typess', ['%entity_types' => $targetType]),
   

   entity types actually have a plural label, check the entity type definition object.

9. +++ b/core/modules/views/src/Plugin/views/filter/EntityReference.php
   @@ -0,0 +1,413 @@
   +
   +      // Show help text if not exposed to end users.
   +      $form['value']['#description'] = t('Leave blank for all. Otherwise, the first selected entity will be the default instead of "Any".');
   +    }
   

   there is a lowercase method for the entity type label, but that's flawed and doesn't really work in many languages.

   You could use a neutral label like "item", we often talk about "content items" or so in the UI.

10. +++ b/core/modules/views/src/Plugin/views/filter/EntityReference.php
    @@ -0,0 +1,413 @@
    +    if ($this->options['type'] != 'auto-complete') {
    

    we use those magic strings a lot, can we make them constants on the class?

11. +++ b/core/modules/views/src/Plugin/views/filter/EntityReference.php
    @@ -0,0 +1,413 @@
    +  protected function getSelectionHandlerOptions() {
    +    $options = ['target_type' => $this->getReferencedEntityTypeId()];
    +    $options['handler_settings']['target_bundles'] = $this->getReferencedBundles();
    +    $options['handler_settings']['sort'] = $this->options['sort'];
    +    return $options;
    

    this needs the same check as the auto-complete above for having bundles? also, can't we re-use this for the selection settings, then we need this logic only once?

12. +++ b/core/modules/views/src/Plugin/views/filter/EntityReference.php
    @@ -0,0 +1,413 @@
    +    // First gather all the entity bundles that can be displayed in this view.
    +    if (array_key_exists('type', $this->view->filter)) {
    +      $displayedBundles = array_keys($this->view->filter['type']->value);
    +    }
    +    else {
    +      $allBundles = $this->entityBundleInfo->getBundleInfo($this->getReferencedEntityTypeId());
    +      $displayedBundles = array_keys($allBundles);
    +    }
    

    this is not an assumption that we can make. This could be a filter on a list of terms, the bundle condition is something else there, or the condition could be based on a relationship or so.

    What I would do is just look for all fields of our field storage definition, you can't use \Drupal\field\Entity\FieldStorageConfig::getBundles(), but as you can see there, that's just a wrapper for the field map, we can use that.

    Then loop over those. In 99% of the cases, all fields are going to have the same allowed reference. But we could just show them in the extra settings like the taxonomy filter does.

Thanks @Berdir for the feedback. I will try to work more on this when I have time.
This is only for 8.2.x, it was not applying cleanly. No changes made.

Well creating patches is not my strongest point :D. Did not include new files..

Did some work. Changed the way getReferencedBundles() works, readded the option of selecting the bundles in the extra config and fixed most of the notes in #54. Now it works with taxonomy (to test comment taxonomy.views.inc:67).

Adding for 8.2.x.

Added check to see if target bundles is a setting on the field to prevent notices.

The patch in #63 successfully allows displaying an exposed entity reference field as a select or autocomplete in a view.

However - it would be a really nice feature to have the ability to order by something other than node ID. For example... node title?

The last patch appears to still work with 8.3.x.

In order to not block this issue, I added a new task for the sorting feature (patch included).
See Entity reference view filter, ability to order values by selected field

The patch in #63 messes up the reverse relationship handler because it re-assigns the variable $field_name.
The foreach that ensures the filter id is set to entity_reference should use another variable name.
Re-rolled a patch against 8.3.x, should work with 8.4.x too.

I'm excited to see progress on this issue. As more builders use entity reference instead of taxonomy for expressing relationships, we will be bumping into the entity reference limitations more. I like the implementation in #10.

The patch in #63 is breaking for me in a total unrelated condition. I have a view of taxonomy_terms and am adding an entity reference display. When I add a relationship to the view which uses a taxonomy term entity reference field, the module incorrectly builds the query adding a 'target_id' to the reference field of the query, resulting in a SQL error looking for *_target_id_target_id. This was on Drupal 8.2.x.

I recently upgraded my DEV site to Drupal 8.3.x and build the entity referernce view display just fine, without the patch installed. When I re-applied the patch (successfully) to 8.3.x, loading a page with my view, or the view itself results in the following error page below.

Would like to provide more testing and information, but don't have time ATM.

Exception: No entity type for field type on view commodities in Drupal\views\Plugin\views\HandlerBase->getEntityType() (line 697 of core/modules/views/src/Plugin/views/HandlerBase.php).
Drupal\views\Plugin\views\filter\Bundle->init(Object, Object, Array) (Line: 888)
Drupal\views\Plugin\views\display\DisplayPluginBase->getHandlers('filter') (Line: 1029)
Drupal\views\ViewExecutable->_initHandler('filter', Array) (Line: 887)
Drupal\views\ViewExecutable->initHandlers() (Line: 2245)
Drupal\views\Plugin\views\display\DisplayPluginBase->preExecute() (Line: 1678)
Drupal\views\ViewExecutable->preExecute(Array) (Line: 1613)
Drupal\views\ViewExecutable->executeDisplay('entity_reference_1', Array) (Line: 220)
Drupal\views\Plugin\EntityReferenceSelection\ViewsSelection->getReferenceableEntities() (Line: 561)
Drupal\Core\Field\Plugin\Field\FieldType\EntityReferenceItem->getSettableOptions(Object) (Line: 116)
Drupal\Core\Field\Plugin\Field\FieldWidget\OptionsWidgetBase->getOptions(Object) (Line: 34)
Drupal\Core\Field\Plugin\Field\FieldWidget\OptionsSelectWidget->formElement(Object, 0, Array, Array, Object) (Line: 322)
Drupal\Core\Field\WidgetBase->formSingleElement(Object, 0, Array, Array, Object) (Line: 85)
Drupal\Core\Field\WidgetBase->form(Object, Array, Object) (Line: 168)
Drupal\Core\Entity\Entity\EntityFormDisplay->buildForm(Object, Array, Object) (Line: 122)
Drupal\Core\Entity\ContentEntityForm->form(Array, Object) (Line: 98)
Drupal\node\NodeForm->form(Array, Object) (Line: 115)
Drupal\Core\Entity\EntityForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 514)
Drupal\Core\Form\FormBuilder->retrieveForm('node_pickup_form', Object) (Line: 271)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 48)
Drupal\Core\Entity\EntityFormBuilder->getForm(Object) (Line: 113)
Drupal\node\Controller\NodeController->add(Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 574)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
call_user_func_array(Object, Array) (Line: 144)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 64)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 656)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Hi there,

There is an issue with ManyToOne discovered in #2559961: ManyToOneHelper ignores group configuration for some cases:

ManyToOneHelper forces INNER JOINs

Here is an example of a buggy behavior (with the fix-group-condition patch applied).
Content:

Result:

It's currently not decided how to fix the INNER JOIN issue nor whether it needs to be fixed.

As the taxonomy reference field is currently the only field that uses ManyToOne, I was going to create "Stop using TaxonomyIndexTid for taxonomy reference fields" issue. But then I found this issue and I don't really know what to do. So, I just inform you about the bug.

What about to make it working when the field is included on a search index and those values you want them into a dropdown or autocomplete?

1. +++ b/core/modules/views/src/Plugin/views/filter/EntityReference.php
   @@ -0,0 +1,449 @@
   +    if ($bundleType = $this->getReferencedEntityType()->getBundleEntityType()) {
   +      /** @var \Drupal\Core\Entity\EntityInterface[] $bundles */
   +      $bundles = $this->entityTypeManger->getStorage($bundleType)->loadMultiple();
   +
   +      $bundle_options = [];
   +      foreach ($this->getReferencedBundles() as $bundle) {
   +        $bundle_options[$bundle] = $bundles[$bundle]->label();
   +      }
   +
   

   One could argue that it would be better to use the bundle info service, given that those labels might come from something else.

2. +++ b/core/modules/views/src/Plugin/views/filter/EntityReference.php
   @@ -0,0 +1,449 @@
   +      $form_state->setError($form['target_bundles'], 'You must choose at least one target bundle.');
   

   This message should be translatable.

3. +++ b/core/modules/views/src/Plugin/views/filter/EntityReference.php
   @@ -0,0 +1,449 @@
   +      /** @var \Drupal\node\NodeStorageInterface $entity_storage */
   

   Nitpick: Let's use EntityStorageInterface

4. +++ b/core/modules/views/src/Plugin/views/filter/EntityReference.php
   @@ -0,0 +1,449 @@
   +        '#default_value' => EntityAutocomplete::getEntityLabels($entities),
   

   Its nice to have this helper method available

5. +++ b/core/modules/views/src/Plugin/views/filter/EntityReference.php
   @@ -0,0 +1,449 @@
   +      $entities = $this->selectionPluginManager->getInstance($this->getHandlerOptions())->getReferenceableEntities();
   +      $options = [];
   +      foreach ($entities as $bundle) {
   +        foreach ($bundle as $id => $entityLabel) {
   +          $options[$id] = $entityLabel;
   +        }
   +      }
   

   We could use the tricky to flatten the array in one line: call_user_func_array('array_merge', $entities), but I believe writing it out is actually easier to read.

6. +++ b/core/modules/views/src/Plugin/views/filter/EntityReference.php
   @@ -0,0 +1,449 @@
   +
   +      if ($exposed = $form_state->get('exposed')) {
   +        $identifier = $this->options['expose']['identifier'];
   +
   +        if (!empty($this->options['expose']['reduce'])) {
   +          $options = $this->reduceValueOptions($options);
   +
   +          if (!empty($this->options['expose']['multiple']) && empty($this->options['expose']['required'])) {
   +            $default_value = [];
   +          }
   +        }
   +
   +        if (empty($this->options['expose']['multiple'])) {
   +          if (empty($this->options['expose']['required']) && (empty($default_value) || !empty($this->options['expose']['reduce']))) {
   +            $default_value = 'All';
   +          }
   +          elseif (empty($default_value)) {
   +            $keys = array_keys($options);
   +            $default_value = array_shift($keys);
   +          }
   +          // Due to https://www.drupal.org/node/1464174 there is a chance that
   +          // [''] was saved in the admin ui. Let's choose a safe default value.
   +          elseif ($default_value == ['']) {
   +            $default_value = 'All';
   +          }
   +          else {
   +            $copy = $default_value;
   +            $default_value = array_shift($copy);
   +          }
   +        }
   +      }
   

   Not your fault, but all this code is just quite sad ...

7. +++ b/core/modules/views/src/Plugin/views/filter/EntityReference.php
   @@ -0,0 +1,449 @@
   +    $ids = array();
   

   Let's ensure to have short array syntax

8. +++ b/core/modules/views/src/Plugin/views/filter/EntityReference.php
   @@ -0,0 +1,449 @@
   +  protected function getReferencedBundles() {
   

   This method name doesn't really communicate that these are all referencable bundles.

9. +++ b/core/modules/views/views.views.inc
   @@ -720,6 +720,13 @@ function core_field_views_data(FieldStorageConfigInterface $field_storage) {
    
   +    // Render filters as select lists.
   +    foreach ($table_data as $table_field_name => $table_field_data) {
   +      if (isset($table_field_data['filter']) && $table_field_name != 'delta') {
   +        $data[$table_name][$table_field_name]['filter']['id'] = 'entity_reference';
   +      }
   +    }
   

   Don't we need some update path for that?

I guess you meant to set this back to NW?

I am using this patch on a field that references users on 8.3.4.

I keep getting those warnings:

Warning: array_keys() expects parameter 1 to be array, null given in Drupal\views\Plugin\views\filter\EntityReference->getReferencedBundles() (line 440 of core/modules/views/src/Plugin/views/filter/EntityReference.php).
Warning: array_merge(): Argument #2 is not an array in Drupal\views\Plugin\views\filter\EntityReference->getReferencedBundles() (line 441 of core/modules/views/src/Plugin/views/filter/EntityReference.php).  

Well I am back to this feature. I've just encountered the case where I need the handler to work with fields that use view selection handling.

Have taught about it and it seems too difficult to handle that case in the best generic way. For example if two bundles implementing the same field are displayed in the view and both these fields have view selection handling, how would you provide the available values for the filter? The ideal way would be merging the two views results for the filter values. To make things more complicated add the possibility for an additional bundle with same field that references directly bundles. Then the two views results would have to be combined with all the entities of that bundle. Which makes this even more complicated, how do you handle all this with the autocomplete field? We would need a new selection handler.

I've will implement this in an easier, limited way for the moment: in the settings form you will have to select whether you want to add bundles for filter possibilities or ONE view selection handler if any exists.

Added support for view selections, described in #80. Also addressed most of the comments in #76. Point 9 I didn't understand the request.

Seems to work with my manual tests.

In "Possible selection values from" the only option is "View result". The "View selection" is empty. Do I have to create a specific view before I can choose it?

@Lukas von Blarer you have to have the "reference method" setting as "Views: Filter by an entity reference view" and NOT "default" (for at least one content-field) on the reference field for which you are adding the filter.

Ah ok. I'll try that. Thank you!

I think it would be better if the user could choose to use a differnt view or display for the selection. It gives the possibility to restrict the exposed filters in a flexible way. As an example: I am using it to only display options that yield results.

I did a rough implementation of that. It is missing a few things:

• The possibility to provide arguments.
• A method to get the supported views. There is duplicated code in buildExtraOptionsForm() and collectFieldsReferenceHandlers().
• The ability to use the default behavior not to use a view.

Subscribe ++ (ttt)

The first fail in the test:
Schema key views.view.test_filter_entity_reference:display.default.display_options.filters.status.value failed with: variable type is boolean but applied schema class is Drupal\Core\TypedData\Plugin\DataType\StringData
looks like to be in
+++ b/core/modules/views/tests/modules/views_test_config/test_views/views.view.test_filter_entity_reference.yml
where it says:

+filters:
+        status:
+          value: true

must say:

+filters:
+        status:
+          value: '1'

But i haven't tested it.

Subscribe+

Fixed #89

I tested #92 manually. Works as expected but one thing I noticed: If there is more than one field referencing the same entity but only one is set to use a reference type of "Views: filter by an entity reference view" and the other uses "Standard" you'll get a warning:

Notice: Undefined index: user_admin_people:entity_reference_1 in Drupal\views\Plugin\views\filter\EntityReference->getHandlerOptions() (line 501 of core/modules/views/src/Plugin/views/filter/EntityReference.php). 

Some additional comments after just trying to make this usable with search_api:

1. Style: This and other non-class variables should use snake_case instead of camelCase:
   
   + $entityType = $this->getReferencedEntityType();
+ if ($bundleType = $entityType->getBundleEntityType()) {
2. collectFieldsReferenceHandlers expects there to be bundles to filter by, we should check this first.
   
   

       // For entity types that do not offer bundles, don't try to look them up.
       $entity_type = $this->getReferencedEntityType();
       if ($bundle_type = $entity_type->getBundleEntityType()) {
         $field_definitions = $this->getBundleFieldDefinitions();
   
         // For each entity bundle check if this field is set and if yes collect
         // the configured target entity bundles.
         foreach ($field_definitions as $field) {
           /* ... */
         }
       }
   

3. Why do we only check entity reference displays if there are bundles in collectFieldsReferenceHandlers? Shouldn't the Views select options always be available, like when there are no bundles (think: user entities), and offer all possible view/display options, not just if configured in the field's settings?
4. The $view->get('base_table') check makes this unusable with differently named source tables, we could ask the ViewExecutable for its entity type instead of the View configuration entity:
   
   if (($executable = Views::getView($view_id)) && $executable->getBaseEntityType() == $entity_type) {

With these changes, collectFieldsReferenceHandlers could look like this:

  protected function collectFieldsReferenceHandlers() {
    $referenced_bundles = [];
    $view_selection_handlers = [];

    // For entity types that do not offer bundles, don't try to look them up.
    $entity_type = $this->getReferencedEntityType();
    if ($bundle_type = $entity_type->getBundleEntityType()) {
      $field_definitions = $this->getBundleFieldDefinitions();

      // For each entity bundle check if this field is set and if yes collect
      // the configured target entity bundles.
      foreach ($field_definitions as $field) {
        $handler_settings = $field->getSetting('handler_settings');

        // Get the configured reference-able bundles.
        if (isset($handler_settings['target_bundles']) && is_array($handler_settings['target_bundles'])) {
          $target_bundles = array_keys($handler_settings['target_bundles']);
          $referenced_bundles = array_merge($referenced_bundles, $target_bundles);
        }
      }
    }

    // Check any entity_reference View that might be relevant.
    $view_selection_options = [];
    $displays = Views::getApplicableViews('entity_reference_display');
    foreach ($displays as $data) {
      list($view_id, $display_id) = $data;
      if (($executable = Views::getView($view_id)) && $executable->getBaseEntityType() == $entity_type) {
        $view_settings = [
          'view_name' => $view_id,
          'display_name' => $display_id,
          'arguments' => []
        ];

        $id = implode(':', [$view_settings['view_name'], $view_settings['display_name']]);
        $view_selection_handlers[$id] = $view_settings;
      }
    }

    return [
      // Remove duplicates and reset the array keying.
      'bundles' => array_values(array_unique($referenced_bundles)),
      'views' => $view_selection_handlers,
    ];
  }

Could we make this work with config entities? That would be awesome.

I've just run into a situation where target entities without bundles (in this case: selecting a commerce shop) cause the view to break when using the patch. It seems, my suggestions from #96 are not only useful for search_api, but actually required in general.

@Insasse, do you have an example use case for selecting config entities? Have you tried the new handler (possibly with the changes to collectFieldsReferenceHandlers), or is it not compatible at all?

I've updated the patch for my remarks in #96. Marking as needs review for the testbot.

We still need to address #95 and possibly think about #97.

Edit: There are also some coding standards to fix, just went over EntityReference.php.

Also noticed that if (in_array($view->get('base_table'), [$entityType->getBaseTable(), $entityType->getDataTable()])) { is duplicated, so the second instance of that should also be updated according to #96. Maybe even put the logic into a reusable method.

Yes in our project we have 2 config entities that are used to control the output for our content, we want to filter our nodes by that.
I tried the patch but it is not working for me in this case.

Here is a tutorial related to this issue: https://atendesigngroup.com/blog/drupal-8-views-entity-reference-exposed-filter-select-list.

This is a prosaic question, in the current state, right now, if I have a view of Articles, and I would like to filter it by a reference field that references a Basic Page, for example, what value do I put in the "Value" field in order to get the field to work? I don't mind putting a value in there but it is not clear what value to put in there. I've tried the node ID of the referenced basic page, the URL, and a text string of the Node Title, and nothing works, Is that filter not working at all in its current state?

I've created a relationship to the reference field on Article etc. But I can't get the list to filter by the value in the reference field.

If someone could point me to some documentation on that, I'd appreciate it. I've looked all over but I guess I'm using the wrong key word phrases.

EDIT: posted a support request here: https://www.drupal.org/project/drupal/issues/2955011

I think it is unfortunate that we are hardcoding all those extra settings and then require all that mapping between selection plugins and hardcoded views settings.

I started looking into re-using the plugins to allow them all and to expose their own settings forms, so we don't have to reinvent things. That is quite a lot of work, but I did manage to make the extra fields show up at least. Just posting an interdiff with my current progress as I need to switch to something else for now.

Some of the exposed settings might be a bit bogus (like the one about auto-creating entities) but I think that's not a big deal.

Not actually less code yet, as I just added a bunch of early returns, but I hope to get there eventually.

Trying to continue from where @Berdir finished.

Made some progress. Views are now selectable and everything is actually works. Feedback appreciated.

I think we need to convert test from Drupal\views_ui\Tests\UITestBase to \Drupal\Tests\views_ui\Functional\UITestBase. Don't have time for it at the moment.

Wrong interdiffs...

Still on it, found issues with filter schema and test view.

Removed copy paste element validate property, disabled auto create option, fixed formatting, fixed sorting handling for default handler, removed unused variable, fixed filter schema, fixed test view, converted test to functional.

Test should go green, at least its green locally.

Tests are green! :)

The configuration form doesn't work if the field is a user a reference. If you select 'User role' under 'Filter By' the role selector does not appear. Investigating...

Went through and made sure the handler settings configuration worked. Removed all of the duplicated hard coded references to target bundles and let the Selection plugins massage the configuration. Tested with user entity reference fields (limiting by roles).

Still needed the hack for the AJAXified Selection plugin configuration forms.

Hi, is this patch "safe" to use on production or is still under development? Thanks :-)

Currently I'm using on a test website and it works for me :-)

Very nice. I'm using this one in my beta production environment now, and while I hit a fairly minor UI bug with views preview (#3027858: Exposed filter widget change triggers 'illegal choice' resp. 'no matching entity') it has been taken over from TaxonomyIndexTid. Actually I also hit a second bug taken over from TaxonomyIndexTid, but have failed to reproduce. Using a generic filter plugin for all kinds of referenced items is a good thing - it will get the code more exposure, so bugs will evaporate over time.

The patch in #114 produces an error when trying to change the filter value, because the entity_autocomplete element requires full entity objects (or NULL), not the names. We should change getDefaultSelectedEntityLabels to getDefaultSelectedEntities. In case of large amounts of entities, can we just set the value to NULL, instead of loading all of them? The autocomplete input has a length limit iirc ...

/**
   * {@inheritdoc}
   */
  protected function valueForm(&$form, FormStateInterface $form_state) {
    $referenced_type = $this->getReferencedEntityType();

    if ($this->options['type'] == self::AUTO_COMPLETE_TYPE) {
      $form['value'] = [
        '#title' => $this->t('Select %entity_types', ['%entity_types' => $referenced_type->getPluralLabel()]),
        '#type' => 'entity_autocomplete',
        '#default_value' => $this->getDefaultSelectedEntities(),
        '#tags' => TRUE,
        // <snip>

  /**
   * Gets the default value for auto-complete field.
   *
   * @return \Drupal\Core\Entity\EntityInterface[]|null
   *   The auto-complete value.
   */
  protected function getDefaultSelectedEntities() {
    $referenced_type_id = $this->getReferencedEntityType()->id();
    /** @var \Drupal\Core\Entity\EntityStorageInterface $entity_storage */
    $entity_storage = $this->entityTypeManger->getStorage($referenced_type_id);

    if ($this->value && !isset($this->value['all'])) {
      return $entity_storage->loadMultiple($this->value);
    }
  }

To make life easier for site builders, we should probably also improve the admin summary of the filter. Maybe add the selected entities to the value options and rely on the parent class?

  public function getValueOptions() {
    if (!isset($this->valueOptions)) {
      $this->valueOptions = [];
    }

    if (empty($this->valueOptions) && $this->options['type'] === static::SELECT_LIST_TYPE) {
      $this->valueOptions = $this->buildReferenceEntityOptions();
    }
    if (empty($this->valueOptions) && $this->options['type'] === static::AUTO_COMPLETE_TYPE) {
      if (empty($this->value) || isset($this->value['all'])) {
        $this->valueOptions['all'] = $this->t('All');
      }
      else {
        // @todo Better yet: map entity id => entity label.
        $this->valueOptions = array_combine($this->value, $this->value);
      }
    }

    return $this->valueOptions;
  }

Displaying the entity id is easiest, but the entity label should be better still. Unfortunately, EntityAutocomplete::getEntityLabels($entities) returns a string instead of an array - and exploding on , would need to consider escaping etc.

• Fixed the bug described in #117. '#process_default_value' => FALSE did the job. Note that this is also the additional bug I mentioned in #116, so another box checked.
• Fixed the admin summary, per #118.
• Removed some unused leftover code
• Renamed a misspelled property and two camel-cased local variables.

Hopefully still green, so no new bugs introduced. Two or three more glitches to be fixed, and then we should be relatively close.

Fixed coding standards + another instance of a camelCased local variable

1) Note that when the filter is not exposed, operator is either of (one/all/none of) and no default is chosen I'm now getting a validation error:

No valid values found on filter: name_of_filter

There's no validation error when using the TaxonomyIndexTid filter in the same configuration, but I guess it's correct that the warning is there now, so it's another previously existing, now fixed bug rather than a new bug, if I'm right. We might want to catch the validation error earlier though by marking the default value field required in this case.

2) In any case, if the operator is unary (one of empty / not empty), we need to hide the value field, both for the default value and in the exposed filter. StringFilter, NumericFilter and others get it right, TaxonomyIndexTid doesn't. I'm preparing another patch that fixes this.

I looked at both the code and the UI of all implementations, and the code is horrible and (at least if I got it right) not even a single filter class gets it right:

• Normally, the default value field is only shown, if the operation is binary (i.e. not one of the unary "empty" and "not empty" ops).
• However, if both the filter AND the operation are exposed AND the operation has a proper identifier, we ẃant the default value field always to be shown. Even if the default operation is unary, the end user may choose another op, and for that case we might want to have a default filter value.

Enclosed patch puts that logic into code, and from what I know, it works correctly and is much cleaner codewise.

However, the actual result looks a bit weird, as the "expose operator" checkbox may show/hide the filter value field above. In the end, I have no idea why the "expose operator" checkbox along with its identifier field is located in the right column under the filter value and not in the left column right under the operator it belongs to. Changing this, however, is beyond the scope of this issue.

I'm happy to accept if someone convinces me that I missed something and got it wrong. But if the logic is approved here, it should be rolled out to the rest of the filter subsystem anyway.

Forgot to post a small screencast showing how my new logic looks like.
Ignore this one please.

Oops, this is the right video. Sorry for the noise.

However, the actual result looks a bit weird, as the "expose operator" checkbox may show/hide the filter value field above. In the end, I have no idea why the "expose operator" checkbox along with its identifier field is located in the right column under the filter value and not in the left column right under the operator it belongs to. Changing this, however, is beyond the scope of this issue.

We can actually decide later if fixing the twig template is out of scope or not. I'm enclosing another patch that provisionally fixes the two-column floatbox design. Further layout changes should in any case be covered in a followup.

Fixed field visibility for the actual exposed filter, too. Reorganized the code a bit to avoid any unnecessary HTML if the operator is not exposed, while avoiding redundant code as well. Manually tested, should be fine now. Sorry for the noise.

Forgot one instance of the internal variable $exposed I renamed to $is_exposed to be a bit more verbose. Hope it is green now.

Test coverage needs to be further expanded.

Next step: I'm rebasing TaxonomyIndexTid on the new generic EntityReference filter.

Unfortunately I need a minor patch to the TermSelection handler to make hierarchy prefixes optional. This currently isn't configurable in the EntityReference selector, and my patch doesn't add any UI to entity references, though it might be easily done in a followup, if desired.

Also, I'm hiding the 'auto_create_bundle' handler setting which doesn't apply to views.

Surprisingly everything works well, including the otherwise unchanged TaxonomyIndexTidDepth filter that is now based on the new TaxonomyIndexTid. We might want to figure out, if and how we can reintegrate the depth option into the main TaxonomyIndexTid filter, but that's definitely out of scope here.

Let's see if the tests agree, and if they do, that's something. Finally, our test coverage should be considerably better now, because of prexisting tests against TaxonomyIndexTid. If everything stays green, we should be veery close.

Config is one of the remaining problems.
Added the dependencies that the taxonomy tests are expecting:

• Entity bundles chosen at handler-level, exported by TaxonomyIndexTid (actually the handler's job, unsure about this)
• DefaultSelectedEntities, right at the EntityReference filter

However, if we stick with the current config structure (bundles in handler_settings), then this will not be compatible with preexisting views and we need an upgrade path. We however need an upgrade path anyway, as the old TaxonomyIndexTid had the (single allowed) bundle under the key 'vid', and we certainly want this to be consistent across all entity types.

I also refactored EntityReference::getDefaultSelectedEntityLabels into getDefaultSelectedEntities as previously proposed by @ckaotik. The previous method was far too specific to be reused anywhere except for autocomplete default values.

Let's see if the tests go green, in which case I would be done for now. We still need a decision on how to proceed with the bundle config as well as the upgrade path for TaxonomyIndexTid. Input on this and more generally a thorough code review would be welcome!

Renamed the 'type' setting to 'widget' both to be clearer (there are so many "types") and more accurate (select or autocomplete aren't different "types" of filters, they are widgets).

Also renamed the values 'select-list' to 'select' and 'auto-complete' to 'autocomplete' to be more in line with how we call it elsewhere.

Config is tricky, and on my local testbed I continue to get 3 errors, but at least it should be a bit closer to green now, and I'm definitely running out of time for today. Input welcome.

Fixed one of the three failures. Minor glitch introduced by myself, should be okay now.

The two remaining ones:

• The wizard test, yes: It has to be adapted to the new config schema.
• The other one (TaxonomyIndexTidUiTest) I don't know.
  

  views.view.test_filter_taxonomy_index_tid:display.default.display_options.filters.tid.type missing schema

  Yes, it's missing schema, but it shouldn't be there in the first place after being renamed to 'widget'.

Feel free to step in as I've run completely out of time now.

Apart from that some input is needed what this weird 'error_message' setting in the old TaxonomyTermTid filter was meant to accomplish. Apart from the setting, I didn't find any code related to it, so almost certain it was useless and can be fully removed.

Fixed the two failing tests in TaxonomyIndexTidUiTest. For one, it manually tries to change the filter 'type', now officially 'widget'. Also, 'target_bundles' may not just be empty but not set at all, courtesy of the handler, so we need to check its existence.

The only test that should still fail is the wizard. I'd need some more time to figure it out.
But in the end, I think we need a maintainer to decide if we want to go ahead with this handler architecture at all or not.

Think (or better: hope) I finally got it right: the ConfigSchemaChecker kept throwing exceptions. This may only have started with patch #133 when I introduced the dependency calculations. Obviously only those triggered the ConfigSchemaChecker, because until #131 there were only some foreseeable test failures.

Now I fixed the Node view wizard (which now allows as many tags fields and as many bundles as desired). The ConfigSchemaChecker kept complaining, but the schema should be correct now. Config-inspector says OK, too.

[edit: There is at least one more preexisting issue with AJAX in the handler setting, at least until the view is saved. Manual testing suggests it is related to the "AJAX hack" mentioned in #114. If someone can reproduce it, they might get an idea what's wrong there. We probably need test coverage for that dialog, too.

Otherwise, the tests have gone green and we may proceed to a thorough code review. I'm unassigning for now.]

I have not looked at the code, but have tested this out in terms of functionality and was able to:

1. Convert existing entity reference fields to use select dropdowns
2. Add new entity reference fields as exposed filters using select dropdowns
3. Combine this with Better Exposed Filters to render the select dropdowns as radio buttons (single) and checkboxes (multiple)

Thank you for all of the effort that has been put into this thus far.

Hm. After applying patch from #141 views edit window stopped working - server memory limit (about 512Mb) and maximum execution time allowed were not enough for it. Maybe because of potentional long select list of referenced entities (about 2k)....

@scott_euser Related to your comment in #142, I'm actually running into an issue with Better Exposed Filters returning the error Notice: Undefined index: type in /var/www/docroot/modules/contrib/better_exposed_filters/src/Plugin/views/exposed_form/BetterExposedFilters.php on line 325

It seems to be looking for 'type' instead of 'widget' on taxonomy terms. I know it's related to Better Exposed Filters, but wanted to note since I saw your comment about it working.

I opened an issue and related it back to this issue, as well as added a patch.

But this makes me wonder if changing the 'type' to widget could potentially cause problems with other modules.

Just a straight reroll of #141 against current dev.
Interdiff didn't work in this case, added a plain diff instead.

Just some minor tidbits.

@scott_euser: Thanks! Yes I think it's working quite flawlessly. I've been using it in production for a week or two now, and it turned out very nice. There's however still the AJAX issue in the handler setting until the view is saved once (as described in #141). If someone can figure that out, that'd be awesome. I probably won't have time for that in the next two weeks.

@skylord: Yes, a select list with 2k entities will bring it down. We could set a limit of max. 100 select options, otherwise switching to autocomplete. Finally, a select list with 2k entities isn't usable either.

@grathbone: Thanks for filing BEF issue #3032467: Issue with upcoming change to Entity Reference/Taxonomy filters in Core. Indeed, $options['type'] is now $options['widget']. We might however do some BC on Core side.

I have a commerce2 project.
I have this patch installed #141, which applies on Drupal 8.6.10.
This patch works on Commerce product fields on entity_references.
I have plenty of Custom Content Entities (let's say A,B,C,D,E,F....)
They have entity_reference between them ... lets say B has a *a_ref* which references A.

In a view that shows B entities (whatever display let's say table) - the exposed filter of field *a_ref* CAN'T be chosen as Select.

What am i missing ?

Patch #148 still applies against 8.8 and 8.7, which is where new features/tasks are landing.

The last one still applying against 8.6 is #141.

The patch from #141 applied cleanly against 8.6.14, and works great.

Patch #141 applied cleanly on 8.6.15 with no errors.

Patch working as expected and used with Better Exposed filters module as well...

Thank you everybody for your hard work!

I will review the patch in depth tomorrow but, can we address the new two coding standards warnings added?

+          'target_bundles' => $target_bundles,
+          'sort' => [
+            'field' => 'name',
+            'direction' => 'asc'
+          ],
+          'auto_create' => FALSE,
+          'auto_create_bundle' => ''
+        ],

Missing coma after 'direction' => 'asc' and 'auto_create_bundle' => ''.

I found a small problem with both patches (#141 for 8.6.x) and (#148 for 8.7.x)

When add a new entity reference field within the filter section of a view, the settings page made available due to patch #141 will automatically open...

Now, try to change the option of Reference Method select list field from Default to Views: Filter by an entity reference view and you will notice that: the "settings" page will auto-close and the "Add Filter" page will re-open again.

Expected Behavior:
The settings page must remain open/active in order to continue the configuration of the filter field.