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.

2. 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