Page MenuHomePhabricator

Method to quote characters with special meaning before sending them to PPFrame->expand()
Open, MediumPublic

Description

In three of my extensions I ran into the following problem:
Assume you have some user input, for example through a parser function. Now you want to use that string as a part of some wiki markup (which could be another user-input) that should be expanded by PPFrame::expand().
For example the following user input:
$a = "foo}}foo"
$b = "baa|aa"
$c = "xxx"

And the actuall string which should be expanded after the variables are inserted:
"{{#ifeq:{{#len: $a }} | 8 | $b | $c }}"

This will go terribly wrong! The user input in $a1 and $a2 will break the whole thing since the whole will look like this then:
"{{#ifeq:{{#len: foo}}foo }} | 8 | baa|aa | xxx }}"

So we need some way to be able to expand something before sending it to PPFrame::expand().
To begin with, 'wfEscapeWikiText()' might work in some cases but its very bad since it will raise new problems, wiki markup just won't work as intended with these escaped characters. Also, it escapes by far to much characters. I believe the critical character (sequences) are just "=", "|", "{{" and "}}", please proof me wrong if I forgot any (":" and ";" at line starts don't seem to be a problem here).

There could be several ways of solving this whole thing

  1. One very simple but not 100% effective is already described in bug #32746. A global function 'wfEscapeForExpansion()' which does some kind of virtual bracketed implode on characters with special meanings. These then require some template or parser function within the wiki so PPFrame::explode() will explode them first and they have their original meaning back without actually influencing anything.

Cons: Requires templates/parser functions, using 'wfEscapeForExpansion()' and then calling PPFrame::explode() with PPFrame::NO_TEMPLATES flag will return unintended output since no templates at all are getting parsed.

  1. introducing another syntax construct for this, but do we really want that?

3.... I don't really know the internals of PPFrame::explode() but there must be some other, more elegant way.

I believe Tim Starling mentioned something about him going to build something for this problem, but at that time it seemed there was no interest in it or some other reason why he didn't in the end.
Anyway, I am not really happy with the way my extensions are handling this right now, which would be method 1 but with a config variable per extension which has to hold the template names that should be used to escape the problematic characters.


Version: 1.20.x
Severity: enhancement

Details

Reference
bz32829

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:02 AM
bzimport added a project: MediaWiki-Parser.
bzimport set Reference to bz32829.
bzimport added a subscriber: Unknown Object (MLST).
Danwe created this task.Dec 6 2011, 8:38 PM

pinging Brion about this

If I understand correctly, this is a request for a wiki-markup-escape() function just like the mw.text.nowiki() method in scribunto, implemented in mw.text.lua. I ran into the same problem, and could really use a generic wiki markup escaping function too. @Anomie, could you port your code from Lua into php? There seem to be some funky moments there that i might miss.

@Anomie, could you port your code from Lua into php?

The Lua code is a port from PHP, specifically wfEscapeWikiText() in GlobalFunctions.php.