Make WordPress Core

Opened 14 years ago

Closed 12 years ago

#13164 closed defect (bug) (fixed)

'Older posts' broken with IIS and Permalinks enabled

Reported by: thushanfernando's profile thushanfernando Owned by: ruslany's profile ruslany
Milestone: 3.5 Priority: normal
Severity: normal Version:
Component: Permalinks Keywords: iis-support has-patch commit
Focuses: Cc:


When Permalinks is enabled under IIS6 the 'Older posts' link generated has an extra Index.php in the link url for page 2 - subsequent pages are OK.

This has been reproduced on a fresh install of WordPress on IIS6 and IIS7 and on multiple WordPress installations.

This has been an issue I've known for a while but only just recently fixed on my own WordPress install on (2.9.2) but I believe its been there since I first looked at v2.

I've hunted the problem down to wp-includes/link-template.php and the function get_pagenum_link which removes any occurrences of index.php in the $request generated URL.

However the regex needs to be case-insensitive so that any Index.php's in the URL (from IIS folks) are also removed.

Fix is simple - and visible on my own blog. Change:

$request = preg_replace( '|^index\.php|', '', $request);

to include case insensitive replace:

$request = preg_replace( '/|^index\.php|/i', '', $request);

I've attached a patch as well.

Attachments (2)

wordpress.permalink.patch (590 bytes) - added by thushanfernando 14 years ago.
patch to update the regex to cater for case insensitive replaces for index.php
13164.patch (535 bytes) - added by SergeyBiryukov 13 years ago.

Download all attachments as: .zip

Change History (17)

14 years ago

patch to update the regex to cater for case insensitive replaces for index.php

#1 @thushanfernando
14 years ago

An example of an existing unfixed blog that has this issue as reported.

#2 @blogurc
14 years ago

I am also seeing this issue on IIS, where the pagination link for this URL
is broken:
(whereas if I alter the original URL to , the pagination is fine)

I also tracked it down to the same line, and can be fixed by the suggested fix above:
$request = preg_replace( '/|index\.php|/i', , $request);

This is because under IIS, in the function add_query_arg() [in functions.php], the variable $_SERVERREQUEST_URI? returns /Index.php?s=gospel for the request above.

#3 @peaceablewhale
14 years ago

  • Keywords iis-support added

Have no problem in IIS 7.5 with WordPress 3.0.


Which IIS version are you using?

#4 @blogurc
14 years ago

I'm using IIS 7.0.6000.16386 and Wordpress 3.0. What does $_SERVER [ 'REQUEST_URI ' ] return when you are viewing ? As I wrote above, my IIS returns /Index.php?s=gospel

#5 @peaceablewhale
14 years ago

I create a folder called test and a index.php file calling phpinfo(). The results are as follows:

_SERVERREQUEST_URI? /test/?s=gospel
_SERVERSCRIPT_NAME? /test/index.php
_SERVERURL? /test/index.php
_SERVERORIG_PATH_INFO? /test/index.php
_SERVERPHP_SELF? /test/index.php

Are you using the IIS URL Rewrite Module?

#6 @blogurc
14 years ago

It appears that the Index.php setting is coming from Plesk's setup of IIS. We are using Plesk 9.0.1, which sets up a number of Default Documents when creating a site in IIS.

I created a test directory with an index.php file calling phpinfo(). The system uses the value of the Default Document (set within IIS Manager->Sites->>IIS->Default Document). If the system is set up with Index.php amongst the default documents, then it returns "_SERVER[ "REQUEST_URI" ] /test/Index.php?s=gospel", if it is set up with index.php, then it returns "_SERVER[ "REQUEST_URI" ] /test/index.php?s=gospel". The value returned is dependent on the Default Document value, and independent of the case of the filename (index.php or Index.php).

I'd suggest this be fixed to cope with users (or software such as Plesk) setting up IIS with a Default Document in the wrong case.

As an aside, I don't know how the function _wp_filter_taxonomy_base (in wp-includes/reqrite.php) is used, but that also seems to have a case-dependent line: $base = preg_replace( '|/index\.php/|', , $base );

#7 @peaceablewhale
14 years ago

  • Keywords dev-feedback added
  • Owner changed from ryan to ruslany
  • Status changed from new to reviewing

I cannot reproduce the IIS problem. No matter which case (upper or lower) is used in Default Document, IIS respects the string input from HTTP Requests.

i.e. If test/index.php is used, $_SERVERREQUEST_URI? returns /test/index.php; if test/Index.php is used, $_SERVERREQUEST_URI? returns /test/Index.php; if test/InDeX.php is input, $_SERVERREQUEST_URI? returns /test/InDeX.php.

There may be a bug in Plesk or a misconfiguration.

Review to ruslany to gain feedback from IIS Team. Also added dev-feedback to get comment from core developers whether this issue should be fixed.

#8 @blogurc
14 years ago

To be clear, I am requesting test/?s=gospel (no file name), where REQUEST_URI returns the Default Document value. As I think peaceablewhale commented, when I specify a filename, the filename is returned to me in the case I requested it, such as for /test/InDex.php?s=gospel REQUEST_URI returns /test/InDex.php?s=gospel .

#9 @peaceablewhale
14 years ago

  • Keywords dev-feedback removed

REQUEST_URI remains correct for /test/?s=gospel. However, IIS does use the file specified in web.config in other path-related server variables.

_SERVERREQUEST_URI? /test/?s=gospel
_SERVERURL? /test/InDex.php
_SERVERPHP_SELF? /test/InDex.php

A patch is then needed in this case I think, because it is not caused by a bug of IIS.

#10 @nacin
13 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release

#11 @SergeyBiryukov
13 years ago

  • Keywords has-patch added; needs-patch removed

#13 @SergeyBiryukov
12 years ago

  • Milestone changed from Future Release to 3.5

#14 @ryan
12 years ago

  • Keywords commit added

#15 @nacin
12 years ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

In [22298]:

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

Note: See TracTickets for help on using tickets.