[meta] Define, then support exact use cases for link generation and storage

I agree with the summary, tomorrow I'll groep the ported ds code to see if I have other cases that arent covered het.

Worth noting #type path. User enters a path but is validated and stored as route name and parameters pair. No uses in core, plans to use in contact module for configurable submission redirects

Having the abstraction of an URL certainly allows us to easily expand the coverage for paths, which also runs through path processing.

As far as the changes to Url, I like what is proposed above. #2347465: Convert all instances of #type link/links to convert to use routes will make it much easier to find all of the edge-cases, since we've found them already.

Today I ran into the following usecase: Create a menu with links to all english posts and all german posts, there is simply no way to do that yet in HEAD.

#1 and #2 would be pretty simple to do with linking to paths - if we allowed it until the Entity Reference Translation tool is available.

So, I'm not sure the issue summary is correct for point#4 - as I understand it, when overriding /blog Views actually replaces the route definition while leaving the original route name.

I expect if we have a fromPath() method it will be widely abused by contrib, regardless of documentation.

@catch - regarding links to English or German, from discussions with dawehner, this is basically a bug that we don't have a way to set or respect the langcode for a link.

e.g. if I want to link specifically to the German version of a post, that langcode needs to taken perhaps from a /de/ prefix on the user-entered path or as an option in the form and stored with the link. That seems like a bug or API-gap in core.

#11: The problem is that paths are the abstraction layer and routes are the implementation, because we have a 1-n relationship between paths and routes.

So any user entered paths needs to be resolved at run time, because we need the context of what the user meant.

e.g. Module X provides /blog for spanish, Module Y provides /blog for english (but with different access rules)

User links to /blog - we cannot determine at user entering time, which route to use as it depends on the context, which we only have at run time.

Even in my own code I cannot reliably link to that path at the moment. Which route do I use?

Already in D7 with hook_url_outbound_alter() you could move 'paths' around and change the underlying "route" / menu entry too, but you would always need to update all content linking to that, so creating a migration problem.

And most people used aliases for that.

So while you could already in practice change "routes" around in D7, this was seldom done, so I expect the use case for actually moving paths around rather low and as you need a content migration strategy anyway, you could also update the code at the same time to match the new paths.

Routes are probably superior when you want to target a specific implementation, but less if you need the abstraction layer of the path or even alias system.

Adding a related issue which should improve the performance in case we start storing the path again, for all entity types.

So we had a very long discussion with dawehner and effulgentsia today -- with a very surprising ending. Not sure whether this is the best issue to post this but it needs to be posted somewhere.

The user might want to link to the entity of type node, number 1 which has an alias content/this-is-a-node-title by entering just that and the expectation is that if the alias changes then the link changes as well. We call this a route reference.

The user might want to link to the about-us page and expect it not to break even if the page under the path changes -- it might point to a new node or page manager or whatever. We call this a path reference. One of the most important results we have arrived to that path references are very literal and outbound processors should not run over them, not even language. If you have a need, then the field is multilingual and you can translate it. Even if you point a path reference to an entity which has translations and the translations have aliases you won't get those automated -- that's the price for path references. The path reference is literal. It is possible even that the "about us" page say in English is a very fancy page manager page and in another language it's just a simple description. This case is covered as well. When creating the link we need to try to route and access check base:// links. We will need to cache the results but access check objects are already carrying caching information -- thanks Wim :)

We need to allow the user to pick which one he wants. It is completely impossible to determine this automatically.

Surprisingly, by accident, HEAD already has support for both with route reference being the default and path reference made available by base://. So the link field description could say "If node/1 has an alias about-us then entering about-us and changing the alias will point to the new alias of node/1. Linking to base://about-us will always point to about-us. base:// can also be used to link paths on the same host as Drupal but not handled by Drupal."

That is good and as long as custom code can also use

Link::createFromUrl(Url::fromUri('base://some-path'))

which is then access checked, this is totally fine.

My only ask (and aspilicious had the same idea) is to make this API more accessible, so that

Url::fromPath('something') would internally correspond to Url::fromUri('base://something')

And I think there is the whole mis-understanding. I never wanted to support putting in node/1 then have language neg, alias support, etc. be supported (which would be a different url generator), no Url::fromPath() should really be just for what base:// does now (plus the access checks), but it feels less 'hacky', but more legitimate.

We still need to solve the issue of having persistent dynamic routes for views pages or panels, but we talked some in IRC today with dawehner and came up with the idea that a UUID could be supported, which means a dynamic route could be transferred from a view to a panel - without having to migrate all the content.

So a canonical identifier for dynamic routes (and paths).

Also the UX of adding base:// will need a UX re-review of the really nice link interface as currently one could only put in base:// as 'external link', which feels kinda strange.

I'd like to point #2010132: Canonical taxonomy term link for forum vocabulary is broken there's 2 ways to build a aliased path for entities:
1) uri_callback - the most performat but replaces a route name
2) outbound processor - looks a right way because use more runtime context to determine a path, but slow

So time when route becomes a link should be taken into account too.

Ok, based on a mega-call today with various people outlined at these meeting minutes, moved the use cases we determined to a handbook page at https://www.drupal.org/node/2407497 since they'll be useful for any future changes. So the "determine" part is figured out.

The "support" will be defined in sub-issues of #2407505: [meta] Finalize the menu links (and other user-entered paths) system.

I believe that this issue can now be closed.