Parser functions cannot control their output
OpenPublic

Description

Author: conrad.irwin

Description:
At the moment some parser functions/variables output is partially escaped and partially treated as wikitext (using wfEscapeWikiText). This breaks both parsing and the use of the output of one variable as input to another, see:

{{PAGENAME}} on [[*]]
{{urlencode:{{PAGENAME}}}} on [[&]]

The solution I propose is to add a new class of UNIQ tags to the parser. Extensions can "return $parser->armouredText( $text );" where they currently "return wfEscapeWikiText( $text )".

The parser should have two replacements for each armouredText, when calling further parser functions, it replaces it with the original; when outputting, it replaces it with the escaped version (at the same time <nowiki> is re-expanded). The ugliness is that it will require several changes to allow armouredText UNIQs to be part of links/template names/magic words.

A much hackier alternatively is an inclusion prefix or two (cf. msg: int: msgnw:) that could be added such that {{plain:PAGENAME}} returns the unescaped version, while {{armour:PAGENAME}} puts it into one of the existing nowiki UNIQs - but this really shouldn't be exposed to users.


Version: unspecified
Severity: normal

bzimport added a project: MediaWiki-Parser.Via ConduitNov 21 2014, 11:08 PM
bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz22880.
bzimport created this task.Via LegacyMar 18 2010, 12:34 PM
Mormegil added a comment.Via ConduitMar 18 2010, 1:08 PM

Isn’t this just a duplicate of bug #12974?

bzimport added a comment.Via ConduitMar 18 2010, 1:14 PM

conrad.irwin wrote:

Fixing this would fix some (but not all) of the problems caused by bug 12974, and vice versa, but they are not duplicates.

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.