Page MenuHomePhabricator

New categories - links to them are red
Closed, ResolvedPublic

Description

Author: brian

Description:
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.


Version: 1.5.x
Severity: minor

Details

Reference
bz3424

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 8:47 PM
bzimport set Reference to bz3424.
bzimport added a subscriber: Unknown Object (MLST).

Works for me in 1.5 and HEAD.

Please give more details, maybe its a 1.4 bug.

brian wrote:

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.

rowan.collins wrote:

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...)

brian wrote:

I've just tested this on www.mediawiki.org and it seems
to work fine.

bena wrote:

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

brian wrote:

I just tried this at the Meta-Wiki site with no
problems.

bena wrote:

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.

brian wrote:

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...

bena wrote:

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.

brian wrote:

What exactly does that option do? See [[Meta:Help talk:Preferences#Disable_page_caching]].

brian wrote:

I tried it again without disabling page caching on mediawiki.org and it worked fine.

brian wrote:

mediawiki.org: currently 1.6devel

bena wrote:

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".

brian wrote:

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.

gangleri wrote:

(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]]

bena wrote:

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.

stanley wrote:

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".

stanley wrote:

This condition seems to happened only on test.leuksman.com. The workaround at #7
is working on wikipedias.

bena wrote:

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.

brian wrote:

(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"?

brian wrote:

(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".

bena wrote:

(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.

brian wrote:

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.

robchur wrote:

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.

Created attachment 1220
Diff of Title.php rev 1.247 to 1.248

The fix as applied.

Attached:

bena wrote:

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(...).

bena wrote:

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;