Page URI canonization

[pah2]

The nice permalink URIs for posts or categories are case-insensitive, but the page URIs are not.

e.g. ​http://matt.wordpress.com/about/
cannot be reached via
​http://matt.wordpress.com/About/

This results in 404s being returned when a user incorrectly gets the case of the URI wrong. This is particularly a problem for weblogs that have migrated old pages to WordPress, and have external pages pointing to them with varying case applied to the URIs.

[markjaquith]

For 2.2, I'd like to have some form of automatic URL correction in core... so if you're using ​http://example.com/about/ and someone puts in ​http://example.com/About/ or ​http://www.example.com/about/ or ​http://example.com/About/ or ​http://example.com/?page_id=2 or any number of "close, but not quite" URLs, it'll 301 to the real URL. That's good for search engine juice!

[Viper007Bond]

For the record, page ID & lack of trailing slash (which we should also address) is currently accomplished via ​a great plugin which I use.

Examples:

​http://www.viper007bond.com/about

​http://www.viper007bond.com/?page_id=43

However, if we put something like this into the core, it needs a filter or a hook. That plugin currently has exclusion regex which is super helpful.

For example, this is my permalink structure:

​http://www.viper007bond.com/archives/2006/12/01/blog-upgraded/

I cheat and have a page located at ​http://www.viper007bond.com/archives/. With the current code, you can't do that without breaking all your post permalinks (at least in 2.0.x it did). I accomplished it via a custom mod_rewrite rule in my .htaccess that loads up index.php/post-archives/.

[markjaquith]

Not handled by current canonical redirect code, but it's too late to start working on it.

[DD32]

Should the Canonical redirect redirect it in this case, Or should the page matches be done case insensitivly?

Do search engines treat different capitalised urls as seperate? (thinking double content here)

[Viper007Bond]

My vote goes for redirect to whatever the user entered for the stub. On Linux, you could have a site.com/file.php and a site.com/File.php and those would be two different scripts.

[DD32]

the canonical code redirects ?page_id=43 to the correct page allready.

I've just made a patch up which attempts to redirect pages, However, it may be too greedy for the likes of some.

Lets say i have a page structure like this:

Sub-marine
About Me 
   Sub about me 
      sub-sub about me

The attached patch will redirect:

hostname/wordpress/abOUT-me/ => hostname/wordpress/about-me/
hostname/wordpress/abOUT-me/sub- => hostname/wordpress/about-me/sub-about-me/
hostname/wordpress/abOUT-me/sub-sub => hostname/wordpress/about-me/sub-about-me/sub-sub-about-me/
hostname/wordpress/sub- => hostname/wordpress/sub-marine/
hostname/wordpress/sub-sub => hostname/wordpress/about-me/sub-about-me/sub-sub-about-me/

Now, getting to the greedy part:
It also has the effect of redirecting things like:

hostname/wordpress/a => hostname/wordpress/about-me/
hostname/wordpress/su => hostname/wordpress/sub-marine/
hostname/wordpress/hta => hostname/wordpress/2007/11/05/htaccess/

In the case where there's multiple destinations possible, It selects the uppermost item alphabetically.
So hostname/wordpress/a will choose 'about-me' over 'azzes', and 'about-me' over 'parent/aaaa-sub-page'

If it comes accross a semi-permalink:
hostname/wordpress/perma/structure/post-na it'll still redirect it to that post: hostname/wordpress/perma/structure/post-name/ rather than sending it to hostname/wordpress/post-nam/

[Viper007Bond]

Another possible solution for multiple destinations possible is to pull up the search template and list out all the post/pages for the user to pick from.

[DD32]

Replying to Viper007Bond:

Another possible solution for multiple destinations possible is to pull up the search template and list out all the post/pages for the user to pick from.

Thats a much nicer option IMO.

The present redirect code(in trunk) just redirects it to the first item it comes accross(unordered) that fits the criteria that its managed to find. On second thoughts, that $order statement could probably be hard coded for the query if its to select only one item.

[janbrasna]

Changing Summary since a) the original issue is no longer present in trunk (however it's not canonized, sic) and b) the comments lean towards a different issue - the canonization itself.

Please see revert [9649] and respective #6627 that caused some regression.

[DD32]

See also: #7577 ( Make sure URLs are all lowercase )

[Denis-de-Bernardy]

One day, we'll need to compile a huge ticket with all of the permalink problems...

[Denis-de-Bernardy]

See also: #8038

[Denis-de-Bernardy]

See also: #6627

[hakre]

Not an issue any longer as reported. Will close as fixed. Anyway, as long as pplz are acutally getting a 404 this is not a bug.

[tellyworth]

Re-opening as an upstream report from dotorg meta: ​https://meta.trac.wordpress.org/ticket/4409

I'm not sure this ticket should have been closed, since others were closed as dupes.

[costdev]

I can't seem to reproduce this in 6.1-alpha trunk.

• The links in the ticket's summary all go to the expected page.
• The links in Meta ticket ​4409 all go to the expected page.
• Visiting ​http://localhost/mysite/sAmPlE-pAgE loads the Sample Page.

Adding needs-testing to have another contributor confirm whether this issue still occurs.

[sebastienserre]

@costdev I do not reproduce either on WordPress 6.1.1

[Mte90]

I can confirm too with the latest alpha release as seems that is case insensitive for urls.