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

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T36684, the corresponding Phabricator task for complete and up-to-date bug report information.
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 ...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.19
All All
: High major (vote)
: 1.19.0 release
Assigned To: Nobody - You can work on this!
http://simple.wikipedia.org/wiki/File...
: 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: ---


Attachments

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
https://commons.wikimedia.org/wiki/File:Billete_$100_Mexico_Centenario_Reverso.png?action=history (shows history of the main page)

If you need more examples, there are enough in https://commons.wikimedia.org/wiki/Category:1_United_States_dollar_banknotes.

But https://simple.wikipedia.org/wiki/$kip works correctly.
Comment 2 Krinkle 2012-02-24 10:26:27 UTC
* Also applies to inexistant page titles with a $ sign: https://commons.wikimedia.org/wiki/File:Foo_bar_$1_b.jpg
* Only happends when a number follows the $-sign: https://commons.wikimedia.org/wiki/File:Foo_bar_$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.


Navigation
Links