Remove leading and trailing slashes in path aliases (and removing dots)

A possible solution would be to sanitize aliases so that incorrect urls like absolute ones are converted to something that will actually be recognizable when requested and point to the same page.

In ver 4.6 I was using absolute urls as path aliases for some static html pages. When I upgraded to 4.7.4 that no longer worked but there was no help given to fix it.
What I found that worked for me is this.
Drupal resides in http:www.mysite.com/drupal. The static page resides at http://www.mysite.com.
The old absolute url path was http://mysite.com/index.html
The new url path that works is ../index.html

Dang, forgot to attach the patch again.

Forgot to say I am using 4.7.4.
At this rate, every time I upgrade to the latest version I loose at least one thing that I need. My last upgrade I lost the album module. This time I lost absolute URLs, authenticated user and all of the usable info under the status column in the users list.
I am beginning to think that upgrading is not a good idea.

New patch for HEAD. This patch trims leading or trailing forward slashes, and removes the warning from the field description. It seems that absolute paths no longer break anything anyway.

Verified issue
Changed url to /my/page/
Upon viewing, was directed to my/page
Editing the page also shows corrected my/page URL
Warning message did not appear in URL setting directions

Ready for commit

I might misunderstand your question but I think maybe the confusion is that the issue has morphed and is now mistitled.

The original issue was about absolute urls, but in head that issue is already fixed and no longer breaks anything. So actually this patch is to fix relative aliases that are misentered, like if someone enters a path /node/14, so that it will just fix it rather than having to include fineprint to warn you not to do it.

Yep, I had a comment in my original patch...

If we anyway have to change the string, we should put improve on the wording:

In path_admin_form():

• "Specify an alternative path by which this data can be accessed." sounds too technical. Instead of "data", we could actually use "page", which would IMHO still be correct and a lot more specific and understandable.
• "For example, type "about" when writing an about page." is misleading here: the about page must already be written, when being aliased here! We could either say "when aliasing an about page" or "to refer to an about page".

In both occurrences:

• I would reorder the sentences and move the example to the end. The quotes might also be misleading, maybe <kbd>about</kbd> is better... (Looks like about then)?
• On the admin page we use the term "path", in nodeapi we use "URL". We should stick with one.

Proposal:
"Specify a path alias by which this page can be accessed. Use a relative path. For example, type <kbd>about</kbd> to refer to an about page."

and

"Optionally specify a path alias by which this node can be accessed. Use a relative path. For example, type <kbd>about</kbd> when writing an about page."

Also it is very misleading that the module is called "Path" (path.module) and the admin page on the other hand "URL aliases". I always intuitively search for a "path" menu entry, then scroll the list down and once I find "URL aliases", I remember: "Ahh, that was the misworded one".

Some comments would be great, since we are mostly done!
All that's left is the correct naming conventions and the wording of two strings (see #19).

So let's start with the most general issue:
The module's name is "path". Right now, the functionality of path aliasing is inconsistently named "URL alias" (mostly), "Path alias", "alternative path".
While core shouldn't generally follow contrib - the important pathauto module is not called URLauto, but pathauto and it consistently uses the terminology "path alias".
Now I think we should make up a decision whether in the functionality be consistently called "Path alias" or "URL alias" in core... some opinions on this, please!

+1 for #22, though this only covers part of the naming issues.

Mainly I was criticizing the inconsistant usage of "URL alias" vs. "Path alias". We would need to unify this to "Path alias" IMO. The enclosed patch covers this. Unfortunately we'd need to rename two permissions, change four more strings and remove one. While this might sound inacceptable, this would IMHO be a large UI improvement and finally streamline the inconsistant naming.

Don't know if we should split that off this issue here, as we moved away from the starting point.
As the trim-slash part we all agree upon should be committed asap, this shouldn't hold back the patch in #22 anyway.

No longer applies to HEAD:

patching file modules/path/path.module
Hunk #1 FAILED at 21.
Hunk #2 FAILED at 37.
Hunk #3 succeeded at 60 with fuzz 2 (offset -4 lines).
Hunk #4 succeeded at 84 (offset -1 lines).
Hunk #5 succeeded at 119 (offset -4 lines).
Hunk #6 FAILED at 126.
Hunk #7 succeeded at 183 (offset 2 lines).
Hunk #8 succeeded at 186 (offset -4 lines).
Hunk #9 FAILED at 201.
4 out of 9 hunks FAILED -- saving rejects to file modules/path/path.module.rej
patching file modules/path/path.admin.inc
Hunk #2 succeeded at 53 (offset 2 lines).
Hunk #4 succeeded at 80 (offset 2 lines).
Hunk #6 succeeded at 126 (offset 2 lines).
Hunk #8 succeeded at 158 (offset 2 lines).
Hunk #10 succeeded at 182 (offset 2 lines).

This is also a large patch that is hard to review, please consider splitting up this patch to make it easier to review quickly.

Robin

Patch removes leading and trailing slashes in user-entered path aliases and adjusts path alias form description text to remove the no-trailing-slash requirement.

I couldn't reproduce the test problem, resubmitting.

tagging, failing test

reroll

Updated patch to fix dot issue noted in #34

Resubmitting for testing, incorporates changes made in #33

Agree - patch modified to trim dots from either end.

Also removes "./" and "/." from aliases which cause page not found errors.

re-rolling for another test...

If we took out the 2 str_replace lines in the patch and just submit the trim slashes functionality, would this then be able to get into D7?

Since #332333: Add a real API to path.module resolved the trim() and str_replace() issues by including trim() in all relevant cases. I believe what's left here is to the update the help text and to check in the alias validation for non-relative URLs. Patch attached to that effect.

Also tagging for backport to D7, though the string updates should probably be left out due to translation issues.

Here is the rerolled patch, for further work.

Still needs tests.

And the patch submitted in #46 and rerolled in #48 is not correct:
It check the alias is not an external url, and set an error if it is. But why? This issue is about trailing slashes. Why is it problem to set an external url for alias? It will works without this patch, I think it isn't a problem.

But the patch don't do anything with trailing slashes, and if we set an alias with them, Drupal will still give a page not found page.

Thanks for the tests. Not sure about the new patch, though... What happened to validation errors for /. in the middle and the updated UI text, though? That's what the url_is_external() bit was for.

Hmmm, I don't think external URLs "work." You end up with URLs like:
http://localhost:8888/d7/http%3A//localhost%3A8888/d7/foo

And it is related. E.g., for especial fun, create a node with this path alias if your site's domain is mysite.com:
http://mysite.com/foo/../

A user might enter an exernal URL for the same reason he or she might enter a relative path using . or .., and I think it makes sense to fail validation on that.

Maybe we just need to expand the scope of this issue?

In any case, the current patch above also does not fix other patterns that result in a 404, like:
/d7/foo/../bar
/d7/foo/./bar
...and I think these at least were in the original scope of the issue.

ran into this again at usability testing.

Wait. Why removing dots? "index.html" is a perfectly valid path alias. If the concern is that people put an entire URL in there, then prefix the field with the site address. (e.g. http://example.com/[_______________________])

But +1000 for stripping out leading/trailing slashes. That's just silly to do to people.

updating tags

And here's a painful video showing the Google Usability study where someone entered a path with a leading slash and got an error.