Last modified: 2011-01-25 01:35:38 UTC
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 [[goatse.cx]]. 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 . . 188.8.131.52 (Talk) (more pron
Alernatively it could be modeled more after "File history" entries on the image
description page (Image:):
(desc) . . ClitorisNewLoc2.jpg; 17:17:05 . . 184.108.40.206 (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
To show up in the watchlist would require updating the timestamp of the image description page
(In reply to comment #1)
> To show up in the watchlist would require updating the timestamp of the image
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?
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...
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
*** Bug 4803 has been marked as a duplicate of this bug. ***
(from bug 4803)
> ...so I would suggest that actions like overwriting
images and reverting to older revisions of an image be
noted somehow in people's watchlists.
Poking 'upload' in the summary for easier searching
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
Created attachment 2237 [details]
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).
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).
2) 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...
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.
*** 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]]
2. 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
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.