Difference between revisions of "MediaWiki/archive/v1.12"

from HTYP, the free directory anyone can edit if they can prove to me that they're not a spambot
Jump to navigation Jump to search
(New page: ==Navigation== <section begin=navbar />{{#lst:MediaWiki|navbar}}: version 1.12<section end=navbar /> ==Parser Changes== The wikitext parser (Parser.php) has been substan...)
 
(→‎Attempted Solutions: one in-code solution)
Line 47: Line 47:
 
===Attempted Solutions===
 
===Attempted Solutions===
 
So far, all solutions seem to involve making changes to extension code or creating entirely new extensions to do things properly rather than relying on the vagaries of parser processing. Also, I haven't yet found any solutions which can be used as a drop-in replacement for templates using this function (or presumably other parser functions broken by the change). Will document what I find as I map it out. --[[User:Woozle|Woozle]] 21:47, 13 August 2008 (EDT)
 
So far, all solutions seem to involve making changes to extension code or creating entirely new extensions to do things properly rather than relying on the vagaries of parser processing. Also, I haven't yet found any solutions which can be used as a drop-in replacement for templates using this function (or presumably other parser functions broken by the change). Will document what I find as I map it out. --[[User:Woozle|Woozle]] 21:47, 13 August 2008 (EDT)
 +
* '''return $parser->recursiveTagParse($out);''' instead of '''return $out;''', where $out is the parser function's output. Perhaps this can be made conditional on the parser version, if there is a constant for that.

Revision as of 01:53, 14 August 2008

Navigation

{{#lst:MediaWiki|navbar}}: version 1.12

Parser Changes

The wikitext parser (Parser.php) has been substantially rewritten for this version. Although this makes it more efficient (presumably faster serving of pages), it also breaks some extensions and certain usages of other extensions.

The basic problem seems to be the order in which things are processed. In v1.12, <tag>s are processed first, followed by {{#parser_function}}s; the latter are also only parsed once, whereas before there were sometimes two (or possibly more) passes.

Example

A third-party parser function called xploop is invoked like this: {{#xploop:\one\two\three\four|\n* This is line $s$}} This results in the following, where the "\one\two\three\four" string is split on the first character ("\") and the remaining text is "executed" once for each item found, with "$s$" being replaced by the value from the first string:

  • This is line one
  • This is line two
  • This is line three
  • This is line four

This continues to work under 1.12. The problem occurred with a usage where the $s$ was being used to refer to a variable set using the PageVars extension:

{{#vardefine:varone|first}}
{{#vardefine:vartwo|second}}
{{#vardefine:varthree|third}}
{{#vardefine:varfour|fourth}}
{{#vardefine:var$s$|WRONG!}}
{{#xploop:\one\two\three\four|\n* This is the \o#var:var$s$\c line}}

("\n", "\o", and "\c" are all "escape" sequences translated by the EscapeChars extension into a newline, double open braces, and double closing braces respectively.)

Under v1.11, the output was:

  • This is the first line
  • This is the second line
  • This is the third line
  • This is the fourth line

Under v1.12, the output now looks like this:

  • This is the {{#var:varone}} line
  • This is the {{#var:vartwo}} line
  • This is the {{#var:varthree}} line
  • This is the {{#var:varfour}} line

In other words, the \o and \c are being translated into braces, but the braces are not then being parsed to execute the #var parser function. Changing the \o and \c to actual braces gives this output:

  • This is the WRONG! line
  • This is the WRONG! line
  • This is the WRONG! line
  • This is the WRONG! line

In other words, the {{var:var$s$}} sequence is being parsed before the $s$ is replaced – the situation which the escape characters are intended to prevent. So the parsing behavior before calling the outer #xploop function seems unchanged; what has changed is that the output of #xploop is no longer being parsed further.

Attempted Solutions

So far, all solutions seem to involve making changes to extension code or creating entirely new extensions to do things properly rather than relying on the vagaries of parser processing. Also, I haven't yet found any solutions which can be used as a drop-in replacement for templates using this function (or presumably other parser functions broken by the change). Will document what I find as I map it out. --Woozle 21:47, 13 August 2008 (EDT)

  • return $parser->recursiveTagParse($out); instead of return $out;, where $out is the parser function's output. Perhaps this can be made conditional on the parser version, if there is a constant for that.