Page MenuHomePhabricator

$wgArticlePath = '/$1' fails if also $wgUsePathInfo set to true
Closed, ResolvedPublic


When $wgArticlePath is set to '/$1' for friendly URL's, $wgUsePathInfo cannot also be used. Many installs use both of these in together so that the friendly-rewrite rules map to a PathInfo based request so that un-encoded ampersands and question marks can be used in article titles which aren't allowed if using query-string.

What's happening is that the new extractTitle method in the WebRequest class is returning a title value like "Wiki/index.php" when the request's title is in the query-string. I suspect that it should not be returning anything in when the title is in the query-string and should only be returning a title key when the request is PathInfo-based.

To fix it temporarily on a number of 1.11's that it's happened to I've replaced the WebRequest constructor with the 1.10 version, and made the interpolateTitle method return before doing anything. I've put more detail at

Version: 1.11.x
Severity: major



Event Timeline

bzimport raised the priority of this task from to High.Nov 21 2014, 9:58 PM
bzimport set Reference to bz11428.
bzimport added a subscriber: Unknown Object (MLST).

Our rule for handling the friendly-url rewriting maps the host name (excluding www part) into the file path,
RewriteCond %{REQUEST_URI} ^/(wiki/|files/|[fF]avicon.ico|[rR]obots.txt)
RewriteCond %{HTTP_HOST} ^(www\.)?(.+)$
RewriteRule (.*) /%2$1 [L]

RewriteCond %{HTTP_HOST} ^(www\.)?(.+)$
RewriteRule (.*) /%2/wiki/index.php$1 [L]
When I put ''phpinfo();die;'' into the start of ''index.php'' all the values for PATH_INFO, REQUEST_URI etc appear to be currect for for all forms of URL request eg. /foo, /wiki/index.php?title=foo, /wiki/index.php/foo. But the ''extractTitle'' function is treating the script path and name as the title even if the title is present in query-string or PATH_INFO.

trevor wrote:

Simplest example I have -


Options FollowSymLinks
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)$ index.php?title=$1 [L,QSA]


$wgArticlePath = "$wgScriptPath/$1";

The articles will show, but links containing index.php (such as edit) will attempt to edit an article called Index.php. This appears to be due to changes in WebRequest.php.

diff -uN mediawiki-1.10.2/includes/WebRequest.php mediawiki-1.11.0/includes/WebRequest.php

shardsofmetal wrote:

Patch to correct the error

This patch detects if the beginning of $path is "$wgScriptPath/index$wgScriptExtension". If it is, it simply strips that from the beginning of $path, giving the results desired. The only time this should be a problem is if someone who isn't using rewrite rules wanted a URL of, say, to make the page "Wiki/index.php", which includes the script path and script file in the page name. If desired, I could also make this only work if a variable, something like $wgEnableRewriting is set to true. (In that case, since I think this would help more people than it would hurt, if it hurts any, that the variable should be enabled by default in DefaultSettings.php.)


r29191 should do it. I've used $wgScript specifically and moved it out to the interpolateTitle() loop as an intitial step.

r29192 fixes a stupid cut-n-paste error I made.