Last modified: 2009-02-03 10:50:17 UTC
I notice there have been some changes in SpecialUpload.php recently regarding the form for reuploading of files. I think this is very good, but there is a problem: When the reupload produces an error, the re-sent upload form no longer has the destination file name disabled. Was that intentional? If so, why? If not, could that error form then please also have the destination file name locked down, and the summary label set to filereuploadsummary? Otherwise I think people may chose a new filename and not update the summary to include all the required info. We'd essentially get files with a minimal change description intended as an edit summary (from the original reupload form) instead of source/author/license info.
*** This bug has been marked as a duplicate of bug 17200 ***
Sorry - my mistake
Fixed in r46479
Uploads now completely broken.
(In reply to comment #4) > Uploads now completely broken. > Underlying collisions between what should have been different url parameters causes this. Broke them off in r46482.
Aaron, could you please give that new hidden field an ID so that it can be checked for easily in JS? - Xml::hidden( 'wpForReUpload', $this->mForReUpload ) . + Xml::hidden( 'wpForReUpload', $this->mForReUpload, , array( 'id' => 'wpForReUpload' ) ) .
(In reply to comment #6) > Aaron, could you please give that new hidden field an ID so that it can be > checked for easily in JS? > > - Xml::hidden( 'wpForReUpload', $this->mForReUpload ) . > > + Xml::hidden( 'wpForReUpload', $this->mForReUpload, , array( 'id' => > 'wpForReUpload' ) ) . > Added
I see at http://wikitech.wikimedia.org/view/Server_admin_log that Brion merged this already, and indeed the changes are already live. However, it seems to me that the associated change in ImagePage.php from r46483 is *not* live yet (diff: r1=45963&r2=46483&pathrev=46483">http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/ImagePage.php?r1=45963&r2=46483&pathrev=46483 ) The Commons still serves image pages with an "Upload a new version link" that contains "wpReUpload=1" instead of "wpForReUpload=1". Hence these links don't trigger the reupload form at all.
Appears to be fixed now. Commons now serves the image description pages correctly with "wpReUpload=1".