Parsing order of onlyinclude and nowiki/html comments differs on view and include
OpenPublic

Assigned To
None
Priority
Normal
Author
bzimport
Subscribers
Catrope, Tgr, wikibugs-l
Projects
Reference
bz9584
Description

Author: webboy

Description:
When viewing templates the parsing order is:

  • nowiki
  • onlyinclude, noinclude, includeonly

When including templates in pages the parsing order is:

  • onlyinclude, noinclude, includeonly
  • nowiki

This is inconsistent and I think it should be changed.


Version: 1.16.x
Severity: normal

bzimport added a project: MediaWiki-Parser.Via ConduitNov 21 2014, 9:38 PM
bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz9584.
bzimport created this task.Via LegacyApr 15 2007, 9:50 AM
Tgr added a comment.Via ConduitMay 20 2007, 4:04 PM

Parsing nowiki later than noinclude is very counterintuitive and makes writing code examples with noinclude/onlyinclude on template documentation subpages rather complicated.

bzimport added a comment.Via ConduitNov 26 2009, 3:15 AM

paul.copperman wrote:

This has been FIXED with the introduction of the new preprocessor. All tags are now parsed in the same pass, so the outermost tag is now always the most significant.

bzimport added a comment.Via ConduitNov 26 2009, 10:22 AM

webboy wrote:

(In reply to comment #2)

This has been FIXED with the introduction of the new preprocessor. All tags are
now parsed in the same pass, so the outermost tag is now always the most
significant.

On Wikipedia (1.16alpha-wmf (r59214)) this has only been fixed for noinclude and includeonly. onlyinclude is still passed in the wrong order:

When viewing templates the parsing order is:

  • nowiki
  • onlyinclude

When including templates in pages the parsing order is:

  • onlyinclude
  • nowiki

I don't have a MediaWiki installation now to test this for SVN HEAD.

Test case:
Template code:
1<nowiki>2<onlyinclude>3'''nowiki -> onlyinclude'''</onlyinclude>4</nowiki>5

Expected result on template page and page calling template:
12<onlyinclude>3'''nowiki -> onlyinclude'''</onlyinclude>45

Result on template page is OK.

Result on page calling template:
3nowiki -> onlyinclude (with nowiki -> onlyinclude in bold)

bzimport added a comment.Via ConduitNov 26 2009, 1:49 PM

paul.copperman wrote:

(In reply to comment #3)

Test case:
Template code:
1<nowiki>2<onlyinclude>3'''nowiki -> onlyinclude'''</onlyinclude>4</nowiki>5

Expected result on template page and page calling template:
12<onlyinclude>3'''nowiki -> onlyinclude'''</onlyinclude>45

Result on template page is OK.

Result on page calling template:
3nowiki -> onlyinclude (with nowiki -> onlyinclude in bold)

Frankly, I think onlyinclude is a quite strange feature, working a bit different from the other tags. As I understand it,

Foo<onlyinclude>Bar</onlyinclude>Baz

is supposed to work similar to

<noinclude>Foo</noinclude>Bar<noinclude>Baz</noinclude>

So your test case would translate to

<noinclude>1<nowiki>2</noinclude>3'''nowiki -> onlyinclude'''<noinclude>4</nowiki>5</noinclude>

which renders as

3nowiki -> onlyinclude

when included, so the result you mention actually seems to be the expected output.

Catrope added a comment.Via ConduitNov 26 2009, 2:07 PM

(In reply to comment #4)

Frankly, I think onlyinclude is a quite strange feature, working a bit
different from the other tags. As I understand it,

Foo<onlyinclude>Bar</onlyinclude>Baz

is supposed to work similar to

<noinclude>Foo</noinclude>Bar<noinclude>Baz</noinclude>

So your test case would translate to

<noinclude>1<nowiki>2</noinclude>3'''nowiki ->
onlyinclude'''<noinclude>4</nowiki>5</noinclude>

which renders as

3nowiki -> onlyinclude

when included, so the result you mention actually seems to be the expected
output.

I think this argument is wrong for two reasons. First, the onlyinclude tag is inside a nowiki tag; stuff in nowiki tags should not be parsed ever, the parser should leave it alone completely. Second, the 'translation' you give is flawed, as it misnests noinclude and nowiki tags. The parser has to make sense out of that tag soup, which kind of defeats your point.

bzimport added a comment.Via ConduitNov 26 2009, 2:20 PM

paul.copperman wrote:

(In reply to comment #5)

I think this argument is wrong for two reasons. First, the onlyinclude tag is
inside a nowiki tag; stuff in nowiki tags should not be parsed ever, the parser
should leave it alone completely. Second, the 'translation' you give is flawed,
as it misnests noinclude and nowiki tags. The parser has to make sense out of
that tag soup, which kind of defeats your point.

It wasn't really meant as an argument, rather as a descrtiption of the status quo. If I had to choose, I would rather drop the feature completely, than change the functionality of it once more, just to make preprocessing even more complicated

tstarling added a comment.Via ConduitNov 26 2009, 10:06 PM

The terminology in the bug summary is incorrect for the 1.12 parser. I went to a lot of trouble to simulate the 1.11 handling of onlyinclude as closely as possible in the 1.12 parser, to maintain backwards compatibility. If you call that behaviour a bug then so be it. But the problem is not "parse order" since onlyinclude is processed at the same time as nowiki. It could be described as precedence. See the awkward handling of onlyinclude here:

http://www.mediawiki.org/wiki/Preprocessor_ABNF

Catrope added a comment.Via ConduitNov 26 2009, 10:32 PM

(In reply to comment #7)

The terminology in the bug summary is incorrect for the 1.12 parser. I went to
a lot of trouble to simulate the 1.11 handling of onlyinclude as closely as
possible in the 1.12 parser, to maintain backwards compatibility. If you call
that behaviour a bug then so be it. But the problem is not "parse order" since
onlyinclude is processed at the same time as nowiki. It could be described as
precedence. See the awkward handling of onlyinclude here:

http://www.mediawiki.org/wiki/Preprocessor_ABNF

Slightly less technical translation of this comment and the details at the link: onlyinclude has a higher precedence than everything else, which explains the behavior in inclusion mode. However, in non-inclusion mode, the parser doesn't look for or recognize onlyinclude tags; they're not recognized as anything special and are treated as literal text.

(For completeness, an explanation of what precedence means: the parser will prefer to interpret things with a high precedence over things with a low precedence. The classic example is that 3+4*5 equals 23 because * has a higher precedence than + .)

duplicatebug added a comment.Via ConduitJun 21 2011, 5:16 PM
  • Bug 24546 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitApr 19 2012, 5:58 PM

richardg_uk wrote:

This an ongoing problem (1.19+): http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#VPT_not_showing_up_at_VPALL

The parse order is inconsistent and unintuitive.

duplicatebug added a comment.Via ConduitSep 16 2012, 9:15 AM

Same for html comments. onlyinclude tags on inclusion are handled before the html comments, which makes the onlyinclude acts like includeonly.

duplicatebug removed a subscriber: duplicatebug.Via WebDec 13 2014, 11:46 AM

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.