https://bugzilla.wikimedia.org/show_bug.cgi?id=32829
Web browser: ---
Bug #: 32829
Summary: Method to quote characters with special meaning before
sending them to PPFrame->expand()
Product: MediaWiki
Version: 1.19-svn
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: Parser
AssignedTo: [email protected]
ReportedBy: [email protected]
Classification: Unclassified
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.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
