Make WordPress Core

Opened 17 years ago

Last modified 15 months ago

#3451 reopened defect (bug)

Page URI canonization

Reported by: pah2's profile pah2 Owned by: markjaquith's profile markjaquith
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 2.1
Component: Permalinks Keywords: needs-patch needs-testing close
Focuses: Cc:


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

cannot be reached via

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.

Attachments (1)

3451.canonical.redirect-pages.diff (2.2 KB) - added by DD32 16 years ago.

Download all attachments as: .zip

Change History (25)

#1 @markjaquith
17 years ago

  • Keywords needs-patch added
  • Owner changed from anonymous to markjaquith
  • Status changed from new to assigned
  • Version set to 2.1

For 2.2, I'd like to have some form of automatic URL correction in core... so if you're using and someone puts in or or or or any number of "close, but not quite" URLs, it'll 301 to the real URL. That's good for search engine juice!

#2 @Viper007Bond
17 years ago

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


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:

I cheat and have a page located at 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/.

#3 @foolswisdom
17 years ago

  • Milestone changed from 2.2 to 2.3

#4 @markjaquith
17 years ago

  • Milestone changed from 2.3 to 2.4 (next)

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

#5 @DD32
16 years ago

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)

#6 @Viper007Bond
16 years ago

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

#7 @DD32
16 years ago

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:

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/

#8 follow-up: @Viper007Bond
16 years ago

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.

#9 in reply to: ↑ 8 @DD32
16 years ago

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.

#10 @djr
16 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

#11 @janbrasna
15 years ago

  • Cc janbrasna added
  • Component changed from General to Permalinks
  • Milestone changed from 2.9 to 2.8
  • Summary changed from Page URIs are case-sensitive to Page URI canonization

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.

#12 @janbrasna
15 years ago

  • Keywords permalink slug canonization added

#13 @DD32
15 years ago

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

#14 @Denis-de-Bernardy
15 years ago

  • Milestone changed from 2.8 to Future Release

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

#17 @Denis-de-Bernardy
15 years ago

  • Keywords needs-patch added; has-patch needs-testing removed

#18 @Denis-de-Bernardy
15 years ago

  • Milestone changed from Future Release to 2.9

#19 @hakre
15 years ago

  • Milestone 2.9 deleted
  • Resolution set to fixed
  • Status changed from accepted to closed

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.

#20 @tellyworth
5 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Re-opening as an upstream report from dotorg meta:

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

#21 @SergeyBiryukov
2 years ago

  • Keywords permalink slug canonization removed
  • Milestone set to Awaiting Review

#22 @costdev
2 years ago

  • Keywords needs-testing added

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

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

#23 @sebastienserre
16 months ago

@costdev I do not reproduce either on WordPress 6.1.1

Last edited 16 months ago by sebastienserre (previous) (diff)

#24 @Mte90
15 months ago

  • Keywords close added

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

Note: See TracTickets for help on using tickets.