DDEV is the official local development tool of Drupal. And like Drupal, DDEV depends on the support of the open source community.We're having an Entity Reference problem over in Views that may need a bit of nudging on the definitions in SelectionInterface. Hopefully this doesn't get too pedantic. This is right at the limit of my comprehension level for entity reference, so if I've misrepresented the problem, please correct me. See related issue 2714089 for context.
Drupal\Core\Entity\EntityReferenceSelection\SelectionInterface has the following definition for getReferencableEntities:
/**
* Gets the list of referenceable entities.
*
* @return array
* A nested array of entities, the first level is keyed by the
* entity bundle, which contains an array of entity labels (escaped),
* keyed by the entity ID.
*/
public function getReferenceableEntities($match = NULL, $match_operator = 'CONTAINS', $limit = 0);
The problem for the views developers is that the definition of "entity labels" here is deemed too rigid. There's a request for Entity Reference to be able to use an Entity Reference View to be able to return labels that are not the labels defined by the entity, but rather arbitrary labels by the Entity Reference View.
Specifically, it's forbidden for Drupal\views\Plugin\EntityReferenceSelection\ViewsSelection::getReferencableEntites to return an arbitrary label, because SelectionInterface::getReferenceableEntities says it must return "entity labels".
My read on is is that there are two paths to resolving this:
1) The definition of SelectionInterface::GetReferencableEntities was never intended to be that strict. "Entity labels" means "labels that most of the time are attached to entities", and modules should be able to return what labels they please.
2) SelectionInterface::GetReferencableEntities was defined as intended, and ViewSelection is overstepping its bounds by implying that an Entity Reference View can return arbitrary labels. Developers instead should be looking to modify Label Callbacks instead of trying to create a view to return labels.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | 2768901-6.patch | 813 bytes | lendude |
Comments
Comment #2
trevorbradley CreditAttribution: trevorbradley commentedComment #3
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedSelectionInterface::getReferencableEntities()was indeed not meant to be that strict on the return values. Let's just remove the 'entity' part and say that we return labels.Comment #4
lendudeShould we also specify if the label can contain HTML? Or that it needs to be sanitised before returning it?
Comment #5
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedYes, let's specify that the label may contain HTML and we already say that the returned labels are escaped.
Comment #6
lendudeWell I think it might help to clearly state that the labels need to be escaped. So how about something like this?
Comment #8
berdirThat looks OK to me. Not sure if this is a feature or task or what exactly :) Changing issue title a bit to clarify that it is "just" a documentation change.
Comment #9
alexpottI think the intention here is to say that the labels are trusted and therefore should be safe for html output. Or maybe because these are used in select lists html is just a big no-no - looking at the implementations.
Comment #10
trevorbradley CreditAttribution: trevorbradley commentedIn the context of my original post, these labels were being used in an autocomplete and I needed them sanitized.
I'd have been more than happy to ensure they were sanitized myself though.
Comment #22
smustgrave CreditAttribution: smustgrave at Mobomo commentedThank you for sharing your idea for improving Drupal.
We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!