Make WordPress Core

Opened 7 years ago

Closed 3 years ago

#8847 closed defect (bug) (fixed)

Odd "Older Entries" link problem

Reported by: jamesisin Owned by:
Milestone: 3.5 Priority: normal
Severity: normal Version: 2.7
Component: Permalinks Keywords: has-patch
Focuses: Cc:


You can find an in depth discussion of the issue here:


In short, at the bottom of the main pages are links for Older/Newer posts which should look something like this:


However, I have discovered a defect in how these links are being created by WP. All other links generated by WP appear to be unaffected and function as expected.

Here is the scenario.

As you can see from the example above, the WP installation URL includes two capital letters (I and W). This is true of the container and the server is set to ignore case so all is well. However, if we substitute the lowercase letters thus:


the resulting links generated by WP become:


Clearly WP is adding in a superfluous folder hierarchy (and the unnecessary index.php file specification). This breaks the link. (The index.php does not effect the matter, but I include it because it is superfluous.) If one removes the additional inkwell (either case) the URL functions as expected.

No other link created by WP within the site is thus effected (or at least none I could find). There must be something about the code which creates these two (Older/Newer) links which is causing this problem.

I have done quite a bit of testing to ensure that the problem was not being caused by something else. I have disabled all plugins, for instance, to no avail.

I am happy to continue testing if that will be useful to you. Please let me know how I can assist.


Attachments (3)

8847.patch (576 bytes) - added by jakbob 5 years ago.
8847.2.patch (593 bytes) - added by SergeyBiryukov 3 years ago.
8847-test.diff (555 bytes) - added by wonderboymusic 3 years ago.

Download all attachments as: .zip

Change History (26)

comment:1 @jamesisin7 years ago

  • Version changed from 2.7 to 2.7.1

Just stopping in to see if there was any progress or if I can offer any assistance.

comment:2 @Denis-de-Bernardy6 years ago

  • Component changed from General to Template
  • Keywords needs-patch added
  • Milestone set to 2.8

comment:3 @Denis-de-Bernardy6 years ago

Possibly related: #8038

comment:4 @Denis-de-Bernardy6 years ago

  • Milestone changed from 2.8 to Future Release

moving to future pending patch

comment:5 @Denis-de-Bernardy6 years ago

  • Component changed from Template to Permalinks

comment:6 @Denis-de-Bernardy6 years ago

  • Milestone changed from Future Release to 2.9

comment:7 @janeforshort6 years ago

  • Milestone changed from 2.9 to Future Release

Changing to future release. If someone wants this to be put into a specific release for review, add a patch.

comment:8 @hakre6 years ago

Is this confirmed against 2.8 anyway? Maybe the bug doesn't exists any longer. I made a comment to the forums thread as well asking if this applies to the default theme having all plugins deactivated as well.

comment:9 @dd326 years ago

I think this affects CGI-based systems.. Really not sure of that though.. would need to test it out.

comment:10 @jamesisin5 years ago

  • Version changed from 2.7.1 to 3.0.5

Actually it has moved in the exact wrong direction. In 3.0.5 the URL constructed under the above conditions looks like this:


So WP is now adding yet another additional and superfluous layer in the folder hierarchy.

(I tried moving to 3.1 but it borked my blog and I haven't sorted it out as yet.)

comment:11 @SergeyBiryukov5 years ago

  • Version changed from 3.0.5 to 2.7

You shouldn't change the version specified at the ticket creation. It is used to track when the bug was initially noticed/introduced.

@jakbob5 years ago

comment:12 @jakbob5 years ago

Hi. I've done some digging, the problem seams to appear when the Site URL is set to say lowercase, but the user tries to access the site with uppercase. Since many servers are case-insensitive it will work, but WordPress wont recognize the uppercase part as part of the Site URL and will treat it like a query, which is wrong.
My patch makes WordPress match the url case-insensitively, which should remove the problem.

comment:13 @hakre5 years ago

-1 - HTTP URI paths are case-sensitive as well as many file-systems, especially server preferred ones.

comment:14 @SergeyBiryukov4 years ago

  • Keywords has-patch added; needs-patch removed

Related: #13164, #16200

@SergeyBiryukov3 years ago

comment:15 @SergeyBiryukov3 years ago

  • Milestone changed from Future Release to 3.5

Refreshed after [21174] (#18034 was a related bug).

Moving for review along with #13164.

comment:16 @georgestephanis3 years ago

+1 for Sergey's patch.

comment:18 @ryan3 years ago

  • Keywords commit added

comment:19 @nacin3 years ago

In [22298]:

When stripping off a pathinfo home root (/index.php/) do it with case insensitivity. props SergeyBiryukov. fixes #13164. see #8847.

comment:20 @nacin3 years ago

  • Keywords needs-unit-tests close added; has-patch commit removed

Would it be possible to have test coverage for [22298]? (This is the only reason I've left this ticket open.)

@wonderboymusic3 years ago

comment:21 follow-up: @wonderboymusic3 years ago

Added a unit test - it passes but requires this ticket to be marked fixed to run. Someone with commit on UT: commit the patch, por favor?

comment:22 in reply to: ↑ 21 @SergeyBiryukov3 years ago

Replying to wonderboymusic:

Added a unit test - it passes but requires this ticket to be marked fixed to run.

Skipped tests for open tickets can be run by specifying the ticket number as a group:

phpunit --group 8847

comment:23 @SergeyBiryukov3 years ago

  • Keywords has-patch added; needs-unit-tests close removed
  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.