Last modified: 2014-09-23 22:32:34 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 T48741, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 46741 - UploadWizard unable to recover from warnings
UploadWizard unable to recover from warnings
Status: PATCH_TO_REVIEW
Product: MediaWiki extensions
Classification: Unclassified
UploadWizard (Other open bugs)
master
All All
: High major with 6 votes (vote)
: ---
Assigned To: Mark Holmquist
:
: 58186 (view as bug list)
Depends on: 40921
Blocks:
  Show dependency treegraph
 
Reported: 2013-03-31 19:39 UTC by David Richfield
Modified: 2014-09-23 22:32 UTC (History)
13 users (show)

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


Attachments

Description David Richfield 2013-03-31 19:39:53 UTC
When I try to upload an svg version of a file that is already on commons, the new "same name" detection completely prevents me from uploading it.  This restriction needs to be relaxed.
Comment 1 Andre Klapper 2013-04-02 08:39:20 UTC
Hi, did you use http://commons.wikimedia.org/wiki/Special:UploadWizard or http://commons.wikimedia.org/wiki/Special:Upload for uploading? (It's always highly welcome to provide exact steps to reproduce, in order to avoid ambiguity.)

What would be good reasons to relax that restriction? If you automatically convert from e.g. svg to png you'd run into filename collisions.
Comment 2 David Richfield 2013-04-03 19:25:15 UTC
I got there from [[Special:Upload]] - specifically by typing the required filename into the address bar and clicking on "upload"

The reason to relax the restriction is that we often create svg diagrams based on other filetypes (most often .jpg, .gif and .png) - very many national flags, scientific diagrams and charts are made that way: an initial uploader supplies a file in a non-vector format, which is then transformed (often after a request at [[:en:WP:GL/I]]) to an SVG file.  Both files still need to be kept (at least for a while): at first they need to be compared to make sure that the vector diagram is a faithful rendition, and sometimes later a PNG version is made offline in Inkscape because the automatic PNG versions (made with librsvg) don't render faithfully.  See for example [[:File:Steroidogenesis.svg]] and [[:File:Steroidogenesis.png]].  They coexist without problems.  Under what circumstances would a name collision occur?  All the preview images are prefixed with "(number)px-"

I'm also not the only one to see this problem.  See for example the discussions at  http://commons.wikimedia.org/wiki/Commons:Forum#Upload_gleicher_Name and http://commons.wikimedia.org/wiki/Commons:Help_desk#Can.27t_upload_an_SVG_version_of_a_PNG
Comment 3 Marco 2013-04-10 17:20:34 UTC
Would be nice to know why this was introduced (and when)... Nevertheless it 'could' be useful considering it was possible to upload files like:
*movie.ogv
*movie.webm
*movie.ogg
containing all the same content.


(In reply to comment #1)
> Hi, did you use http://commons.wikimedia.org/wiki/Special:UploadWizard or
> http://commons.wikimedia.org/wiki/Special:Upload for uploading? (It's always
> highly welcome to provide exact steps to reproduce, in order to avoid
> ambiguity.)
> 
> What would be good reasons to relax that restriction? If you automatically
> convert from e.g. svg to png you'd run into filename collisions.

Both are affected (UpWiz and old upload form)



(In reply to comment #2)
Clumsy workaround: You can still upload the file to any random name and move it directly after upload to the wanted name.
Comment 4 Bawolff (Brian Wolff) 2013-05-10 01:27:50 UTC
Seems to be introduced in I21eddc5d08ca3c23b3 / bug 40326
Comment 5 Bawolff (Brian Wolff) 2013-05-10 01:31:12 UTC
(In reply to comment #4)
> Seems to be introduced in I21eddc5d08ca3c23b3 / bug 40326

It seems to me that this should be a "recoverable warning" (By which I mean you ask the user if they are sure, and then let them do it if they really want to). Does that sound right?
Comment 6 David Richfield 2013-05-10 10:30:08 UTC
That would solve my problem, and I guess it would still avoid the problem in Bug 40326.  

This would also allow a user to make an intelligent choice, for example if I want to upload steroidogenesis.svg and there's already a steroidogenesis.png, I can either keep the filename if I'm just making an svg version of the png, or change the name if it's a completely different picture.
Comment 7 Rainer Rillke @commons.wikimedia 2013-05-28 10:57:49 UTC
(In reply to comment #5)
> this should be a "recoverable warning"
Recoverable only if it has a different file extension/type. Uploading Foo.JPG and Foo.jpg should be still impossible (as some file systems do not like this; Just imagine, their MD5 would start with the same byte).
Comment 8 Kevin Jones 2013-05-28 22:54:48 UTC
Recoverable with a different file extension/type sounds good to me. 

I'd  recently added transparent backgrounds (alpha channels) to some .jpg images via [[GIMP]] and was a bit irked/befuddled when I'd entered info for multiple .png versions I was uploading simultaneously via UploadWizard only to get denied at the end. At the very least it would be nice if the filename denial had come nearer the start of the process. Of course a "recoverable warning" would make this moot... well, perhaps not... it would still be nice to get warnings regarding filenames as soon as the file name is entered via the file browser. Before going through additional steps.

Advance 'tanx' goes out to those with the skillz, :  }
Comment 9 Kevin Jones 2013-05-28 22:59:44 UTC
p.s. I'm...
[[User:Kevjonesin|Kevjonesin]] ([[User talk:Kevjonesin|talk]]) 22:58, 28 May 2013 (UTC)
...on English Wikipedia.
Comment 10 Andre Klapper 2013-05-29 12:09:54 UTC
Bryan.TongMinh: Could you take a look at this, as https://gerrit.wikimedia.org/r/#/c/24124/ was written by you? Thanks.
Comment 11 Marco 2013-06-20 18:37:36 UTC
Please fix this bug or revert the initial commit. This should not stay the way it is now.
FYI: I wasted some hours with debugging some python script because I could not upload a WebM file. Some minutes ago I realized another file was already uploaded with the same name (totally unrelated) with PNG extension.

Even if there are two related files like "animal123.png" & "animal123.webm" the error should not show up!
Comment 12 Bawolff (Brian Wolff) 2013-11-07 04:29:49 UTC
Is this still an issue on commons. (I was going to review your commit [Sorry about letting that fall through the cracks] today), but I couldn't reproduce the issue locally. Although it may be me just getting a little sleepy and doing something stupid
Comment 13 Marco 2013-11-07 17:30:43 UTC
(In reply to comment #12)
> Is this still an issue on commons?
Jup!
Comment 14 Marco 2013-11-08 10:07:13 UTC
Related Patch set:
Change 87020
Change-Id I1a98bf43284b5045b1ee6c60e64075404fd0a837

https://gerrit.wikimedia.org/r/#/c/87020/
Comment 15 Bawolff (Brian Wolff) 2013-11-15 18:25:09 UTC
(In reply to comment #13)
> (In reply to comment #12)
> > Is this still an issue on commons?
> Jup!

Really, because I was able to successfully upload https://commons.wikimedia.org/wiki/File:Carngranny_level_crossing_-_geograph.org.uk_-_274643.png even though https://commons.wikimedia.org/wiki/File:Carngranny_level_crossing_-_geograph.org.uk_-_274643.jpg exists
Comment 16 Marco 2013-11-15 20:48:38 UTC
It is not possible for me to use the UpWiz which gives me:

There is [/wiki/File:Carngranny_level_crossing_-_geograph.org.uk_-_274643.webm another file] already on the wiki with the same filename

in red textcolor regardless of me clicking on "Retry failed uploads".

Also youtube2mediawiki gives "Upload failed."
Comment 17 Bawolff (Brian Wolff) 2013-11-15 20:50:27 UTC
(In reply to comment #16)
> It is not possible for me to use the UpWiz which gives me:
> 
> There is
> [/wiki/File:Carngranny_level_crossing_-_geograph.org.uk_-_274643.webm
> another file] already on the wiki with the same filename
> 
> in red textcolor regardless of me clicking on "Retry failed uploads".
> 
> Also youtube2mediawiki gives "Upload failed."

I would view that as an upload wizard bug in that it doesn't allow people to bypass warnings. It seems kind of silly to me to get rid of all non-critical warnings because upload wizard is not giving the option to the user to ignore them
Comment 18 Marco 2013-11-15 21:00:15 UTC
(In reply to comment #17)
Makes sense, actually. I guess we better file a new bug as this one is quite stuffed?
Comment 19 Bawolff (Brian Wolff) 2013-11-15 21:06:35 UTC
(In reply to comment #18)
> (In reply to comment #17)
> Makes sense, actually. I guess we better file a new bug as this one is quite
> stuffed?

Although it appears that originally this happened for Special:Upload too, We could probably just move this bug to uploadWizard component.
Comment 21 Mark Holmquist 2013-11-15 22:10:54 UTC
I guess we could add in a check to ignore the filename exists error if they're not actually identical - i.e. the extension is different. That sounds fine to me. As long as we warn the user in the description step.
Comment 22 Marco 2013-12-07 17:08:41 UTC
Changing importance: This is not an "enhancement" but a major bug displeasing uploaders for months now.

Just two more examples:
https://commons.wikimedia.org/w/index.php?oldid=103108315
https://commons.wikimedia.org/w/index.php?diff=111356217
Comment 23 Andre Klapper 2013-12-09 12:23:30 UTC
*** Bug 58186 has been marked as a duplicate of this bug. ***
Comment 24 Rainer Rillke @commons.wikimedia 2013-12-18 19:27:42 UTC
(In reply to comment #21)
> I guess we could add in a check to ignore the filename exists error if they're
> not actually identical - i.e. the extension is different. That sounds fine to
> me. As long as we warn the user in the description step.

What would you like to "warn the user about"?
Comment 25 Andre Klapper 2014-01-02 10:48:51 UTC
mtraceur:  Could you answer comment 24 please?
Comment 26 Mark Holmquist 2014-01-08 23:52:12 UTC
Well, I would definitely like to tell the user that they're creating a potentially confusing filename. I won't make it *fatal*, but there should be notice of some sort.
Comment 27 Rainer Rillke @commons.wikimedia 2014-04-16 22:19:31 UTC
(In reply to Mark Holmquist from comment #26)

Any progress? Or can I author a patch?
Comment 28 Marco 2014-04-17 07:20:19 UTC
(In reply to Rainer Rillke @commons.wikimedia from comment #27)
Please do. :)

Regardless whether you decide to include a warning or decide to drop them... Everything is better than the current state which blocks "valid" uploads and confuses uploaders.
Comment 29 Adam Cuerden 2014-06-09 15:34:27 UTC
This also causes problems with PNG/JPEG versions - JPEGs display better, but are lossy, so, with scans and restorations it's pretty normal to have both a JPEG and PNG. Up until recently, it was at least possible to upload both at once, it's blocked now.
Comment 30 Adam Cuerden 2014-06-09 15:35:07 UTC
(By which I mean that the recent patch actually made the uploads ''more'' restrictive.)
Comment 31 Mark Holmquist 2014-09-10 20:25:26 UTC
It looks like no work has been done on this, I'm going to try to whip up a patch now.
Comment 32 Gerrit Notification Bot 2014-09-10 22:31:29 UTC
Change 159625 had a related patch set uploaded by MarkTraceur:
[WIP] Add override button back in

https://gerrit.wikimedia.org/r/159625
Comment 33 Mark Holmquist 2014-09-11 16:03:02 UTC
This is WIP because the issues with the prior patches still exists. I guess we need to finish refactoring before we can have any real solution here.

*weeping in the corner*

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


Navigation
Links