Last modified: 2014-06-08 21:47:09 UTC
I don't know why people add a new "$wgCopyUploadsFromSpecialUpload" since 1.20.0. But it creat bug in my wiki(1.22wmf9 (0727d6a)) I use to use $wgGroupPermissions['autoconfirmed']['upload_by_url'] = true; $wgAllowCopyUploads = true; everything works fine. After 1.20 the URL upload bar despaired and then I realized new configuration is : $wgGroupPermissions['autoconfirmed']['upload_by_url'] = true; $wgAllowCopyUploads = true; $wgCopyUploadsFromSpecialUpload = true; From http://www.mediawiki.org/wiki/Manual:$wgCopyUploadsFromSpecialUpload However, when $wgCopyUploadsFromSpecialUpload = true; the system can't detect duplicate image and can't copy file name too. Here is a screenshot when $wgCopyUploadsFromSpecialUpload set to false: http://i.imgur.com/JVImbF2.jpg Here is another screenshot when $wgCopyUploadsFromSpecialUpload set to true, which is abnormal: http://i.imgur.com/3oBwXfd.jpg And this is a link for testment: http://en.moegirl.org/Special:Upload
(In reply to comment #0) > I don't know why people add a new "$wgCopyUploadsFromSpecialUpload" since > 1.20.0. Description says "to enable uploading from URLs". :) > And this is a link for testment: http://en.moegirl.org/Special:Upload I logged in with test1 and test1234 and used the example filename from your screenshots when going to Special:Upload. I get "A file with this name exists already, please check File:Img illust miku.png if you are not sure if you want to change it." So either you've set the value to False, or I cannot reproduce the problem.
(In reply to comment #1) > (In reply to comment #0) > > I don't know why people add a new "$wgCopyUploadsFromSpecialUpload" since > > 1.20.0. > > Description says "to enable uploading from URLs". :) > > > And this is a link for testment: http://en.moegirl.org/Special:Upload > > I logged in with test1 and test1234 and used the example filename from your > screenshots when going to Special:Upload. I get > "A file with this name exists already, please check File:Img illust miku.png > if > you are not sure if you want to change it." > So either you've set the value to False, or I cannot reproduce the problem. I tried the account test1 but the system reply "There is no user by the name "test1"." In order to make sure this is not a browser problem, I registered a new account "testerforurlupload" with password "123456". Using this account to test, neither IE10, chrome 28 nor firefox 23 can generate the file name. BTW, I find a new bug, when using Source URL, the Destination filename will be filled by Url not real file name. Screenshot: http://i.imgur.com/QgypTnc.jpg
Created attachment 13131 [details] Screenshot Sorry for the confusion with the account. (In reply to comment #2) > In order to make sure this is not a browser problem, I registered a new > account "testerforurlupload" with password "123456". I used that account, chose a random PNG file to upload, set the name to Img_illust_muiku.png, and it works for me as the existing file is detected.
That is quite strange, May I know which kind of browser you are using?
Firefox 23 on Fedora 19.
*** Bug 53859 has been marked as a duplicate of this bug. ***
My guts tell me that bug 39507 might have the same underlying reason, plus we have dup bug 53859 now so there is definitely some issue here to sort out though conditions to reproduce are not totally clear yet. Worth investigating by the Multimedia team.
Conditions to reproduce. Set these in LocalSettings: $wgAllowCopyUploads = true; $wgCopyUploadsFromSpecialUpload = true; $wgGroupPermissions['user']['upload_by_url'] = true; Then login, go to the upload form, and Browse for a file. When you select the file, Destination filename is not filled-in and the thumbnail doesn't appear. No duplicate filename detection.
I found the line of code which changed from 1.20 to 1.21 that broke it: /includes/specials/SpecialUpload.php line 1116: $id = $this->mParams['id']; Change to what it was in 1.20 and Special:Upload works again with copy uploads: line 1116: $id = "wpSourceType{$this->mParams['upload-type']}";
mtraceur: Could you take a look at this?
For what it's worth I have the same problem and I can confirm that Steve's solution fixes it. I also tested disabling copy uploads and everything still works.
This bug is fixed for me with version 1.23. Thanks.
Also works for me on master. Closing as fixed
