Entity Reference Plugins have weird behaviour around their ID and other properties which make them a timesink when trying to create one.
This should be fixed -- see #2649712: Entity reference selection plugins break when not following a weird ID pattern (which also has several developers commenting on how they've wasted time figuring it out).
A fix will not be straightforward, so until that lands, the documentation should be improved so we stop wasting developers' time.
Things to decide here before a patch is worked on:
- where should the docs go: the plugin manager / the plugin base class / the plugin interface?
- what do the docs need to say?
To start with:
- An ERSP must declare its ID and group in one of the following forms:
-- group: GROUP, id: GROUP:ID (the id has the group as a prefix)
-- group: ID, id: ID (the id and the group are identical)
- the weight property is not used to order them in the UI, but rather to select the 'best' plugin within a group
| Comment | File | Size | Author |
|---|---|---|---|
| #26 | 2945789-ersp-26.patch | 1.46 KB | jcisio |
| #19 | 2945789-19.patch | 1.04 KB | ravi.shankar |
| #16 | 2945789-16.patch | 1.54 KB | ravi.shankar |
| #12 | 2945789-ERS-plugin-quirks-12.patch | 1.03 KB | jcisio |
| #11 | 2945789-ERS-plugin-quirks.patch | 1.03 KB | jcisio |
Comments
Comment #2
mpotter commentedOh yes ++ please. I spent hours banging my head trying to understand why my custom Selection plugin wasn't being discovered until I finally ran across this series of issues. The only example I could find in core was Views, which has the "group: views" and "ID: views" second form. But it never occurred to me the ID would matter.
Thanks for posting this!
Comment #3
joachim commented@mpotter Is there anything you found that I've not listed in the summary?
Comment #4
kristiaanvandeneyndeThanks for drawing attention to this!
Comment #6
jcisio commentedWhere to document it? I don't see any page on drupal.org. Maybe update \Drupal\Core\Entity\Annotation\EntityReferenceSelection?
Comment #7
kristiaanvandeneyndeIf there is a documentation page on DO it should definitely be mentioned there too. But I agree that the annotation might be the best place to have something, as that's where most developers (the target audience for this issue) will look.
Comment #8
joachim commentedI am not sure where developers are most likely to look for guidance. My hunch is the interface, as the annotation is more out of the way in the file structure.
Comment #9
kristiaanvandeneyndeWhy not both? :) Where one refers the reader to the other.
Comment #10
joachim commentedYup, good idea!
Comment #11
jcisio commentedHow about this? The annotation and the interface are cross referenced so there is no need to put it in both places. Only in the annotation there are comments about the properties.
Comment #12
jcisio commentedNew patch with link to the actual issue, not to this one.
Comment #13
joachim commentedThe overall text is good.
> The annotation and the interface are cross referenced so there is no need to put it in both places.
I'm not seeing that cross-reference. Unless you mean just the basic cross-reference.
But it would be good for the interface to say something like "See the annotation for quirks concerning implementation of plugins of this type."
Comment #15
jonathanshawComment #16
ravi.shankar commentedI have done this patch on Drupal-8.8.x-dev
Comment #17
jungleFirst time saw @var arrayoptional
Comment #18
joachim commentedI also wouldn't bother getting into the detail of whether this line needs a final full stop of not. That's not a fix related to this issue.
Apart from that and the comment in #17, this patch looks good! Nearly there!
Comment #19
ravi.shankar commentedComment #20
joachim commentedLooks good. Thanks for the patch!
Comment #23
shashikant_chauhan commentedThis patch shouldn't fail as it's just updating the document.
Queueing the patch for retesting.
Comment #24
init90Back to RBTC
Comment #25
alexpottEither this shouldn't be here - it adds nothing to the current docs... or it should be an @todo to update these docs as a result of whatever is chosen to do in that issue. In order to not hold the much more important part of actually documenting this...
I was going to fix this on commit by removing the @see but then I saw the follwoing docs for \Drupal\Core\Entity\Annotation\EntityReferenceSelection::$group in the file:
We need to update them so they actually work because according to these docs they won;t
Comment #26
jcisio commentedNice catch @alexpott.
Comment #27
jonathanshawComment #28
alexpottCommitted and pushed 96dad7dc08 to 9.0.x and 24c3d0a2d6 to 8.9.x and 5ba7940278 to 8.8.x. Thanks!
I removed the @todo - it doesn't really add anything. If #2649712: Entity reference selection plugins break when not following a weird ID pattern changes how this works then it has to update the docs... that's just part of that issue. The @todo doesn't really add anything other than maintenance burden.
Backported to 8.8.x as a docs fix.