Image upload replacements should create watchlist entry
Closed, ResolvedPublic


Author: leercontainer-bugzilla

As per discussion on the Wikitech-l mailinglist, it is obvious that vandalism by
way of changing images is a big problem. Jimbo mentioned a conference image on
[[George W. Bush]] being replaced by [[]]. See supplied link for the

When a new image (or file) is uploaded to an already existing image it should
show up in the watchlists of users watching the image description page (as
suggested by Evan). This would serve the same "watching" function that is done
with text today.
I suggest that it shows up among the rest of the watchlist entries with the same
line as other items, except that instead of "(diff)(hist)" you'd have "(view)"
that would be a direct (Media:) link to the image (file).

Example wathlist line:
(view) . . Image:ClitorisNewLoc2.jpg; 17:17:05 . . (Talk) (more pron

  • haha!)

Alernatively it could be modeled more after "File history" entries on the image
description page (Image:):
(desc) . . ClitorisNewLoc2.jpg; 17:17:05 . . (Talk) (more pron - haha!)
Where "(desc)" ('imgdesc' message in Language.php) would lead to the description
page (Image:ClitorisNewLoc2.jpg), and the filename would be a direct link
("Media:" type).

Version: unspecified
Severity: enhancement


Blocked By
T7546: Logs about watched pages should appear in the watchlist and recentchanges
Unknown Object (Diffusion Commit)
bzimport set Reference to bz778.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Oct 25 2004, 4:58 PM
brion added a comment.Oct 26 2004, 5:16 AM

To show up in the watchlist would require updating the timestamp of the image description page

leercontainer-bugzilla wrote:

(In reply to comment #1)

To show up in the watchlist would require updating the timestamp of the image

description page


Well, the description page _is_ infact changed, since a line is added to the
"File history" section. I'm not into the technicalities of things, but I suppose
what you describe is the easy way to do it. Would updating the timestamp also
affect the history part of the description page?

rowan.collins wrote:

Some additional thoughts on this:

  • Under 1.5, a new revision doesn't have to be linked to a new piece of text, so

image uploads could cause genuine "null revisions"

  • To take that even further, we could avoid conflating this with the history of

the description text by having a kind of "null page" in a special namespace
which had no text, but whose revisions represented overwrite/reversion actions
on the file itself. This might cause some craziness by violating assumptions
about the structure of the database, though; it certainly feels a bit hacky...

  • Alternatively, could the watchlist check the upload log and interleave the


  • With the advent of the commons, however, this becomes a lot more awkward - bug

1394 discussed the need to *list* what projects use a commons image, this would
require *contacting* them (since an image changing on commons means it changes
everywhere else too!) But in a sense, that's a multi-project watchlist problem,
which brings us back to single login...

dbenbenn wrote:

It would be nice to have a null revision added to the image page, in exactly the
same way as when moving an article. (For extra credit, the edit summary of the
null revision could include the new version's file size, dimensions, and the
upload summary.)

Wiki.Melancholie wrote:

*** Bug 4803 has been marked as a duplicate of this bug. ***

Wiki.Melancholie wrote:

(from bug 4803) I would suggest that actions like overwriting

images and reverting to older revisions of an image be
noted somehow in people's watchlists.

brion added a comment.Jan 31 2006, 8:52 PM

Poking 'upload' in the summary for easier searching

aleonard1 wrote:

Since the watchlist is one of the two most powerful vandal fighting tools, the
other being RC, this is an absolutely necessary tool. Poke the data and force a
watchlist update or something, but until then, having watchlists on Commons is
almost worthless.

Created attachment 2237
Possible patch for issue

This issue may be resolved with the attached patch, although it is entirely
possible I'm using methods that are not available at this point in the code...
(untested, please comment).

Attached: Image.php.patch

robchur wrote:

You need to save the revision.

There is a problem using null revisions in this manner too, as I discovered when
I added the one for page protection/unprotection operations; users attempting to
roll back the revision will not encounter the expected behaviour, and it can
cause unexpected problems. I've discussed the issue with Brion before; we need
to be able to mark revisions as being unable to be rolled back for some reason.

(In reply to comment #10): > You need to save the revision.
I see 2 possible alternative approaches on top of the one you are suggesting:

  1. have Revision::newNullRevision take care of saving the revision. (which means that

all uses of newNullRevision elsewhere have to be looked at and possibly changed).

  1. change the rollback code and make it act as expected in this case.

This is what newNullRevision promises to do (Revision.php:693): "Create a new null-
revision for insertion into a page's history. This will not re-save the text, but
simply refer to the text from the previous version." This does sound pretty efficient
to me. Saving the rev with the same content just creates unnecessary overhead, IMO.

P.s. I'm afraid solving this in real code this currently over my head...

robchur wrote:

No, you haven't inserted the null revision into the database. See example in
Article::updateRestrictions(). You also have to update the page.page_latest and
page.page_touched fields to ensure a continual relationship and to make sure
various caches are invalidated.

robchur wrote:

*** Bug 7153 has been marked as a duplicate of this bug. ***

Done in filerepo changes. Uploads create a null edit.

(In reply to comment #14)

Done in filerepo changes. Uploads create a null edit.

It does not work reliable. It works on my local testwiki fine, but at least not on WMF wikis.


  1. [[de:Bild:Test watchlist.png]] uploaded today by [[de:User:Raymond]]
  1. Overwritten today by same image by same user. The image history looks ok incl. a null edit but no entry on the wachtlist of [[de:User:Raymond]]

Same effect on Commons today with [[commons:Image:Hohenzollernbrücke Köln - Einfahrt von Westen.jpg]].

Still the same behaviour Raimond described in comment 15. Tested on

brion added a comment.Dec 3 2007, 7:43 PM

It doesn't show up in the watchlist due to bug 5546.

Currently, for operations where we create both log and edit history entries, only the log entry gets added to the recent changes queue. The log entry in RC records the special page title, not the target page title, so doesn't show up in watchlists.

Per notes on bug 5546, there have been changes to the recentchanges table to add log information fields so that the records can be stored in a way that *will* show up on watchlists (putting the log info in [rc_log_type,rc_log_action], while recording the target page in [rc_namespace,rc_title]). When the logging code is updated to make use of this, it should start working as desired. I'll mark this as depending on bug 5546 for now...

Done with r32685 by Aaron Schulz.

Gilles moved this task from Untriaged to Done on the Multimedia board.
epriestley added a commit: Unknown Object (Diffusion Commit).Mar 4 2015, 8:20 AM

Add Comment