Last modified: 2011-04-30 01:16:46 UTC
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).
Basically Linker::makeBrokenImageLinkObj should follow $wgUploadNavigationUrl.
Created attachment 6922 [details] 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.
$wgUploadNavigationUrl is just an url, it may not understand &wpDestFile
(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.
(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
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.
(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.
Fixed in r60593
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
This issue is already tracked in bug 23140. Restoring original closed state.
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.
Not reverted, but instead introduced $wgUploadMissingFileUrl in r69997.
If it's possible, can this be backported to 1.16 ?
(In reply to comment #13) > If it's possible, can this be backported to 1.16 ? No, we're not backporting new features.
(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.
