Last modified: 2012-05-03 02:42:48 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 34684 - [Regression] File pages named having a dollar sign + number redirect to main page
[Regression] File pages named having a dollar sign + number redirect to main ...
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
All All
: High major (vote)
: 1.19.0 release
Assigned To: Nobody - You can work on this!
: code-update-regression
Depends on:
Blocks: 31217
  Show dependency treegraph
Reported: 2012-02-24 09:59 UTC by Michael M.
Modified: 2012-05-03 02:42 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Michael M. 2012-02-24 09:59:33 UTC
Since the update to 1.19 all files containing a dollar sign ($) seem to redirect to the main page. Try the URL or$100_Mexico_Centenario_Reverso.png?action=history (shows history of the main page)

If you need more examples, there are enough in

But$kip works correctly.
Comment 2 Krinkle 2012-02-24 10:26:27 UTC
* Also applies to inexistant page titles with a $ sign:$1_b.jpg
* Only happends when a number follows the $-sign:$a_b.jpg
* Doesn't happen locally for me on 1.19-svn
* Might be Wikimedia specific
Comment 3 Daniel Friesen 2012-02-24 11:36:17 UTC
This was to do with the PathRouter code.

The PathRouter has an extra check to make sure all parameters have been replaced:
For example this:
$router->add( "/wiki/$1", array( 'title' => "$1$2" );
Should never succeed because $2 will never be replaced. It's also just in case there is a situation where it's not a coding error and that is in fact happening because the pattern is not a proper match.

The problem was that it couldn't tell the difference between a $# or $key in the pattern that wasn't replaced and a $1 that came from the url.

I've updated the tests to include some cases I didn't think of originally. And I've fixed the issue by switching to a preg_replace_callback based system.
Comment 4 Antoine "hashar" Musso (WMF) 2012-02-24 13:17:30 UTC
I bisected it to r104274 which was reverted, then bisected it again to r104689.
Comment 5 Antoine "hashar" Musso (WMF) 2012-02-24 13:18:25 UTC
reclosing, looks like it was fixed while I was having lunch :-)

Note You need to log in before you can comment on or make changes to this bug.