Last modified: 2005-06-25 13:57:29 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 1666 - we need a warning if the image exists in the shared upload dir
we need a warning if the image exists in the shared upload dir
Status: RESOLVED DUPLICATE of bug 889
Product: MediaWiki
Classification: Unclassified
Uploading (Other open bugs)
unspecified
All All
: High major with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-09 01:25 UTC by peter green
Modified: 2005-06-25 13:57 UTC (History)
0 users

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


Attachments

Description peter green 2005-03-09 01:25:18 UTC
on the wikimedia websites the shared upload dir is used to load images from commons.

a newbie just went and uploaded an image to the en wikipedia that blocked out an
image from commons.

when this happens there is no easy way to deal with it (especilly as we can't
move images). WORSE it may not even be noticed until much later by someone
viewing a page on which the image from commons was being used.

There needs to be at least a warning and possiblly more (maybe admin approval
needed) before users are allowed to upload an image that clashes with one in the
shared upload dir.
Comment 1 Brion Vibber 2005-03-09 01:31:41 UTC
It's very easy to deal with it -- delete it!

But yes, a warning might be nice.
Comment 2 peter green 2005-03-09 01:41:22 UTC
i don't consider throwing away the local image (or reuploading it and losing its
history in the process) to be a good way of dealing with this.

not to mention the issue of untangling any links to the two images.

in this case it was caught quickly and probablly won't be a major issue but the
real cleanup problem comes if something like this goes undetected for a while.
Comment 3 Fred Chess 2005-06-24 09:53:36 UTC
(In reply to comment #0)
> on the wikimedia websites the shared upload dir is used to load images 
from commons.
> a newbie just went and uploaded an image to the en wikipedia that 
blocked out an
> image from commons.
> when this happens there is no easy way to deal with it (especilly as 
we can't
> move images). WORSE it may not even be noticed until much later by 
someone
> viewing a page on which the image from commons was being used.
> There needs to be at least a warning and possiblly more (maybe admin 
approval
> needed) before users are allowed to upload an image that clashes with 
one in the
> shared upload dir.

(In reply to comment #0)
> on the wikimedia websites the shared upload dir is used to load images 
from commons.
> a newbie just went and uploaded an image to the en wikipedia that 
blocked out an
> image from commons.
> when this happens there is no easy way to deal with it (especilly as 
we can't
> move images). WORSE it may not even be noticed until much later by 
someone
> viewing a page on which the image from commons was being used.
> There needs to be at least a warning and possiblly more (maybe admin 
approval
> needed) before users are allowed to upload an image that clashes with 
one in the
> shared upload dir.

Just a suggestion: information about the commons page could be inserted 
into the wikipedia image page, stating "this image is ''also'' available 
at commons, would you chose to use this instead?" 
Comment 4 Rowan Collins [IMSoP] 2005-06-25 13:57:29 UTC

*** This bug has been marked as a duplicate of 889 ***

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


Navigation
Links