Last modified: 2012-04-12 13:59:49 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T25140, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 23140 - $wgUploadNavigationUrl breaks image red links
$wgUploadNavigationUrl breaks image red links
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
1.16.x
All All
: Normal major with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: code-update-regression
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-10 14:18 UTC by Derk-Jan Hartman
Modified: 2012-04-12 13:59 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Derk-Jan Hartman 2010-04-10 14:18:02 UTC
Apparently the behavior of the red linked thumbs has changed


http://en.wikipedia.org/w/index.php?title=Rome&oldid=181221673#Universities
Includes an image thumb since deleted. The thumb shows a redlink, leading to: http://en.wikipedia.org/wiki/Wikipedia:Upload?wpDestFile=MinervaSapienza.JPG

wpDestFile is an argument to Special:Upload of course, not Wikipedia:Upload.


Also, a second problem is that for editors it is now impossible to see the file history of that page. It should probably only ever link to the upload interface, if a file by that name did not exist at any point in time. For editors, the description page for that file is very hard to reach now for instance. You have to manually copy paste the image title and navigate there. I also note that the "magnify" icon is not available in these thumbs.
Comment 1 Bryan Tong Minh 2010-04-11 21:12:59 UTC
(In reply to comment #0)
> Apparently the behavior of the red linked thumbs has changed
> 
See bug 18885. Previously it used to point to local Special:Upload, which was not desirable in all cases. If I recall correctly, the only change is that it now actually follows $wgUploadNavigationUrl. Do you suggest to change this behaviour?
Comment 2 Derk-Jan Hartman 2010-04-25 20:13:05 UTC
Actually what seems to have happened is that Special:Upload no longer shows a warning when a page was deleted. To quote from VP/T

"Up until a week or two ago, whenever I clicked on a deleted image link (i.e. a red link that links to the "File" namespace), it would lead me to WP:UPLOAD as it does now, but below the page's title, there would also be links to deletion logs for the image, on both Wikipedia and the Commons."
Comment 3 p858snake 2010-04-26 00:33:17 UTC
Based on comment #2 it sounds like a regression, key-wording as such (+code-update-regression)
Comment 4 Bryan Tong Minh 2010-04-29 21:06:12 UTC
Either 1) the log excerpt should be shown on WP:UPLOAD or 2) wpDesiredDestname should propagate to Special:Upload. I'm not sure what is the proper way to fix this issue.
Comment 5 Gary 2010-06-02 17:55:32 UTC
Instead of going to Wikipedia:Upload, if red linked images went to http://en.wikipedia.org/w/index.php?title=Special:Upload&wpDestFile=Foo.png instead, that would fix the problem, at least on en.wikipedia.org, since http://en.wikipedia.org/wiki/MediaWiki:Uploadtext shows the deletion logs when wpDestFile is set in the URL.
Comment 6 Bryan Tong Minh 2010-06-08 08:52:32 UTC
(In reply to comment #4)
> Either 1) the log excerpt should be shown on WP:UPLOAD or 2) wpDesiredDestname
> should propagate to Special:Upload. I'm not sure what is the proper way to fix
> this issue.

Or we could of course revert and WONTFIND bug 18885.
Comment 7 Conrad Irwin 2010-07-02 21:06:33 UTC
Yuck, this is all very messy as there are a lot of conflicting assumptions being made and broken.

Under the assumption that a red link should point you to the place you can make that link blue (or create the image), and the assumption that $wgUploadNavigationUrl points to the page you can upload at, everything is fine. I imagine this is the case almost everywhere.

What this bug seems to assume is that a redlink takes you to the place that a deletion log is visible - which is conveniently enough the same as the place you upload on Wikipedia (but not everywhere? - perhaps that should be fixed also?).

Wikipedia importantly breaks the assumption that $wgUploadNavigationUrl points to a place you can upload - not sure the best way to fix that and still let the upload button at the left hand side work as Wikipedia wants - probably to define yet-another configuration variable specifically for that left-side link (that defaults to $wgUploadNavigationUrl), or create a simple extension/javascript hack that allows wpDestFile to be used on WP:Upload
Comment 8 Krinkle 2010-07-20 23:52:50 UTC
Please read my comment here:
https://bugzilla.wikimedia.org/show_bug.cgi?id=18885#c9

On wmf wikis (and self-hosted wikis aswell, especially when using Commons or when using a step-by-step upload proces such as wikipedia's Wikipedia:Upload and commons' Commons:Upload, the $wgUploadNavigationUrl variable is used for that.

Which is fine, because it's the 'navigation' url. It points to the page where one should navigate to to start a new upload. Which is by default directltly the upload-page. But almost all major wikis have changed this to an inbetween step.

But those links are not for uploading directly, which is what is is been (ab/re)used for since bug 18885.

Read further there.. https://bugzilla.wikimedia.org/show_bug.cgi?id=18885#c9
Comment 9 Bryan Tong Minh 2010-07-27 10:33:15 UTC
Introduced $wgUploadMissingFileUrl in r69997. Once deployed, wikis can decide for themselves what desirable behaviour is.
Comment 10 Derk-Jan Hartman 2012-03-01 21:07:16 UTC
This behavior was again changed for 1.19 by r92598

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links