Relative URLs should not start with / (slash)

Well, I suppose - but on the other hand, the system I'm using to validate urls doesn't know what kind of a url you were trying to make - it just knows that what you entered doesn't pass any of the regexes that define what's legal. It's a little silly saying "Don't start local links with /" in an error message if the user was trying to enter a non-local url.

Is there a reason that URLs with a leading / are not accepted?

It's standard throughout Drupal that /node/1 is not valid entered into a form field, where node/1 is.

I suspect it's related to how the url() function works.

I encountered this issue and at first considered it a bug since "/node/1" is certainly a valid URL for a link target.

However, when the Link module renders/themes a URL, the URL gets run through url(), which translates a path like "node/1" to "/node/1" (if the Drupal base path is "/"). So I think it would help to note that when a relative URL is entered, it is relative to Drupal's base path.

This also means that if you're doing your own theming of a raw link field value, you should run the URL value through url().

I would still consider this a bug. We have always trainer our users to consider urls that start with a slash to be relative to the root url, and urls that don't to be relative to the page they are on, since this is html standards. Just because drupal does things differently in the back end, doesn't mean we should expose our users to non html compliant standards. Its not a big issue, but I just wanted to say +1 for this addition.

+1 I just encountered someone confused by this (them and myself included).

Preceding / causing issue in Views when trying to use value from a link field formatted as URL, as plain text as the link path value of the Output this field as a link option in the Rewrite Results section of the field settings config.

Relative urls aren't working at all in some cases. If the link output is displayed on a page using an alias with a slash in it (for example content/mypage), then a link entered as node/1 will be directed to content/node/1.

I'm not convinced this is important yet, and I'm setting it back to the 6.x, because there isn't a 7.x release yet.

Folks are, as always, welcome to provide patches for review.

I suspect I'm running into this. I have a content type that contains an image field and a link field. I have a view with two fields. The first is the link field "as plain text", excluded from the display. The second is the image field "output field as a link" using the first field as the link URL. The resulting link is like "http://node/123" (drops the hostname.)

OK. I see what's happening in the code, and it makes sense. The "URL, as plain text" runs the URL through url() and returns that.

For local paths (e.g., taxonomy/term/123), this will return /taxonomy/term/123.

Sensible. Except.

When this is used in Views or as a token passed into a field that runs the token'd text through url() again, we get //taxonomy/term/123 (arguably a bug in url()).

So, here is a patch that adds a new link view option: "URL, as entered." It runs the URL through check_plain(), but not url() or l(). This can be tokenized appropriately.

@John Franklin:
Your patch doesn't actually solve the orignal post, which was to allow users to enter relative paths with a leading slash.

Your patch actually belongs in this issue (which could be reopened) #478922: Add CCK/views formatter to output raw url path

The best way is to clean the url if internal path begins with / in the validation state.
For example, /node/1 to node/1

Are you agree with that ?

Thank you all for your efforts, but I'm sorry to say that the D6 version is no longer supported.