(Translated by https://www.hiragana.jp/)
⚓ T18474 {{FILEPATH:{{PAGENAME}} }} doesn't work for filenames containing characters that get escaped to HTML entities
Page MenuHomePhabricator

{{FILEPATH:{{PAGENAME}} }} doesn't work for filenames containing characters that get escaped to HTML entities
Open, LowPublicBUG REPORT

Description

Author: phoenixct

Description:
The command {{FILEPATH:{{PAGENAME}} }} in page with non-ASCII characters in name doesn't work.


Version: unspecified
Severity: major
URL: http://commons.wikimedia.org/wiki/Image:Aci_Sant'Antonio.svg

Details

Reference
bz16474

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:29 PM
bzimport set Reference to bz16474.
bzimport added a subscriber: Unknown Object (MLST).

herd wrote:

It isn't unicode, which works fine, it happens with the following characters (which are allowed in page titles): & " ' which, in {{PAGENAME}} and related magic words, get escaped to their HTML entities before parser function expansion: " & ' ... renaming but to reflect this.

A workaround is to use [[Special:Filepath/{{PAGENAME}}]].
http://en.wikipedia.org/wiki/Special:ExpandTemplates?contexttitle=Image%3AAci_Sant%27Antonio.svg&input=%23-+%7B%7BPAGENAME%7D%7D%0D%0A%23-+%7B%7Bfilepath%3A%7B%7BPAGENAMEE%7D%7D%7D%7D%0D%0A%23-+%5B%5BSpecial%3AFilepath%2F%7B%7BPAGENAME%7D%7D%5D%5D%0D%0A&removecomments=1&generate_xml=1

This might be a dupe of an existing magic word/entity bug?

phoenixct wrote:

Workaround can't be used in template like http://commons.wikimedia.org/wiki/Template:ValidSVG, because it doesn't work well inside "[" "]" url address.

herd wrote:

That workaround can still be used, you just have to use urlencode and fullurl (admittedly uglier URLs though).
http://commons.wikimedia.org/w/index.php?title=Template:ValidSVG&diff=16376628&oldid=15911588

That seems to work, at least temporarily until {{PAGENAME}} gets fixed?

Looks like the same base problem as bug 14779...

Also seems to apply to the output of other magic Words, even simple ones like LC. We risk getting into the situation where people are relying on the broken behaviour, and fixing it will then break stuff.

  • Bug 23253 has been marked as a duplicate of this bug. ***
  • Bug 24938 has been marked as a duplicate of this bug. ***

a.d.bergi wrote:

I'm not sure whether it was already posted, but
{{NAMESPACE:xyz}} and
{{PAGENAME:xyz}}
are also not working with "<", ">" or their html-escaped equivalents &amp;lt; and &amp;gt;. The quote characters (",') are OK in here.
I think it belongs to this bug, please fix me.

(In reply to comment #9)

I'm not sure whether it was already posted, but
{{NAMESPACE:xyz}} and
{{PAGENAME:xyz}}
are also not working with "<", ">" or their html-escaped equivalents &amp;lt;
and &amp;gt;. The quote characters (",') are OK in here.
I think it belongs to this bug, please fix me.

"<" and ">" are not allow inside titles, see [[mw:Manual:$wgLegalTitleChars]], so there are cannot work with NAMESPACE or PAGENAME.

(In reply to comment #4)

Looks like the same base problem as bug 14779...

No, using "$title = Title::newFromText( $name );" and give the $title to wfFindFile works (with or without "File:"-prefix). But that doesnot work with urlencode title, that is bug 14779.

wfFindFile is using Title::makeTitleSafe, which use Tilte::makeTitle for the mDbkeyform. Title::newFromText use Sanitizer::decodeCharReferencesAndNormalize and that normalize the &quot; &amp; &#39;.

It looks like, newFromText should used for all Titles from Wikitext and makeTitleSafe should used for form given titles. So this parser function use the wrong method.

(In reply to comment #6)

Related issue:
{{PAGESINCATEGORY:{{PAGENAME}}}} doesn't work on categories with a '

PAGESINCATEGORY used Category::newFromName which use Title::makeTitleSafe -> see comment 11

(In reply to comment #11)

... ([wfFindFile works] with or without "File:"-prefix). ...

reported as bug 25670

Workaround:

  • filter the fiven file name / page name / category name, containing HTML entities as returned by various parser functions (like lc:, uc:, #if:, #switch:...), through #titleparts to convert back these HTML entities to plain characters
  • this returned value can be passed to parsers functions that do not like these HTML entities: PAGESINCATEGORY, FILEPATH, #ifexist...

The HTML entities we need to handle are notably those characters:

' " &

which are valid in page names (the < and > characters are not valid in
pagenames, they will remain encoded after calling #titleparts).

For details about te various encodings used in page names, see

[[mw:Manual:PAGENAMEE encoding]]

which details how characters may get encoded.
This covers the full ASCII set, and the first printable non-ASCII characters (tested with UTF-8 assumed for their plain-text encoding).
This also covers some other contextual changes that may occur for some characters which are not encoded except in leading positions where they may be changed, or dropped, as well as those few charaters that get transformed within specific subsequences anywhere in the string (such as the slash and periods).

But I agree that functions like PAGESINCATEGORY, FILEPATH... should properly decode these HTML entities (and notably the 3 characters above; the most frequent one encountered being the ASCII apostrophe-quote).

Change 145724 had a related patch set uploaded by Brian Wolff:
Have Title::makeTitleSafe decode html entities.

https://gerrit.wikimedia.org/r/145724

Aklapper changed the subtype of this task from "Task" to "Bug Report".Feb 6 2022, 7:18 PM
Aklapper removed a subscriber: wikibugs-l-list.