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.
PHP: 4.3.8 (apache2handler)
I just tried this at the Meta-Wiki site with no
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
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
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
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
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
(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):