On Thu, Jun 25, 2009 at 11:33 PM, Tim Starlingtstarling@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 Kattouwroan.kattouw@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.