Problem/Motivation
When presenting an entity for interaction by a content author, many factors are considered:
- What is the entity type?
- What is the entity ID?
- What is the revision?
- What is the translation?
- Other things?
Some of these things are codified in places like \Drupal\Core\ParamConverter\EntityConverter
But that is not an API that is reusable.
Additionally, the current best practice for retrieving an entity is:
$entity = $this->entityTypeManager->getStorage($entity_type_id)->load($entity_id);
Yet this bypasses all access, revision checking, translation handling, etc.
Core provides a service for loading entities: \Drupal\Core\Entity\EntityRepositoryInterface
But it only provides other helper methods for edge cases, not the 80% case.
Proposed resolution
Expand EntityRepositoryInterface to include methods for:
- retrieving the canonical entity variant matching the specified context: this is typically the variant that would be displayed on the entity's canonical route.
- retrieving the active entity variant matching the specified context: this is the variant that is suitable for editing and previewing.
In this issue the only contextual information actually used is the (content) language, however the plan is to implement a more complete revision negotiation logic allowing to attach contextual information to each revision and allowing to support multiple modules relying on pending revisions at the same time, without them having to code against each other. This follow-up work is tracked at #3023194: [PP-3] Add parallel revisioning support: there we will expand on the implementation provided here to implement the full solution.
The API introduced here will only take care of negotiating the fittest variant for the specified context, access control will need to be applied on top of that.
See #31, #35, #49, #53, #81 for details.
Remaining tasks
Find consensus on the method names: the debate is currently between keeping a terminology close to what we have been using so far in core (active variant vs canonical variant, where variant is the generic terminology we use for both revisions and translations) and adopting something closer to what is used in RFC 5829. See #80 and #82. In the former case we still are not sure whether a "variant" suffix in the method names is useful to improve DX or on the contrary makes things unnecessarily scary.
User interface changes
None
API changes
Only additions
Data model changes
None