Problems after setting $wgCategoryPrefixedDefaultSortkey on Swedish Wikisource
Closed, DeclinedPublic


Author: lars

For the Swedish Wikisource (,
we want the variable$wgCategoryPrefixedDefaultSortkey
set to false, so category content is sorted
alphabetically without regard to namespaces.

There is a community consensus for this change.
Five users expressed their enthusiastic support,
and nobody was against,ötesplatsen#Kategorisortering

Version: unspecified
Severity: normal

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz23287.
bzimport created this task.Via LegacyApr 22 2010, 7:01 AM
Catrope added a comment.Via ConduitApr 22 2010, 7:38 PM

This needs a refreshLinks.php run after switching the setting.

bzimport added a comment.Via ConduitApr 22 2010, 9:26 PM

lars wrote:

So the documentation says. But what does it mean, and who can do that?

Catrope added a comment.Via ConduitApr 22 2010, 9:28 PM

(In reply to comment #2)

So the documentation says. But what does it mean, and who can do that?

It's a reminder for Rob, to whom I assigned this bug.

bzimport added a comment.Via ConduitApr 23 2010, 10:28 PM

jeluf wrote:


refreshLinks.php is currently running, should be finnished in about 10 Minutes or so.

bzimport added a comment.Via ConduitApr 23 2010, 10:59 PM

lars wrote:

Is the operation completed now?

The categories are now sorted without regard to namespaces, fine.

But most of the categorized pages don't appear in categories anymore.
Our category for not proofread pages (status 1, color red) has shrunk
from 7800 pages to 582 pages,

An Index: page that used to contain a mix of pages in green, yellow
and red status, now has all pages marked red,

Individual pages in the Page: namespace look very naked, e.g.

Pages that were proofread after the change look alright
and appear in categories as they should, e.g.

bzimport added a comment.Via ConduitApr 24 2010, 4:51 PM

lars wrote:

JeLuF and Roan tried to run refreshLinks.php without disabling
all the hooks, but this didn't help. We ended up doing
"null edits" of all articles in the Page namespace. Since
real null edits aren't saved, we added a whitespace in a
place where it doesn't show.

Lejonel added a comment.Via ConduitApr 24 2010, 8:58 PM

From refreshLinks.php:

70 # Don't generate extension images (e.g. Timeline)
71 if( method_exists( $wgParser, "clearTagHooks" ) ) {
72 $wgParser->clearTagHooks();
73 }

That will not just disable tags that generate images. Other tags (like <pagequality> which adds category links) are also disabled.

Testing on my own wiki with these lines commented out, the links are updated.

Lejonel added a comment.Via ConduitApr 24 2010, 10:35 PM

Is there some kind of cache for the results of parsing wikitext?
Because the following is very strange:

  1. Disable javascript to make it easier to see complete wikicode in page namespace.
  1. Go to
  1. Paste the wikicode in (for example) and preview.
  1. See the "unparsed" <pagequality> tag.

I get the same result logged in or out, and also if previewing in other namespaces. This does not happen if the wikicode is changed to something that was not parsed by the link refreshing.

Lejonel added a comment.Via ConduitApr 24 2010, 10:44 PM

Just because I made the comments everything looks fine now. (someone fixed it? or 24 hour caching?)

bzimport added a comment.Via ConduitApr 25 2010, 7:11 AM

jeluf wrote:

Yes, the clearTagHooks() line caused the initial problem.

Yes, there is caching of a lot of things in mediawiki.
We've used the following input to eval.php for testing:

$wgTitle = Title::newFromID( 12857 );
$revision = Revision::newFromTitle( $wgTitle );
$options = new ParserOptions;
$parserOutput = $wgParser->parse( $revision->getText(), $wgTitle, $options, true, true, $revision->getId() );

With memcached access disabled, the <pagequality> tag gets rendered correctly, with memcached enabled, we get &lt;pagequality&gt; as output. This output might be the cached result of the initial refreshLinks.php run.

12857 is

There was a bot doing whitespace edits to all pages. That might have fixed the issues on the site. "Might", since I can't see the bots edit e.g. in the history of Amtmannens_döttrer/90.

I remove the shell keyword, this is either a ProofreadPage issue or a refreshLinks.php issue.

bzimport added a comment.Via ConduitApr 25 2010, 12:07 PM

lars wrote:

Page 90 was manually edited by user "Obelix". But the bot went
through all other articles that didn't appear in categories.
The bot job was finished some hours ago.

bzimport added a comment.Via ConduitJun 19 2010, 8:28 AM

thomasV1 wrote:

A similar issue is sometimes observed on index pages at :
The pagelist tag is not recognized.


Any edit to the page solves it, but the problem tend to come back after a while...

Is there a way to know if refreshLinks has been used on this page ?

bzimport added a comment.Via ConduitFeb 18 2011, 2:49 PM

ForoaW wrote:

Correct name space independent sorting even more needed at Commons with its many very large categories. ($wgCategoryPrefixedDefaultSortkey
set to false). Current sorting seems be mixed up. Suggest to run refreshLinks.php. Thank you.

Bawolff added a comment.Via ConduitFeb 6 2013, 2:30 AM

This issue is old. Closing worksforme

The setting that is being talked about doesn't even exist anymore in MediaWiki (nor has it since 1.17)

If anyone is actually still experiancing the issue of random parser hooks not rendering sometimes, please re-open (or at this point, even just file a new bug. Its unlikely to be caused by a refreshLinks.php run from 3 years ago).

For anything related to namespace independant sorting (like comment 13) please open a new bug (however that shouldn't really be an issue anymore).

Aklapper added a project: Wikisource.Via WebMar 10 2015, 4:16 PM

Add Comment