On Thu, Jun 25, 2009 at 11:33 PM, Tim Starling<tstarling(a)wikimedia.org> wrote:
Those templates can be defeated by reducing the
functionality of
padleft/padright, and I think that would be a better course of action
than enabling the string functions.
The set of string functions you describe are not the most innocuous
ones, they're the ones I most want to keep out of Wikipedia, at least
until we have a decent server-side scripting language in parallel.
Well, then at least let's be consistent and cripple padleft/padright.
Also, while I disagree with Robert's skepticism about the comparative
usability of a real scripting language, I'd be interested to hear what
your ideas are for actually implementing that.
Come to think of it, the easiest scripting language to implement would
be . . . PHP! Just run it through the built-in PHP parser, carefully
sanitize the tokens so that it's safe (possibly banning things like
function definitions), and eval()! We could even dump the scripts
into lots of little files and use includes, so APC can cache them.
That would probably be the easiest thing to do, if we need to keep
pure PHP support for the sake of third parties. It's kind of
horrible, of course . . .
How much of Wikipedia is your random shared-hosted site going to be
able to mirror anyway, though? Couldn't we at least require working
exec() to get infoboxes to work? People on shared hosting could use
Special:ExpandTemplates to get a copy of the article with no
dependencies, too (albeit with rather messy source code).
On Fri, Jun 26, 2009 at 6:33 AM, Roan Kattouw<roan.kattouw(a)gmail.com> wrote:
The reason I believe breaking up templates improves
performance is
this: they're typically of the form
{{#if:{{{someparam|}}}|{{foo}}|{{bar}}}} . The preprocessor will see
that this is a parser function call with three arguments, and expand
all three of them before it runs the #if hook.
I thought this was fixed ages ago with the new preprocessor.