Hi,
I have been using and writing extensions for MediaWiki for a little while now. Lots of them use $wgParser->parse to format output using MediaWiki functions. This seems to break if used in an included page. Instead of rendering the output you get "UNIQ211d04e92beed640...".
It looks to me that the parser requires another step to finish the replacements, and that somehow calling "parse" stops this happening.
Using the parse function in principle is very handy, as can be used clean input, and correctly format links to media wiki style. The cleaning of the input is especially useful, as otherwise every extension has to determine if any of their parameters have an XSS attack in them (or am I missing something??).
So my questions are:
Is this behaviour a bug, or by design?
If it is by design, is there something that can be called to get the parser back into a correct state? Or is there a different function that can be called to benefit from MediaWiki's XSS checks?
Best regards,
Alex Powell
Alex Powell wrote:
I have been using and writing extensions for MediaWiki for a little while now. Lots of them use $wgParser->parse to format output using MediaWiki functions. This seems to break if used in an included page. Instead of rendering the output you get "UNIQ211d04e92beed640...".
You need to pass the right parameters to the parse function or it clears state and messes thigns up. Hopefully we'll get this cleaned up more easily by 1.8 (which should be released in October).
See Cite.php for an example that's known to work with current MediaWiki.
-- brion vibber (brion @ pobox.com)
mediawiki-l@lists.wikimedia.org