Help talk:Extension:ParserFunctions/2014-2020

#time
Why is it that the time function y only works for years before 2000? For example,   yields 08 (currently, when the year changes to 2009 presumably it will yield 09 at that point) when it should yield 02. This is very frustrating when trying to construct things utilizing dates with 2 digits. It doesn't seem to matter for 1999 and before, though. Examples:   yields   yields   yields   yields Thanks for any help that anyone may be able to provide. I had no idea where to post this question, but hopefully this is the right spot. 24.236.101.233
 * Also, I edit mainly on wikipedia (sorry for not having a username here). If/when this is fixed, would it automatically update on wikipedia or not? Sorry, I didn't know how that worked. Thanks again for any info anyone might be able to provide. 24.236.101.233 09:52, 30 December 2008 (UTC)
 * The problem is that if you use  , you get, like for    . i Alex  12:56, 30 December 2008 (UTC)
 * You just need to make the date look more like a date. A 4 digit number staring with a 2 isn't enough. Try:  or  . See strtotime. Splarka 21:35, 30 December 2008 (UTC)
 * It is possible with some minor limitations to use #time for specifying dates from -6999BCE to 6999CE. It requires some template hackery to bypass normal limitations of #time, but it is possible to do.  One limitation is that there is no way of recognizing the precision the editor intended for certain dates and times.  EG: if seconds were specified as 00, there is no way (that I have come up with yet) to tell if the user simply omitted the seconds because they didn't measure with that precision.  For example of the lengths I had to go to in order to get this functionality, see code at .  (Note- you won't be able to see the results of the calculations from preview- the easiest way to see the UTC value emitted is to turn off CSS, eg, Opera View.Style.User mode.  Look for the UTZ value in parens following the visible date-time.) -J JMesserly 20:05, 17 February 2009 (UTC)

#switch
Quote from help: ''It is possible to have 'fall through' values, where several case strings return the same result string. This minimises duplication.'' — It doesn't seem to work for me. Instead, an empty string is returned for cases where right-hand side is emty. --Lozman 14:19, 3 January 2009 (UTC)


 * I fixed the description.--Patrick 10:20, 4 January 2009 (UTC)


 * Thanks a lot! Now it works OK. --Lozman 11:11, 4 January 2009 (UTC)

I have used #switch to return one string at and a different one at. This works very well, however one of my strings had a leading space. This was not parsed correctly, the space was ignored. I have had to precede it with a line break for it to work. 213.126.244.228 14:36, 17 February 2009 (UTC)

Example for first black president
The above example should change on Jan. 20, 2009. --Ed Poor 20:40, 9 January 2009 (UTC)


 * That won't because there is no Template:Age in days on this wiki, and even if there were, #if only checks nullity. Try something like:
 *  </tt>
 * Splarka 22:45, 9 January 2009 (UTC)

Using #if to call an image and adding attributes
I am trying to use #if to call an image. I don't want this image to link to its source page or anywhere. I think that I can do that by using "|link=" as an attribute but I can't get it to work. Anyone able to help?


 * if:|[[Image:|130px|]]


 * well, this:


 * Works for me, but note that the link= parameter is new to version 1.14 which isn't released yet. Splarka 08:25, 15 January 2009 (UTC)
 * Works for me, but note that the link= parameter is new to version 1.14 which isn't released yet. Splarka 08:25, 15 January 2009 (UTC)
 * Works for me, but note that the link= parameter is new to version 1.14 which isn't released yet. Splarka 08:25, 15 January 2009 (UTC)

Errrrm - so does that mean that I have to wait for 1.14 and upgrade or is there a workaround? I tried it in mine and it didn't work - you can still click on the image and get through to the Image page, which is what I want to disable :(.


 * Only if you want to wait for the quarterly release, if you're ambitious you can Download from SVN to get the latest version. --Tlosk 10:46, 30 January 2009 (UTC)

Move to Help:ParserFunctions
I don't know if anyone else noticed, but Help:Extension: looks ridiculous. I amend that we move this page to the above link. -PatPeter  MediaWiki Support Team  00:23, 18 January 2009 (UTC)


 * I think the distinction can be helpful in that Help: applies to a default installation and Help:Extension: makes clear that the information applies to an added extension. --Tlosk 10:38, 30 January 2009 (UTC)

HTML in #IF statement branches is not rendered as html but as plain text
In this example I want to include or exclude a row of a talbe based on the presence of a passed paramter:

However what happened is the html is renderes as plain text and I get a bunch of HTML code showing up on my page.

How can I prevent this?

Thanks, Pete.
 * See Manual:$wgUseTidy -- Skiz zerz  21:40, 5 February 2009 (UTC)


 * I recommend using wiki-markup instead of HTML:


 * —Sledged (talk) 00:28, 6 February 2009 (UTC)

Help
This code in a template:

produces this error.

but it still works when the template is used??? --Droll 13:31, 7 March 2009 (UTC)

See w:User:Droll/sandbox1 for template and w:User:Droll/sandbox3 for test. --Droll 15:16, 7 March 2009 (UTC)

Never mind. My bad. --Droll 21:42, 7 March 2009 (UTC)


 * What did you do wrong? I see the error still on your sandbox1 page.  Have you tried to fix it?  --Lance E Sloan 20:44, 9 March 2009 (UTC)


 * What I wanted to do was:


 * Thanks for asking. --<font style="color:#355E3B">droll <font style="color:#704214">&#91;chat&#93; 23:53, 13 March 2009 (UTC)

When I try to use a code like:

I just get the input and no answer. I should get: true, but get  . I think it have some to do with the setting in a file, but I have no idea how to fix it?


 * It is likely that the ParserFunctions extension is not installed on your wiki. Is it listed in Special:Version? Happy ‑ melon 11:50, 11 April 2009 (UTC)

Exactly. Now it works. I used the information from this site about Extension:ParserFunctions

Better Operator table
See Extension:ParserFunctions/Help/sl for a table that is much more helpful in my opinion. --<font style="color:#355E3B">droll <font style="color:#704214">&#91;chat&#93; 23:47, 13 March 2009 (UTC)
 * That operator table is GFDL, which means we can't use it here. If you feel like rewriting something that is similar (but not a derivative work), feel free to put it up here, but because the Help: namespace is Public Domain and the rest of the site is GFDL, we can't just copy/paste it. -- Skiz zerz  23:54, 13 March 2009 (UTC)
 * That is a shame but I understand. I will keep an translated version locally. I think some mention of operator precedence is worth mention. I assume its the same a c?. --<font style="color:#355E3B">droll <font style="color:#704214">&#91;chat&#93; 00:03, 14 March 2009 (UTC)

More versatile #titleparts?
Could the #titleparts: function be expanded to allow other separators than slashes (colons, maybe even spaces)? (Possibly having a third parameter to specify the separator, with slashes as default so as not to break its current use…) -- 87.165.184.244 02:06, 14 March 2009 (UTC)
 * Then it wouldn't be a titleparts function, it would be a string-splitter, which is a completely different concept. String-manipulation ParserFunctions are available in the StringFunctions extension; if you want proper string-manipulation functions, you need to get this installed on your wiki.  Happy ‑ melon 08:17, 14 March 2009 (UTC)
 * Ah. Thanks for the quick reply! 87.165.185.6 01:27, 15 March 2009 (UTC)

#if doesnt works
On my version of wikimedia 1.14, #if option dont works. I'm printing - and nothing happens, text showing only as plain text

Joe.


 * Install the ParserFunctions extension. —Emufarmers(T 21:27, 29 March 2009 (UTC)

Rand for #expr:?
Doesn't anyone think it make huge sense to add a Rand function to the #expr: group of functions? Extension:Choose is definitely not applicable (all the hooks are in the wrong places...) and Time-based pseudo-randoms won't work either. I was amazed when I realized this wasn't there yet... Timeroot|undefinedTalk • Contribs • Edit Count 19:28, 30 March 2009 (UTC)
 * Why do you hate the cache so much? The cache loves you, the cache does everything it can for you, and it has to go to work and tell its friends "oh, I just ran into a door". Splarka 07:14, 31 March 2009 (UTC)


 * The original commit of ParserFunctions included a "rand" function. But I removed it, because I thought it would be confusing. People will expect it to work, which of course it won't, due to the parser cache. Random selection is best done with JavaScript. -- Tim Starling 09:09, 1 April 2009 (UTC)

Is it possible to have a 3-tiered approach to parameters (not) passed in to templates?
Given a template that can be used in three ways like this:

is it possible to have the template handle itself differently based on param not being given, param given without a value and param given with a value?

I've been looking at using and  to distinguish the first and second case (the third case handles well), but it doesn't seem to work; the output is the same either way.

It's especially how handles itself when put into an  I'm interested in.

Rafiki 07:57, 16 April 2009 (UTC)


 * "parameter" is
 * Not the usual method of using #if, but that #if will only trigger in your second case. Note that I edited your example above, because your second case was actually a different parameter, it was assigning "param" to . If you really did mean that, that is a different barrel of fish. Splarka 08:16, 16 April 2009 (UTC)


 * On enwiki we tend to use the "logical negation" ¬ character that's found at the top-left of most keyboards. Since it's not something that anyone is ever likely to actually pass to a parameter.  So you could test for your three separate conditions like this:


 * Does that make sense? Happy ‑ melon 10:08, 16 April 2009 (UTC)


 * Even if it may not make sense, it works like a charm. Many thanks for the insights! And you are, of course, right about the assignment of "param" to ; I didn't consider that at all. Rafiki 13:30, 16 April 2009 (UTC)

limits of #titleparts
There seems to be a limit for the #titleparts-function. These two lines of code should produce the same result ...:

... but only the second one seems to work correctly:

Is there a limit of string-length? Or a limit to the number of segments? And if there is a limit, (how) can I change it? I have to use #titleparts because I want to receive longer substrings like "2/3/4/5" and with #explode it is only possible to get one piece based on its position. Sorry for my lack of English. --213.39.183.144 17:39, 2 May 2009 (UTC)


 * The function only performs a maximum of 25 splits, so no more than 26 segments can be created:
 *  </tt> &rarr;
 * The string must also be less than 255 characters in length. Hope this clarifies. Happy ‑ melon 11:32, 3 May 2009 (UTC)


 * Thanks for the quick reply. Is it possible to change the maximum string-length and maximum number of splits? --80.171.78.168 12:12, 3 May 2009 (UTC) and why do I have a completely different IP today? --80.171.78.168 12:13, 3 May 2009 (UTC)
 * The number of splits is hardcoded into trunk/extensions/ParserFunctions/ParserFunctions.php (line 504); you could change it, but you'd have to remember to change it every time you updated the file. The maximum string length is essentially unavoidable: the string is converted into a Title object to check its validity (it is supposed to be a page title, after all :D</tt>), and the maximum title length is a function of the database field width.  Happy ‑ melon 16:35, 3 May 2009 (UTC)
 * And if you want to avoid being confused (or confusing others) with a dynamic IP, why not create an account?? It takes literally ten seconds, and gives you all sorts of cool features... Happy ‑ melon 16:35, 3 May 2009 (UTC)
 * Again, thank you for the quick reply. Maybe it is possible to avoid the conversion to a Title object? So, it would be possible to use links and and other stuff within the string ... I'll try this. Greetings, --WiMu 10:16, 4 May 2009 (UTC) and where is my IP today? ... ah, it's my new account now ;-)

#ifexpr for strings
Would be great if #ifexpr would be enabled for strings as well. Imagine string comparison like  --Danwe 14:48, 4 May 2009 (UTC)


 * And what would be the expected logical value of  </tt>?? :D</tt> Happy ‑ melon 17:05, 4 May 2009 (UTC)


 * False. In this case we can look at the 1 as string and the strings "one" and "1" are not equal. I only don't know if we should define that  is nonsense and will lead to an error message or if this has a meaning as well for example comparison of the string lenght. --Danwe 13:17, 5 May 2009 (UTC)
 * There is only one problem I can see: The and and or words. They shouldn't be interpreted as strings. A way to avoide that could be to set strings into quotes like . It should be possible to use and and or for strings as well and also mixed with number comparision like    --Danwe 13:44, 5 May 2009 (UTC)


 * Hmn, with quotes, it could perhaps work, although there is still some rather wierd logic available ( </tt>??) We'd need to define an appropriate string&rarr;integer cast for such expressions, which should probably be the same for all strings.  Casting to true makes some sense, as would casting to the binary representation, but both allow some rather odd concepts (division by a string?!?).  Casting to an error avoids that problem, but makes them essentially unusable. Casting to different representations based on the calling operator could be at best described as "quirky"... Happy ‑ melon 17:15, 5 May 2009 (UTC)
 * I think it's not neccessary to compare "1" and 1, sting and non string. Because the template programmer knows what he want's to compare he should know at least whether he wants to compare strings or numbers. And if you have a string with unknown content which perhaps could be a number it doesn't matter because it could be a real string as well which you must compare as string anyway. And casting integer into string is no problem in the template, the quotes do it so it's save in any case as long the user won't forget the quotes. --Danwe 17:40, 5 May 2009 (UTC)
 * Casting integers to strings for comparison is a good idea, but has its own set of problems. What does   </tt> evaluate to?  Or do you mean only explicit casts (using quotes) would avoid an error? That's more tenable, but what if the input strings contain quotes themselves? Don't even think about suggesting we escape them... :D</tt> Happy ‑ melon 22:11, 5 May 2009 (UTC)
 * "(1 and 2)" is a string, not a logical comparision which is converted into string after the comparision. You can write: 1 and 1 and "abc" because with and and or you only compare boolean results. But your last point was one I never thought about. What if there are user defined quotes inside the quotes... i agree, escaping them won't work. " inside of ' quotes could be possible but then we have the same problem with the ' quotes... honestly I have no idea yet --Danwe 18:42, 6 May 2009 (UTC)

Request: new flag to force date interpretation in #time:
Is it possible to add a flag (may be xd) to force date interpretation of ambiguous inputs like four-digit and six-digit numbers, giving an error when that number is not a valid date? It should be a toggled flag like xN and it should work as follows: Feel free to correct my English. Gustronico 00:42, 21 May 2009 (UTC)
 *  </tt> &rarr; 2006 instead of 
 *  </tt> &rarr; November 2006 instead of 
 *  </tt> &rarr; Error instead of 
 *  </tt> &rarr; 1998 04 01 00:00:00 instead of 
 *  </tt> &rarr; 1998 01 01 00:00:00 instead of 


 * Well, don't waste your time. I've solved the problem with  «ambiguous number» </tt>
 *  20060000 </tt> &rarr; 20060000 &rarr; 
 *  20061100 </tt> &rarr; 20061100 &rarr; 
 * <tt> 20061500 </tt> &rarr; 20061500 &rarr; 
 * <tt> 19980400 </tt> &rarr; 19980400 &rarr; 
 * <tt> 19980000 </tt> &rarr; 19980000 &rarr; 
 * Nevertheless I think that it would be a usefull flag. Gustronico 16:08, 21 May 2009 (UTC)

Division
How much is:



There seems to be an error in the info box which lists /div as a binary operator. Shouldn't that be / div with a space between the slash and the letters? Ed Poor 21:57, 25 May 2009 (UTC)
 * Yes. Happy ‑ melon 22:16, 25 May 2009 (UTC)

Rounding
Is all rounding to the nearest integer, or what?

=

Where is this documented? --Ed Poor 22:03, 25 May 2009 (UTC)
 * meta:Help:Calculation, hasn't been moved over from meta yet. If you want to write a PD version here, we'd be very grateful! Happy ‑ melon 22:17, 25 May 2009 (UTC)

Import from StringFunctions
The features of StringFunctions have been imported as of r50997 (probably MW 1.16). The documentation will need to be merged when it is released. GreenReaper 17:35, 31 May 2009 (UTC)
 * Don't hold your breath on it surviving to a release... Splarka 07:12, 1 June 2009 (UTC)
 * That's what I was going to say: I want to see it get through code review before I put any work into documenting it. The documentation can't be "merged" because they're incompatible licenses (Help: is public domain), so it'll have to be written from scratch. Happy ‑ melon 08:53, 1 June 2009 (UTC)


 * Well if someone wants to point out terrible flaws, please do. The code was almost totally rewritten from the StringFunctions implementation (which was just plain terrible in some places).  In the meantime, the bastardized string manipulation templates are now being used on >20,000 enwiki pages and that will almost certainly continue growing until we either have real string functions or Brion changes his mind and kills off the padleft: abuse that made those possible.  In the mean time, if someone does start working on this documentation please ping me and I'll certainly check it for accuracy and make sure it covers all the appropriate quirks.  Dragons flight 21:33, 1 June 2009 (UTC)
 * Presumably we eventually need Help:Extension:StringFunctions anyway, so I guess we might as well start. The way the string function implementations on enwiki have grown is a very clear sign of just how valuable these methods are.  But I'm not breaking out the champagne until I see  as "3" right here.
 * Incidentally, do you know why Wikimedia's MW is lagging so far behind SVN trunk? We're 2,500 revisions behind now... <tt>:(</tt> Happy ‑ melon 22:19, 1 June 2009 (UTC)
 * Once Upon A Time, the developers were told that some simple ParserFunctions would reduce the instances of ugly <tt> </tt> type templates and simplify the codebase of templates, and make everyone live happily ever after. They initially and very briefly made code simpler, but then made templates a thousand times more complex (see any template on en.wp).
 * Adding StringFunctions will only add to the insane complexity, and turn Wikimedia's wikicode into a natural language parsing system, making templates almost impossible for anyone to edit safely, and giving the servers even more very inefficient overhead. Certain developers absolutely do not want this, as this would only make things more complex in the long run, and more system intensive. They seem to prefer playing a "But this isn't up to snuff" game on bugzilla. If you want a more frank admission of the reasoning, please see This log starting at about <tt>[16:45:35]</tt>. This almost certainly will be reverted (again) before scap, and if not, domas will probably come along later and cripple the features after tracing the crazy profiling spikes. My guess anyway.
 * Also, brion has been very distracted for about 7 weeks, what with dev meetups and getting hitched and all. Splarka 07:23, 2 June 2009 (UTC)
 * Hmm, seems Brion's actually more amenable to the idea than Tim; and it seems to be a fairly even split amongst the senior devs. As I said, I'm definitely keeping the champagne in the bottle for now.
 * I didn't know Brion got hooked up! Congrats to him.  Is there more to read into <tt>[12:01:49] he's also not back permanently, I think he's heading somewhere</tt>?? Is that just his honeymoon or is our venerable leader leaving us??  <tt>:S</tt> Happy ‑ melon 09:21, 2 June 2009 (UTC)
 * Last week was part of his honeymoon, as I understand it. Unless there is evidence to the contrary, I'd just assume he was off having a good time.  I think you are correct that Brion is generally supportive of StringFunctions in concept, as long as the implementation is reasonable.  The past implementations had serious flaws that generally made them unsuitable for use at the WMF scale.  I'm hoping that the new version is technically acceptable, so the only concern is more of the "do we want this variety", and I think the community can have a significant voice in that.  Dragons flight 23:13, 2 June 2009 (UTC)

(Undent) See 51497 for latest developments. I still think you should wait to see if it makes it to a release before going through the trouble and clutter of adding them here. Aside, this would mean the deprecation of the StringFunctions extension... but still, the (totally obvious) main goal of sneeking these in to Wikimedia is as yet unfulfilled. Splarka 12:24, 5 June 2009 (UTC)
 * I am still failing to see why these two extensions have been merged, except as you say as a broad-daylight attempt to sneak them onto WMF as part of normal code review/scap, rather than an explicit shell request. Which Tim has now just foiled.  The two function sets are radically different, and yes, enabling them is as much a philosophical/ideological step as a technical one.  Either way, nothing is going to happen without Brion's say-so. Happy ‑ melon 15:32, 5 June 2009 (UTC)


 * I'm not actually sure either (and I'm the one that merged them!). Comments at 6455 favored such a merge, as did devs I spoke to privately before doing it.  I don't "think" the intent was merely to backdoor them in (it certainly wasn't my intent anyway, and it should be obvious to any reasonable person that this would immediately draw discussion and hence couldn't actually be accomplished as some secret plot).  Personally, I would have been just as happy to implement it as a separate extensions, and even think that seems more natural.  Dragons flight 02:29, 6 June 2009 (UTC)