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

#ifexist shows up as link in WhatLinksHere
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)

Well I see that no one ever bothered to look into this error, yes it is an error and not "just how it works". We had someone from our own ranks look at the extension and we found the cause of this problem. It's an extra, unnecessary line of code that adds the link to the target page, not displayed though. So it's totally pointless. Here is the code: Just remove any instances of that code from the #ifexist function code and the problem is gone. We tested it out and it works.Matt 08:18, 9 July 2010 (UTC)


 * It is there so that the page containing the #ifexist check can be purged when the target page gets created, see 12019.--Patrick 09:08, 9 July 2010 (UTC)
 * Really that's complete nonsense. I'm not a total expert on PHP coding, but I know enough to know that isn't true. The other functions that do a similar database query do not need any such drastic measures. While I'm sure it seemed like a good idea, it's not worth it. It causes more harm than good to have it in there. Find another way to get an unnecessary extra purge. It's not like this is a minor issue. This one line of code can cause a whole lot of chaos, not worth keeping. As I have said, we've tested it and have not seen any of theses supposed "purging" problems that are claimed to happen without it.--Matt 15:05, 9 July 2010 (UTC)
 * What I am trying to say, is that this claim basically says that "this is the only way to possibly purge this function". I refuse to believe that. That's like saying "the only way to open a bottle is to sprinkle salt on it." If that were true, then ALL functions would require an addition to the links table, which is ridiculous. There's plenty of functions out there that need purging that have nothing to do with links, and they manage to get purged. Obviously there are other ways to trigger a purge. So don't be lazy and taking the "quick fix" that does more harm than good.Matt 15:16, 9 July 2010 (UTC)
 * I was just quoting the bugzilla discussion. It was also mentioned that an alternative would be a special database table. It seems that would contain page pairs (A,B) for #ifexist on page A checking existence of page B. That might be better.--Patrick 23:35, 9 July 2010 (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)

#ifexist results in Wanted Pages
If #ifexists checks that the page does not exist, the page is shown on Wanted Pages. How do I turn that off? "Programming" with that function is not possible with that behaviour, thanks! :) —The preceding unsigned comment was added by 91.61.51.192 (talk • contribs) . Please sign your posts with ~ !
 * Yes, it's a known bug, it's required for caching to work properly, you can't disable it. see 12019 Nx 19:29, 12 April 2010 (UTC)
 * Thanks Nx, mh I guess I need a workaround for my wiki then, but thanks so far.

#switch Optimization?
I was looking at the code for #switch, it struck me odd that once a match was found, it continued to try to match subsequent single values. The solution is to replace lines #170 (" ") with " " and #221 (" ") with " ". -- BlindWanderer 10:26, 17 April 2010 (UTC)

#if compatble with wiki2xml?
I'm using wiki2xml to generate some text output and it does not like | statements from an #if if the template parameter has a link in the form of alt Is there a way from the wiki2xml extension to invoke the ParserFunctions parser?

Can't download trunk version
svn: Working copy '/mnt/upload6/private/ExtensionDistributor/mw-snapshot/trunk/extensions/ParserFunctions' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

I have received this error on three trunk versions now of different extensions, could be a general problem with MediaWiki. --Ejcaputo 13:44, 19 July 2010 (UTC)

Sub
This extension should make StringFunctions obsolete but I don't think Sub is working - so I'm still using StringFunctions. Anyone else have this issue (or not have it?!)? --Robinson Weijman 08:37, 28 July 2010 (UTC)

Missing SVN Version tags
The Extension doesnt have version tags (like in http://svn.wikimedia.org/viewvc/mediawiki/tags/extensions/SemanticMediaWiki/ ) in SVN ... it would be great for version management at installations to have these tags .. would it be possible to set a tag at the last release revision and provide tags in the future? --RScheiber 22:11, 14 September 2010 (UTC)

Don't know how to fix this error
Warning: Parameter 1 to ExtParserFunctions::ifObj expected to be a reference, value given in C:\xampp\htdocs\mediawiki\extensions\ParserFunctions\ParserFunctions.php on line 122

I recently migrated a dev wiki from one computer to the next, and any page using Parser Functions gets this error. I cannot find any information about how it is being caused, nor anything about how to fix it. After refreshing the browser cache, the error goes away, but only until I restart my copy of XAMPP. Any suggestions? Jim Vance 21:12, 7 December 2010 (UTC)


 * It sounds like your new computer is running PHP 5.3.1; it has a bug that causes this error. You should use PHP 5.3.0 or 5.3.2 instead. —Emufarmers(T 02:31, 8 December 2010 (UTC)


 * Awesome, you're right. Thank you so much! Jim Vance 04:20, 8 December 2010 (UTC)

#replace tag not working same as it did in StringFunctions
in MW1.15 I used #replace to process string output from #dpl. For example to replace spaces in Article Names with underscore.


 * 1) replace in the latest MW1.16 version will work on simple strings, but not on more complicated compound operations (such as above). In the case above, the statements produce "no output". However:

produces "A_test" as expected. However if I replace the subject text with a #dpl query it produces no output at all.

Has anyone else encountered and fixed this? I have tried the latest trunk, and have also used StringFunctions and ParserFunctions together with $wgEnableStringFunctions turned off. Nothing works. Was going to try the 1.15 versions of String and Parser and see if this works.

Any help?

Brett Tyson January 27, 2011