See
#2418017-78: Implement autocomplete UI for the link widget →
and onwards for the discussion that sparked this issue.
Drupal has for a long time used the special token <front> in various UIs to represent the front page of the site. In Drupal 8, we are standardizing all user-entered paths in menu links as /something/something (with a leading slash), which matches how those routes are defined in YAML for consistency. It also allows us to give us a way to signify we do not want the autocomplete behaviour of the menu link UI once
📌
Implement autocomplete UI for the link widget
Fixed
makes it in.
However, <front> is inconsistent with this new direction, and so it's proposed to remove this abstraction and instead make it just /, which would match the mental model used for all other links.
And, if we choose to remove <front> support for the link widget, the question is if we must also remove it from other places where we use it, such as the path aliases UI, block visibility rules, etc.
Places where <front> is currently used
At the time of writing there are 216 references in code, tests, or comments. Here's what a simple grep looks like:
https://www.drupal.org/files/issues/front-usages.txt →
Fancier greps welcome!
Reasons to do this
- The primary reason is consistency with the rest of the web (how URLs work).
<front> is a Drupalism. / is not. (It's straight-up how URLs work (if you type <a href="/">home</a> you'll also get a link to the home page). Removing <front> means to have a consistent mental model for the user: thinking about the web, URLs and linking in Drupal, it's all a single, consistent mental model.
<front> is an English string and not translatable, versus / is the same in any language. This fits in well with Drupal 8's goal of being more multilingual-friendly.- We require a leading slash for every path. Hence the
<front> one-off is highly inconsistent; it breaks the mental model.
- Another reason is code simplification. With this change, we're able able to remove a lot of annoying code like this:
- if (strpos($string, '<front>') === 0) {
- $string = '/' . substr($string, strlen('<front>'));
- }
- elseif (strpos($string, '<none>') === 0) {
- $string = substr($string, strlen('<none>'));
- }
- elseif (!in_array($string[0], ['/', '?', '#'])) {
- $string = '/' . $string;
- }
In favour of just:
+ // Detect a schemeless string, map to 'user-path:' URI.
+ elseif (!empty($string) && parse_url($string, PHP_URL_SCHEME) === NULL) {
+ $uri = 'user-path:' . $string;
}
Removing all occurrences would be nice, but not necessary because the places where you can enter "old style path input" is strictly limited to site administrators/site builders, whereas the "new style path input" (i.e. the changes made here to LinkWidget) affect content authors.
Reasons not to do this
- Requires long-time users to unlearn old habits, and invalidates long-standing documentation. It also creates an annoying inconsistency for anyone using both D6/7 and D8 sites at the same time, which will be basically everyone for the next 1-2 years, at least. (Though could combat this concern to some extent by back-porting optional support for "/" to D7.)
- We're now exposing internals of how our backed works to end-users, particularly content authors since this change will affect link fields as well.
<front> is a plain-English string that (to native English speakers) is extremely clear (except for non-native speakers). / is not obvious to a layperson without a background in web development, though is at least intuitively known at some level by anybody who has frequently seen or created links.
- Comparing
https://www.drupal.org/project/i18n →
and
https://www.drupal.org/project/usage/drupal →
shows that approximately 15% of all Drupal sites are successfully using multilingual functionality with the current
<front> token, so this does not seem to be a significant barrier to multilingual adoption. (But that doesn't mean it's not a usability problem or a Drupal WTF.)
-
On removing all occurrences:
- Taking a look at how often
<front> is actually used, it's a not insignificant chunk of work to complete this issue, when we already have several not insignificant chunks of work that we actually need to complete in order to ship Drupal 8.
- It also would require extra work for the D6/D7 migrate team to change all instances of
<front> in various database tables to / (which they already have to do anyway, to migrate them to user-path: URIs).
Goal
It's unclear if the benefits outweigh the impact here, both on users and on the Drupal 8 release timeline. That's what we're here to discuss in this issue.