Red links for media files do not support shared repositories
Closed, ResolvedPublic

Description

Author: svippy

Description:
When inserting a reference to image on a page (e.g. [[File:Image.png]]) that does not exist, MediaWiki will in general (if uploads are enabled) create a link to where you may upload an image with that very name.

However, should you be using a pool wiki (for the purpose of keeping your images centralised), this link will still refer to your local Special:Upload, and if you disable uploading on your local wiki, for the sake of avoiding people uploading there and refer them to your pool wiki, the link won't work at all.

MediaWiki needs a better way of checking this. And using $wgUploadNavigationUrl seems awfully close to a "hack", a better solution would have been a basis, so rather than creating a link to say, "http://pool.wiki.tld/wiki/Special:Upload", it should rather have contained "http://pool.wiki.tld/w/index.php".

If people using "http://pool.wiki.tld/w/index.php?title=Special:Upload" rather than its prettier version is a concern to you, perhaps write something even better!

In any case, the current version lacks a version for inserting queries (unless you want to simply append them to current link, but MediaWiki doesn't seem to approve of that internally, eh).


Version: 1.14.x
Severity: minor

bzimport added projects: MediaWiki-Uploading, Easy.Via ConduitNov 21 2014, 10:43 PM
bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz18885.
bzimport created this task.Via LegacyMay 23 2009, 6:41 AM
bzimport added a comment.Via ConduitSep 25 2009, 4:41 PM

Bryan.TongMinh wrote:

Basically Linker::makeBrokenImageLinkObj should follow $wgUploadNavigationUrl.

bzimport added a comment.Via ConduitJan 3 2010, 10:07 PM

conrad.irwin wrote:

patch against 60582

  • Causes broken [[Media:_]] links to behave as broken [[File:_]] links in all circumstances.
  • If $wgUploadNavigationUrl is set, these links link to that with either ?wpDestFile=_ or &wpDestFile=_ and look red.
  • Otherwise if $wgEnableUploads is true, these links are red and link to Special:Upload as normal.
  • Otherwise these links go to the image page, and look blue (whether or not the page exists - there will always at least be the link-back section) as before.

Attached: PATCH.remote_uploads

Platonides added a comment.Via ConduitJan 3 2010, 10:14 PM

$wgUploadNavigationUrl is just an url, it may not understand &wpDestFile

bzimport added a comment.Via ConduitJan 3 2010, 10:20 PM

svippy wrote:

(In reply to comment #3)

$wgUploadNavigationUrl is just an url, it may not understand &wpDestFile

Indeed, which is why I propose an additional setting for locating an alternative uploadwiki, so that &wpDestFile could be understood, for instance
$wgUploadWikiUrl = 'http://pool.wiki.org/w/index.php';

And if set, $wgUploadWikiUrl could be applied with '?title=Special:Title&wpDestFile=etc.'.

I assume $wgUploadNavigationUrl is reserved for non-MediaWiki links as well.

bzimport added a comment.Via ConduitJan 3 2010, 10:21 PM

Bryan.TongMinh wrote:

(In reply to comment #4)

I assume $wgUploadNavigationUrl is reserved for non-MediaWiki links as well.

That's true, yet I doubt it will break anything. I think it is fine to repurpose the variable leaving a note in RELEASE-NOTES/DefaultSettings.php

Platonides added a comment.Via ConduitJan 3 2010, 10:27 PM

We could also add a $1 parameter to $wgUploadNavigationUrl
If there's no $1, it works as now. If you set it to /index.php?title=Special:Title&wpDestFile=$1 you are expected to know your page arguments.

bzimport added a comment.Via ConduitJan 3 2010, 10:35 PM

Bryan.TongMinh wrote:

(In reply to comment #6)

We could also add a $1 parameter to $wgUploadNavigationUrl
If there's no $1, it works as now. If you set it to
/index.php?title=Special:Title&wpDestFile=$1 you are expected to know your page
arguments.

That would break, or at least uglify the sidebar link.

bzimport added a comment.Via ConduitJan 3 2010, 10:46 PM

Bryan.TongMinh wrote:

Fixed in r60593

Krinkle added a comment.Via ConduitJul 20 2010, 11:39 PM

I noticed since this change that inexistant filelinks are kind of broken on several wikis that use $wgUploadNagivationUrl as a way to send people more to Commons.

For example on nl.wikipedia.org the value of this variable is
"http://commons.wikimedia.org/wiki/Commons:Upload/nl?uselang=nl"

When looking at the noc [http://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php] one can see nl.wiki isn't the only one doing this.

I should note that uploading is not disabled on nl.wiki, it's just discouraged, and the link in the Sidebar has been put to Commons. However locally re-uploading files and uploading files with redlinks was still possible,
... and is now broken !

As illustrated in this Testcase:
http://nl.wikipedia.org/wiki/Gebruiker:Krinkle/Testcase/3

Clicking it bring me to a useless page:
http://commons.wikimedia.org/wiki/Commons:Upload/nl?uselang=nl&wpDestFile=This_file_should_not_exist_anywhere_12875203.jpg

It should've gone to :
http://commons.wikimedia.org/wiki/Special:Upload/nl?uselang=nl&wpDestFile=This_file_should_not_exist_anywhere_12875203.jpg

or:
http://nl.wikipedia.org/wiki/Special:Upload/nl?uselang=nl&wpDestFile=This_file_should_not_exist_anywhere_12875203.jpg

Since wgUploadNagivationUrl is for the navigation, the actual upload path may vary. And as seen above the purpuse on wmf wikis for wgUploadNagivationUrl is indeed for the navigation (and not just on wmf wikis).

The idea mentioned above to use a variable like $wgUploadWikiUrl may be better.
Or perhaps auto-construct this URL based on $ForeignAPIRepo

TheDJ added a comment.Via ConduitJul 20 2010, 11:47 PM

This issue is already tracked in bug 23140.

Restoring original closed state.

bzimport added a comment.Via ConduitJul 21 2010, 12:27 PM

Bryan.TongMinh wrote:

I'm going to revert this, it is clear that we need a separate variable for red links and a separate one for the sidebar.

bzimport added a comment.Via ConduitJul 27 2010, 10:32 AM

Bryan.TongMinh wrote:

Not reverted, but instead introduced $wgUploadMissingFileUrl in r69997.

Krinkle added a comment.Via ConduitAug 15 2010, 7:38 PM

If it's possible, can this be backported to 1.16 ?

bzimport added a comment.Via ConduitAug 16 2010, 7:36 PM

Bryan.TongMinh wrote:

(In reply to comment #13)

If it's possible, can this be backported to 1.16 ?

No, we're not backporting new features.

Krinkle added a comment.Via ConduitAug 23 2010, 3:38 PM

(In reply to comment #14)

(In reply to comment #13)
> If it's possible, can this be backported to 1.16 ?

No, we're not backporting new features.

Not sure what else is attached/involved to this extra variable, but it seems more like a little bugfix to me.
Right now <= MW 1.16 installs spit out useless and/or illogical links. This variable is a big yet simple improvement to that.

Take for example a self-hosted wiki with Wikimedia Commons as FileRepo with local uploads enabled for sysops. Currently produces a link to the local uploadpage (which shows "sysop-only"-message) or, if wgUploadNavigationUrl is set (which is meant for "navigation"-link in the sidebar) to "http://commons.wikimedia.org/wiki/Commons:Upload" will give a link that is great for navigation (hence the variable name) but useless for broken filenames, as discusses above.

If the existance, function / implementation of this variable is dependant on other changes then so be it, we'll have to wait for 1.17. But if can be implemented with a few line changes in 1.16 that would be a great help.

Gilles added a project: Multimedia.Via WebDec 4 2014, 10:29 AM
Gilles moved this task to Closed on the Multimedia workboard.Via WebDec 4 2014, 10:41 AM

Add Comment