Last modified: 2011-03-13 18:06:15 UTC
I've noticed that when replacing a certain image on a few wikis, the usage was instantly updated. Also the usage of the old image was instantly un-done as if it was no longer in use (which is true for the latest version, but not the the latest "stable" version). I'm not sure by which Extension this sould be handled, but I'm reporting it here.
cc. Aaron I have no clue about this flaggedrevs speak :)
I'll rephrase -- I've noticed that when I replace a used image with another one in an article on a wikipedia, that the GlobalUsage page of the new image was instantly updated. Also the usage of the old image was instantly up2date as no longer in use on that article. However, on wikis were FlaggedRevs (or Pending Changes) is in use this is actually incorrect. Because although it is correct for latest revision, not per se for the latest "stable" revision. The old image is no longer indicated as used on that article in GlobalUsage, but in the latest stable revision (!== latest revision) the old image is still in use. This is problematic on Commons when deleting or universal replacing an image. A vandal may have blanked a wiki page and thuss, eventho it hasn't been marked as a stable revision, it does hide from GlobalUsage. A Commons admin then deletes an image, sees no gobal usage and then all of the sudded there will be a missing image in that latest stable version of the article. I'm not sure by which Extension this sould be handled, but I'm reporting it here.
Thanks for the explanation. I think that flaggedrevs should only update the links tables when a pending revision is approved, so changing component to FlaggedRevs
(In reply to comment #3) > Thanks for the explanation. > I think that flaggedrevs should only update the links tables when a pending > revision is approved, so changing component to FlaggedRevs That is already WONTFIXED elsewhere (breaking consistency, bots, and drains performance).
Actually, even without FR, blanking a page (or the like) could lead to the same bad-timing deletion mistake. Such edits (with or without FR) should be reverted quickly though.
(In reply to comment #5) > Actually, even without FR, blanking a page (or the like) could lead to the same > bad-timing deletion mistake. Such edits (with or without FR) should be reverted > quickly though. Outside the scope of this, that's bug (In reply to comment #4) > (In reply to comment #3) > > Thanks for the explanation. > > I think that flaggedrevs should only update the links tables when a pending > > revision is approved, so changing component to FlaggedRevs > > That is already WONTFIXED elsewhere (breaking consistency, bots, and drains > performance). WONTFIX per that comment, bug 20813 and bug 15250.
(In reply to comment #6) > Outside the scope of this, that's bug > Bug 17154, I meant to say :)
Bug 17154 seems unrelated. That's about the links not updating sometimes when they should. The issue of the links being gone due to a page in a vandalized, blanked, state when a commons admin happened to check for a deletion is by design. The stable version not having tracking links in the global usage table is also by design (implicitly). Doing so would require some tricks to avoid parsing.
