Last modified: 2012-03-01 05:28:11 UTC
https://de.wikipedia.org/w/index.php?title=Spezial:Logbuch&page=Roy+Worters&hide_review_log=0 Times UTC+1, article viewing not logged-in(!) ========== * before 2011-12-23T20:35:29: the images were mis-oriented since the flaged revisions setup froze article and showed the old file versions (which are in two templates on bottom of the article). * 2011-12-23T20:35:31 I removed and set the flag for the last version. The files show up correctly afterwards. * 2011-12-23T20:38:12 NowCommons-Sichtbot reflagged the last revision. Images were mis-oriented again although it would be expected that the keep showing the current file versions like before. This is the flaggedrevs bug this report is about.
I assume the bot edits via the API, which always uses the current versions. In that case, the only issue could be some sort of outdated cache of what current templates/files and revision of a page uses.
The misbehaviour not only happened in this single case but is easily reproduceable in at least a dozen examples. Procedure: - Latest version of article is flagged. - Included image is changed at commons, or locally deleted and so included from commons for now on. - Article keeps link to old image. So far so good. - Article is flagged again via API, logentry is created. In nearly all cases the image is displayed correctly now. In _some_ cases: - Article shows image wrong. - Via web UI remove flag and set flag again. - Article shows image right. - Via API set flag again, logentry is created. - Article shows image wrong. - ...repeat In all cases I speak of "flag" or "unflag", I am speaking of flagging or unflagging _the same version_ of the article, which is the top version. So in some cases via API, although the flagging of the top version of an article creates a log entry saying that the top version of the artcle was flagged again, the web UI (for not-logged-in users) shows an older version of included images. This all does happen only in some cases I don't see any pattern in. The only escape seems to be to create a new version; a zero-edit doesn't help, too.
If you review pages on diffs with diffonly=1 do you get similar problems as with reviewing via API?
No, this has never been observed, and is not reproducable. The problem only arises if you review again a version that is already reviewed, which is only possible via the API, as the web interface doesn't show the neccessary button (only grayed and not pushable).
Fixed in r112773 (not live).
