Last modified: 2010-05-15 15:38:44 UTC
If I type [[Category:A]] in a page and then create the category "A", it the category link on the page will remain red until I purge the cache for Category:A.
Works for me in 1.5 and HEAD. Please give more details, maybe its a 1.4 bug.
I used MediaWiki (www.mediawiki.org), which is running 1.6alpha. It had a red link, as described above, and still had a red link after a normal refresh (F5), but when I did a hard refresh (CTRL+F5), it had a blue link. I am using Windows XP with all updates (so I am using whatever version of IE that has) with cache updating set to "Automatic".
I can confirm this, I checked it the other day so unless someone fixed it yesterday and I didn't notice, it's still current. Probably category backlinks aren't being followed for purging on page creation.
Yes, looks like Title::touchLinks() and Title::getLinksTo() [which it looks like Article.php uses to do the squid purging] only look in the pagelinks table, when really they need to look at categorylinks as well (or the first does; the second may be used for other things which *wouldn't* want that...)
I've just tested this on www.mediawiki.org and it seems to work fine.
I've had this problem in MediaWiki versions 1.5b4 and 1.5.1. I haven't been able to reproduce it on Wikimedia sites, possibly because they're at 1.6alpha or possibly because caching is handled differently at Wikimedia. My experience is only slightly different from the description. To fix it I have purged the cache for article with the red link, not the category. Purging the category doesn't fix it. Nor does a hard refresh. MediaWiki: 1.5.1 PHP: 4.3.8 (apache2handler) MySQL: 4.0.20a-debug
I just tried this at the Meta-Wiki site with no problems.
Meta-Wiki is a Wikimedia site. According to Rob Church on the Mediawiki-l list, Wikimedia sites use a "weird and wonderful caching system". It's possible that the Wikimedia caching system hides this defect.
I know Meta-Wiki is a Wikimedia site - when they were being upgraded to 1.6beta, it looked like the projects were done separately, and there are many different aspects (the English Wikipedia login page is particularly different), so I thought they might use different caching systems too.
Confirmed it seems to be working on meta.wikimedia.org, but I can still confirm it's failing on 1.6 at home. Probably related to use of squid cache mode on Wikimedia sites. Investigating...
I have tried ticking the "Disable page caching" option under user preferences, but this doesn't fix the problem. My installation is still the same (see prior comment) and I'm running these servers on Windows XP Professional.
What exactly does that option do? See [[Meta:Help talk:Preferences#Disable_page_caching]].
I tried it again without disabling page caching on mediawiki.org and it worked fine.
mediawiki.org: currently 1.6devel
I have just tested this at http://test.leuksman.com/ and confirm that it still seems to be a problem there. Not sure if that's useful information or how recent their version is. It says "1.6devel" but that I think that just means "head".
I presume you are referring to the Main Page category called "Redlinktest"? I checked just now, not having opened that page previously on this computer, and it still had a red link. I don't know how to purge the cache on that wiki.
(In reply to comment #16) > I don't know how to purge the cache on that wiki. Append "?action=purge" to the url if no "?" is included already, else append "&action=purge". best regards reinhardt [[user:gangleri]]
Yeah it had a red link, as you saw, but the category page was already in existence. In fact if you had clicked the red link you would have seen that the edit box already had content in it.
Confirmed. purge cache, clearing browser cache and enabling "disable page cache" has no effect. The link is still "red" . Unless you edit the page, add something and save. it'll become "blue link".
This condition seems to happened only on test.leuksman.com. The workaround at #7 is working on wikipedias.
I'd guess that the Mediawiki sites are the exception, rather than the general case, because of their special caching configuration (see comment #8). There are two workarounds I know of. One is to add "? action=purge" to refresh the page with the red links. The other is to avoid the problem in the first place: create the category before you use it anywhere. Both of these workarounds require user training, and are sufficiently technical to be prohibitive for most casual users, so I don't think they constitute a complete solution.
(In reply to comment #20) > This condition seems to happened only on test.leuksman.com. The workaround at #7is working on wikipedias. Comment #7 simply states that the bug cannot be reproduced on Meta-Wiki. How is that a "workaround"?
(In reply to comment #18) > Yeah it had a red link, as you saw, but the category page was already in existence. In fact if you had clicked the red link you would have seen that the edit box already had content in it. Yeah, the category page was in existence; that's why we are calling it a bug. If the category page wasn't in existence this bug would be marked "fixed".
(In reply to comment #23) > If the category page wasn't in existence this bug would be marked "fixed". Yeah I know, just clarifying what happens.
Comment 4 seems to be the only comment that discusses where the bug actually is and how to fix it, apart from the comments that discuss caches, which now don't really seem to be relevant.
Another case of this reported in IRC the other day; "fixed" it there and then with a quick purge. It's obviously a lovely caching issue which isn't affecting Wikimedia due to the squid cluster.
Fixed in CVS HEAD.
Created attachment 1220 [details] Diff of Title.php rev 1.247 to 1.248 The fix as applied.
Cheers Brion! There were other changes around that patch that I needed to bring myself up to date with (I'm at 1.5.1). But the end result was that it worked. In addition to the change marked by the patch I also removed the apparently unused $arr variable, and I added the if-return statement above the $dbw->update(...).
I have upgraded to 1.5.4. This fix did not make it into that release. When applying the patch to 1.5.4 you also need to include the missing lines I alluded to before (they're in the diff, but not marked as new): if (!count($toucharr)) return;
