#ifexist problem

I'm creating a template to redirect red links to wikipedia, here's the content of the template :

{{#ifexist:{{{1}}}|[[{{{1}}}]]|[[w:en:{{{1}}}|{{{1}}}]]}}

theorically if {{{1}}} exists output [[{{{1}}}]], if doesn't exist output [[w:en:{{{1}}}|{{{1}}}]], function seems right isn't it?

practically, it works with one word, for instance it works with

{{w|Example}}

, w being the name of the template but when it comes with spaced words such as

{{w|Test Page}}

, output is Page Test Page and link is w:en:Test

why is spacing causing issues? I don't get it, if anyone can help me, thanks. —The preceding unsigned comment was added by an unknown user on a unknown date. 03:46, 14 January 2012 (UTC)

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 (Unknown date) 03:46, 14 January 2012 (UTC)

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) 03:47, 14 January 2012 (UTC)

Any ideas why PF sometimes don't work? For example, page 1 and page 2. —The preceding unsigned comment was added by an unknown user on a unknown date. 03:47, 14 January 2012 (UTC)

nvm, fixed, tidy helped —The preceding unsigned comment was added by an unknown user on a unknown date. 03:47, 14 January 2012 (UTC)

#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) 03:48, 14 January 2012 (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. --Skizzerz 02:08, 22 July 2008 (UTC) 03:48, 14 January 2012 (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) 03:49, 14 January 2012 (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)? --Skizzerz 15:26, 22 July 2008 (UTC) 03:49, 14 January 2012 (UTC)

Here you go:

* MediaWiki: 1.13.0

   * PHP: 5.2.5 (apache)
   * MySQL: 4.1.22-standard
   * URL: Zelda Wiki.org

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:

{{#ifexist:{{TALKSPACE}}:{{PAGENAME}}|[[{{TALKSPACE}}:{{PAGENAME}}|talk page]]|talk page}}

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

{{#ifexist:{{TALKSPACE}}:{{PAGENAME}}|<span class="plainlinks">[http://zeldawiki.org/{{TALKSPACEE}}:{{PAGENAMEE}} talk page]</span>|talk page}}

That's my story. I hope it helps. Mjr162006 03:06, 23 July 2008 (UTC) 03:50, 14 January 2012 (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) 03:50, 14 January 2012 (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) 03:50, 14 January 2012 (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) 03:51, 14 January 2012 (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:

$parser->mOutput->addLink( $title, $id );

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) 03:51, 14 January 2012 (UTC)

It is there so that the page containing the #ifexist check can be purged when the target page gets created, see bugzilla:12019. --Patrick 09:08, 9 July 2010 (UTC) 03:52, 14 January 2012 (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) 03:52, 14 January 2012 (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) 03:52, 14 January 2012 (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) 03:52, 14 January 2012 (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) 03:53, 14 January 2012 (UTC)

Try using the 1.12.x version from Special:ExtensionDistributor/ParserFunctions instead. Mr.Z-man 21:14, 29 September 2008 (UTC) 03:54, 14 January 2012 (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) 03:54, 14 January 2012 (UTC)

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

I can't find, that removing the code $parser->mOutput->addLink( $title, $id ); solves the problem, or changes anything for that matter. I use ifexist in templates, so I can see if a certain parameter is equivalent with a page, then turn it into a link, or is not, so it won't turn up as a link. So, I don't want to have it appear "Wanted Sites" either. Heinrich krebs 16:00, 18 October 2011 (UTC) 03:54, 14 January 2012 (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) 03:55, 14 January 2012 (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

{{#ifexist: {{{1}}} | [[{{{1}}}]] }}

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

{{#ifexist: {{{1}}} | [[{{{1}}}]] | [[<font color="red">{{{1}}}</font>]] }}

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:

{{ #expr:
{{#ask: 
[[Category:MyCategory]] [[semanticAttribut1::value1]] [[semanticAttribut2::value2]]
| ?number
| format=template
| template=MyTemplate
| mainlabel=-
}}
0
}}

while MyTemplate does nothing more than

{{{1}}}+

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 03:56, 14 January 2012 (UTC)

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) 03:57, 14 January 2012 (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) 03:57, 14 January 2012 (UTC)

ParserFunctions don't work!

This is a part of my template, but if I wrote p.e. {{Charakter|name=...}} there is only a white gap. Where is the mistake?

|-
{{#if: {{{name|}}}|
{{!}} style="white-space: nowrap; background-color: #FFFFFF;" {{!}} '''Name:''' {{!!}} {{!}} {{{name}}} }}
|-

84.145.244.244 12:40, 17 May 2009 (UTC) 03:58, 14 January 2012 (UTC)

Read The Help. In addition to creating your template with the logic you've posted... you must create a template called ! that contains only

<nowiki><includeonly>|</includeonly></nowiki>

It took me a few hours to figure it out too. Look at this wiki's template ! (Template:!) --Bigorangemachine 03:58, 14 January 2012 (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) 03:59, 14 January 2012 (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:

{{#expr: {{{1|}}} * {{{2|}}} }}

and if used as such:

{{multiply|5|2,500}}

would give 12500 as the result, rather than fail. --Tlosk 20:23, 1 November 2009 (UTC) 03:59, 14 January 2012 (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:

{{formatnum: {{#expr: {{formatnum:{{{1|}}}|R}} * {{formatnum:{{{2|}}}|R}} round 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) 04:00, 14 January 2012 (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) 04:04, 14 January 2012 (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) 04:04, 14 January 2012 (UTC)

you could hack it into the code very easy. But you could also use {{lc:}} or {{uc:}} magic words to convert a string. Those are MW functions. --Danwe 22:37, 1 March 2010 (UTC) 04:05, 14 January 2012 (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) 04:05, 14 January 2012 (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) 04:06, 14 January 2012 (UTC)

Have you actually downloaded this extension and put it at $IP/extensions/ParserFunctions/? Max Semenik 09:55, 15 January 2010 (UTC) 04:06, 14 January 2012 (UTC)

Yes --Badbread 09:57, 15 January 2010 (UTC) 04:06, 14 January 2012 (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) 04:07, 14 January 2012 (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) 04:07, 14 January 2012 (UTC)

Thank you very much. I solved it. --Badbread 11:13, 15 January 2010 (UTC) 04:07, 14 January 2012 (UTC)

Installation problem...Internal Error, Magic word 'if' not found

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? —The preceding unsigned comment was added by an unknown user on a unknown date. 04:08, 14 January 2012 (UTC)

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. —The preceding unsigned comment was added by an unknown user on a unknown date. 04:08, 14 January 2012 (UTC)

#time with other languages than English - since when?

In early version 1.1.1 the extension uses strtotime() 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 DateTime 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) 04:09, 14 January 2012 (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) 04:09, 14 January 2012 (UTC)

Yes. At most Wikipedia versions (for example Swedish) it {{#time: Y-d-m|~~~~~}} results in error, but at enwp it results in 2011-06-10). To make this work would be useful in auto-categorization of templates based on date. One approach would be to alow an input date format/locale parameter, for example {{#time: Y-d-m|sv|6 oktober 2011 kl. 08.59 (CEST)) }} for swedish date format. Today this results in Error: Invalid time.. The locale parameter should defualt be sv at Swedish Wikipedia, etc. Mange01 07:13, 6 October 2011 (UTC) 04:09, 14 January 2012 (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 bugzilla:12019 Nx 19:29, 12 April 2010 (UTC) 04:10, 14 January 2012 (UTC)

Thanks Nx, mh I guess I need a workaround for my wiki then, but thanks so far. —The preceding unsigned comment was added by an unknown user on a unknown date. 04:11, 14 January 2012 (UTC)

Has there been any progress in a solution for this issue? Or a workaround? Perhaps another template or function? 68.35.181.7 19:23, 3 April 2013 (UTC)

I brought up this issue with a wiki admin on a wiki I edit from time to time. This person was able to use the Exists template (http://meta.wikimedia.org/wiki/Template:Exists) to solve the issue. Pages that are searched for with the Exists template solution only do NOT show up on the wanted pages anymore! However, pages that are linked through actual red links elsewhere will still show up on the Wanted Pages, which is exactly what we want.

The pages that have actual red links will still show the #ifexists as a wanted link on the Wanted Pages (so a page that had a missing link and an #ifexist call would show (2) pages that link to it) because the #ifexists call will show up on the "What Links Here" for any page, with a "(transclusion)" beside it.

I've asked the admin to post the solution here, to help others with the issue. 68.35.181.7 15:22, 4 April 2013 (UTC)

The discussion for the change that fixed this issue is here: http://www.cohtitan.com/forum/index.php?topic=8183.0 However, it also caused an issue where pages were showing up in the WIP category even though they were not actually works in progress, because they transcluded a page that *was* a WIP. So the change ended up being reverted. 68.35.181.7 20:09, 7 June 2013 (UTC)

#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 ("} elseif ( count( $parts ) == 1 ) {") with "} elseif ( !$found && count( $parts ) == 1 ) {" and #221 ("} else {") with "} elseif ( !$found ) {". -- BlindWanderer 10:26, 17 April 2010 (UTC) 04:11, 14 January 2012 (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 [[link|alt]] Is there a way from the wiki2xml extension to invoke the ParserFunctions parser? —The preceding unsigned comment was added by an unknown user on a unknown date. 04:11, 14 January 2012 (UTC)

Can't download trunk version and 1.16x version

<pre>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) 04:12, 14 January 2012 (UTC)

I have the same problem, same error too but with 1.16x version 182.52.192.10 13:29, 1 February 2011 (UTC) 04:12, 14 January 2012 (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) 04:13, 14 January 2012 (UTC)

Don't know how to fix this error

<pre>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</pre>

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) 04:13, 14 January 2012 (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|C) 02:31, 8 December 2010 (UTC) 04:13, 14 January 2012 (UTC)

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

changing number characters in non English wiki

In Arabic wiki ,How can i convert English numbers characters to Arabic numbers characters with out having Comma(,) . I want to use these numbers as year but having comma inside year number is not good. formatnum function 2,010/12/05 in Arabic wiki shows numbers in Arabic characters with comma. Reza1615 16:47, 28 January 2011 (UTC)reza1615 04:14, 14 January 2012 (UTC)

I guess you need to be more precise. What's your input? --Subfader 20:17, 28 January 2011 (UTC) 04:15, 14 January 2012 (UTC)

Minor bug due to use of ParserClearState

There is a bug between the use of ParserClearState hook and transcluding special pages. Whenever transcluding a special page, the hook will be called which leads to resetting those counters in this exytension. Right now we've got to deal with the same thing in Extension talk:VariablesExtension#Variables Become Unset When Transcluding a Special Page. For ParserFunctions this might not be a big thing, but it allows users to bypass rules set by the admin. --Danwe 19:13, 19 March 2011 (UTC) 04:15, 14 January 2012 (UTC)

#if:A or B display text

I am trying to make a template display text if A or B has anything. like instead of: <pre></pre> have it do: <pre>text text text</pre>

Is there a way to do this? --Cla1067 20:11, 11 June 2011 (UTC) 04:16, 14 January 2012 (UTC)

{{#if:{{{A|}}}{{{B|}}}| text text text}}

untested, but should work ;-) --Cboltz 20:43, 11 June 2011 (UTC) 04:16, 14 January 2012 (UTC)

Awesome thank you! I guess the way it worked didn't process in my head for some reason. --Cla1067 21:02, 11 June 2011 (UTC) 04:16, 14 January 2012 (UTC)

How do you the same only #if:A AND B (not empty) display text?

Will this work:

{{#if:{{{A|{{{B|}}}}}}| text text text}}

84.111.101.105 18:02, 19 November 2013 (UTC)

Simple answer:

{{#if:{{{A|}}}|{{#if:{{{B|}}}|Text to display}}}}

Technical 13 (talk) 18:20, 19 November 2013 (UTC)

I want to display the text None specified if parameter 1 & 2 are empty. Nothing mentioned above seems to work.

Code:

{| style="border:1px solid #7F5000;width:100%"
    ! style="height:32px;background:#7F5000;color:#f0f0f0" | Stub
    |-
    ! style="background:#f0f0f0;color:black" |
    This article is a [[:Category:Article stubs|stub]]. You can help {{SITENAME}} by  [{{fullurl:{{FULLPAGENAME}}|action=edit}} expanding it].
    |-
    | style="background:#f0f0f0;color:black;padding:5px" | <div class="mw-collapsible mw-collapsed">Aditional Info:
    <div class="mw-collapsible-content">
    {{#if:{{{1|}}}|This page lacks: ''{{{1|}}}.''}}
    {{#if:{{{2|}}}|{{{2|}}}}}
    </div></div>
    {{#if:{{{1}}}{{{2}}}| |''None specified''}} //This line should display ''None specified'' if no parameters are specified.
    |}

80.201.99.238 (talk) 23:55, 28 September 2015 (UTC)

Problems with switch

Hi,

i work on a Wiki, where i have Articles with name like this: H'nanza or La'Res. I try to get follow things bring to work:

{{#switch: {{PAGENAME}}|H'nanza = Test 1|La'Res = Test 2|}}

but it didn't work. It only works, if the Name where written like this: H´nanza or H`nanza.
But this isn't correct. Have someone a idea why? Or how i can fix it? Yukii 07:15, 30 September 2011 (UTC) 04:17, 14 January 2012 (UTC)

{{#switch:{{PAGENAMEE}}|H%27nanza = Test 1|La%27Res = Test 2}} --Subfader 22:59, 30 September 2011 (UTC) 04:17, 14 January 2012 (UTC)

Any idea why the example by Yukii does not work? Nnemo (talk) 12:15, 7 May 2015 (UTC)

The example works on MediaWiki.org. Shirayuki (talk) 07:04, 10 May 2015 (UTC)

Read this (under the table). I hope it'll help. Randomdude999 (talk) 18:48, 13 May 2015 (UTC)

Are there ANY issues I should know about when updating from the last Extension:StringFunctions?

I am still using Extension:StringFunctions (version 2.0.3, Nov 30, 2008) and an old version of parser functions from about that time (v1.1.1). So I wonder what has improved in the mean time and will everything still work as expected? Are there any changes from including StringFunctions into Parser functions? Of course I could try, but I have lots of templates and very likely things would look normal for a while until somebody stumbles into some wrong template functionality where nobody knows where it could come from, requiring some ugly bug solving. Would be thankful for any information on that. --Danwe 05:09, 1 October 2011 (UTC) 04:18, 14 January 2012 (UTC)

$wgPFEnableStringFunctions

What exactly does $wgPFEnableStringFunctions do? Badon 08:41, 16 December 2011 (UTC) 04:18, 14 January 2012 (UTC)

It will enable String Functions parser functions. Those were integrated in r50997. Seems like this isn't documented very well. IMHO these two extensions should still be separated. --Danwe 18:12, 22 December 2011 (UTC) 04:19, 14 January 2012 (UTC)

I am curious why you think they should be separated? I might agree with you, but I'm not sure. Badon 00:41, 7 January 2012 (UTC) 04:19, 14 January 2012 (UTC)

It just doesn't feel right, ParserFunctions is more for adding some kind of control flow statements whereas StringFunctions is for processing strings. Both are for extending MW markup to some kind of programming language which is ugly but seems like a necessary evil. The more features you add, the more twisted it gets, String Functions is just the start but take a look at Variables or Loops and you get the idea how far this could go. So I'd prefer providing either all of these as package with some clear configuration guide to allow everybody to choose how far he'd like to go there OR to put all of these into single extension packages where you can clearly choose what twisted feature you want and how far to go.

But for this particular example, ParserFunctions joining with StringFunctions, I have another problem. It is a extension employed at Wikimedia foundation wikis such as Wikipedia! Therefore it would be very confusing for users of those wikis to look at Help:Extension:ParserFunctions where they should find information about string functions as well (right now they are not even documented there) whereas they are not even available in those wikis.

It really seems like StringFunctions were just put into ParserFunctions as a cheep attempt to get them into Wikipedia without anybody noticing/complaining. I'd really be happy to see them separated again so maintenance of these two extensions wouldn't be so mixed up and confusing. --Danwe 22:28, 10 January 2012 (UTC) 04:20, 14 January 2012 (UTC)

I think for maintenance reasons alone it would be a good idea to keep them separated. All the other reasons you mentioned are additional good reasons. Given the pressure to include string functions in Wikipedia, it seems plausible that adding StringFunctions to ParserFunctions was an end-run attempt to get it enabled on Wikipedia, especially now that ParserFunctions and a few other extensions are now bundled with MediaWiki 1.18+. There is a lot of resistance for MediaWiki markup becoming a programming language, but it seems to be happening on its own, and I have been very pleased with the capabilities. Since it has happened naturally, without anyone planning it - and with a lot of resistance - it seems inevitable now that MediaWiki markup is becoming an important scripting/programming language. I know it gets a lot done for me! Badon 03:13, 11 January 2012 (UTC) 04:21, 14 January 2012 (UTC)

Sure, it gets a lot done but it is/was buggy and ugly as hell. If I could travel back in time, I would have put all my programming efforts in further developing Extension:Lua or some alternative as a programming language which can be used within MediaWiki. Now I already depend on these programming extensions too much. --Danwe 20:34, 11 January 2012 (UTC) 04:21, 14 January 2012 (UTC)

That's amazing that it's possible to use "real" programming languages in wiki code. However, it appears to me that there is no way to do that without introducing security problems, so I suspect that the way things are currently going (with a "MediaWiki language") is the only way to do programming without losing control over security issues. Does that sound right? Security is the most important, above all else, but I would love to see python or PHP directly usable for private wikis where security isn't a problem. I think that may not be as exciting as it sounds since it is already possible to use JavaScript and widgets. Badon 00:40, 14 January 2012 (UTC) 04:21, 14 January 2012 (UTC)

Actually, I am not aware of any security risky by Extension:Lua. Making PHP directly available of course would be a huge risk! But with LUA it is more like the LUA interpreter is just like another parser ontop of the wiki-markup parser and therefore running within its restrictions. It makes html code-injection impossible as well as direct access to php. Danwe 04:55, 14 January 2012 (UTC)

Well, if it's possible to do things securely that way, I wonder if Lua would be the right choice. It seems a lot is being done with Python. Maybe there's a way to do PHP safely? The extensions seem to be giving access to portions of PHP, anyway. Badon 05:21, 14 January 2012 (UTC)

Note sure about Python, but about PHP: Might be possible but it's not the prettiest language and offers too much server-specific stuff you wouldn't want anybody to use within templates. Certainly not the best choice.

Basically, what LUA as well as any other half-hearted implementation of any programming language is missing would be some framework to access some MW specific stuff like you have in PHP using MWs base classes. That would be for example something like the MW Title class in php, access to some Parser functionality or even basic stuff like a function for accessing template parameters nicely. For realizing this, we would have to introduce some kind of wrappers into the PHP extension, connecting the new language (like LUA) with existing php functionality. Danwe 06:49, 14 January 2012 (UTC)

That sounds like a lot of glue code. Correct me if I'm wrong, but I think that would be very difficult to maintain since small changes in MediaWiki could break the entire extension - or worse, cause security holes. Does that sound right? Badon 21:03, 14 January 2012 (UTC)

No Security holes, perhaps some stuff will break from time to time but you can have this problem with all MW extensions when a new MW version comes out. Its not like we'd have to to this for ALL MW classes, just for some so it wouldn't be too problematic I guess.

I think there is just nobody developing this because everybody is depending on Parser Functions in their own wikis already, just like me. Danwe 23:59, 15 January 2012 (UTC)

Use comma as decimal separator

In portuguese ,and I think also in several other languages, the comma is the decimal separator and the dot is the thousand separator, but in english is the opposite. In templates that use #expr in the portuguese Wikipedia the editors fill the fields using comma as decimal separator and it frequently generate erros. How can we solve this problem? Danilo.mac 02:39, 27 April 2011 (UTC) 04:22, 14 January 2012 (UTC)

I do have the same problem in a German Wiki --Francishunger 8:40, 20 November 2011 (UTC) 20:41, 1 August 2013 (UTC)

For the record, for the separators for Portuguese (pt and pt-BR) are defined on the following line of languages/messages/MessagesPt.php (resp. MessagesPt_br.php)

$separatorTransformTable = array( ',' => "\xc2\xa0", '.' => ',' );

The problem seems to be analogous to bugzilla:19412 (which is about the {{#time: ... }} parser function). Helder 21:01, 1 August 2013 (UTC)

I have added $expr = str_replace( ',', '.', $expr ); to the begin of ExprParser::doExpression() and replaced line 82 in ExtParserFunctions::expr() with

$result = self::getExprParser()->doExpression( $expr );
$result = $parser->mOptions->mUserLang->formatNum( $result );
return $result;

. The first replaces all commas in a given expression with dots and the second formats the output in the user language. Is this useful for you?   —   Phorgo   @   ☭   —   21:36, 1 August 2013 (UTC)

I think so. Thanks for you suggestion!

I requested this on bugzilla:52426. Helder 22:04, 1 August 2013 (UTC)

#ifexist and empty pages

Hi, would it be possible to have a function similar to #ifexist but that also checks that the page is not empty ?

For example, some templates (like fr:Modèle:Wikiprojet for TODO subpages) currently use #ifexist to chech that the page exists before including it and putting decorations around it (rounded frame, explanations, ...). It could be useful to be able to check also that the page is not empty before including it. --NicoV 14:14, 13 January 2012 (UTC) 04:22, 14 January 2012 (UTC)

This can already be done using the {{PAGESIZE}} magic word. It will give you the page size, and you can use ParserFunctions #ifexpr to set some minimum size threshold before performing some other action. I hope that info helps. Badon 00:36, 14 January 2012 (UTC) 04:23, 14 January 2012 (UTC)

Yes, thanks. I could use {{PAGESIZE}}, but I wanted to avoid using a magic word marked as expensive for a template that is used on many talk pages (probably several 100.000). Would it be a problem?

And a minor disagreement: I would need to repeat the text that is inserted when the subpage is not filled, something like {{#ifexist: {{FULLPAGENAME}}/Subpage | {{#ifexpr: {{PAGESIZE:{{FULLPAGENAME}}/Subpage}} > 0 | {{/Subpage}} | Other text }} | Other text}}

Anyway, thanks for the answer.

--NicoV 09:59, 14 January 2012 (UTC)

1. ifexist is expensive too ;) Subfader 17:41, 14 January 2012 (UTC)

I have a solution for both.

• First, you can make an AND on two expressions like this: {{#ifeq: {{#expr: {{#ifexist: {{FULLPAGENAME}}/Subpage | 1 | 0}} and {{#ifexpr: {{PAGESIZE:{{FULLPAGENAME}}/Subpage}} > 0 | 1 | 0 }}}} | 1 | {{/Subpage}} | Other text}}

It's pretty hard to read but it works.

• Then, you can test if a page is empty with a string comparison: {{#ifeq: {{/Subpage}}a | a | Other text | {{/Subpage}}}}

Beware! It is not equal when the page doesn't exist! Ftiercel (talk) 06:27, 4 December 2012 (UTC)

min, max, and sqrt

Whenever I get a new version of ParserFunctions, I need to manually add min, max, and sqrt for my site. Can we put them back (I'd be glad to), or was there some good reason for pulling them awhile ago? Salquint 02:22, 19 January 2012 (UTC)

Nesting a magic word within a string function?

I'm trying to execute the following function on every page that exists for an uploaded file: {{filepath:{{PAGENAME}}.pdf}}

So, if I uploaded a file called "File.pdf", on the wiki page for File.pdf, I'd expect {{PAGENAME}} to return "File". I'd expect the entire function to return something like: http://mywiki.com/mediawiki/images/4/4d/File.pdf

Instead, nothing at all is returned when PAGENAME is embedded within filepath. If I type the expression without {{PAGENAME}}, i.e. {{filepath:File.pdf}}, it works fine and returns: http://mywiki.com/mediawiki/images/4/4d/File.pdf

Is it just not possible to embed magic words in string functions, or am I missing some escape character or something?

Thanks in advance,

UPDATE: This can be done by simply writing {{filepath:{{PAGENAME}}}} the ".pdf" part is unnecessary. Danachandler 00:57, 22 January 2012 (UTC)

{{PAGENAME}} already includes the file extension. Use {{filepath:{{PAGENAME}}}}. Subfader 12:11, 22 January 2012 (UTC)

#switch in MediaWiki:Pagetitle

Once I tried to use #switch in MediaWiki:Pagetitle to make the <title>...</title> different when viewing different pages, like this:
{{#switch:$1
|Some page=Some page - {{SITENAME}}, this should appear differently
|Some other page=Some other page - {{SITENAME}}, the main topic is unrelated to this page
|$1 - {{SITENAME}}}}
However, it still always displays the option for if $1 is not "Some page" or "Some other page". Is there a workaround for that or must this be reported at Bugzilla? 218.186.15.241 11:10, 24 January 2012 (UTC)

I looked over these pages:

Manual:FAQ#How_can_I_change_what_the_.3Ctitle.3E_of_each_page_is.3F_Where_do_I_make_changes.3F

Project:Support desk/Flow/2011/03#h-sourabh_J_sarkar-2011-03-11T16:19:00.000Z

and I think you may need to change your #switch to something like this:

{{#switch: {{FULLPAGENAME}}
 |Some page = Some page - {{SITENAME}}, this should appear differently
 |Some other page = Some other page - {{SITENAME}}, the main topic is unrelated to this page
 |default = $1 - {{SITENAME}}
}}

Your mistake may have been not using ParserFunctions or Extension talk:ParserFunctions to determine what page you're on. See Help:Magic words for more info about those. However, I'm not 100% sure that will work, since I haven't tried it. That would only work if MediaWiki treats MediaWiki:Pagetitle like a transcluded page, which I suspect it does. Badon 17:39, 24 January 2012 (UTC)

Installation instructions wrong again.

It is pathetic how the community tries to deny and conceal the fact that the installation instructions as they stand are objectively false.
ParserFunctions are not part of the 1.18+ codebase. The mere installation of MW 1.18+ does not magically provide this extension. Solely the installation of one particular distribution of MW 1.18+, the official tarball, provides this extension as an add-on.

But hey, who cares about things like truth, reality and end-user-installation-issues when there's a face to save, right?
Clearly pretending no one was wrong is more important than actually having correct documentation. 87.142.154.86 13:22, 19 December 2012 (UTC)

Heiya, may you please elaborate the problem more deeply? So far I do not really grasp the cause of your frustration. Thank you and cheers [[kgh]] (talk) 15:04, 19 December 2012 (UTC)

There's documentation everywhere that certain things have been "bundled" with MW 1.18+, but no indication as to what this actually means and how users should enable this new "bundled" functionality. Most of it is not enabled by default.

In this particular case, it is clear on a vanilla install that ParserFunctions is not enabled. For example, {{#if: | Yes | No}} on a Sandbox page will simply outputs "{{#if: | Yes | No}}" instead of "No". None of the instructions have been updated to let users know what to do in this case.

The installation instructions indicate that "Steps 1 to 3" are for users of older versions only, implying that new users can enable ParserFunctions by following steps 4 to 6. But it's obvious that "$IP/extensions/ParserFunctions/ParserFunctions.php" doesn't exist, and following these instructions results in an error saying as much.

tl;dr: In great detail, how do we actually enabled ParserFunctions in MW 1.18+? "It's bundled" is not a reasonable (nor correct) answer. 99.104.158.175 21:45, 24 December 2012 (UTC)

What discourages you to do the steps 1 to 3 in the rare case that the code of this extension was not bundled with the code you obtained from somewhere? Isn't it obvious to try this next? Hmm ... [[kgh]] (talk) 21:57, 24 December 2012 (UTC)

Database size skyrockets after enabling?

I have a small Mediawiki installation of about 60 pages, operating for about 2 years. The database size was about 10-12 MB. I enabled parserfunctions and the string functions in order to get cite web working. The next database backup that I did was now 125 MB! Other than making a few edits and putting in a citeweb template, there was not much else going on between backups. Is this normal? Brted (talk) 18:45, 3 February 2013 (UTC)

Hi Brted. I see that your wiki now has ParserFunctions enabled again. Did you manage to solve the database size problem? Or did you decide just to live with the extra disk space usage? Unforgettableid (talk) 18:02, 3 April 2013 (UTC)

Not working: Making wiki go blank with error message

After download and placing the extension in the extensions folder and adding:

require_once( "/wiki/extensions/ParserFunctions/ParserFunctions.php" );

to the localsetttings.php page the website loads with:

Warning: require_once(/wiki/extensions/ParserFunctions/ParserFunctions.php): failed to open stream: No such file or directory in /home/pktweb/www/wiki/LocalSettings.php on line 145

Fatal error: require_once(): Failed opening required '/wiki/extensions/ParserFunctions/ParserFunctions.php' (include_path='.:/usr/share/pear:/usr/share/php') in /home/pktweb/www/wiki/LocalSettings.php on line 145

Does anyone know how to fix this? Imamathwiz (talk) 21:31, 12 February 2013 (UTC)

Try calling the extension with require_once( "extensions/ParserFunctions/ParserFunctions.php" ); Cheers [[kgh]] (talk) 22:08, 12 February 2013 (UTC)

I tried that and it still didn't work. I also tried adding a different extension and I got the same error. Imamathwiz (talk) 04:42, 14 February 2013 (UTC)

Hmm, the error message says that ParserFunctions.php is not at the expected location. Somehow you have to find the correct location of the file and point to it in LocalSettings.php. Somehow you must have moved the extension to another place. [[kgh]] (talk) 12:05, 14 February 2013 (UTC)

Fatal exception of type MWException Error

Download links wrong version?

The page states the latest version is 1.5.1, however Special:ExtensionDistributor/ParserFunctions provides downloads to 1.4.1. 81.147.55.6 22:23, 15 May 2013 (UTC)

Probably you downloaded the latest stable for MW 1.20 which was tagged in November 2011 when this extension was at version 1.4.1. Version 1.5.1 dates from January 2013. If you pick the latest development version (master) you should get 1.5.1 [[kgh]] (talk) 22:27, 15 May 2013 (UTC)

So, the question is really will 1.5.1 work with origin/REL1_20, origin/REL1_21, and so on? Amgine (talk) 21:47, 1 June 2013 (UTC)

You can never know since the tagging for the branches is not done hand picked afaik. However chances that you get a working version through the extension distributor for the respective branch a quite good. [[kgh]] (talk) 06:13, 2 June 2013 (UTC)

Bug in time code?

"Feb" is getting reported as 3 for format letter "n" (see below)

Esjs (talk) 16:14, 30 August 2013 (UTC)

You probably want {{#time:n|Feb 1}}, otherwise it's going to be defaulting to the current date-of-month but in February. This doesn't exist because there is no February 30th, so it pushes you into March. brion (talk) 19:34, 30 August 2013 (UTC)

Brilliant! Thank you. Esjs (talk) 03:46, 31 August 2013 (UTC)

on install: Unable to move the new CDB file into place

On running the installed extension I get:

Unable to move the new CDB file into place.

As I understand I should have 777 rights on the cache subdir. changing that still genertes the error.

any help is appreciated.

MW 1.19 is used

ruud

Backtrace:

1. 0 /var/www/html/wiki/includes/Cdb_PHP.php(325): CdbWriter_PHP->throwException('Unable to move ...')
2. 1 /var/www/html/wiki/includes/LocalisationCache.php(1032): CdbWriter_PHP->close()
3. 2 /var/www/html/wiki/includes/LocalisationCache.php(702): LCStore_CDB->finishWrite()
4. 3 /var/www/html/wiki/includes/LocalisationCache.php(397): LocalisationCache->recache('nl')
5. 4 /var/www/html/wiki/includes/LocalisationCache.php(283): LocalisationCache->initLanguage('nl')
6. 5 /var/www/html/wiki/includes/LocalisationCache.php(218): LocalisationCache->loadItem('nl', 'fallback')
7. 6 /var/www/html/wiki/languages/Language.php(3620): LocalisationCache->getItem('nl', 'fallback')
8. 7 /var/www/html/wiki/languages/Language.php(184): Language::getFallbacksFor('nl')
9. 8 /var/www/html/wiki/languages/Language.php(149): Language::newFromCode('nl')
10. 9 /var/www/html/wiki/includes/Setup.php(473): Language::factory('nl')
11. 10 /var/www/html/wiki/includes/WebStart.php(157): require_once('/var/www/html/w...')
12. 11 /var/www/html/wiki/index.php(54): require('/var/www/html/w...')
13. 12 {main} Ruud Habets (talk) 09:19, 24 November 2013 (UTC)

Hmm :-)

trying to install USerMerge extension, run into the same error, googling for an answer I stumble upon this (my) error fromm last year.

Any suggestions?

ruud 2001:982:A21F:1:D866:C154:9D6C:691E 07:30, 19 October 2014 (UTC)

Message from User:Ruud Habets that was posted on the wrong place :

-----

As it turns out: as root you can create the cache directory everywhere you want, but it can't be read by apache. I found cdb files in

/tmp
/var/www/html/cache
/var/www/html/wiki/cache

all because of typos and wrong entries in LocalSettings.php

and because I did not start >php maintenance/rebuildLocalisation.php after each edit

All is well now

-) Ciencia Al Poder (talk) 16:05, 13 August 2015 (UTC)

Unable to call ExtParserFunctions::ifObj() in includes/parser/Parser.php

Im' using Mediawiki 1.16.5.

I followed instruction to install PArserFunctions but whan I load a page using it I'v got the error message :

Warning: call_user_func_array() [function.call-user-func-array]: Unable to call ExtParserFunctions::ifObj() in /mnt/102/sdb/d/8/patrick.gelin/wiki/includes/parser/Parser.php on line 2920

I need to say I'm into free.fr server, so I know it's not the best way to run mediawiki. I've got similar problem with other extensions so I'm saying myself it may be a global installation problem of my wiki. Because I installed it not at the root of the web serveur but into a children directory. So I'm using the url http://patrick.gelin.free.fr/wiki and not http://patrick.gelin.free.fr.

When I look into special:version it's all fun, the component PerserFunctions seems to be installed withour error.

Thank you for your help !

Patrick Gelinp (talk) 09:40, 8 December 2013 (UTC)

Installation

The installation instructions seem to say that this extension is ready to go when you install the MediaWiki software, but I couldn't get it to work. After about 45 minutes of playing with templates, I finally came back to this page and added the following line to my LocalSettings.php file:

• require_once( "$IP/extensions/ParserFunctions/ParserFunctions.php" );
• $wgPFEnableStringFunctions = true;

Now the templates work. Unless I'm missing something, I think the installation instructions should be changed to say these lines need to be used. BenjaminBarrett12 (talk) 19:10, 21 March 2014 (UTC)

I guess this clarified it. [[kgh]] (talk) 19:18, 21 March 2014 (UTC)

Thank you. I've been hesitant to modify instructions on this wiki, but I think I will do so from now on. BenjaminBarrett12 (talk) 06:26, 25 March 2014 (UTC)

$wgPFStringLengthLimit

How to set unlimited String length? 114.54.30.96 00:46, 14 July 2014 (UTC)

BUMP Ssaz 12 (talk) 12:18, 22 July 2014 (UTC)

The maximum size of a string is 2GB in PHP. The effective string length this will give you varies according to the type of encoding used. Set that number to 2³¹ and you should be fine for most use cases. Tinss (talk) 04:39, 11 December 2020 (UTC)

I've been having some trouble with these - I tried installing them with composer, but it fell over with version 1.3

I'm getting the 'magic word' error too.

"" is not a valid magic word for "github"

It installs OK, and even the maintenance/update.php script is happy.

The errors come when I run the SemanticMediaWiki rebuildData.php command.

If I remove it, it all works.

Any suggestions? Fustbariclation (talk) 16:08, 29 August 2014 (UTC)

I guess the issue is that this extension is not installable via Composer. Every attempt to do so should fail. [[kgh]] (talk) 08:07, 1 September 2014 (UTC)

Problem with ParserFunctions on 1.15

Hi All,

Just having problems getting the ParserFunctions enabled (latest ver REL1_23) so that I can enable UNC links. System is Windows 2008 with IIS, and the Wiki is on a private LAN.

Product Version MediaWiki 1.15.0 PHP 5.3.19 (cgi-fcgi) MySQL 5.5.28

Have added to localsettings.php the following

1. require_once( "$IP/extensions/ParserFunctions/ParserFunctions.php");
2. $wgPFEnableStringFunctions = true;

When I do this, I get the errors below, so i'm wondering if I have something weird in the localsettings or if its some form of version conflict.

Appologies for posting to the main support page - couldn't find where the link was for the ParserFunctions extension.

Backtrace:

Internal error
From XXXXXWiki
Jump to: navigation, search
Magic word 'if' not found

#0 D:\IIS\WWW\Wiki\includes\MagicWord.php(244): Language->getMagic(Object(MagicWord))
#1 D:\IIS\WWW\Wiki\includes\MagicWord.php(197): MagicWord->load('if')
#2 D:\IIS\WWW\Wiki\includes\parser\Parser.php(4034): MagicWord::get('if')
#3 D:\IIS\WWW\Wiki\extensions\ParserFunctions\ParserFunctions.php(73): Parser->setFunctionHook('if', 'ExtParserFuncti...', 2)
#4 [internal function]: wfRegisterParserFunctions(Object(Parser))
#5 D:\IIS\WWW\Wiki\includes\Hooks.php(117): call_user_func_array('wfRegisterParse...', Array)
#6 D:\IIS\WWW\Wiki\includes\parser\Parser.php(178): wfRunHooks('ParserFirstCall...', Array)
#7 D:\IIS\WWW\Wiki\includes\parser\Parser.php(190): Parser->firstCallInit()
#8 D:\IIS\WWW\Wiki\includes\parser\Parser.php(312): Parser->clearState()
#9 [internal function]: Parser->parse('<big>'''XXXX XX...', Object(Title), Object(ParserOptions), true, true, 1930)
#10 D:\IIS\WWW\Wiki\includes\StubObject.php(58): call_user_func_array(Array, Array)
#11 D:\IIS\WWW\Wiki\includes\StubObject.php(76): StubObject->_call('parse', Array)
#12 D:\IIS\WWW\Wiki\includes\Article.php(3557): StubObject->__call('parse', Array)
#13 D:\IIS\WWW\Wiki\includes\Article.php(3557): StubObject->parse('<big>'''XXXX XX...', Object(Title), Object(ParserOptions), true, true, 1930)
#14 D:\IIS\WWW\Wiki\includes\Article.php(979): Article->outputWikiText('<big>'''XXXX XX...')
#15 D:\IIS\WWW\Wiki\includes\Wiki.php(450): Article->view()
#16 D:\IIS\WWW\Wiki\includes\Wiki.php(63): MediaWiki->performAction(Object(OutputPage), Object(Article), Object(Title), Object(User), Object(WebRequest))

Schnarked (talk) 03:53, 3 September 2014 (UTC)

I don't see why ParserFunctions ver REL1_23 (read: 1.23) should work with an ancient MediaWiki 1.15 version. Have you considered upgrading MediaWiki to a supported version? AKlapper (WMF) (talk) 13:26, 3 September 2014 (UTC)

I'm happy to do this, but that's a wider problem and i'm only setting up ParserFunctions to get the UNC links working. Upgrading it is a seperate activity that's been tried before by someone else unsuccessfully, so whilst it would be the good long term idea, i'm just trying to address the point problem today.

Is there a older version that I could use that would work with release 1.15? Mea Culpa on not spotting that that it was MediaWiki 1.19 and later.

I had a look on the extension page and the versions seemed to be for 1.19 and later. Schnarked (talk) 04:12, 4 September 2014 (UTC)

This version should work with MW 1.15.x [[kgh]] (talk) 13:18, 4 September 2014 (UTC)

Hiya,

Thanks for the correct version (1.1.1), but when I install it, I get the (exact) same magicword error on "if" as per the original post.

Internal error

From XXXXWiki

Jump to: navigation, search

Magic word 'if' not found

From having a look at other errors to do with parserfunctions that seem to be similar, and it was a version problem on parserfunctions. Is there an earlier release that we can try? Or what else could I do to troubleshoot this more?

I tried it both with:

- require( "extensions/ParserFunctions/ParserFunctions.php"); - instructions in the README

- require( "$IP/extensions/ParserFunctions/ParserFunctions.php"); - to be consistent with later ver method

- require_once( "$IP/extensions/ParserFunctions/ParserFunctions.php"); - later version method of calling it

Cheers Schnarked (talk) 23:01, 8 September 2014 (UTC)

Okay, so I did some googling and found this:

http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_15/extensions/ParserFunctions/

Once I downloaded that and copied the files over, its running okay now.

Many thanks for everyone's assistance. Schnarked (talk) 23:14, 8 September 2014 (UTC)

This worked for me too after much hair pulling and searching! Thanks so much! FYI I'm running MW 1.16 on Free.fr server Chris 23:01, 12 December 2014 (UTC)

Howto: Getting ParserFunctions & UNC links working with 1.15 (avoid MagicWord issues)

Hi All,

Thought i'd quickly document how to do this as I got help and it took me a bit of time:

1. Make sure you have a compatible version - I got mine from http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_15/extensions/ParserFunctions/ - this is where the magicword errors come from
2. Copy the downloaded files into a ParserFunctions folder within extensions
3. Add in the following line (only) to localsettings.php (without the ') - 'require( "extensions/ParserFunctions/ParserFunctions.php");'
4. Download StringFunctions files from http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_15/extensions/StringFunctions/
5. Copy the downloaded files into a StringFunctions folder within extensions
6. Add in the following line (only) to localsettings.php - 'require( "extensions/StringFunctions/StringFunctions.php");'
7. Do not add in $wgPFEnableStringFunctions = true; - This only works on later versions of the ParserFunctions plugin where StringFunctions is included
8. Add in to localsettings 'array_push($wgUrlProtocols, "file://");'
9. Save the file and confirm that the pages are still loading without errors. If errors are coming up, add in '$wgShowExceptionDetails = true;' and troubleshoot
10. Search for 'Template:Unc' in your Wiki and add in '[file:///{{#replace:{{#replace:{{{1}}}| |%20}}|\|/}} ]'
11. Save the new article
12. Add in the UNC links as per https://www.mediawiki.org/wiki/UNC_links

This should make it work Schnarked (talk) 00:09, 9 September 2014 (UTC)

Default time

Hi how can i change this Tuesday, June 3, 2025, 15:10 to use wiki default time. 151.225.136.51 10:43, 11 October 2014 (UTC)

Use #timel instead of #time:

{{#timel: l, F j, Y, H}}:{{#timel:i}}

See Help:Extension:ParserFunctions#.23timel. Ricordisamoa 19:54, 23 October 2014 (UTC)

Translated month error

Hi, can anyone please explain why #time: F is suddenly adding an extra month in the translated version? Has the function been edited recently? Thanks!

Jan–Dec month by month output in Afrikaans: Januarie; Februarie; Maart; April; Mei; Junie; Julie; Augustus; September; Oktober; November; Desember.

{{#time: F|January|af}} = Januarie {{#time: F|February|af}} = Maart N {{#time: F|March|af}} = Maart {{#time: F|April|af}} = Mei N {{#time: F|May|af}} = Mei {{#time: F|June|af}} = Julie N {{#time: F|July|af}} = Julie {{#time: F|August|af}} = Augustus {{#time: F|September|af}} = Oktober N {{#time: F|October|af}} = Oktober {{#time: F|November|af}} = Desember N {{#time: F|December|af}} = Desember

There are also errors in other language translations. HelenOnline (talk) 09:26, 31 October 2014 (UTC)

Here for several languages:

#	Month	af	de	fr	ok	code (for af)
1	January	Januarie	Januar	janvier		{{#time: F|January|af}}
2	February	Februarie	Februar	février	N	{{#time: F|February|af}}
3	March	Maart	März	mars		{{#time: F|March|af}}
4	April	April	April |avril	N	{{#time: F|April|af}}
5	May	Mei	Mai	mai		{{#time: F|May|af}}
6	June	Junie	Juni	juin	N	{{#time: F|June|af}}
7	July	Julie	Juli	juillet		{{#time: F|July|af}}
8	August	Augustus	August	août		{{#time: F|August|af}}
9	September	September	September	septembre	N	{{#time: F|September|af}}
10	October	Oktober	Oktober	octobre		{{#time: F|October|af}}
11	November	November	November	novembre	N	{{#time: F|November|af}}
12	December	Desember	Dezember	décembre		{{#time: F|December|af}}

Anna reg (talk) 10:46, 31 October 2014 (UTC)

Strange. The months having 31 days are OK, the other months are buggy. Nnemo (talk) 16:13, 23 November 2014 (UTC)

Full or partial absolute dates can be specified; the function will "fill in" parts of the date that are not specified using the current values.

Shirayuki (talk) 13:22, 31 October 2014 (UTC)

Thank you very much Shirayuki! HelenOnline (talk) 16:13, 31 October 2014 (UTC)

rounding bug?

#expr:69.2-69.1

0.10000000000001

W!B: (talk) 21:25, 9 February 2015 (UTC)

also: #expr:92.6-92.7 = -0.10000000000001

but not (giving .1): #expr:107.1-115.2 = -8.1

W!B: (talk) 00:31, 10 February 2015 (UTC)

See m:Help:Calculation#Numbers_as_output. Shirayuki (talk) 02:19, 10 February 2015 (UTC)

thx, answers my question W!B: (talk) 07:09, 23 February 2015 (UTC)

Suggestion: new functions #ifnot, #ifand

Do you think a new function #ifnot would be accepted?

Very simple to implement and unambiguous, it would simply be the contrary of #if, and let avoid the extra, easy-to-overlook pipe we encounter quite often:

{{#ifnot: <expr> | <dosomething> }}

instead of:
{{#if: <expr> | | <dosomething> }}
or even:
{{#ifeq: <expr> | | <dosomething> }}

Od1n (talk) 07:06, 11 April 2015 (UTC)

Another function that would be much useful, and integrates smoothly with the existing ones: #ifand.

{{#ifand: <expr1> | <expr2> | yep | nope }}
instead of:
{{#ifexpr: {{#if:<expr1>|1|0}} and {{#if:<expr2>|1|0}} | yep | nope }}
or even:
{{#if: <expr1> | {{#if: <expr2> | yep | nope }} | nopebis }}

Easy to apprehend, as it's a bit similar to #ifeq.

No need for #ifor, as {{#if: <expr1> <expr2> | yep | nope }} already does the job. Od1n (talk) 07:28, 13 April 2015 (UTC)

Let's not further encourage abusing wikitext for programming. 121.219.80.119 09:26, 13 April 2015 (UTC)

It's undesirable to pile on more and more complicated magic words. However, wiki text is ultimately the single most desirable programming medium for wikis, as it embraces the wiki philosophy by putting control directly into the hands of the general community of wiki users. The problem — daunting, but not impossible — is to fashion wiki markup into a language suitable for that sort of radically user-driven programming. Pi zero (talk) 11:22, 13 April 2015 (UTC)

We don't need to try to pretend wikitext is capable of sane programming (it isn't), when we already have actual programming languages available. 121.219.247.173 12:38, 13 April 2015 (UTC)

Wikitext is currently poor for sophisticated purposes. There are ways and ways to fix that. Scribunto is (though imho a nice programming language, as traditional ALGOL-style programming languages go) a good example of the poor fit between ALGOL-style programming and wikis, and sadly an example of the socially destructive trend toward isolating control away from the lay wiki community, on the far side of a linguistic and conceptual discontinuity where it becomes the province of a high priesthood. It looks great if you compare it only to the status quo ante, but looked at in the larger realm of possibilities it's leading in the wrong direction. Pi zero (talk) 16:19, 13 April 2015 (UTC)

• Scribunto is powerful, but often you don't want to implement a whole Lua module just because you need it at one location.
• What happens when a simple, useful, ParserFunction is not implemented because "let's not encourage/pretend blah blah" ? People nevertheless implement it, in a very much shitty way.

Let's face it: there is Scribunto, because there was a need for it. So wiki users have many, many possibilities in their hands. It officially buried the "you should not program" legacy for good. But Scribunto is heavy artillery. Restraining ParserFunctions just for the sake of restraining it, is a way of thinking that has become obsolete for something like ten years. Od1n (talk) 21:33, 13 April 2015 (UTC)

A technique I'm trying out with, so far, good results is to support complex, powerful parsing operations through an embedded custom lisp — implemented, of course, in Scribunto, which is how I use Scribunto and, where necessary, JavaScript: as a means to empower wiki markup. {{evalx}}. Pi zero (talk) 22:19, 13 April 2015 (UTC)

I'm just interested in filling the obvious gaps related to the #if functions so whe have much cleaner templates. Very simple, future-proof, and damn useful. My point is not disserting on Algol or integrating a custom Lisp... Od1n (talk) 23:26, 13 April 2015 (UTC)

Point taken. But, to be fair, #ifnot and #ifand can be written straightforwardly using ordinary #if. The existing syntax of magic words and template calls in wiki markup is limited in how readable it can be, by the comparatively heavy syntactic overhead of the notation — delimiting double-braces {{}} and separating pipes |. It's not entirely obvious that the cost to readability of adding more magic words is made up for by the gain in readability &mdash if there is one — of writing {{#ifnot:{{cond}}|...}} instead of {{#if:{{cond}}||...}}, and {{#ifand:{{cond1}}|{{cond2}}|...}} instead of {{#if:{{cond1}}{{cond2}}|...}}; the differences get buried in the heavy syntactic overhead.

Now, if you want to take about helpful improvements to magic words, there was a proposal, way back I think, to add a magic word that provides the name of the page on which the magic word occurs regardless of what pages it's transcluded on. That would be immensely useful in writing templates that (1) are easier to read because the markup explains itself instead of hardcoding a page name that you then have to decipher to figure out what's going on, and (2) don't break if you move them, along with all their subpages, because they can name their subpages relative to themselves. The bug request was, I believe, classified as a WON'T FIX based on some rather unconvincing excuse about parser state. Pi zero (talk) 01:52, 14 April 2015 (UTC)

Your example above is wrong. {{#ifand:{{cond1}}|{{cond2}}|...}} is NOT the same as {{#if:{{cond1}}{{cond2}}|...}}. Please double check my presentation of #ifand above. That's precisely the kind of errors I've encountered countless times ;-)

Same goes for {{#if:<expr>||...}}. First contributor makes it right, following contributor goes too fast and deletes the extra pipe because he thinks of a mistake.

About your second paragraph, though an interesting point, it is off-topic again... Od1n (talk) 02:54, 14 April 2015 (UTC)

Yup, sure enough, I got #ifand wrong, which I can only agree is a fair practical demonstration of the utility of #ifand. I also concede it's easy to forget the double-pipe for #ifnot; I've sometimes made that mistake myself, and have learned to recheck pathologically against it. So, okay, I'm convinced. You're right, adding these magic words would indeed lead to a practical reduction in markup errors — and, despite the IP's comment above, it's kind of absurd to claim they'd encourage doing stuff with wiki markup instead of Scribunto because they're the sorts of things one would routinely do in really, really simple logic that nobody in their right mind would resort to Scribunto for. For what my agreement is worth. Pi zero (talk) 11:28, 14 April 2015 (UTC)

Glad I have convinced you :-) It would be great to get supplementary approvals, as the hardest part of this proposal is in fact to have it accepted, by demonstrating its benefits and proving a clear consensus. Od1n (talk) 23:08, 15 April 2015 (UTC)

• NOT — {{#ifeq:{{{arg|}}}||| ...do since not true... }} works just fine, and there is no reason add an ifnot.
• NOT — {{#ifeq:{{{arg1|}}}|{{#if:{{{arg2|}}}| ...do since both true... }}}} or {{#if:{{AND|{{{arg1|}}}|{{{arg2|}}}}}| ...do since ALL true... }}}} where {{AND}} is a template that will allow multiple inputs and return true if all inputs are true or false if one is false.
• As you said, OR is easy, but what about XOR? Since it is a much more complicated example, that could be done with a template as well {{XOR}}. Both of the AND and XOR templates if created are generic enough that they might benefit from being coded in Lua (Scribunto) which would easily allow infinite parameters to be passed. The current request here for a ifnot is too easily done with what is existing, and the request for an ifand is too limited in scope only allowing two arguments to be tested and would be much better resolved with a module allowing infinite and then the parser only has to test for one true or false based on the return of the module. Similar for my suggested XOR module, it wouldn't work well as a parser function but would be a great Scribunto default module (they would even make great intro to Lua tutorial modules). — {{U|Technical 13}} (e • t • c) 16:13, 16 April 2015 (UTC)

Your examples are complicated as hell. Ah, and the first is wrong.

But I had considered the {{and}} idea for a moment. Even if the most common use case is with no more than 2 conditions. Though, the name is already taken on numerous wikis, the English wiki for instance. Also, such a template would be much longer and complicated than the short, straightforward PHP implementation.

Then, I think {{xor}} would be less useful. Why not, but let's focus of the main topic for now.

----

Long story short, trying to do it using templates quickly gets complicated whereas in PHP it is incredibly short and straightforward. And it integrates smoothly for the users. Od1n (talk) 16:57, 16 April 2015 (UTC)

Also an ambiguity: should {{and|0|0}} be true or false?

As it complements #if, #ifand alleviates this ambiguity: {{#ifand:0|0}} is true, as {{#if:0}} is true. Od1n (talk) 01:14, 17 April 2015 (UTC)

@Technical 13: You're trying to apply a traditional concept in programming language design, but one that doesn't apply well to this situation. It's traditional to try to minimize the number of keywords. However, number of keywords trades off against the overhead cost of structural syntax. In a language with low overhead for structured expressions, it often makes sense to use a really minimal set of keywords, and build slightly more complex strutures to compensate. But the overhead for structured expressions is high in wiki markup, with relatively heavy delimiters and separators, and high likelihood of error when fancy structure calls for consecutive separators. The more effective strategy for wiki markup is to build uniform structure into the set of keywords itself, as there's much lower overhead in providing uniform variation in keywords than in trying to build big cumbersome structured expressions to make up for a minimal keyword set. Pi zero (talk) 13:52, 17 April 2015 (UTC)

I support the proposal by Od1n at 200 %. Especially for ifand. In fact, I would even prefer having and. Having to nest several if to do and is horrible ! Nnemo (talk) 12:00, 7 May 2015 (UTC)

Suggestion: #redir parser function

Is it possible to make a parser function to detect where a page redirects to? That would also allow username detection in another parser function (By removing the namespace from the page where Special:MyPage redirects to). 2 in 1! 90.190.250.247 07:23, 19 April 2015 (UTC)

Installation section broken

Appears corrupted. AlastairIrvine (talk) 04:32, 27 May 2015 (UTC)

Indeed. See this post. Let's hope for the best. [[kgh]] (talk) 08:21, 27 May 2015 (UTC)

#time localization issue with Greek (el)

Still bundled in MW 1.26.3?

Cannot load the extension in a vanilla install. Only when I download the extension into the extensions directory, wfLoadExtension( 'ParserFunctions' ) will work.

I don't find any ParserFunctions-related files in the tree, so I wonder if this extension still comes bundled with MediaWiki 1.26.3? Bovender (talk) 08:41, 7 June 2016 (UTC)

Just had a look, it is in included in the tarball provided. If you are using Git you indeed have to clone it separately. [[kgh]] (talk) 09:00, 7 June 2016 (UTC)

Yes, sure, my bad. Before upgrading MediaWiki, I had made a backup copy of the extensions folder which I copied back after the upgrade. Under the assumption that the bundled extensions are stored somewhere else, I then deleted the ParserFunctions directory... Bovender (talk) 19:25, 7 June 2016 (UTC)

Help: I still see #if and #ifeq etc

look i have ParserFuctions Installed: http://wiki.tumblenet.tk/wiki/Special:Version

but still i see #if anf #ifeq http://wiki.tumblenet.tk/wiki/Talk:Home Cammy26 (talk) 13:43, 2 August 2016 (UTC)

You are using a "very" old MW version (1.19.24) and the most recent version of ParserFunctions. Is it an option to use a more up to date MW version for your wiki? Felipe (talk) 14:14, 2 August 2016 (UTC)

Whats the latest version of media wiki that suports

i cannot update them im on a webhost https://www.000webhost.com/ Cammy26 (talk) 14:39, 2 August 2016 (UTC)

Well, the first version of PHP 5.2 came out almost 10 years ago. MySQL 5.1 back in 2008. If your web-host is running such outdated software then move to another host that runs up to date software. You are free to do so :) Felipe (talk) 06:37, 3 August 2016 (UTC)

i found this that has unlimated everything except for disk space and its free and it uses CPanel

http://www.heliohost.org/home/signup

here are the packages

is 500MB enough? Cammy26 (talk) 13:18, 3 August 2016 (UTC)

Adding facility for localization of keyword

What about adding internationalization support in the extension? Magic words does enable contributor to have localized aliases, so to my mind it would make sense that this extension also enable that. Psychoslave (talk) 14:43, 16 December 2016 (UTC)

Apparently they have this support, according to this comment Ciencia Al Poder (talk) 11:08, 18 December 2016 (UTC)

I'm rather unsure about it. I don't see anything related to localization in the repository expect for error messages. I'll ask on the ticket to be sure, thank you for the hint. Psychoslave (talk) 14:25, 18 December 2016 (UTC)

Installed but not enabled

I think the instructions should be more clear that, yes, it does come with mediawiki, but it is not enabled! I just spend an hour tearing my hair out over this. Gstupp (talk) 18:13, 11 April 2017 (UTC)

The first phrase on the page reads: (...) Thus you do not have to download it again. However, you still need to follow the other instructions provided. Ciencia Al Poder (talk) 20:14, 11 April 2017 (UTC)

timel functionality removed

Formerly, using #timel would allow a time to be formatted according to the user's personal tz preference as defined in their MW account settings. Some time between MW 1.24 (working) and 1.27 (not working) this seems to have been changed so that #timel only takes its location from $wgLocaltimezone. I don't know which behavior was intended but it sure seems like some useful functionality was lost. ~ Ham Pastrami (talk) 09:29, 17 October 2017 (UTC)

What you describe is not documented in Help:Extension:ParserFunctions#.23timel, and I'd be surprised that it worked as you say, since that would break cache horribly (a page cached by a user with a different preference than the current user viewing the page) Ciencia Al Poder (talk) 09:50, 17 October 2017 (UTC)

ifeditor

An #ifeditor which checks edit permissions would be nice for some template transclusion edge cases. I am not going to argue hard for it because it is very much an edge case thing, and also I threw one together on my server already, but it's a very simple addition which is useful if you want to add edit links conditionally in a template. 71.120.96.241 (talk) 18:22, 12 November 2017 (UTC)

Variables that depend on the user viewing the page right now won't be added because that breaks caching.

This means a user viewing a page being logged in may cache the page, and another visitor not being logged in, or a different user, would get the cached page with the wrong value. Ciencia Al Poder (talk) 18:50, 12 November 2017 (UTC)

#time bug

Entering a datetime value with timezone "AST" or "ACST" produces an incorrect result.

{{#time:YmdHi|11 March 2018 02:00 AST}} gives 201803102300, while the expected output is 201803110600.

{{#time:YmdHi|7 October 2018 02:00 ACST}} gives 201810070600, while the expected output is 201810061630.

Other timezones, including "ADT" and "ACDT", do work correctly. Thayts (talk) 20:09, 6 April 2018 (UTC)

Created a ticket at Phabricator for this: https://phabricator.wikimedia.org/T193346 Thayts (talk) 21:12, 9 May 2018 (UTC)

Time zone abbreviations can be ambiguous as there are abbreviations shared by multiple time zones. One solution is to use ISO 8601 notation: +hh:mm or -hh:mm. Another solution is to convert to UTC before entering it. Heddy10 (talk) 03:02, 21 August 2018 (UTC)

using #ask with template result format in #expr

URL transcoded/double-encoded when search for term with & or '

I'm not sure if this is related to the ParserFunctions plugin, but all research I've exhausted points to this. I'm not sure how to fix this, however. Hopefully someone can help.

Out of nowhere, when a term is searched that has an ampersand (&) or an apostrophe ('), the URL returns the article double-encoded. i.e. a term with an "&" is selected from the search box drop-down and instead of the standard %26, it returns as %2526, thus producing a "Bad title" error. With apostrophes in the term, it transcodes to %2527.

I'm using MediaWiki version 1.31.

Any ideas? Stillhouse (talk) 19:37, 21 July 2018 (UTC)

Disable Extension:ParserFunctions. If it still happens without ParserFunctions installed, open a new thread in Project:Support desk Ciencia Al Poder (talk) 09:48, 22 July 2018 (UTC)

Still happening after disabling the extension. I will open a new thread there - thanks. Stillhouse (talk) 18:07, 23 July 2018 (UTC)

Hex numbers with #expr

Any support? At least simple conversion to and from decimal? Of course it could be made from scratch, interpreting hex numbers as strings and evaluating each cahracter as a power of 16, but I was hoping to find something ready made, just like, say, #invoke:Roman (which is harder to implement, and seldom used, than hex). Tuvalkin (talk) 03:56, 19 July 2019 (UTC)

If you install Extension:Scribunto you can create a function to do that: https://stackoverflow.com/questions/27294310/convert-hexadecimal-to-decimal-number

Having Scribunto for that, I doubt you'll get that functionality included in Parser Functions. Anyway, if you're interested, the only way to get it is to bugreport it. Ciencia Al Poder (talk) 09:10, 19 July 2019 (UTC)

Thanks and apologies: I should have said that I'm asking not for a wiki I’m managing myself, but for the Portuguese-language Wikipedia. Tuvalkin (talk) 18:38, 19 July 2019 (UTC)

Then you can use the Scribunto extension, because it's already installed on WMF wikis. Ciencia Al Poder (talk) 09:46, 20 July 2019 (UTC)

Both possible results from an #if are occurring?

VsCode extension

Has anyone made an extension for VSCode (or any other IDE) for working with parser functions? Lynkfox (talk) 19:04, 16 May 2023 (UTC)

My parserfunctions does not work

My parserfunctions extension does not work on both my wiki, MoscowAmerican.com and on project zomboid www.pzwiki.net do you have to enable it? Or is it there by default?

using 1.27 and 1.39 2A00:1370:8186:92F2:94AF:3297:41C8:56D6 (talk) 08:04, 22 November 2023 (UTC)

The page Special:Version on your wiki will tell you if the extension is installed or not. If it's not listed there, it needs to be installed. Ciencia Al Poder (talk) 14:38, 22 November 2023 (UTC)

Is #time with local set/#timel intended to not use the user's timezone?

Whenever I use something like {{#timel: r}} or {{#time: r | now | en | 1}}, it outputs the current date and time using the wiki's timezone instead of the user's timezone set in Special:Preferences. This does not behave as expected according to the documentation for #timel, which currently states that "it always uses the preferred time zone of the user or the configured time zone of the wiki". Since #timel is described as effectively #timel but with the local parameter set to true, it is reasonable to believe that #time would also use the user's timezone.

The code currently only uses the value of $wgLocaltimezone and some server value if that is not set (per commit 1430c5a: ParserFunctions.php line 523). When the documentation for #timel was "clarified" to say that it follows the user's timezone (revision 6259692, 11 December 2023), the version of ParserFunctions at the time (commit bccd783, 22 November 2023) also only uses $wgLocaltimezone and some server value (per that commit's ParserFunctions.php line 523).

I initially thought that #time with local/#timel not using the user's timezone was a bug, but according to two Phabricator tasks (T9133 and T34923), this appears to be known? I'm not sure if a lack of support for the user's timezone is intentional or not, can someone clarify whether or not it is? BlankEclair (talk) 11:33, 16 June 2024 (UTC)

Unable to fetch information about any branches

I get an "Unable to fetch information about any branches" error when trying to download from Special:ExtensionDistributor/ParserFunctions Runefire3 (talk) 15:09, 3 June 2025 (UTC)