Page MenuHomePhabricator

When moving a file at Commons, the created redirect is not recognized (or file usage is not updated) in other wikis and the file is not shown in articles it is included in
Closed, ResolvedPublic

Description

Issue screenshot: As you see you see no files.

The Issue:
-> "The file move example"
Recently we had issues at Wikimedia Commons with CommonsDelinker (a bot that replaces file usage in the Wikimedia Cluster) causing a huge queue of files to be globally replaced e.g. in Wikipedia Articles after moving.

When a file is moved, we leave a redirect in almost all cases. In the past, it was possible to include a file into an article through a file redirect. Consider we have File:A.png and move it to File:B.png. After moving File:A.png redirects to File:B.png. In a Wikipedia article we should be still able to use [[File:A.png|thumb|caption here]]. But this currently does not work; at least for articles where usage of [[File:A.png|thumb|caption here]] started before the file was moved.

The Symptoms:
The file included through a redirect which was created during moving a file does not show up (the thumb box is there but it is completely collapsed; However, there is also no red link like usually created when a file is not found or does not exist)

How to reproduce this issue?

Where did I test?
I used https://commons.wikimedia.org/wiki/File:Testtesttesttest-deleteme.png and moved it to https://commons.wikimedia.org/wiki/File:Testtesttesttest-deleteme_2.png
Now usage at https://de.wikipedia.org/wiki/Benutzer:Rillke/Sandkasten is broken. If you purge the page, it will show up! So don't be surprised if you see the files.

The solution?
The server cache of the page using the file must be deleted if it contained a file that was moved.


Version: unspecified
Severity: normal

Attached:

2012-11-30-BenutzerRillke-Sandkasten-Screenshot.png (331×711 px, 9 KB)

Details

Reference
bz42582

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 1:08 AM
bzimport set Reference to bz42582.
bzimport added a subscriber: Unknown Object (MLST).

Created attachment 11437
HTML source shows that MediaWiki still thinks that the file is at the old position

Attached:

Am I interpreting this correctly? Some caching stops InstantCommons from detecting commons redirects?

Rainer Rillke - You were viewing the page logged in? (That's important to determine which cache is involved).

Do the issues occur only when embedding the image on a foreign-repo client wiki (aka wikipedia). Or does it also happen when the image is being embedded on the same wiki as the image is located (By which i mean does the old version of the page still not get purged if the page with the embedded images is on commons)


Off the top of my head I'm not sure - but this might not be a new issue. I don't think we do cross wiki purges currently. See bug 22390.

I'm unsure if historically the old urls for files may have taken longer before they got killed out of squid cache (Or even if they currently get purged or just fall out naturally).

(In reply to comment #2)

Am I interpreting this correctly? Some caching stops InstantCommons from
detecting commons redirects?

Not instant commons. (Note: instant commons is totally borked with redirects - but that's a separate issue)

Basically when file moves, the url to the file changes (The actual url to the file is not a redirect). I believe what is being reported is that during a move the parser cache of pages using the moved image are not purged if the page is using the image through a foreign repo

Not instant commons. (Note: instant commons is totally borked with redirects -
but that's a separate issue)

Sorry, for bugspam, but for ref the instant commons issue is bug 36751

(In reply to comment #3)

You were viewing the page logged in?

Yes. I edited my sandbox shortly before.

Do the issues occur only when embedding the image on a foreign-repo client wiki
(aka wikipedia).

Yes.

does it also happen when the image is being embedded on the
same wiki as the image is located

No issue here. Tested at Commons. Files displayed correctly after moving in my sandbox there.

Sorry for the confusion. I thought it was clear.

I believe what is being reported is that during a move
the parser cache of pages using the moved image are not purged if the page is
using the image through a foreign repo

Sounds good.

I'm unsure if historically the old urls for files may have taken longer before
they got killed out of squid cache

I believe so. In the past I had the feeling it was "handled more smoothly" (even if it sounds like it wasn't handled at all). Since it is only Commons in the WMF cluster that shares files with other wikis, a really simple purge bot that is tracking the file move log could do the job. Does the WMF run bots? Well, like CommonsDelinker, it is an essential task that has to be done.

Off the top of my head I'm not sure - but this might not be a new issue. I
don't think we do cross wiki purges currently. See bug 22390.

If you like, you can close it as a duplicate of Bug 22390.

  • This bug has been marked as a duplicate of bug 22390 ***
Gilles triaged this task as Unbreak Now! priority.Dec 4 2014, 10:11 AM
Gilles moved this task from Untriaged to Done on the Multimedia board.
Gilles lowered the priority of this task from Unbreak Now! to Needs Triage.Dec 4 2014, 11:23 AM