Last modified: 2009-02-03 10:50:17 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 T19193, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 17193 - Reupload form
Reupload form
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Uploading (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-28 11:01 UTC by Lupo
Modified: 2009-02-03 10:50 UTC (History)
3 users (show)

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


Attachments

Description Lupo 2009-01-28 11:01:51 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.
Comment 1 Mike.lifeguard 2009-01-28 19:55:06 UTC

*** This bug has been marked as a duplicate of bug 17200 ***
Comment 2 Mike.lifeguard 2009-01-28 19:56:30 UTC
Sorry - my mistake
Comment 3 Aaron Schulz 2009-01-28 20:03:29 UTC
Fixed in r46479
Comment 4 Brion Vibber 2009-01-28 20:09:32 UTC
Uploads now completely broken.
Comment 5 Aaron Schulz 2009-01-28 20:18:31 UTC
(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.
Comment 6 Lupo 2009-01-28 20:48:59 UTC
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' ) ) .

Comment 7 Aaron Schulz 2009-01-28 20:58:42 UTC
(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
Comment 8 Lupo 2009-01-29 12:55:30 UTC
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.
Comment 9 Lupo 2009-02-03 10:50:17 UTC
Appears to be fixed now. Commons now serves the image description pages correctly with "wpReUpload=1".

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


Navigation
Links