Only template parsing in Special:Ask [[SMW::off]]/[[SMW::on]] is distorted because [1] fails to enter parsing due to $wgParser->getTitle() and $wgParser->getOptions() being null.

I'm not aware of that anyone has worked on this part ([1] and [2] are the same for master and 1.8.0.5) therefore I can't tell why the behaviour are suppose the be different.

[1] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/includes/queryprinters/ResultPrinter.php#L293

[2] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/1.8.0.5/includes/queryprinters/SMW_ResultPrinter.php#L282

PS: Checked the output of $wgParser->getOptions()/$wgParser->getOptions() using var_dump() in Special:ask which yields null.

I don't know if this helps, but the problem appears in Special:RunQuery, too (from SemanticForms), not only in Special:Ask.

See: http://wikincat.org/wiki/Special:RunQuery/AdvancedSearch
(type "wiki", for example, in the first entry field).

(In reply to comment #2)

I don't know if this helps, but the problem appears in Special:RunQuery, too
(from SemanticForms), not only in Special:Ask.

This is due to the "special" status of a SpecialPages where parsing is handled differently in MW in comparison to a standard page.

The issue appears to be the $wgParser stubobject initialization.

[1] https://www.mediawiki.org/wiki/Manual:$wgParser

As an easy fix, just remove [1], [2].

[3] was set for a reason (exists at least since 1.8) which is why the SpecialPage like Ask or RunQuery will show [[SMW::off]]/[[SMW::on]] for a template output.

[1] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/includes/queryprinters/ResultPrinter.php#L303

[2] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/includes/queryprinters/ResultPrinter.php#L304

[3] $result = '[[SMW::off]]' . $result . '[[SMW::on]]';

Ok, thanks.
This fix the Special:Ask, but not the Special:RunQuery.

I was looking at the wrong cause and while the above analysis is certainly not wrong, the reason why the parsing is excluded for Specialpages is that in order to avoid unnecessary parsing and performance degradation [1] checks whether a page is a special page or not and only in a case it is a normal page it uses the SMW\ContentProcessor to process SMW's annotations.

[1] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/includes/hooks/InternalParseBeforeLinks.php#L54

I need some time to think this over since I don't want to make the check arbitrary towards Specialpages. Maybe use something like [1] and only allow specific SpecialPages to pass (setting that tells which Specialpages are allowed to pass).

[1] $this->parser->getTitle()->isSpecial( 'Ask' ) || $this->parser->getTitle()->isSpecial( 'RunQuery' )

[1] should allow to use SMW's internal content processor for listed Specialpages (earlier suggestions for a fix should be reverted in favour of [1]).

Default setting is (deployed with SMW-core):
$GLOBALS['smwgEnabledSpecialPage'] = array( 'Ask' );

In case of SF, [2] should be added to the LocalSettings.

[1] https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/59

[2] $GLOBALS['smwgEnabledSpecialPage'] = array( 'Ask', 'RunQuery' );

Yes, this fixes the problem. Thanks again.
I am not a developer and I don't know PHP, but I put

$smwgEnabledSpecialPage = array( 'Ask', 'RunQuery' );

in LocalSettings.php, instead of

$GLOBALS['smwgEnabledSpecialPage'] = array( 'Ask', 'RunQuery' );

Is this fine, too? Right?

(In reply to comment #9)

Yes, this fixes the problem. Thanks again.
I am not a developer and I don't know PHP, but I put

$smwgEnabledSpecialPage = array( 'Ask', 'RunQuery' );

This works as well.

Merged with master