Last modified: 2012-12-19 20:21:16 UTC
Created attachment 11436 [details] 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? * Log in to Wikimedia Commons https://commons.wikimedia.org/w/index.php?title=Special:UserLogin * Upload a test file. https://commons.wikimedia.org/w/index.php?title=Special:Upload&wpDestFile=RedirectFileIssueTest.jpg * Use it in 2 or 3 wikis e.g. [[File:RedirectFileIssueTest.jpg|thumb|Lorem ipsum dolor sit amet]] * Move it to a new name (don't use Move & Replace provided by a JavaScript); leave a redirect behind 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.
Created attachment 11437 [details] HTML source shows that MediaWiki still thinks that the file is at the old position
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 ***
