Last modified: 2013-02-06 02:30:30 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T25287, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 23287 - Problems after setting $wgCategoryPrefixedDefaultSortkey on Swedish Wikisource
Problems after setting $wgCategoryPrefixedDefaultSortkey on Swedish Wikisource
Product: Wikimedia
Classification: Unclassified
Site requests (Other open bugs)
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
Blocks: Wikisource 25297
  Show dependency treegraph
Reported: 2010-04-22 07:01 UTC by Lars Aronsson
Modified: 2013-02-06 02:30 UTC (History)
10 users (show)

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


Description Lars Aronsson 2010-04-22 07:01:19 UTC
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
Comment 1 Roan Kattouw 2010-04-22 19:38:42 UTC
This needs a refreshLinks.php run after switching the setting.
Comment 2 Lars Aronsson 2010-04-22 21:26:33 UTC
So the documentation says. But what does it mean, and who can do that?
Comment 3 Roan Kattouw 2010-04-22 21:28:44 UTC
(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.
Comment 4 JeLuF 2010-04-23 22:28:17 UTC

refreshLinks.php is currently running, should be finnished in about 10 Minutes or so.
Comment 5 Lars Aronsson 2010-04-23 22:59:08 UTC
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.
Comment 6 Lars Aronsson 2010-04-24 16:51:19 UTC
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.
Comment 7 Lejonel 2010-04-24 20:58:15 UTC
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.
Comment 8 Lejonel 2010-04-24 22:35:44 UTC
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.

2. Go to 

3. Paste the wikicode in (for example) and preview.

4. 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.
Comment 9 Lejonel 2010-04-24 22:44:36 UTC
Just because I made the comments everything looks fine now. (someone fixed it? or 24 hour caching?)
Comment 10 JeLuF 2010-04-25 07:11:15 UTC
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.
Comment 11 Lars Aronsson 2010-04-25 12:07:38 UTC
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.
Comment 12 ThomasV 2010-06-19 08:28:14 UTC
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 ?
Comment 13 Foroa 2011-02-18 14:49:08 UTC
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.
Comment 14 Bawolff (Brian Wolff) 2013-02-06 02:30:30 UTC
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).

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