Last modified: 2014-10-17 21:56:32 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 T16779, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 14779 - {{#ifexist}} does not recognise URL encoded titles
{{#ifexist}} does not recognise URL encoded titles
Status: RESOLVED INVALID
Product: MediaWiki extensions
Classification: Unclassified
ParserFunctions (Other open bugs)
unspecified
All All
: Low normal with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://test.wikipedia.org/wiki/User:R...
:
Depends on:
Blocks: 16474
  Show dependency treegraph
 
Reported: 2008-07-10 10:07 UTC by Raimond Spekking
Modified: 2014-10-17 21:56 UTC (History)
6 users (show)

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


Attachments

Description Raimond Spekking 2008-07-10 10:07:46 UTC
{{#ifexist}} does not recognise URL encoded filenames, see URL for testcase.

I fixed it with r37387 but Brion didn't like the fix at this point.

With r37420 he reverted:

Revert r37387 "Let the {{#ifexist}} works with encoded URLs too. See testcase"
Causes regression for titles containing "+".
Proper fix here is to move the existing % decoding into Title::newFromText or
Title::secureAndSplit so it's done automatically, rather than attempting to
replicate it, with the potential of getting it wrong like this, every place we
decide to accept titles


Sticking it to Bugzilla for the moment until I have time (or another dev ;-) )
Comment 1 René Kijewski 2009-01-03 02:49:04 UTC
Maybe the underlaying Sanitizer::decodeCharReferences could be changed?
{{titleparts}} is even worse affected by the bug: It only returns the input.
I tried to provide a patch, but I got confused with the mathematics of converting URL encode to UTF-8. ;-)

I don't know if someone needs might it, but this it the regex for proper URL encoded characters:
/(%[0-7][0-9A-Za-z])
|(%[CDcd][0-9A-Za-z]%[89ABab][0-9A-Za-z])
|(%[Ee][0-9A-Za-z](?:%[89ABab][0-9A-Za-z]){2})
|(%[Ff][0-7](?:%[89ABab][0-9A-Za-z]){3})/x
Comment 2 René Kijewski 2009-01-03 15:24:33 UTC
Wouldn't rawurldecode do it well? But I think it should go directly to Title::newFromText.

<http://de.php.net/manual/en/function.rawurldecode.php>: "Note: rawurldecode() does not decode plus symbols ('+') into spaces. urldecode() does"
Comment 3 Brion Vibber 2009-01-04 03:32:21 UTC
Sanitizer::decodeCharReferences *must not* attempt to deal with URL percent-encoding, as that would cause corruption of totally unrelated HTML output.

Probably the Sanitizer::decodeCharReferences() and the %-check & urldecode() both belong in either Title:newFromText or directly into Title::secureAndSplit() to ensure that titles are being consistently handled at the low-level; this means the various checks at higher levels should be checked and mostly pulled out.

There are probably a number of related bugs still open on this issue; be good to make sure they're all tied together.
Comment 4 Umherirrender 2009-07-01 17:29:54 UTC
fullurl has no problem with urlencoded pages:

{{fullurl:{{FULLPAGENAME}}}} and {{fullurl:{{FULLPAGENAMEE}}}} gives the same result.

CoreParserFunctions.php has the description - since r15276
$title = Title::newFromText( $s );
# Due to order of execution of a lot of bits, the values might be encoded
# before arriving here; if that's true, then the title can't be created
# and the variable will fail. If we can't get a decent title from the first
# attempt, url-decode and try for a second.
if( is_null( $title ) )
  $title = Title::newFromUrl( urldecode( $s ) );

#ifexist has not this and only try to get the title from text and not from URL second.

I do not know this is a possible solution. I am not so familiar with MediaWiki or PHP to say, this is good or not. I can only give you a place, who this works. Maybe you can adapt from there.
Comment 5 Platonides 2010-02-13 15:10:16 UTC
You got it right. Fixed r62436
Comment 6 Tim Starling 2010-02-19 07:15:29 UTC
I don't see why this is a bug. It doesn't recognise URL-encoded file names because the parameter is the file name, not the URL. I don't see the need to take MediaWiki apart and put it back together again when you could just fix your broken #ifexist calls.
Comment 7 Umherirrender 2010-03-03 11:49:39 UTC
This is not only a problem of file names. I have add a example (see url).
Comment 8 Tim Landscheidt 2012-04-14 18:52:35 UTC
Rereading this, I have to concur with comment 6.  This must have blocked some use case of mine in the past so I CC'd but I don't remember it and neither do the other comments explain why it is a bug from their points of view.  I propose closing as INVALID.
Comment 9 Tim Landscheidt 2012-05-14 21:09:26 UTC
Thus closing as INVALID.

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


Navigation
Links