Wikimedia Bugzilla is closed!

I believe string functions are disabled for a reason... (ie they give crap performance)

Machine translation from the given wiki section:

> == $wgPFEnableStringFunctions ==
> Hello.
> We already have expansion ParserFunctions. This extension allows additional 
> functionality, especially the majority (if not all) functions were extensively 
> StringFunctions old. The problem is that additional functionality is controlled by 
> a flag in LocalSettings (see title), this flag we must not exist (or exists but with 
> a value of false). The specific reason I want the add-on function is mainly to
> replace: for example for a site Vyakirafvah, so that links will work to replace all spaces 
> in "_", which is also ugly and makes it impossible to use the name value directly 
> (see the example in even {{ Vyakirafvah }} now produces a broken link for 
> earnings). Is there a mode to add
> "; wgPFEnableStringFunctions = true $" to LocalSettings? (I also vaguely 
> remember that David Shay asked someone about the possibility of interchangeable 
> format, though I no longer remember the exact reason.)
> Thanks - Akipodnges - Talk 21:26, 20 May 2011 (UTC)
>> Should open a bug Ababagzilo, you want to do this, or am
>> I? waist • Talk 22:12, 21 May 2011 (UTC)
>>> You mean we have no control over our LocalSettings?
>>> I always thought that. If you do not mind I'd rather you not open
>>> - thanks. Akipodnges - Talk 22:38, 21 May 2011 (UTC)
>>>> I'll open a bug later today. Mattaniah • Talk 11:46, 22 May 2011 (UTC)

Should this be marked as a duplicate of bug 6455. From what I understand bug 6455 is essentially a no for all Wikimedia wikis (?)

(In reply to comment #5)
> Should this be marked as a duplicate of bug 6455. From what I understand bug
> 6455 is essentially a no for all Wikimedia wikis (?)

There are many things that won't get enabled cluster wide but will on smaller projects.

cc'ing tim so he can comment about it.

(In reply to comment #3)
> I believe string functions are disabled for a reason... (ie they give crap
> performance)

Last I heard, the reason was "We would rather have Lua or some other real language. Never mind that no one is working on it and the various requirements (e.g. a pure-PHP implementation must exist for use by people on crappy hosting who want to reuse Wikipedia templates) increase the work needed dramatically."

(In reply to comment #7)
> (In reply to comment #3)
> > I believe string functions are disabled for a reason... (ie they give crap
> > performance)
> 
> Last I heard, the reason was "We would rather have Lua or some other real
> language. Never mind that no one is working on it and the various requirements
> (e.g. a pure-PHP implementation must exist for use by people on crappy hosting
> who want to reuse Wikipedia templates) increase the work needed dramatically."

There is the InlineScripts extension now, which should already be better than StringFunctions for just about everything. Maybe we could enable it on Wikimedia if a little more work were done on it.

http://www.mediawiki.org/wiki/Extension:InlineScripts

No documentation. Not even a description. (But thanks to Reedy for adding it to WMF in January.)

However functionality is visible at http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/InlineScripts/interpreterTests.txt


This looks good, providing list manipulation, although it does duplicate a lot that we already have.  

What is the "little more work" that needs doing? And should we make a site request to enable it on Test?

Closing as WONTFIX just like 6455. The string parser functions are too CPU intensive although they fill a valid need.

The current plan is to replace that kind of functions with a more robust solution (LUA) to handle that kind of user needs.

See also : https://bugzilla.wikimedia.org/show_bug.cgi?id=6455#c148

Sigh. What we use now is too CPU intensive (far far more so than parser functions), though I have no problem with the WONTFIX since Lua is a coming. Some time...