content hidden as private in Bugzilla

content hidden as private in Bugzilla

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