Last modified: 2011-01-25 01:35:38 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 778 - Image upload replacements should create watchlist entry
Image upload replacements should create watchlist entry
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
All All
: Normal enhancement with 23 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: 4803 7153 (view as bug list)
Depends on: 5546
  Show dependency treegraph
Reported: 2004-10-25 16:58 UTC by Guttorm Flatabø
Modified: 2011-01-25 01:35 UTC (History)
5 users (show)

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

Possible patch for issue (645 bytes, patch)
2006-08-16 23:04 UTC, Siebrand Mazeland

Description Guttorm Flatabø 2004-10-25 16:58:49 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 [[]]. 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).
Comment 1 Brion Vibber 2004-10-26 05:16:31 UTC
To show up in the watchlist would require updating the timestamp of the image description page 
Comment 2 Guttorm Flatabø 2004-10-26 17:08:44 UTC
(In reply to comment #1)
> To show up in the watchlist would require updating the timestamp of the image
description page 
> itself.

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?
Comment 3 Rowan Collins [IMSoP] 2005-06-21 00:35:58 UTC
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...
Comment 4 David Benbennick 2005-12-30 21:51:24 UTC
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.)
Comment 5 Melancholie 2006-01-31 12:57:43 UTC
*** Bug 4803 has been marked as a duplicate of this bug. ***
Comment 6 Melancholie 2006-01-31 13:02:29 UTC
(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.
Comment 7 Brion Vibber 2006-01-31 20:52:55 UTC
Poking 'upload' in the summary for easier searching
Comment 8 Andrew 2006-02-27 22:39:41 UTC
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.
Comment 9 Siebrand Mazeland 2006-08-16 23:04:13 UTC
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).
Comment 10 Rob Church 2006-08-16 23:15:39 UTC
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.
Comment 11 Siebrand Mazeland 2006-08-17 07:51:27 UTC
(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...
Comment 12 Rob Church 2006-08-18 17:34:44 UTC
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.
Comment 13 Rob Church 2006-08-28 21:49:40 UTC
*** Bug 7153 has been marked as a duplicate of this bug. ***
Comment 14 Aaron Schulz 2007-07-21 11:37:36 UTC
Done in filerepo changes. Uploads create a null edit.
Comment 15 Raimond Spekking 2007-08-28 10:58:54 UTC
(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]].
Comment 16 Siebrand Mazeland 2007-10-19 09:01:02 UTC
Still the same behaviour Raimond described in comment 15. Tested on
Comment 17 Brion Vibber 2007-12-03 19:43:04 UTC
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...
Comment 18 Raimond Spekking 2008-04-02 07:03:04 UTC
Done with r32685 by Aaron Schulz.

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