Leading slash in link fields and views has different UX

...

So, in the Views UI, there are theoretically some places where we might some day want a link widget, but others (like defining the path for a page display itself) that can only ever be a path from user input. I.e. it's inventing a new path, not referencing an existing one. This latter case is true of path aliases for nodes as well.

I think option 2 has a few sub-cases:

• Require a slash in the UI always, and fail validation if it's not provided.
• Expect a slash, but append it during the submit handler for the plugin (not hither and thither in the codebase) if it's not provided.
• Denote that the slash will automatically be appended in the UI by displaying a / in front of the actual field, which will also help the user understand what to put in the field, and append the slash during submit handling.
• Convert to the link widget some day where appropriate (where it's actually links and not defining a new path).

Also, this slash-or-no-slash expectation for the link widget was considered the best solution UX-wise to support an autocompleted link to a thing (the far more usable option) while still allowing the entry of a specific path without the annoyance of the autocomplete getting in the way. (Edit: so IMO option 3 is not a good choice.) However, it already has a UX tradeoff there for being able to toggle between the autocomplete behavior and the other behavior. I think that being inconsistent or inexplicit about that expectation elsewhere in the UI is seriously confusing and WTFy. So based on that I think this is major.

Several @todo referencing this issue have been added in #2426181: Add a Url::fromUserInput() wrapper method for generating URLs from user-entered paths.

Something to potentially weave into the upcoming usability testing.

Thank you @xjm for pointing the sub-cases for option 2.

Whatever path we choose for fixing this issue should be consistent across the whole system.

This means that in the future other sub-systems or other contrib modules may also have the autocomplete implemented for input of a link OR title, and it makes sense that all these inputs behave in the same way.

The end user does not need to know the difference between defining a path and linking to a path. Then, option 1 is not a good choice.

Maybe this should be more than a patch, but a policy to encourage the use of leading slash and its validation when the input is path definition.

In this case where the input may be either a path definition of a link to a path it should have two validations. The first would check for the leading slash, the other would be responsible for linking to a valid and alre. The presence or not of the leading slash would indicate which validation should be run.

Denote that the slash will automatically be appended in the UI by displaying a / in front of the actual field, which will also help the user understand what to put in the field, and append the slash during submit handling.

I have to assume I was really confused with the leading slash in front of the field. Maybe an input place holder would look better. Actually, I think just a help text with example linking to an existing title and an example defining a internal path would be even better. Do not add the leading slash as a field prefix, because it would be awkward when the user has to input the slash again for a path definition.

In summary:

• linking to an existing path: autocomplete
• defining a path: user must input leading slash
• Do not add / as field prefix - it may be awkward if the user has to input the slash one more time
• Add help text explaining the autocomplete may link to an existing path, or user must add a leading / to define a new one
• Be consistent across the system with this behavior

Moving to Views, as we also need to discuss this issue there.

I would tend to agree with #6. In the future, we could always add explore other niceties like auto-prepending "/" where it's missing in form submit on those fields where we always expect a path. Also agreed that putting a "/" visibly before the field just introduces inconsistency at a different point.

Untagging, and demoting, since this didn't really come up in usability testing. The good news is most people figured out the fact that you could now type a title in the link field. Hooray. So hopefully this inconsistency will bite people less than I initially worried it would.

Linking #2474471: Views page displays do not accept an integer as path as an example of a patch that has to do some dumb things to get around this issue.

This just caught me out, i've just got used to enter /path everywhere, I feel that views should work the same way.

I do stumble on this regularly, consistently.

@yoroy
So you actually vote for using a starting slash in views as well?

Well what I notice is that I always forget to start with a leading slash. So I'd rather not have to think about adding it myself.

@yoroy yup, me too - thats also how I expect it to work.

As the issue summary says #2418017: Implement autocomplete UI for the link widget introduced this slash behaviour. If we come up with a way to keep the autocompletion sort of working, that would be great.

+1 for making the auto-complete forgiving, i.e. by making it auto-complete even without a leading slash. I think this would address the usability concerns.

-1 for making paths without a leading slash valid input. Was discussed at length in #2418017: Implement autocomplete UI for the link widget and elsewhere.

@yoroy and @Bojhan, don't you have this expectation because that's how it worked for the past 10 years? Having a leading slash makes more sense because that's how relative URLs work. That's what relative URLs are. Having a leading slash means this is a valid URL you can copy/paste anywhere in the site — including in your content — and have it work.

I *know* what a relative path is, and still I always make this mistake. Typical example of the difference between how people expect things to work and how it really works under the hood :-)

But isn't this (bad) muscle memory from Drupal 7, 6 and before?

Also, this is not "under the hood" IMO. This is literally moving away from a Drupalism.

Also:

+1 for making the auto-complete forgiving, i.e. by making it auto-complete even without a leading slash. I think this would address the usability concerns.

+1 for making the auto-complete forgiving, i.e. by making it auto-complete even without a leading slash. I think this would address the usability concerns.

So you basically argue for the current behaviour in HEAD, right?

@yoroy and @Bojhan, don't you have this expectation because that's how it worked for the past 10 years? Having a leading slash makes more sense because that's how relative URLs work. That's what relative URLs are. Having a leading slash means this is a valid URL you can copy/paste anywhere in the site — including in your content — and have it work.

Yeah I think there is no system out there where you have to start using a slash in menu links.

This is pretty screwed up in the context of customizing an RSS feed.

I'm trying to use the following config for a views feed display.
Format: RSS Feed
Show: Fields

Mapping "Content: Path" field to the link field passes in "/path-to/node". Note the leading slash... which causes RssFields::render() to add second leading slash and thenUrl::fromUserInput() interprets "path-to" as the host name. Not sure how to work around it.

EDIT: Workaround I found was add an ID field, then a custom text field with "node/{{nid}}" in it... then the url gets replaced with the nice path alias. Good enough.

About #27 see #2673980: RSS view with fields give wrong URL from path field.

Bumping this to major bug and marking #3064119: Symfony\Component\Routing\Exception\MissingMandatoryParametersException: Some mandatory parameters are missing ("taxonomy_term") to generate a URL as duplicate - it's possible to create an unrecoverable view in the UI.

Consistency is one thing, but the other problem (at least in Views' Rewrite Results -> Output this field as a custom link) is that the help text doesn't specify whether there should be a slash or not. The form gets submitted in both cases, with no feedback for as to which form is correct. Is one invalid? There's no way to know. Users have to try both ways and see what happens.

If there were at least an example or guidance here, consistency would be secondary. At least folks would know what to enter in each particular field.

Pretty sure this is a duplicate of #3065720: When creating a Page View in the wizard and setting a path with leading slash (/) the created View display ends up with a double-slash (//), so marking as such.