Page MenuHomePhabricator

Internal page and file links that look like urls render as external links (e.g. [[http://]] or [[file:Example.svg]])
Open, HighPublic

Description

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:

Version: 1.20.x
Severity: major
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=69500

Details

Reference
bz44011

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:17 AM
bzimport added a project: MediaWiki-Parser.
bzimport set Reference to bz44011.
bzimport added a subscriber: Unknown Object (MLST).

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):

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:

  1. Don't allow internal links to pages containing
  2. PROTO: where PROTO is a valid URL protocol; these
  3. 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):

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