Help talk:Extension:ParserFunctions/2009

#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 {{templ|begin}} and a different one at {{templ|end}}. 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)

subsequent cases

I wonder if there is any good reasons why subsequent cases are not supported. They would save some time and Code I think. Think of something like the following:

{{#switch:
|1=1 foo
|2=2 foo
|3=3 foo
|1
|2=1+2 foo
|1
|3=1+3 foo
}} 

--Danwe 00:26, 18 June 2009 (UTC)

They are supported. That example will work perfectly, when you specify a test string as the first parameter. It is not particularly useful, however, because an input of 1 will always match the first case encountered (the "1 foo" case). However, a statement like this:

{{#switch: {{{input}}}
 | foo = You entered 'foo'
 | bar = You entered 'bar'
 | baz
 | quok = You entered either 'baz' or 'quok'
}}

Will work perfectly. Happy‑melon 08:08, 18 June 2009 (UTC)

I know that this will work perfectly but this is not what I meant. I meant subsequent cases, match each "1" and not only the first "1". That would be the same behavior than in C++ for example where you can stop it with the break kommand. --Danwe 14:20, 21 June 2009 (UTC)

No, the behaviour in languages like C++ is to scroll through the cases until a match is found, then to execute all the remaining statements in the switch until a break is found. So the output of a statement like your example in C++ would be "1 foo2 foo3 foo1+2 foo1+3 foo" What you want is the output to be "1 foo1+2 foo1+3 foo", right? That's basically just string substitution. How would that be useful? Happy‑melon 21:24, 26 June 2009 (UTC)

This would be usefull if some cases should have the same output and the output is very long so you don't want to write it down for all the cases. --Danwe 18:48, 5 July 2009 (UTC)

Not sure whether this is exactly the thing you want, but I have a simple patch which I belief does this exact thing (I needed it), but it might nearly definitely break some other functionality: replace line 220 ( "return trim( $frame->expand( $valueNode ) );" ) with ($returnvalue .= trim( $frame->expand( $valueNode ) );") and add a line between 241 and 242 containing "if($returnvalue != "") return $returnvalue;". Lastly it might be necessary to add "$returnvalue = null;" at the begin of the function. -- David Mulder (can't login) 77.95.97.53 11:17, 6 January 2010 (UTC)

Example for first black president

{{#if:{{age in days|2009|1|20}}|Bush|Obama}}

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:

{{#ifexpr: {{#time:U}} > {{#time:U| January 20 2009}}|Obama|Bush}}

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?

1. if:|[[Image:{{{Logo}}}|130px|]]

well, this:

• {{#if:1|[[Image:Wiki.png|30px|link=]]}} >
• {{#if:|[[Image:Wiki.png|30px|link=]]}} >

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:

{{#if: {{{room}}} |
<tr>
<td></td>
<td></td>
<th>
Room {{{room}}}
</th>
<td></td>
<td></td>
</tr>
|  }}

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 --Skizzerz 21:40, 5 February 2009 (UTC)

I recommend using wiki-markup instead of HTML:

{{#if: {{{room}}} | 
{{#!: |-
|
|
! Room {{{room}}}
|
|
}}
}}

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

Help

This code in a template:

{{#ifexpr: {{{width}}} > 300 | {{{width}}} | 300}}

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:

{{#if:{{{width|}}}|{{#ifexpr:{{{width|}}}>300|{{{width}}}|300}}|300}}

Thanks for asking. --droll [chat] 23:53, 13 March 2009 (UTC)

When I try to use a code like:

{{#ifexpr: 1 > 0 | true | false}}

I just get the input and no answer. I should get: true, but get {{#ifexpr: 1 > 0 | true | false}}. 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. --droll [chat] 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. --Skizzerz 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?. --droll [chat] 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 - {{#if:test|test2|test3}} and nothing happens, text showing only as plain text

Joe.

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

I'm having trouble with the same thing. I have ParserFunctions extension installed (see http://wiki.accelereyes.com/wiki/index.php/Special:Version). I have a test page too (see http://wiki.accelereyes.com/wiki/index.php/TEST). What am I doing wrong? Why is it showing only as plain text? UPDATE: This error only occurs when I'm logged in. When I'm logged out, everything works fine.

You're running very old versions of MediaWiki and ParserFunctions. I don't know how they behave. —Emufarmers^(T|C) 22:03, 25 January 2011 (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 Talk • 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)

I'd like to use it with subst, so if you still got the code, would you share it? --Sidcom 10:58, 1 July 2010 (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:

{{ MyTemplate }}
{{ MyTemplate | param = }}
{{ MyTemplate | param = value }}

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 {{{param}}} and {{{param|}}} 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 {{{param}}} handles itself when put into an {{if: }} I'm interested in.

Rafiki 07:57, 16 April 2009 (UTC)

• "parameter" is {{#if:{{{parameter|undefined}}}|{{{parameter|undefined}}}|defined but empty}}

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 {{{1}}}. 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:

{{#switch: {{{param|¬}}}
  | ¬       = <!--undefined-->
  |         = <!--defined but empty-->
  |#default = <!--defined and with a value-->
}}

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 {{{1}}}; I didn't consider that at all. Rafiki 13:30, 16 April 2009 (UTC)

To distinguish between defined (and possibly empty) and undefined, use:

{{ #ifeq: {{{param|+}}} | {{{param|-}}} | param is defined | param is undefined }}.

Patrick 11:00, 14 July 2010 (UTC)

limits of #titleparts

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

{{#titleparts: 1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/19/20/21/22/23/24/25/26/27/28/29/30/31/32/33/34/35/36/37/38/39/40/41/42/43/44/45/46/47/48/49/50/51/52/53/54/55/56/57/58/59/60/61/62/63/64/65/66/67/68/69/70/71/72/73/74/75/76/77/78/79/80/81/82/83/84/85/86/87/88/89/90/91/92/93/94/95/96/97/98/99/100 | 2 | 2 }}

{{#titleparts: 1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/19/20/21/22/23/24/25/26/27/28/29/30/31/32/33/34/35/36/37/38/39/40/41/42/43/44/45/46/47/48/49/50 | 2 | 2 }}

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

1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/19/20/21/22/23/24/25/26/27/28/29/30/31/32/33/34/35/36/37/38/39/40/41/42/43/44/45/46/47/48/49/50/51/52/53/54/55/56/57/58/59/60/61/62/63/64/65/66/67/68/69/70/71/72/73/74/75/76/77/78/79/80/81/82/83/84/85/86/87/88/89/90/91/92/93/94/95/96/97/98/99/100

25/26/27/28/29/30/31/32/33/34/35/36/37/38/39/40/41/42/43/44/45/46/47/48/49/50

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:

{{#titleparts: 1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/19/20/21/22/23/24/25/26/27/28/29/30/31/32/33/34/35/36/37/38/39/40/41/42/43/44/45/46/47/48/49/50 | 1 | 25 }} → 25/26/27/28/29/30/31/32/33/34/35/36/37/38/39/40/41/42/43/44/45/46/47/48/49/50

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), 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 {{templates}} 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 {{#ifexpr: {{{text 1|}}} && {{{text 2|}}} |If both exist |If one or both don't exist/void}} --Danwe 14:48, 4 May 2009 (UTC)

And what would be the expected logical value of {{#ifexpr: one == 1 | true | false }}?? :D 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 {{#ifexpr: one > 1 | true | false }} 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 {{#ifexpr: "{{{1|}}}" = "{{{2|}}}" | true | false }}. It should be possible to use and and or for strings as well and also mixed with number comparision like {{#ifexpr: "{{{1|}}}" = "{{{2|}}}" and 3 > 1 | true | false }} --Danwe 13:44, 5 May 2009 (UTC)

Hmn, with quotes, it could perhaps work, although there is still some rather wierd logic available ({{#ifexpr: "1" == 1 || | true | false }}??) We'd need to define an appropriate string→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 {{#expr: "(1 and 2)" == (1 and 2) }} 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 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:

• {{#time: xdY | 2006 }} → 2006 instead of 2006 Fixed since rev:86805 24 April 2011
• {{#time: xdF Y | 200611 }} → November 2006 instead of December 2024
• {{#time: xdY m d H:i:s | 200615 }} → Error instead of 2024 12 17 20:06:15
• {{#time: xdY m d H:i:s | 199804 }} → 1998 04 01 00:00:00 instead of
• {{#time: xdY m d H:i:s | 1998 }} → 1998 01 01 00:00:00 instead of 1998 12 17 00:00:00

Feel free to correct my English. Gustronico 00:42, 21 May 2009 (UTC)

Well, don't waste your time. I've solved the problem with {{padright: «ambiguous number» | 8 | 01 }}

Note: #time: function is omitted for simplicity. Refer to cases above.

• {{padright: 2006 | 8 | 01 }} → 20060101 → 2006
• {{padright: 200611 | 8 | 01 }} → 20061101 → November 2006
• {{padright: 200615 | 8 | 01 }} → 20061501 →
• {{padright: 199804 | 8 | 01 }} → 19980401 → 1998 04 01 00:00:00
• {{padright: 1998 | 8 | 01 }} → 19980101 → 1998 01 01 00:00:00

Nevertheless I think that it would be a usefull flag. Gustronico 16:08, 21 May 2009 (UTC)

Division

How much is:

• {{#expr: 60 / 2.54}} 23.622047244094
• {{#expr: 60 /div 2.54}}
• {{#expr: 60 div 2.54}} 23.622047244094

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?

{{#expr: 123.456789 round 2}} = 123.46

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 {{#len:Foo}} 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... :( 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 {{qif}} 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 [16:45:35]. 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 [12:01:49] he's also not back permanently, I think he's heading somewhere?? Is that just his honeymoon or is our venerable leader leaving us?? :S 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 rev: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 bugzilla: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)

Using {{time}} in {{switch}}?

I want to show diffent content each day, for example: {{ #switch: {{#time: dmY}} | 10062009 = Content 1 | 11062009 = Content 2 }}

But every time i save the template the code is changed and does not work! --80.228.185.14 20:19, 10 June 2009 (UTC)

It is impossible for anyone here to help you with only that desciption of the problem. How does "the code change"? What does it do instead of work? The more information you provide, the more likely we are to be able to solve your problem. Happy‑melon 22:54, 11 June 2009 (UTC)

Hi Happy-melon, thanks for your reply. The code changes to the following {{ #switch: }}{{ #time: dmY}} | 10062009 = Content 1 | 11062009 = Content 2 }}--80.228.182.220 15:32, 12 June 2009 (UTC)

That is extremely odd. Can you provide a url to the wiki where you're experiencing this problem? Happy‑melon 16:31, 12 June 2009 (UTC)

Just look here: http://gzsz-wiki.de/index.php/Sandkasten. The code only changes if you save a page. in preview-mode the code works. maybe a plugin causes the changes? --80.228.183.126 07:40, 13 June 2009 (UTC)

To be honest, it's probably something wrong with one or more of the wierd-and-wonderful extensions that are installed there, most of which are not WMF-stable. What happens if you try and remove just one of the extra braces? Happy‑melon 08:12, 13 June 2009 (UTC)

If i remove just one after saving there are three of the braces. ;-) I'll try to deactivate the plugins to check if of of them produces the error. --80.228.183.25 19:55, 13 June 2009 (UTC)

Yeah, the errors suffer from the autolink-plugin. i deactivated it and now it works. --80.228.182.105 09:42, 16 June 2009 (UTC)

Switch and Parameters/Arguments

Is there anyway to use switch with a passed parameter/Argument? Something like:

{{#switch: {{{1}}} | case1 = blah | case2 = duh | default whatever}} --71.187.221.128 23:13, 13 June 2009 (UTC)

Exactly like that. Splarka 07:36, 14 June 2009 (UTC)

Setting timezone

Hi.

Shouldn't this give different results?

{{#time:Y-m-d H:i:s|2009-07-30T22:00:00+02:00}}
{{#time:Y-m-d H:i:s|2009-07-30T22:00:00+00:00}}

Just as does this:

<?php
	echo date('Y-m-d H:i:s', strtotime('2009-07-30T22:00:00+02:00')) . "<br />";
	echo date('Y-m-d H:i:s', strtotime('2009-07-30T22:00:00+00:00')) . "<br />";
?>

--Nux 23:36, 30 July 2009 (UTC)

Parameter with #expr

I have a parameter in my template, say {{{number}}}. How can I use it with #expr so that when {{{number}}}=20

{{#expr: {{{number}}}-10}}

produces 10? All I get is the error: Expression error: Unrecognised punctuation character "{"

It will work when transcluded. If you want it to work on the template page, give it a fallback default like {{{number|0}}}, or wrap it in noinclude tags. Splarka 07:19, 5 August 2009 (UTC)

That seems to do the trick. Thank you!

This worked for me too:

{{#if:{{ {{{1|0}}}|out=found|}}|  {{ {{{1|0}}}|out=found|}} }}

Thank you. Errectstapler 21:40, 12 May 2011 (UTC)

Internal link in Template - not working

I created a following template, modeled after w:en:Template:Missing_information. I wanted to add a parameter "anchor" so I could jump to a section on the talk page. But when I try to use it, I get garbage instead of an internal link like Talk:Pagename#Section

{{ambox
| type  = content
| text  = '''To do:''' {{{1}}} See [[:{{NAMESPACE}} talk:{{PAGENAME}}{{#if: {{{anchor|}}}|#{{{anchor}}}}}|talk page]] for  additional comments (if any). {{#if:{{{date|}}}|<small>''({{{date}}})''</small>}}
}}

Expensive parser functions

How can the number be changes?--Launchballer 19:56, 11 September 2009 (UTC)

As it says very clearly on this help page, by changing $wgExpensiveParserFunctionLimit. See Manual:$wgExpensiveParserFunctionLimit for more details. Happy‑melon 21:31, 11 September 2009 (UTC)

Conditional statements inside math functions

I am trying to create a template while using a conditional statement inside of a math tag (<math>...</math>), but I'm having problems. It seems like the math tags are running before the conditional statements, but after receiving the other parameter values from the template. Here's the code, which can be found at Template:DentalFormula:

<math alt="Upper: {{{upper}}} / Lower: {{{lower}}}{{#if: {{{total|}}} |, Total teeth = {{{total}}}|}}">\tfrac{ {{{upper}}}}{ {{{lower}}}}{{#if: {{{total|}}} | \times 2 = {{{total}}}|}}</math>

This yields the error: "Failed to parse (lexing error): \tfrac{ {{{upper}}}}{ {{{lower}}}}{{#if: {{{total|}}} | \times 2 = {{{total}}}|}}"

Am I doing something wrong? Is there any way to fix this? –Visionholder 03:47, 16 September 2009 (UTC)

You can't use template parameters directly in a parser extension tag. You have to convert it to a parser function with #tag. Splarka 07:03, 16 September 2009 (UTC)

You absolutely rock! I never would have figured that out. Thank you! –Visionholder 08:41, 16 September 2009 (UTC)