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

lars wrote:

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

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

jeluf wrote:

Done.

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

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,
http://sv.wikisource.org/wiki/Kategori:Ej_korrekturl%C3%A4st

An Index: page that used to contain a mix of pages in green, yellow
and red status, now has all pages marked red,
http://sv.wikisource.org/wiki/Index:Amtmannens_d%C3%B6ttrer.djvu

Individual pages in the Page: namespace look very naked, e.g.
http://sv.wikisource.org/wiki/Sida:Amtmannens_d%C3%B6ttrer.djvu/144

Pages that were proofread after the change look alright
and appear in categories as they should, e.g.
http://sv.wikisource.org/wiki/Sida:Amtmannens_d%C3%B6ttrer.djvu/118

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.

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.

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 http://sv.wikisource.org/w/index.php?title=Sida:Julqv%C3%A4llen_-_tre_s%C3%A5nger.djvu/10&action=edit&oldid=49533

3. Paste the wikicode in (for example) http://sv.wikisource.org/w/index.php?title=Sida:Test&action=edit 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.

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

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() );
print_r($parserOutput->mText);

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 http://sv.wikisource.org/wiki/Sida:Amtmannens_d%C3%B6ttrer.djvu/90

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.

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.

thomasV1 wrote:

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

example: http://fr.wikisource.org/wiki/Livre:Bulletin_de_la_soci%C3%A9t%C3%A9_g%C3%A9ologique_de_France_-_1re_s%C3%A9rie_-_III_-_1832-1833.djvu

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 ?

ForoaW wrote:

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

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