add an entity Links handler, to provide menu links/tasks/actions for entity types

The Needs Review Queue Bot → tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Added a 10.1 branch and MR.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

The branch is up to date AFAICT.

Looking into MR 3441 I see tests were added so removing that tag.

Remaining tasks mention

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.

So tagging for that.

The 1 failure in the MR seems valid.

Rebased branch 2976861-add-an-entity-Links-handler-to-provide-menu-linkstasksactions-for-entity-types for 9.5 and 2976861-10.1-add-an-entity-Links-handler-to-provide-menu-linkstasksactions-for-entity-types for 10.1.

I have a question about entity collection listing: Is there a guideline, policy or d.o issue about where the entity list should go in the admin menu?
something like:
- if you extend the ContentEntity class, then your entity listing should be under admin/content/my-entity-plural
- if you extend the ConfigEntity class, then your entity listing should be under admin/structure/my-entity-plural

Some of the examples where this "guideline" does not apply:
Shortcuts (ContentEntity from core) listing is under /admin/config/user-interface/shortcut
Taxonomy terms (ContentEntity from core) listing is under /admin/structure/taxonomy/manage/%vocabulary%/overview
Image styles (ConfigEntity from core) listing is under admin/config/media/image-styles
Workflows (ConfigEntity from core) listing is under admin/config/workflow/workflows
Languages (ConfigEntity from core) listing is under admin/config/regional/language
Entity Browsers (ConfigEntity from entity_browser module) listing is under admin/config/content/entity_browser
Newsletters (ConfigEntity from simplenews module) listing is under /admin/config/services/simplenews
QRCodes (ContentEntity from qrcode module) listing is under /admin/config/services/qrcode

There isn't guidance AFAICT.

There's a common pattern for content entity type/content entity type bundle pairs of admin/content and admin/structure.

Beyond that, as you say, there's a lot of variance. But the base classes here are meant to cover the common case and can be extended for other cases.

I have a question about entity collection listing: Is there a guideline, policy or d.o issue about where the entity list should go in the admin menu?

While we were working on the effort to reorganise blocks in the admin UI, we were guided by structured content principles, and we applied these to the Drupal admin menu as follows:

• Content: this is where you create individual items of content (whether that be nodes, blocks, media, etc).
• Structure: this is where you build the structures that your content uses (aka bundles and fields), along with different representations of your structure (thinking Views here).
• Appearance: this is where you decide what the look and feel of your site as a whole (aka selecting a theme, and hopefully in 10.2 the global block layout).

There's a nice organisation there, from individual items up to the whole site.

This isn't formally documented anywhere that I'm aware of (maybe it should be), but we will likely use this to help inform any future reorganisation efforts of the admin UI.

In terms of how that relates to the question on this issue, it allows us to think about this a little more holistically. For collections of content entities, in general those probably fit best under Content; If it's a collection of config entities, those could live under Structure if they facilitate structured content (aka bundles and fields), but those could also live under Configuration if they are not related to structured content.

> For collections of content entities, in general those probably fit best under Content; If it's a collection of config entities, those could live under Structure if they facilitate structured content (aka bundles and fields), but those could also live under Configuration if they are not related to structured content.

Are you suggesting we split DefaultConfigEntityLinksProvider into two classes,

- one for config entities for structured content, under Admin > Structure
- one for config entities that live under Admin > Configuration

In which case, for Configuration config entities, we'd need an entity property to specify the base route.

I've decided not to wait for figuring out how to deprecate plugins.

Instead, we can use alter hooks to ensure that plugin IDs are maintained for node and node_type links. We can remove those in due course. In fact, there is already this exact same handling in node module currently!

A separate problem is that core/modules/views/tests/src/Kernel/TestViewsTest.php is failing on a recursive router rebuild, because of Views. The chain goes like this:

- views data needs to know about routes
- the router is built
- MenuRouterRebuildSubscriber tells MenuLinkManager to rebuild() links
- that calls our new EntityMenuLinkDeriver
- BaseEntityLinksProvider checks routes for things

I'm not sure why this circularity is only coming up in Views, and only in that kernel test. After all, I don't get an error when I go `drush cr` with this MR.

Ok it looks like it IS Views that's somehow the problem, as if I add this kernel test on this branch, it passes:

  public function testRouteBuilderRebuild(): void {
    $this->container->get('router.builder')->rebuild();

    $this->assertTrue(TRUE);
  }