Standardize node route names by relationship

What about entity types that don't happen to match their module name?
Our current policy is to namespace routes by their module name.

Initial patch ...

looking at the fails. I am going to remove canonical route name and submit patch again.

Since last patch passed for delete-form, edit-form, version-history, admin-form route name change. I am going to work on canonical route name.

Rerolled

Fix the _entity_access values.

oops -- removed debugging cruft.

Missed fixing one _entity_access value.

Might want to put the brakes on this for now as the patch only covers nodes and not all entities. I believe kgoel was going to finish up with the other entities.

In #19/#20 this was turned into a subissue of #2285413: [Meta] Standardize entity route names and renamed to be just about nodes. You are correct that it was originally a much larger scope.

Rerolled to track HEAD.

Rerolled

Rerolled

What about entity types that don't happen to match their module name?

I think that could use a bit more discussion. What about prefixing with entity? e.g., entity.node.page?

I appreciate the desire to get the route names standardized before beta. Especially since this is just for nodes, and we have many more entity types to go. But, it's counterproductive to get this in and then realize later that the naming convention is problematic and needs to be changed. So let's get it right the first time.

The problems with using a short ENTITY_TYPE.RELATIONSHIP pattern are:

1. We have in core, several entity types not namespaced to their module. For example, date_format. So, if there were a contrib module named date_format, it would need to make sure to not define any routes that happen to have the same name as a link relation.
2. Even if you argue that the above is a separate bug, and that we should either rename those entity types or squat their project names on d.o. to prevent a contrib module from grabbing it, you also have the situation that contrib can add more link relations. For example, in HEAD, user module defines a user.account_settings route that is not an entity route. What happens when a contrib module decides it wants to add an "account-settings" link relation for the user entity type?

By the way, the routes that REST module generates for entity types follows the pattern of either rest.entity.ENTITY_TYPE.HTTP_METHOD or rest.entity.ENTITY_TYPE.HTTP_METHOD.FORMAT. So there's already precedent for using the entity prefix.

Asked to comment in a wscii meeting. I think we should prefix with entity. too. @sun +1'd in IRC too.

working on prefixing with entity

Sorry to be a pain, but also, what is the rationale for using "page" instead of "canonical"? TBH, I prefer entity.node.canonical to entity.node.page. @alexpott and others: thoughts?

EDIT: I realize that "canonical" is longer than "page", but it has a meaning that is more precise, which is why I like it.

"canonical" isn't the only link relationship that can apply to non-HTML. "version-history" and many others can as well. We will need some way for non-HTML routes to occupy a different namespace than HTML routes. Currently, that way is that in HEAD, non-HTML routes for entity operations are prefixed with "rest.entity" while this issue, as of #44, is proposing to prefix HTML routes with "entity". If we're unhappy with "entity" prefix = HTML and "rest.entity" prefix = non-HTML, that's a separate thing for us to figure out, and special-casing "canonical" is neither necessary nor sufficient for addressing that.

Forgot to add one file

  *   see the node.view route in node.routing.yml for an example, and see

Needs fixing in core/modules/system/core.api.php

+++ b/core/modules/node/src/Entity/Node.php
@@ -52,11 +52,11 @@
- *     "canonical" = "node.view",
- *     "delete-form" = "node.delete_confirm",
- *     "edit-form" = "node.page_edit",
- *     "version-history" = "node.revision_overview",
- *     "admin-form" = "node.type_edit"
+ *     "canonical" = "entity.node.page",
+ *     "delete-form" = "entity.node.delete_form",
+ *     "edit-form" = "entity.node.edit_form",
+ *     "version-history" = "entity.node.version_history",
+ *     "admin-form" = "entity.node.admin_form"

I agree with @effulgentsia if we are standardising route names to entity.TYPE.RELATION. It's pointless to make an exception to that standard by saying "except when RELATION=canonical, then make it entity.TYPE.page".

To clarify my position from #49: I agree with #48's requirement that html and non-html need to have different route names. And I think HEAD's approach of prefixing REST-module defined non-HTML routes with "rest." is an acceptable way of achieving that. If we want to change that, however, we need to change it to something that doesn't rely on coming up with format-specific variants of link relation names. Therefore, what makes entity.node.canonical acceptable as an html-only route name isn't that "canonical" as a concept is limited to HTML, but that the entire entity.TYPE.RELATION route naming pattern is something we're limiting to HTML, and that non-HTML routes will need a different pattern entirely (e.g., prefixed with rest.), so that we can have non-HTML routes for version-history and other non-canonical relations just as easily and consistently as for canonical.

Sure, I will work on this later today.

I guess the change record work has to be done.

+++ b/core/modules/content_translation/tests/src/Menu/ContentTranslationLocalTasksTest.php
@@ -53,19 +53,19 @@ public function testBlockAdminDisplay($route, $expected) {
-        'node.revision_overview',
...
+        'entity.node.version_history',

tbh. this is a bit odd given that the feature on entities is called revisions not version_history, but well this is how it is,
given that the link template has that key.

Previously we defined node's admin-form to be the node_type edit route:

*     "admin-form" = "node.type_edit"

That made sense.

Now we've reversed that, node defines an admin_form route that performs node type editing (?!), specifies that as the admin-form link,
and the node type's edit-form now points to the entity.node.admin_form route:

- *     "edit-form" = "node.type_edit",
+ *     "edit-form" = "entity.node.admin_form",

What's the reasoning for this reversal? I find it very confusing.

+++ b/core/modules/node/src/Entity/Node.php
@@ -51,11 +51,11 @@
- *     "admin-form" = "node.type_edit"
...
+ *     "admin-form" = "entity.node.admin_form"

+++ b/core/modules/node/src/Entity/NodeType.php
@@ -36,7 +36,7 @@
- *     "edit-form" = "node.type_edit",
+ *     "edit-form" = "entity.node.admin_form",

I'm confused by this too. We're dealing with node type entities here. Why is this not entity.node_type.edit_form. And therefore programmatically - node's admin form is the edit form for its bundle entity type.

Agreed with #65, also seems odd to me.

missed couple route name in previous patch

Just a reroll, more later.

There seemed to be quite some misunderstanding ...

meh.

Needs a reroll

git ac https://www.drupal.org/files/issues/standardize-entity-routes-2278567-82.patch
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 28682  100 28682    0     0  64249      0 --:--:-- --:--:-- --:--:--  318k
error: patch failed: core/modules/book/src/Form/BookOutlineForm.php:103
error: core/modules/book/src/Form/BookOutlineForm.php: patch does not apply

Meh

Committed cd8986c and pushed to 8.0.x. Thanks!

diff --git a/core/lib/Drupal/Core/Form/FormSubmitterInterface.php b/core/lib/Drupal/Core/Form/FormSubmitterInterface.php
index 15ce4d2..af9b3db 100644
--- a/core/lib/Drupal/Core/Form/FormSubmitterInterface.php
+++ b/core/lib/Drupal/Core/Form/FormSubmitterInterface.php
@@ -59,7 +59,7 @@ public function executeSubmitHandlers(&$form, FormStateInterface &$form_state);
    * @endcode
    * And here is an example of how to redirect to 'node/123?foo=bar#baz':
    * @code
-   * $form_state->setRedirect('node.view',
+   * $form_state->setRedirect('entity.node.canonical',
    *   array('node' => 123),
    *   array(
    *     'query' => array(
diff --git a/core/modules/menu_link_content/src/MenuLinkContentInterface.php b/core/modules/menu_link_content/src/MenuLinkContentInterface.php
index 1f56715..a5d0aca 100644
--- a/core/modules/menu_link_content/src/MenuLinkContentInterface.php
+++ b/core/modules/menu_link_content/src/MenuLinkContentInterface.php
@@ -48,8 +48,8 @@ public function getRouteParameters();
    *
    * @param array $route_parameters
    *   The route parameters, usually derived from the path entered by the
-   *   administrator. For example, for a link to a node with route 'node.view'
-   *   the route needs the node ID as a parameter:
+   *   administrator. For example, for a link to a node with route
+   *   'entity.node.canonical' the route needs the node ID as a parameter:
    *   @code
    *     array('node' => 2)
    *   @endcode
diff --git a/core/modules/system/system.api.php b/core/modules/system/system.api.php
index 57a2e24..3d52bbd 100644
--- a/core/modules/system/system.api.php
+++ b/core/modules/system/system.api.php
@@ -411,9 +411,10 @@ function hook_page_build(&$page) {
  *   patten is the route name followed by a dot and a unique suffix. For
  *   example, an additional logout link might have a machine name of
  *   user.logout.navigation, and default links provided to edit the article and
- *   page content types could use machine names node.type_edit.article and
- *   node.type_edit.page. Since the machine name may be arbitrary, you should
- *   never write code that assumes it is identical to the route name.
+ *   page content types could use machine names
+ *   entity.node_type.edit_form.article and entity.node_type.edit_form.page.
+ *   Since the machine name may be arbitrary, you should never write code that
+ *   assumes it is identical to the route name.
  *
  *   The value corresponding to each machine name key is an associative array
  *   that may contain the following key-value pairs:

Fixed the above during commit.