Last modified: 2011-03-13 18:04:40 UTC
I think there's a problem with the correct auto numbering of links when a xml-like wiki markup extension is involved. More specific:
If a extension which uses xml-like wiki markup, parses wiki links internally, the numbering of the appearing links on the output page is not correct. That means that firstly all links which are parsed within the extension are getting autonumbered and then the rest of the wiki page (the stuff without a xml markup) gets parsed and numbered.
So if you have some links (e.g. at the end of a page), which will be passed to the extension (and will get parsed there) the autonumbering function will give them the numbers 1 to x and then the rest of the links on the page (without a xml Markup) will get the numbers startting with x+1.
So the result is that the numbering of the links is mixed up. (But there are no gaps within that numbering).
I tested this problem with MW Version 1.6.9 and 1.9.3
Here are the different versions of the code I used to parse the links within my xml-like markup extension:
$htmlText = $wgParser ->parse( $wikitext, $wgParser->mTitle, $wgParser->mOptions, false, false );
# $parser was passed as argument to the extension
$htmlText = $parser ->parse( $wikitext, $parser->mTitle, $parser->mOptions, false, false );
also tried it with the recursive entry point of the parser.
This is a limitation of the current multi-pass parser, which in one pass, strips out extension tags, calls the appropriate callback for each, then injects a placeholder for the content so it can be re-inserted at the end. This, of course, happens at a different time to the main link parsing operations, and the internal autonumbering counter is incremented in an inconsistent fashion.
I'm not sure there's a whole lot we can do about this with the current parser or extension hook design, so I'm going to mark it as LATER.