Last modified: 2012-09-16 09:15:04 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 9584 - Parsing order of onlyinclude and nowiki/html comments differs on view and include
Parsing order of onlyinclude and nowiki/html comments differs on view and inc...
Status: NEW
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.16.x
All All
: Normal normal with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 24546 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-15 09:50 UTC by Jelte (WebBoy)
Modified: 2012-09-16 09:15 UTC (History)
6 users (show)

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


Attachments

Description Jelte (WebBoy) 2007-04-15 09:50:09 UTC
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.
Comment 1 Tisza Gergő 2007-05-20 16:04:50 UTC
Parsing nowiki later than noinclude is very counterintuitive and makes writing code examples with noinclude/onlyinclude on template documentation subpages rather complicated.
Comment 2 P.Copp 2009-11-26 03:15:51 UTC
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.
Comment 3 Jelte (WebBoy) 2009-11-26 10:22:23 UTC
(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)

Comment 4 P.Copp 2009-11-26 13:49:31 UTC
(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.
Comment 5 Roan Kattouw 2009-11-26 14:07:43 UTC
(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.
Comment 6 P.Copp 2009-11-26 14:20:45 UTC
(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
Comment 7 Tim Starling 2009-11-26 22:06:53 UTC
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
Comment 8 Roan Kattouw 2009-11-26 22:32:46 UTC
(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 + .)
Comment 9 db [inactive,noenotif] 2011-06-21 17:16:53 UTC
*** Bug 24546 has been marked as a duplicate of this bug. ***
Comment 10 Richard Guk 2012-04-19 17:58:52 UTC
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.
Comment 11 db [inactive,noenotif] 2012-09-16 09:15:04 UTC
Same for html comments. onlyinclude tags on inclusion are handled before the html comments, which makes the onlyinclude acts like includeonly.

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


Navigation
Links