Problem/Motivation
Providing a UI for an entity type involves a lot of boilerplate code.
In particular, three YML files have to be provided:
- MODULE.links.menu.yml
- MODULE.links.task.yml
- MODULE.links.action.yml
These contain repetitive boilerplate code, where furthermore it's very easy to make a mistake and match up the route names incorrectly.
Proposed resolution
Add a new handler type for entities, 'link_provider'. This defines menu, task, and action links for an entity type.
Provide two link provider handlers in the Entity component that follow the standard admin UI pattern (for example, as used by Media module's entity types):
- DefaultContentEntityLinkProvider
-- defines a local task link for the collection under admin/content, alongside the Content admin listing
-- defines a menu link for the collection as well, so it appears in the admin toolbar
-- defines the 'add new entity' action link on the collection page
-- defines a set of local tasks link for view/edit/delete for a single entity
- DefaultConfigEntityLinkProvider
-- defines a menu link for the collection under admin/structure
-- defines the edit form local task link, which allows Field UI to attach its own tasks for the case that this config entity is the bundle for a content entity.
Both of these link provider handler classes expect to find the route names created by core's route_provider classes.
Entity types that customize their route provider to change or add routes would need to use their own link_provider handler (or keep using hardcoded link plugins of course).
Remaining tasks
- Get a review from one of the managers of the plugin system. YAML plugins are not discoverable in core/lib (unlike annotation-based plugins), and so the current patch declares the plugin derivatives that are in core/lib/Core/Entity in system module's YAML files. This approach needs framework manager review.
Follow-ons
Convert core's entity types to use these handlers. This is left as as follow-up, because changing an entity type to use a link provider handlers will cause the plugin IDs of the link plugins to change. It's not clear whether the BC policy on plugin IDs applies to menu plugins, and there is no policy or defined way on how to handle YAML plugin ID changes -- see #2922451: [policy no patch] Make it possible to mark plugins as deprecated.
User interface changes
None.