Extension talk:ParserFunctions/LQT Archive 1

Problems with #switch
I just installed v.1.1.1 on MW 1.12.0, but any time I try to create a page with a "#switch" in it, my server won't serve the page correctly. Instead of showing a page, it gives me the option to download "index.php" which is a 0 byte file. Other parserfunctions ("ifexist" for example) work fine. Does this happen to anyone else? -SColombo 12:06, 5 June 2008 (UTC)

Older versions
Is there any way to get old versions of this extension? I'm specifically interested in a version which would work with MediaWiki 1.5.6 under PHP4 (not PHP5, which is required for modern versions).

Parse error
On 1.12, I've run into what may be an interesting problem: ''Parse error: syntax error, unexpected '{' in extensions/ParserFunctions/ParserFunctions.php on line 74. (http://rafb.net/p/NEDkaT63.html)'' This occurs on multiple wikis/different websites I operate, all under the same host. I'm told by several proficient mwikians/devs that the code is correct (they can't figure it out either); yet no matter what I do, fresh installs, etc., the error persists. I'm trying to fathom if it's a server or filepath issue and what the nature of it is, if that's the case, so I can explain it to them. (They're wiki-illiterate.) --Sasoriza 19:12, 21 July 2008 (UTC)
 * Disregard. Apparently it was a PHP version problem (thanks domas). If anyone should ever encounter the above issue, make sure you're running PHP5x. Still, the timing was very strange. Happened right after I tried installing this extension (and no, I won't try again; call me superstitious). -- Sasoriza 04:18, 22 July 2008 (UTC)
 * Any ideas why PF sometimes don't work? For example, page 1 and page 2.
 * nvm, fixed, tidy helped

Error with a Function
I have discovered an error with #ifexist function from this extension. If there is an internal link in the either of the outputs for the function, then that link will show up in all of the relevant Special Pages regardless of whether the target pages exists or not.--Mjr162006 22:59, 21 July 2008 (UTC)
 * It's not an error, it's just how the Parser works. Everything inside both the then and else statements get evaluated, regardless of which one is true. The true one is then displayed. Depending on the contents of the output statements, some things may trigger unexpectedly. -- Skiz zerz  02:08, 22 July 2008 (UTC)


 * Hmm... Even if it is not an error, it is still a problem correct? Is there any way at all to program this out of the extension? The other parser functions don't seem to have this problem. The reason this is an issue, is because it messed up our Special Pages: Disambiguations, Whatlinkshere, and Wanted Pages. It kept on showing links that didn't exist. That was all thanks to the ifexist function. Those of us that were trying to fix redirecting links and links to disambiguation pages were essentialed stopped in our tracks by this problem. For now, we went into the templates that used the function and formated the links as external links, but made them look like normal links with plainlinks option with the span tags. But it would be nice if this was corrected in the extension itself. I'm my wiki's resident expert on such things, and it took me a few days to realize that the ifexist function was the cause of it all.--Mjr162006 05:27, 22 July 2008 (UTC)
 * It still is a problem, since it really shouldn't be doing that... I'm guessing it's because it utilizes the Link Cache to check for existence of the pages. Just to be safe, though, what MediaWiki and ParserFunctions versions are you running, and what ifexist function is causing this issue (if there are more than one, just paste one)?-- Skiz zerz  15:26, 22 July 2008 (UTC)

Here you go:

We have version 1.1.1 of ParserFunctions. I think the best way to tell you is to give you the entire story. Some our important templates for certain page operations, like merging, splitting, and moving; as well as a few other templates, link to the article's talk page. Many of those talk page's didn't exist, thus flooding our Wanted Pages. So, we used the ifexist function to form the link if the talk page existed, and to display plain text if it did not. We began to notice the Disambiguations special page was showing pages linking to game disambiguation pages when they in fact didn't. We then noticed that the special page indicated had a certain template in it. So I went in the template and reorganized it. The template no longer exhibited problems but I had no idea as to the cause. About a week later, another user noticed that the delete template causing talk pages to show up in the wanted pages even though the links didn't exist. This was a was very similar problem as the last template had. So I examined its code. I then noticed that both templates used the ifexist function. Realization dawned upon me. I went and check every other template that used this function. Every single one was having the exact same problem. We were formating the ifexist function like this:

But that was cause the problem. Our solution for the time being is to format the ifexist function like this:

That's my story. I hope it helps.Mjr162006 03:06, 23 July 2008 (UTC)


 * If you have any more questions for me that might help solve this problem, then you must know that I will be unable to respond. I'm leaving to go on a camping trip for about four days. I'll ask another one or two of our users to come here and fill in.--Mjr162006 03:21, 23 July 2008 (UTC)


 * Hello. I'll be taking over this discussion on behalf of Mjr162006 during his absence. If you have any further questions regarding various aspects of our Wiki's configuration or need me to test something there, let me know, as I'll be checking in at least daily. --ZWAndo (Talk) 05:13, 23 July 2008 (UTC)


 * I'm here too. In case either of them aren't here, I may be. While I don't have as much knowledge on this subject (Heck, I understand but don't use them) as either Ando or Mjr162006, think of me as the helper. I'll answer what I can, and relay to them what I can't. ZWSeablue 14:31, 23 July 2008 (UTC)

problems with #ifexist (don't work)
"#ifexist:" is not working in my wiki as you can see:
 * My Sandbox wiki for test
 * Wiki Sopa de pedres (public project wiki)

I have this configuration:
 * MW 1.12.0
 * ParserFunctions 1.1.1 r41321

I have also installed:
 * SMW 1.2
 * SF 1.2.6
 * reCaptcha

Other parser functions are working fine.

--Dvdgmz 08:07, 29 September 2008 (UTC)
 * Try using the 1.12.x version from Special:ExtensionDistributor/ParserFunctions instead. Mr.Z-man 21:14, 29 September 2008 (UTC)


 * Hi, I tried with 1.12.x and with the current version (1.14) but the problem persist: ifexist test --Dvdgmz 15:07, 30 September 2008 (UTC)


 * It is not solved yet, but I use template:Exists as alternative. --Dvdgmz 07:55, 3 September 2009 (UTC)

Problem with Time parser function
I posted a question on the ParserFunctions help talk page having to do with a problem with time functions when having a 2 digit date. If anyone has a clue of how to fix it, it would be greatly appreciated! (apologies for not having a screen name; I have one on wikipedia I use a lot, but I just came here to try and figure out why the error was occurring in edits I made at wikipedia) Thanks. 24.236.101.233 09:42, 30 December 2008 (UTC)

Why is #ifexist marked out as an expensive parser function?
Perhaps this is one for bugzilla but before I post a bug there, I have a question. If I write

is the result one database request to see if the article exists or two? Given that every link on Wikipedia is in effect

so you might understand my curiosity over why #ifexist uses more resources than any link on any page. Blue-Haired Lawyer 12:39, 24 February 2009 (UTC)

Using expr - Function in inline queries
I am trying to do something like this:

while MyTemplate does nothing more than

+

So I try to ask for all articles that fit the conditions above. What I get as a result is a number, no text, thats defined by convention. And each result is put in the template, adding a "+". The outer-Expression #expr should receive these results and add them. But all I get is an Error, saying that the char "[" is undefinded. I guess the inner-ask is responsible for this message because of the conditions Category:MyCategory etc.

Is there a way of solving this problem or maybe there are alternatives fitting my purposes? --Mr.Reed 08:48, 04 March 2009

Installation Issue
I've installed the ParserFunctions and PipeEscape extensions into their respective folders ($IP/extensions/ParserFunctions & $IP/extensions/PipeEscape) and added the relevant requisite code to the LocalSettings.php file along with creating and copying the code for the ExtensionFunctions.php file in the $IP/extensions folder. I'm running MediaWiki 1.13.3, PHP 5.2.8 and MySQL 5.0.67.

My issue is that I still see a plain text version of my magic words rather than the functionality it is supposed to evoke. I've attempted re-installing the extensions, checked that they were for the right version of MediaWiki and moving the location of the extension. Are there any other things I can try?

Thank you,

74.14.98.134 20:14, 30 March 2009 (UTC)

Any way to get equal sign in default #switch?
I've tried & # 6 1 ; and also using a template containing the equal sign but can't get it to work. I would like default to be a web link which contains an equal sign. Thanks. Jonathan3 15:34, 16 May 2009 (UTC)

ParserFunctions don't work!
This is a part of my template, but if I wrote p.e. there is only a white gap. Where is the mistake?






 * 84.145.244.244 12:40, 17 May 2009 (UTC)

#if and #ifexist
I am curious as to why neither #if nor #ifexist parser functions are operational. I am currently running MediaWiki 1.13.4 and ParserFunctions Extension 1.1.1

Dgennaro 15:38, 6 August 2009 (UTC)

Using EXPR to evaluate numbers with commas
How would you go about using expr to perform an operation when one or more of the numbers used has commas?

I tried both using "replace" and "formatnum" (both of which will remove the commas if used in isolation) but give "Expression error: Unrecognized punctuation character ","" when used within expr when the value is a template parameter.

Does anyone know of a way to use expr with numbers that have commas in them?

As an example say you have a template named Multiply with this content:



and if used as such:

 NaN

would give 12500 as the result, rather than fail.

--Tlosk 20:23, 1 November 2009 (UTC)


 * I apologize for not remembering who gave me this but the following worked for me in being able to multiply two numbers having comma separators on both input and output:

0


 * Drop the initial formatnum if you don't want commas on output, and drop "round 0" if you want decimals. --Tlosk 07:01, 31 March 2010 (UTC)

Case-Sensitivity Options
I was wondering if there was an existing option or variable that we can set, either within the functions or within the php, to toggle case-sensitivity? Ideally it would be something within the function for on-the-fly modification, but that might be asking too much and possibly confusing. Anyway, I figured it couldn't help to ask. 66.135.130.19 03:16, 25 November 2009 (UTC)
 * To clarify, I am specifically interested in #ifeq. I have a rather complex template that uses this function quite a lot. 66.135.130.19 03:21, 25 November 2009 (UTC)
 * you could hack it into the code very easy. But you could also use or  magic words to convert a string. Those are MW functions. --Danwe 22:37, 1 March 2010 (UTC)

No Download? 404 error
I am getting a 404 error page when trying to download the exetnsion with the given link. Dinraum 11:40, 7 December 2009 (UTC)

I can't install this extension on mediawiki software.

 * MediaWiki: 1.16alpha
 * PHP: 5.2.12 (apache2handler)
 * MySQL: 5.1.41-community
 * I add require_once( "$IP/extensions/ParserFunctions/ParserFunctions.php" ); in Localsettings.php to finish installing extension. but This is happens PHP error. please help me! --Badbread 09:46, 15 January 2010 (UTC)
 * Have you actually downloaded this extension and put it at $IP/extensions/ParserFunctions/? Max Semenik 09:55, 15 January 2010 (UTC)
 * Yes --Badbread 09:57, 15 January 2010 (UTC)
 * This message is "Warning: Cannot modify header information - headers already sent by (output started at C:\APM_Setup\htdocs\Wiki\LocalSettings.php:1) in C:\APM_Setup\htdocs\Wiki\includes\WebResponse.php on line 16" --Badbread 09:58, 15 January 2010 (UTC)
 * You made a mistake while modifying LocalSettings. It contains something before the first <?, likely whitespace or byte order mark (which is invisible in most editors). Don't edit anything with Notepad. Max Semenik 10:12, 15 January 2010 (UTC)
 * Thank you very much. I solved it. --Badbread 11:13, 15 January 2010 (UTC)

Installation problem...
Mediawiki 1.15.1 PHP 5.2.6 MySQL 5.0.67

When I add the "require_once" in my LocalSettings.php, my Wiki gives me "Internal Error, Magic word 'if' not found". Any suggestions?

error on Special:Specialpages when extension enabled.
when i enable this extension, going to Special:Specialpages generates an error at the top of the page:

Warning: Invalid argument supplied for foreach in path/to/wiki/includes/MessageCache.php on line 636.

disabling the extension makes the error go away. currently i cannot find another page that generates this error.

#time with other languages than English - since when?
In early version 1.1.1 the extension uses  php function for getting the date. strtotime only works with English date formats and month names. In the current 1.1.1 versions (quiet confusing the versioning of ParserFunctions…) we use the class  at least for php >=5.2. I am not familiar with the DateTime class but I saw on the German Wikipedia (which uses ParserFunctions 1.3.0) that German month names and date formatting is working there with #time. So under which circumstances and since when does #time work with other languages formats? Does it work since some 1.3 version (which revision exactly?) or should it work with one of the 1.1.1 revisions already? In my wiki it won’t work with 1.1.1 and I don’t use the MW 1.16 trunk version yet. I think the versioning is a little bit confusing and the documentation is not very clear about this topic. --Danwe 14:37, 2 March 2010 (UTC)
 * Ok, sorry, looks like i was wrong after all. I just tried it again and the German Wikipedias #time wasn't able to interpret german month names. Looks like this still is an open feature. Are there any plans how to implement this? A simple solution which would be helpful could be to replace english month names and their shortcuts against the local languages month names. --Danwe 14:58, 2 March 2010 (UTC)