Make it possible to link to an entity by UUID

This Issue started with this text by @dawehner:

> It would be great to provide URLs with UUIDs in their so you can link to them.

> For poormans menu staging you could use menu_link_config and store refs to UUIDs, like uuid/{entity_type}/{uuid}
which page does a 301 redirect to the actual entity page.

I think this issue should stay on focus with the "{entity_type}/{uuid}" plan. Getting the entity_type removed from the urls is interesting but I think this should move to another issue including all the problems and dependencies like #2690747: [PLAN] Create an index of UUIDs → .

Because of symfony and ParamConverter etc. there are many possibilities to fix things in contrib. So I just decided to solve things there. At first I will concentrate on user entities (e.g. "uuid/user/{uuid}") because I need a solution where users should not know their serial uid. After doing some tests today I think this is basically not complicated.

Especially for everything related to nodes, aliases, and redirects things are more complicated. And that's another reason to stay focused on {entity_type} in paths. For me he user part is the most important thing because I don't want to replace the user entity. Since we can create our own entity types with nearly everything a node can do this would be easier. And on the project where I need user/uuid paths I haven't decided yet if I really want to use nodes.

(I will add a comment here when there is a project I will add my solutions.)

Re-roll patch created for 11.x.

Fixed the CCF issue, Please have a look.

Fixed the failed test cases.

Thanks @vsujeetkumar for pushing this forward/keeping patch compatible.

I removed Tasks from issue which are not on focus of this issue:

• [ ]
• [ ]

I'm currently working on a small symfony only project and discovered that it's possible to define multiple routes on an identical path and tested that Drupal 10.3 is compatible with this. For example this documetation:
https://symfony.com/doc/current/routing.html#parameters-validation

I tested the last patch and was wondering why it's working so I found this in the patch code:

/**
+   * {@inheritdoc}
+   */
+  public function processInbound($path, Request $request) {
+    $matches = [];
+    if (preg_match('/^\/([a-z_]+)\/(' . Uuid::VALID_PATTERN . ')$/i', $path, $matches)) {
+      $entity_type_id = $matches[1];
+      $uuid = $matches[2];
+      if ($this->entityTypeManager->hasDefinition($entity_type_id)) {
+        $storage = $this->entityTypeManager->getStorage($entity_type_id);
+        $entity_type = $this->entityTypeManager->getDefinition($entity_type_id);
+        if ($entity_type->hasLinkTemplate('canonical') && $entities = $storage->loadByProperties(['uuid' => $uuid])) {
+          /** @var \Drupal\Core\Entity\EntityInterface $entity */
+          $entity = reset($entities);
+          $path = '/' . ltrim($entity->toUrl()->getInternalPath(), '/');
+        }
+      }
+    }
+    return $path;
+  }

It's interesting that it's working but with this solution we loose the benefit of routing information and debugging etc. I like the idea to just disable integer routes in custom code to only use. If just use an entity_uuid param converter it is possible to use the same controllers for all entity paths e.g. "/user/{user}/edit" with a route 'user.uuid_edit'

I also want to make it possible to avoid user (int) ids in password reset paths where currently {uid} is used. But this maybe something for contrib.

I try to improve in direction of second route as described above.

Before I start with coding want to add some additional comments after thinking about two routes which allows several thinks like the described identical scheme which is now possible with symfony.
Using two route definitions for each involved entity makes it possible to realize many thinks like different access and also different routes. We can also introduce switches to enable uuid Routes of core only if somebody wants. And if somebody want the additional uuid route just as a redirect or with a path pattern like /uuid/user/{uuid}" this can be solved separately in additional code/contrib/custom code etc. So it's possible to solve seo concerns with robots.txt is possible.
In my personal opinion, it's currently a big disadvantage of Drupal that it's not possible to avoid serial IDs especially for users. At any other place I can avoid this easier e.g with not using node and other core entities. The reason why I want to avoid this that I think this is very important for situations when you run a web application where others should not see how many content entities are generated e.g. users, shop carts, issue tickets, mails etc. This gives competitor organizations and persons too much information not everyone likes to share. This is maybe a reason why companies and other organizations didn't choose Drupal.
On the the other side brings a uuid only strategy lots of possibilities to export, archive, re-import or import elsewhere of content without dealing with complex redirection data.
Both areas are my current motivation. Beside users I have already solved everything with custom entities and the wonderful module entity_reference_uuid. But it would be fine to have something more in core like an official uuid param converter. I know Drupal\jsonapi\ParamConverter and maybe start to use this at first.

By the way, loading entities by UUID is not cached, here is the issue ✨ Add static cache for loadEntityByUuid function to store uuid-id pairs in memory Active

@murz Thanks for the input.

I did some research of the current code and the actual patch. I still like to have an uuid everywhere strategy including revision routes. But currently the serial id strategy is deep integrated in a dynamical way. So a complete new strategy especially as dual solution ha a high complexity. So I think this should be postponed until there is more interest and some discussion and decision by core maintainers.

Meanwhile I will solve the user uuid situation in contrib and just created a new project for this: U3ID → . With the U3ID module I can present a prove of concept and maybe something which can move partially to core in future.

I will try to test the current patch against the the dual route concept ASAP on patch /user/{user|u3id_user} if there is a conflict which think it will be. Maybe there are other custom solutions out there based on additional routes which can be affected by the PathProcessor solution of the current patch.

I created additional routes for /user/{uuid} and /user/{uuid}/edit in the u3id module and published already:
https://git.drupalcode.org/project/u3id

1. This is working fine.
2. The pathprocessing from actual patch makes it impossible for such clean route solution. So I strongly recommend to not commit for core. I currently even not recommend to not move to contrib or with add a warning for risks of breaking other code.

There are lot's of concerns against a pure uuid strategy as I read here: [1726734]

For getting forward I suggest to focus on a a minimal improvement:
1. First of all we should provide an entity_uuid ParamConverter. For u3id I copied of the core jsonapi: 🐛 Cannot use UUID as entity ID Needs work
2. Following the initial feature request we can just provide a possibility to access entities based on additional uuid route configurations.
3. Per default we can just do redirections and introduce settings.php options to change behavior to an entity view.

Everything else should be postponed for core until there is a larger support for more uuid in core routes. I'm currently fine with my contrib project u3id and already solved the problem of rendering the serial uid in the canonical html link with replacing the entity view controller and use now the uuid path.

🐛 Cannot use UUID as entity ID Needs work just landed. Time to reconsider this? 😊