In my example we are looking for entities that could be any one of multiple content types. The default settings, which should work, result in the error: "The entity_lookup plugin found no bundle but destination entity requires one."
My patch removes the constraint of having a bundle so that the query can discover matching entities, regardless of their bundle, and seems to work just fine in my testing.
This takes the related issue #2938112 a step further by saying, we don't even need to look one up, if it isn't provided.
Side note: if there is a rationale why we *must* have a bundle condition on the query (some beartrap I'm missing), it doesn't appear to be documented anywhere.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | interdiff_1_4.txt | 1.41 KB | falco010 |
| #4 | remove_bundle_requirement-2960251-4.patch | 2.46 KB | falco010 |
Comments
Comment #2
seth.e.shaw commentedComment #3
falco010+1
I had the same requirement that I needed to find a node ID that could be in multiple content_types. The patch solved it for me.
Comment #4
falco010When using this patch on other entity lookups I started to receive warnings:
Undefined array key "target_bundles" on $handlerSettings. This was because $handlerSettings could be an empty array.
Therefore I added a guard to check if $handlerSettings is not an empty array.
Patch attached, also added interdiff.
Comment #5
falco010Comment #6
heddnThis will conflict with the work in #2787219: Entity lookup plugin not able to guess config for entity types without bundle. Let's see how it can integrate with the development going into that issue. Also, I consider this more a feature request and less of a bug.