Add leading slash to paths within 'user-path:' URIs, to allow 'user-path:' URIs to point to the <none> route

But... why? :( We don't do that with either base: nor entity:

#2417333: Add support for user-path: scheme to Url class just got committed so this probably needs some adjustment.

Would also love even a single detail in the issue summary explaining why we are doing this. :)

Thanks for the issue summary update. I still worry this creates confusion though, because it's non-standard from the other schemes.

For argument's sake, can't we just prefix the "/" in the link text field on display for "normal" paths? We will already be manipulating the value anyway to strip out the user-path: part prior to showing it.

For the front page, I would think that would be user-path:<front>
For the jump link, I would think that would be user-path:#jump

Don't want to block this necessarily, but I am concerned that this is going to result in DX headaches. :\ What am I missing?

Yeah, we could potentially just do it for the widget UI for now, though It would be better to literally store the input the user types into the widget.

Discussing with effulgentsia in person, I think we should get the widget working even if it's not storing literal user input and then re-visiting this.

So, let's postpone this until the widget it working as we want. That means we will need to e.g. store user-path:<front> as the replacement for the typed / for now.

I discussed this a bunch with Wim and xjm, and here's what I believe to be the consensus at least between the 3 of us. Posting it here for feedback from others. TL;DR: +1 to this issue. Reasoning:

1. Different schemes are different. Entities, non-entity Drupal pages, and non-Drupal pages are sufficiently different concepts that we should not be constrained to enforce syntax "consistency" in their identifiers. Just like tel:+1-201-555-0123 is not "consistent" with mailto:admin@example.com (leading + vs. not, - delimiter vs. @), each of our schemes can optimize its syntax within its own scope without concern for what the other schemes do.
2. The semantics of user-path is to store a normalized representation of what the user intended to link to when typing a path. With that in mind, I think normalizing that intent into "absolute path" (with leading slash) notation is more logical than "relative path" (no leading slash) notation. When the user enters a path, I think it's clear that the most likely intent is a reference to a resource in the site's structure that is independent of the current Drupal resource that the visitor is viewing. I.e., if the link is to "about", that means "about" regardless of whether I'm currently on the front page, or the "user/login" page. It does not mean the "user/about" page when I'm on the "user/login" page. Such independence is common to represent with a leading slash.
3. UIs may choose to expose the above or not. For example, the autocomplete link widget may have the user start paths with a leading slash in order to disambiguate from node titles which don't start with a leading slash. Another widget, however, might choose to not require users to start paths with a leading slash. This UI choice is independent of user-path syntax. So, whether user-path:/blog or user-path:blog is friendlier to UI users is irrelevant; it is only developers who are affected by this decision, and per above, I think with the leading slash is friendlier for developers due to its greater accuracy in modeling the underlying concept.
4. We should not, however, add a leading slash to base. Or rather, we should follow the semantics of "base URI" defined by the RFC. Which basically translates into base:blog meaning relative to the subfolder that Drupal is installed in, and base:/blog meaning relative to the host (i.e., outside of Drupal's subdirectory).
5. The above difference can be confusing if viewed side-by-side in code. For example, if 'blog' is implemented by Drupal and so you linked to it as user-path:/blog vs. if 'blog' is implemented by another script inside the same subdirectory as Drupal and so you linked to it as base:blog. However, once we add the methods suggested in #2417459: Provide internal API for special schemes and thin public wrappers for user input and non-routed URLs, you won't be viewing things like that side-by-side in code, so per point 1 above, this is almost a non-issue. I'll add a more detailed comment about that specifically in that issue.

1. +++ b/core/lib/Drupal/Core/Url.php
   @@ -319,6 +319,30 @@ protected static function fromEntityUri(array $uri_parts, array $options, $uri)
   +   * To clarify, a few examples of path plus corresponding 'user-path:' URI:
   +   * - 'node/add' -> 'user-path:/node/add'
   +   * - 'node/add?foo=bar' -> 'user-path:/node/add?foo=bar'
   +   * - 'node/add#kitten' -> 'user-path:/node/add#kitten'
   +   * - '<front>' -> 'user-path:/'
   +   * - '<front>foo=bar' -> 'user-path:/?foo=bar'
   +   * - '<front>#kitten' -> 'user-path:/#kitten'
   +   * - '<none>' -> 'user-path:'
   +   * - '<none>foo=bar' -> 'user-path:?foo=bar'
   +   * - '<none>#kitten' -> 'user-path:#kitten'
   +   *
   

   Great documentation.

2. +++ b/core/lib/Drupal/Core/Url.php
   @@ -319,6 +319,30 @@ protected static function fromEntityUri(array $uri_parts, array $options, $uri)
   +   * URIs, we must ensure to not use it in case of the
   +   *
   

   ... this sentence stops in the middle of

3. +++ b/core/modules/link/src/Plugin/Field/FieldWidget/LinkWidget.php
   @@ -53,6 +53,20 @@ protected static function getUriAsDisplayableString($uri) {
   +      // @todo Present the leading slash to the user and hence delete the next
   +      //   block in https://www.drupal.org/node/2418017. There, we will also
   +      //   remove the ability to enter '<front>' or '<none>', we'll expect '/'
   +      //   and '' instead respectively.
   +      $path = parse_url($uri, PHP_URL_PATH);
   +      if ($path === '/') {
   +        $uri_reference = '<front>' . substr($uri_reference, 1);
   +      }
   +      elseif (empty($path)) {
   +        $uri_reference = '<none>' . $uri_reference;
   +      }
   +      else {
   +        $uri_reference = ltrim($uri_reference, '/');
   +      }
   

   I'm not entirely sure whether its a good idea to remove the support for and in the link UI, given that other places like block visibility still supports it. Some kind of consistency is nice.

I just assume it will be green as well

Shoot, I'm sorry, I saw #2216271: Regression: Shortcut links access is not checked first, so this needs a quick re-roll.

While we're waiting for testbot (and these comments aren't going to block a commit):

Different schemes are different. Entities, non-entity Drupal pages, and non-Drupal pages are sufficiently different concepts that we should not be constrained to enforce syntax "consistency" in their identifiers. Just like tel:+1-201-555-0123 is not "consistent" with mailto:admin@example.com (leading + vs. not, - delimiter vs. @), each of our schemes can optimize its syntax within its own scope without concern for what the other schemes do.

Hm? These are both totally consistent. scheme: then paste in the thing you want to link to in full.

And in this respect I can actually understand not prefixing entity: with a slash, because what you want is entity:taxonomy_term/4 not entity:/taxonomy/term/4. Lack of leading slash makes it clear.

The semantics of user-path is to store a normalized representation of what the user intended to link to when typing a path. With that in mind, I think normalizing that intent into "absolute path" (with leading slash) notation is more logical than "relative path" (no leading slash) notation. When the user enters a path, I think it's clear that the most likely intent is a reference to a resource in the site's structure that is independent of the current Drupal resource that the visitor is viewing. I.e., if the link is to "about", that means "about" regardless of whether I'm currently on the front page, or the "user/login" page. It does not mean the "user/about" page when I'm on the "user/login" page. Such independence is common to represent with a leading slash.

Ok, so far so good...

We should not, however, add a leading slash to base. Or rather, we should follow the semantics of "base URI" defined by the RFC. Which basically translates into base:blog meaning relative to the subfolder that Drupal is installed in, and base:/blog meaning relative to the host (i.e., outside of Drupal's subdirectory).

Here's where you lose me. As a web developer for 20 years but one who doesn't have all of the various RFCs memorized (like at least 99.9% of web developers, I would reckon), it's frightfully confusing that when either way you're talking about putting in a link directly to a given URL, and when either way you want "a reference to a resource in the site's structure that is independent of the current Drupal resource that the visitor is viewing." So why would this not also be a leading slash, or else eliminate base: altogether in favour of just user-path: everywhere?

That said... the rationale for this patch makes a lot more sense now thanks to comment #34. And I guess the idea is that whether we bring consistency to base: or not doesn't really matter, because "in theory" if #2417459: Provide internal API for special schemes and thin public wrappers for user input and non-routed URLs makes it in, developers won't be dealing with these raw schemes directly anyway.

So let's get this in, and get to the end of the NJ sprint criticals ASAP so we can take a step back and look at the "big picture" once it's complete, and decide how we want to move from there.

Committed and pushed to 8.0.x. Thanks! See you in #2418017: Implement autocomplete UI for the link widget. :)