Support for entity reference filtering like TaxonomyIndexTid

A fix for the issue when the index field name differs from the entity field name.

Thanks _Archy_ for the review.

Great idea, thanks a lot!

Haven't tested yet, but I'll believe you for the moment that this actually works – which would be great, really simple change for this nice feature!
However, instead of the workaround in init() (which won't work for nested fields), I think you should just set the correct field name in the definition, in _search_api_views_handler_adjustments(). (Come to think of it: created #2867481: Add an alter hook for _search_api_views_handler_adjustments().)
Note, though, that the property path could contain multiple segments, the field name will usually just be the last one (i.e., youd should use Utility::splitPropertyPath()). With that change, this will also work when, e.g., indexing a user reference on a related node.

Also, of course, we'll have to postpone this until the parent issue has been committed AND we depend on the Core version in which it is introduced. (But can properly review, test and work on this once the parent issue has at least been committed.)

Patch rerolled against latest dev.

Just found an issue with this patch for entity reference fields containing references to config entities: #2884779: Values filtered for config entity reference fields

Adding a intval filter for entity in _search_api_views_handler_mapping() is valid for content entities, but this is a problem for fields with references to config entities.

Removed the intval filter to fix this, patch still works fine without it.

Patch rerolled against the changes from parent issue comment https://www.drupal.org/project/drupal/issues/2429699#comment-12243440

This patch works perfectly with the latest ( #107 at the time of writing ) version of the patch in parent.

Improved patch version: removed UncacheableDependencyTrait - because we want to cache exposed entity labels, constructor override and init().

Tested, works like a charm with patch from #2429699-162: Add Views EntityReference filter to be available for all entity reference fields.

Tests still wanted.

This patch is broken by #2674750-10: Views : Issue while using indexed field. Reverted that change to fix it in the attached patch.

#15 did not work for me, it fails with EntityReference class not found:

+++ b/src/Plugin/views/filter/SearchApiReference.php
@@ -0,0 +1,18 @@
+use Drupal\views\Plugin\views\filter\EntityReference;

It seems that this class does not exists, I didn't manage to find it out in VCS.

Hi all,

I've rerolled this patch to work with Drupal core 8.8.4 and the latest patch on the parent issue https://www.drupal.org/project/drupal/issues/2429699:
https://www.drupal.org/files/issues/2020-03-18/drupal-generalize-taxonom...

Essentially there was a race condition which meant the field_name was not set on the definition which was causing the following error:

The website encountered an unexpected error. Please try again later.
TypeError: Argument 1 passed to Drupal\Core\Field\BaseFieldDefinition::createFromFieldStorageDefinition() must implement interface Drupal\Core\Field\FieldStorageDefinitionInterface, null given, called in core/modules/views/src/FieldAPIHandlerTrait.php on line 49 in Drupal\Core\Field\BaseFieldDefinition::createFromFieldStorageDefinition() (line 83 of core/lib/Drupal/Core/Field/BaseFieldDefinition.php). 

There's probably a better way to fix this (open to suggestions), but at least my site runs again now!

Confirm it works in combination with https://www.drupal.org/node/2429699 in D8.9

Fixed to D 9.1

Fixed to D 9.2

Confirmed.

1. Drupal Core 9.3.6 (with Core patch #453 https://www.drupal.org/files/issues/2021-12-02/2429699-453-9.3.x.patch
2. Search API 8.x-1.23 (with above patch #20 https://www.drupal.org/files/issues/2021-10-27/search_api-2858061-20.patch
3. Better Exposed Filters 8.x-5.0

#3253260: Add an entity argument handler would add such functionality specifically for nodes, but without depending on the Core issue. Feedback there would be appreciated regarding whether the patch works for you and whether you think it should be committed while we’re waiting for the Core issue to be finalized and merged.

Fixed to 10.1

The patch in #23 can no longer be applied to the latest Search API 8.x-1.32 with Drupal Core 10.2.5.

I just made a few changes to the patch 23 so that work with the last version of Search API.

Pointing to the new parent issue.

@lucasgrecco: Thanks!

Re-roll of #19 for compatibility with Search API 1.35.

Note that #20 introduces formatting only updates and #25 omits the conflicting, but necessary, update in #15.

The parent issue has finally been merged, so this one is not blocked anymore.
Created an MR with the latest patch, please continue work there.
This still needs automated test coverage before it can get merged. But confirmations that this still works with the version of the parent issue that was now merged would also be welcome.

Re-roll of #27 because it did not apply for me with Search API 1.35

@remco hoeneveld: But your patch works for you? That’s at least good to know. I also updated the MR with the latest changes from HEAD.
Still needs test coverage.

I couldn't get the latest MR to apply on Search API 1.38. Though patch from #30 applies cleanly.

Re-rolled the patch to work with search_api 1.40.0 and added an OOP hook

Should we be hiding branch !159? It looks like !297 is the right one now targeting the OOP hooks

Thanks for attempting to help, @yazanmajadba, but the proper way to move an MR with merge requests forward is to fix the merge conflicts, not to create a new MR. This would have gotten rid of the existing history in the old MR, and made it hard to see the actual changes you made (which introduced code style issues).

Also, still NW for the missing tests. (Apparently I marked the MR as a draft because of that, but I don’t think we do that in general.)

I updated the issue summary so its a bit more clear here.

In addition to test coverage there are also schema errors. With schema errors enable in develop, if you save a view using this filter for example, all the EntityReference filter schema attributes are invalid here. We need to have Search API's entity reference plugin schema extend core's I believe.

In my example, default D11 install:

1. Add field 'Related Articles' to Page
2. Add that field to Search API Database fields
3. Create a View from Search API Database (in my case 'Test Related Articles' is my view name)
4. Add Related Articles as exposed filter

Schema errors for views.view.test_related_articles with the following errors: views.view.test_related_articles:display.default.display_options.filters.field_related_articles.value non-scalar value but not defined as an array (such as mapping or sequence), views.view.test_related_articles:display.default.display_options.filters.field_related_articles.expose.reduce missing schema, views.view.test_related_articles:display.default.display_options.filters.field_related_articles.reduce_duplicates missing schema, views.view.test_related_articles:display.default.display_options.filters.field_related_articles.sub_handler missing schema, views.view.test_related_articles:display.default.display_options.filters.field_related_articles.sub_handler_settings missing schema, views.view.test_related_articles:display.default.display_options.filters.field_related_articles.widget missing schema. These errors mean there is configuration that does not comply with its schema. This is not a fatal error, but it is recommended to fix these issues. For more information on configuration schemas, check out the documentation.

I did also test the upgrade process (create filter first, apply this MR, see what happens - the plain text input changes to an entity reference autocomplete single which is good but probably needs a release note as it'd be a change of behaviour on a live site for someone doing an upgrade. I think the risk there is low because how useful would that filter have even been originally?

Okay schema validation now passes. There was also a fairly major error in the config being saved, it would previously be:

          sub_handler_settings:
            target_bundles:
              article: article
            sort:
              field: _none
              direction: ASC
            auto_create: false
            auto_create_bundle: ''
          'reference_default:node':
            target_bundles:
              article: article
            sort:
              field: _none
              direction: ASC
            auto_create: false
            auto_create_bundle: ''

Ie, saving the sub-handler settings twice. The 'reference_default:node' bit comes from temporary form state used in #3347343: Add Views EntityReference filter to support better UX for exposed filters to allow the user to switch between sub-handlers but gets removed on save into the central 'sub_handler_settings' config. In this extension to it, that no longer happened, so have added code to do that clean-up here borrowing from the parent ::submitExtraOptionsForm() method.

Still NW because of tests, but that should be the last step now.

Test coverage added now too. Had to modify the shared test method ::checkResults() as it was checking entire html content for entity labels, so as soon as those entity labels now also appear in the exposed filter, they led to false positives. Added a comment to the MR to explain.

Hopefully that's enough to get this one over the line!

Environment

• Drupal 10.5.4
• Search API 1.40.0

MR !159 (2858061-entity-reference-filter branch)

Testing

• Created entity reference field field_related_articles on Page content type
• Added field to Search API Database index
• Created View with exposed filter for field_related_articles

---

Results

Before: Filter was only a free text input requiring manual ID entry

After: Filter now supports:
Dropdown (select) widget with list of entity titles
Autocomplete widget for entity search
Both widgets work correctly and filter results properly

Status: Working as expected

Brilliant, thanks a lot, @scott_euser!
I made some tiny adjustments and also temporarily enabled testing against other Drupal versions so we can make sure this doesn’t break anything in Drupal versions that do not yet have the EntityReference filter class. (Though, now that I think about it, it is sure to at least break the new test? Let’s wait and see.)

Anyways, apart from that this looks ready to be merged, though some more feedback (tests, reviews) would of course also be nice.

Hm, interesting. The fail against Drupal 11.3 seems unrelated (see #3560524: Update ignored deprecations with latest from Core) but if this is passing against Drupal versions that do not have the required base class it seems like the test isn’t actually testing the new functionality? I.e., it also passes with the current standard filter plugin?
Or do you have another explanation?

Hmm will take a look (probably next week), thanks for checking!

Hmmmm yeah, actually its perfectly fine now with the issue merged into Core. Instead of search_api_reference it just uses entity_reference plugin. Can use BEF etc to get checkboxes and all the niceties. So actually maybe this is closed outdated? Self-face palm for not rechecking first!

OK, that would of course be great. Thanks for checking!
Can someone else also confirm that this is now resolved with Core versions that include the fix for #3347343: Add Views EntityReference filter to support better UX for exposed filters? If so, or if otherwise noone objects, I guess we can really close this as outdated.

I am finding that this patch is still needed. At least with search_api 1.40.0 and Drupal 10.6.4. I did not do tests with Drupal 11.x.

I have a view that already has an autocomplete entity_reference exposed filter and when I try loading that view without this patch, I get the following error:

InvalidArgumentException: Missing required 'target_type' property for a EntityReferenceSelection plugin. in Drupal\Core\Entity\EntityReferenceSelection\SelectionPluginManager->getInstance() (line 37 of core/lib/Drupal/Core/Entity/EntityReferenceSelection/SelectionPluginManager.php).

Additionally, the current version of the patch doesn't seem to apply to search_api 1.40.0.

@jonmcl: Well, tough luck. Thanks for reporting back!
I’m not quite sure on the steps to reproduce, though. Could you elaborate?

Or would maybe someone be able to provide test coverage for this? Then we could see right away against which Drupal versions this works or fails. (And make sure it keeps working.)

Fixed MR conflicts; now applies cleanly in 1.41.0

Tested in Core 11.4.5.

Leaving it NW per #54