Last modified: 2010-05-15 15:38:44 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 3424 - New categories - links to them are red
New categories - links to them are red
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
All All
: Normal minor with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2005-09-11 09:05 UTC by Brian Jason Drake
Modified: 2010-05-15 15:38 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

Diff of Title.php rev 1.247 to 1.248 (1.12 KB, patch)
2005-12-20 21:19 UTC, Brion Vibber

Description Brian Jason Drake 2005-09-11 09:05:31 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.
Comment 1 Antoine "hashar" Musso (WMF) 2005-09-18 11:00:08 UTC
Works for me in 1.5 and HEAD.

Please give more details, maybe its a 1.4 bug.
Comment 2 Brian Jason Drake 2005-09-24 06:40:31 UTC
I used MediaWiki (, 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".
Comment 3 Brion Vibber 2005-09-24 06:43:09 UTC
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.
Comment 4 Rowan Collins [IMSoP] 2005-09-24 12:44:42 UTC
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...)
Comment 5 Brian Jason Drake 2005-10-30 08:55:38 UTC
I've just tested this on and it seems 
to work fine.
Comment 6 Ben Arnold 2005-10-30 20:54:33 UTC
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 
Comment 7 Brian Jason Drake 2005-10-31 05:55:14 UTC
I just tried this at the Meta-Wiki site with no 
Comment 8 Ben Arnold 2005-11-01 03:58:49 UTC
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.
Comment 9 Brian Jason Drake 2005-11-01 05:37:02 UTC
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.
Comment 10 Brion Vibber 2005-11-01 06:07:02 UTC
Confirmed it seems to be working on, 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...
Comment 11 Ben Arnold 2005-12-05 02:38:17 UTC
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 
Comment 12 Brian Jason Drake 2005-12-06 03:30:49 UTC
What exactly does that option do? See [[Meta:Help talk:Preferences#Disable_page_caching]].
Comment 13 Brian Jason Drake 2005-12-06 03:36:22 UTC
I tried it again without disabling page caching on and it worked fine.
Comment 14 Brian Jason Drake 2005-12-06 03:38:05 UTC currently 1.6devel
Comment 15 Ben Arnold 2005-12-09 00:37:06 UTC
I have just tested this at 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".
Comment 16 Brian Jason Drake 2005-12-09 01:18:13 UTC
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.
Comment 17 lɛʁi לערי ריינהארט 2005-12-09 01:45:21 UTC
(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]]

Comment 18 Ben Arnold 2005-12-09 03:57:19 UTC
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.
Comment 19 Borgx 2005-12-09 04:03:25 UTC
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".
Comment 20 Borgx 2005-12-13 04:33:43 UTC
This condition seems to happened only on The workaround at #7
is working on wikipedias.
Comment 21 Ben Arnold 2005-12-13 20:45:30 UTC
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.
Comment 22 Brian Jason Drake 2005-12-15 02:56:40 UTC
(In reply to comment #20)
> This condition seems to happened only 
on 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"?
Comment 23 Brian Jason Drake 2005-12-15 02:58:09 UTC
(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".
Comment 24 Ben Arnold 2005-12-15 03:01:40 UTC
(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 25 Brian Jason Drake 2005-12-20 05:04:22 UTC
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.
Comment 26 Rob Church 2005-12-20 15:08:55 UTC
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.
Comment 27 Brion Vibber 2005-12-20 21:17:55 UTC
Fixed in CVS HEAD.
Comment 28 Brion Vibber 2005-12-20 21:19:10 UTC
Created attachment 1220 [details]
Diff of Title.php rev 1.247 to 1.248

The fix as applied.
Comment 29 Ben Arnold 2005-12-20 21:39:30 UTC
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(...).
Comment 30 Ben Arnold 2005-12-22 03:26:58 UTC
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))

Note You need to log in before you can comment on or make changes to this bug.