Last modified: 2014-01-08 16:47:25 UTC
After moving an image, the imagelinks table is not updated straight away. This leads to people nominating images for deletion because they are no longer in use, simply because they were recently moved.
See also Bug 17259
Created attachment 7341 [details] Update the pages in imagelinks after file move I hope I interpreted the process correctly. I think this patch should put the titles of pages that link to the old filename title on the update queue....
We could separate the behavior depending on wether or not a redirect is left behind. If a redirect is left behind, we could just rewrite the database table in one go i guess (a bit like the watchlist entries). This would have the benefit of the new filepage being immediately up to date. (We do need the HTMLCache update when no redirect is left behind, because missing images have different HTML than present images of course.
Created attachment 7342 [details] update imagelinks to new target Implemented direct update of the imagelinks table.
A direct update consumes to much resources, so it should be batched. Note that the parser puts the DBkey of the redirect in the imagelinks table, instead of the target image. This should probably be fixed first. Plan: In ParserOutput addImage() function resolve the DBkey to an article and follow the redirect if needed, store DBkey() of target ? Can redirects only be resolved for Articles or also for Titles ?
How do we handle pagelinks for normal page moves?
(In reply to comment #6) > How do we handle pagelinks for normal page moves? We just keep it pointing to the redirect, I believe.
(In reply to comment #7) > (In reply to comment #6) > > How do we handle pagelinks for normal page moves? > We just keep it pointing to the redirect, I believe. I just confirmed this behaviour on trunk. It currently is thus consistent. The fix for this problem would be show also redirects on the "the following pages link to this file".
On the other hand, new imagelinks will point to *both* the redirect and the redirect target. It should only point to the redirect.
Fixed in r88054.
Is this really fixed in r88054? It seems the redirect created during page move doesn't get its imagelinks entry properly created until r107636 (although prior to r107636, a null edit to the redirect will fix it). So it's still fixed, although the fix isn't completely live in 1.18wmf1 yet.
Change 105830 had a related patch set uploaded by Anomie: Make imagelinks work like templatelinks https://gerrit.wikimedia.org/r/105830
Change 105830 merged by jenkins-bot: Make imagelinks work like templatelinks https://gerrit.wikimedia.org/r/105830
Starting with 1.23wmf10, imagelinks updating on moves and deletions should be more reliable. See https://www.mediawiki.org/wiki/MediaWiki_1.23/Roadmap for the schedule.
