See also Bug 17259

Created attachment 7341
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....

attachment updateimagelinks.patch ignored as obsolete

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
update imagelinks to new target

Implemented direct update of the imagelinks table.

Attached:

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 ?

Bryan.TongMinh wrote:

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.

Bryan.TongMinh wrote:

(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".

Bryan.TongMinh wrote:

On the other hand, new imagelinks will point to *both* the redirect and the redirect target. It should only point to the redirect.

Bryan.TongMinh wrote:

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.