Last modified: 2012-08-21 19:02:49 UTC
I tried today to upload several files on Commons through Upload Wizard (using Mozilla Firefox) and after uploading I receive "Unknown error: "unknown-warning".". I tried with Google Chrome and the result is the same. I've also tried to upload the files on Test Wiki and I got the same unknown error.
Please try uploading with the old form. Do you get a better warning with it? Could help to isolate the "unknown".
I've managed to upload the file successfully using the old form. I haven't got any errors.
The problem appears when the filename is too common (if it begins with IMG or DSC or other usual prefixes). See also https://commons.wikimedia.org/wiki/Commons:Upload_Wizard_feedback#unknown-warning and https://commons.wikimedia.org/wiki/File:Upload-wizard_-_unknown-warning,_upload_failed.jpg.
If you're using a bad filename like that, you shouldn't be able to proceed to the upload, it should error out. I feel like I fixed something like this at one point, but I could be wrong. Possible fixes: https://gerrit.wikimedia.org/r/#/c/7608/ https://gerrit.wikimedia.org/r/#/c/10995/ Thanks for the bug report, maybe someone will review my patches now :) (I removed "all browsers" because there's no proof or even rumour that supports that, and removed "Windows 7" because apparently there's a known cause) (also, "blocker" isn't warranted here, seriously)
There are a lot of reports about this on the UW feedback page, we really should prioritize resolution of this issue a bit.
(In reply to comment #4) > If you're using a bad filename like that, you shouldn't be able to proceed to > the upload, it should error out. No, it should not error out at the point where it does not. At the moment, you get the uninformative "unknown-warning" message before you get to the "Describe" screen, where you'd get a chance to select the file name on the server. The Upload Wizard should not care what the file is called on the uploader's computer. > (I removed "all browsers" because there's no proof or even rumour that supports > that, and removed "Windows 7" because apparently there's a known cause) Pretty sure all browsers are affected. We have reports from users of Opera, Safari and Firefox on Commons:Upload Wizard feedback, and I've confirmed it myself on Chromium. > (also, "blocker" isn't warranted here, seriously) I don't know what the severity definitions for this Bugzilla are, but it's serious enough that if this isn't fixed within the next couple of days, we'll probably have to look at changing the upload link to point to the old upload form again. When the process fails with an utterly unhelpful error message for a common use case, who knows how many contributions we're turning down a day? I'm counting 11 reports on Commons:Upload Wizard feedback in the last five days alone. And that's only from people who spotted the small feedback link and bothered to tell us. Most people probably don't.
Hi! Recently, a patch to MediaWiki core [0] changed the behavior of API warnings. We now get those at the first step, even if we don't handle them necessarily. Could you try to reproduce this bug, and let us know if it still occurs? If so, the solution would likely be very different from before this patch. I'm not sure if this occurred before or after the change to the API was pushed to Commons, it may have changed in the past few days :) [0] https://gerrit.wikimedia.org/r/#/c/9261/ Thanks!
Hi, we want to use the UW for the upcoming WLM2012 campaign in Austria because it makes things much simpler for beginners. At least that's what we thought. (A lot of effort was spent to allow passing parameters to the UW exact for that very purpose.) The UW must continue even with forbidden filenames (without explicit warning), as the user can change the filenames in the describe step later. Only than you can check for sound filenames. If a filename misses to match criteria, the message should make a clear statement about that. "Unknown error: "unknown-warning", for sure, isn't. a hint: My local filenames are quite long, containing date and time and processing steps (something like 20120630_19-00-10_01.2.jpg), I do not get the message mentioned above in the beginning, but I have to change the name in the describe step. So the workaround for the problem is to rename files on the local disk before uploading, but that's far from being obvious and convenient. regards
I confirm that the bug still occurs when uploading forbidden filenames.
*** Bug 39256 has been marked as a duplicate of this bug. ***
This is indeed a major issue caused by the recent API change and we'll resolve it ASAP. In the meantime, renaming the file to a unique name should resolve the issue; if not, please report it here.
If I try to upload say DSC_0578.JPG from Aurora or Chrome, I get "Unknown Error : Unknown Warning" but if I use a Unique name I am not getting the error and am able to upload file successfully, but its really tedious to rename all the files first locally and then upload them. Hope this gets resolved sooner.
Bumped it to highest because now the UploadWizard has been disabled as default way of upload at Commons.
This should now be fixed in production; please report if you're still getting this issue (and provide details about file name / contents if possible). We still have a few cases to improve upon per https://www.mediawiki.org/wiki/Extension:UploadWizard/Error_behavior and the recent core API change, but we wanted to make sure we get this fix out the door ASAP.
Confirmed that iOS 6 iPad simulator is able to get past this step on UploadWizard on Commons now. Yay!
