]] or [[file:Example.svg]])
Open, HighPublic
Actions

Assigned To

None

Authored By

	MarkAHershberger
	Jan 15 2013, 7:49 PM

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

Related Objects

Mentioned In: T326048: What URL protocols are recognized in plain text should be configurable separate of $wgUrlProtocols

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

MarkAHershberger created this task.Jan 15 2013, 7:49 PM

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

Ricordisamoa subscribed.Jan 19 2015, 11:08 PM

Tgr mentioned this in T326048: What URL protocols are recognized in plain text should be configurable separate of $wgUrlProtocols.Jan 1 2023, 2:58 AM

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

Description

Details

Related Objects

Event Timeline

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