Last modified: 2014-09-08 00:28:51 UTC
From https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Uploads_not_working_in_1.20.1/reply_(6) I upgraded to MediaWiki 1.20.2 ... File links are still not rendered correctly. Example: a previously (i.e., before the update to 1.20.1/1.20.2) created link like [[File:IMG_3334.JPG|thumb]] is now rendered as [<a rel="nofollow" class="external autonumber" href="File:IMG_3334.JPG%7Cthumb">[2]</a>] It seems like File is not recognised as all. The inner brackets are interpreted as a link to an external resource, and the contents are rendered accordingly. A later post gives this update: [Having "file:" in $wgURLProtocols] didn't cause problem until a recent upgrade of the MediaWiki software.... Fixing the last line (the file:// protocol) solved the problem:
Same issue reported in this Stack Overflow thread: http://stackoverflow.com/questions/14375177/mediawiki-upgrade-breaks-file-prefix-but-legacy-image-works
A git bisect suggests I706acb7a0ae194b50d2318763beae4e5e83671f3 is the cause.
(In reply to comment #2) > A git bisect suggests I706acb7a0ae194b50d2318763beae4e5e83671f3 is the cause. That's probably what made the problem more visible, since previously it would've only happened if the "file:" prefix was written in all lowercase. However, the *real* issue, as I see it, is that "[[foo:bar]]" is parsed as an external link rather than an internal one if "foo:" is both a known URL prefix and a valid namespace. That's likely to go much deeper.
Actually, on second thoughts, whether "foo:" is a valid namespace or not shouldn't really matter. What we *should* be doing is to always parse "[[whatever]]" as an internal link, even if "whatever" happens to look like a URL. Test case (these should all be internal links): * This works: [[:http://www.example.com/]] * This doesn't: [[http://www.example.com/]] * This used to work before MW 1.20: [[Http://www.example.com/]]
And problematically I have a feeling that there are wikis depending on the behaviour of [[http://example.com/ Example]].
Wondering if bug 41584 is related...
(In reply to Andre Klapper from comment #6) > Wondering if bug 41584 is related... I don't think so.
This is handled in Parser.php around line 2010, removing this block fixes this bug: > # Don't allow internal links to pages containing > # PROTO: where PROTO is a valid URL protocol; these > # should be external links. > if ( preg_match( '/^(?i:' . $this->mUrlProtocols . ')/', $m[1] ) ) { > $s .= $prefix . '[[' . $line; > wfProfileOut( __METHOD__ . "-misc" ); > continue; > } (In reply to Ilmari Karonen from comment #4) > Actually, on second thoughts, whether "foo:" is a valid namespace or not > shouldn't really matter. What we *should* be doing is to always parse > "[[whatever]]" as an internal link, even if "whatever" happens to look like > a URL. > > Test case (these should all be internal links): > > * This works: [[:http://www.example.com/]] > * This doesn't: [[http://www.example.com/]] > * This used to work before MW 1.20: [[Http://www.example.com/]] According to the comment, this is the expected behaviour.
Change 158935 had a related patch set uploaded by Jackmcbarn: Warn about bug 44011 https://gerrit.wikimedia.org/r/158935
Change 158935 merged by jenkins-bot: Warn about bug 44011 https://gerrit.wikimedia.org/r/158935
