Help talk:Extension:ParserFunctions/2010

Active discussions


Is this the expected behaviour?

<math>\unknownname</math> Failed to parse (unknown function "\unknownname"): {\displaystyle \unknownname}
{{#iferror: <math>\unknownname</math> | error | correct }} correct

I mean, if the math formula returns an error, should #iferror return "error"? Helder 17:18, 29 November 2009 (UTC)[]

It's not ideal, but it is expected. Extension tags like <math> are processed after parser functions like iferror, so when the function is evaluated, the input string is just "<math>\unknownname</math>", not the expanded HTML with error class. Other tags, like <timeline>, <ref>, etc, behave the same way. Happymelon 17:55, 29 November 2009 (UTC)[]
Is this order the reason for this too?
{{#ifeq:{{:Special:PrefixIndex/MediaWiki talk:}}|{{:Special:PrefixIndex/MediaWiki talk:}}|yes|no}} no
(I was thinking about the possibility of using something like this to watch the creation of discussion of MediaWiki messages...) Helder 19:04, 29 November 2009 (UTC)[]
Essentially, yes. <code>{{:Special:PrefixIndex/MediaWiki talk:}} is replaced by a strip marker (a placeholder that tells the parser that more complicated content will later be inserted), which is a unique reference. Compare also {{#ifeq:[[foo]]|[[foo]]|yes|no}}no , because links are also replaced by strip markers. Happymelon 15:41, 30 November 2009 (UTC)[]
Thanks for the information! =) Helder 17:08, 30 November 2009 (UTC)[]
The example above, {{#ifeq:[[foo]]|[[foo]]|yes|no}}no , is incorrect because the evaluated part of it is missing an opening square bracket in the second [foo]]. With the bracket: {{#ifeq:[[foo]]|[[foo]]|yes|no}}yes. Hamilton Abreu 20:47, 29 January 2010 (UTC)[]

#titleparts warningEdit

I added a warning about #titleparts, coming from a very difficult bug I discovered yesterday into a complex template I wrote. The functiong capitalizes the first substring only!--Alex brollo 11:33, 2 January 2010 (UTC)[]

Repeating functionEdit

Is there a repeating Parser Function?--Περίεργος 12:03, 29 January 2010 (UTC)[]

Not in this extension. See Extension:Loops and Extension:LoopFunctions. Splarka 09:21, 30 January 2010 (UTC)[]

Using tabs and newlines in the string searching functionsEdit

I have a string something like "a a[ tab ]b" where "[ tab ]" represents the tab character. I would like to find the position within the string of "a[ tab ]". Unfortunately, the #pos function seems to strip the tab from the search term, giving 0 instead of 2. Here's what I've tried:

{{#pos:a a	b|a	}}
{{#pos:a a	b|a{{1x|	}}}}

Unfortunately, all of these find the first and not the second a. I'd also like to know how to do this with a newline instead of a tab. Thanks. Eric304 08:50, 7 February 2010 (UTC)[]

Whitespace not strippingEdit

I'm not entirely certain my problem is related to this extension, but it started when I was editing a newly template, adding the #switch function of this extension to it and is affecting other templates, also calling the switch function. I had created a new template in which, within the results of each possible variable for the #switch function, I had invoked "nowiki" tags around an area of text. Since then, whitespace is not being stripped from any of my templates using the #switch function, resulting in some undesirable formatting. on the pages using those templates. The first thing I tried doing was replacing all the files for this extension with fresh copies, but that didn't work. After reading about whitespace and "nowiki" tags at the bottom of this hep page, I tried to undo the changes to the template, but when that had no effect, I deleted the template from the table in PHPmyAdmin. Still there is no effect. The only way it seems to restore the formatting on the pages calling the other extensions is to manually remove all the excess whitespace from the templates, which I tried and succeeded with one, but is not desirable as it makes the template difficult to interpret when I have to go back and edit these templates down the road. Does anyone know how to restore the automatic whitespace stripping functionality? --Ds093 14:52, 21 February 2010 (UTC)[]

I have a similar issue with variables on the top of a page in a wiki;
{{#vardefine:CC1|background:#CB0000}} <!-- First Character Menu Color -->
{{#vardefine:CC8|background:#000000}} <!-- 8th Character Menu Color -->
{{#vardefine:CC9|background:#000000}} <!-- This Character's Menu Color -->
{{#vardefine:charname|John Carter}}
* Goal 1 
* Goal 2 
* Goal 3}}

These variables seem to cause white space at the top of my page and the only way to rid myself of it is to set the style margin into negative values. (such as: style="margin-top:-200px;) I hope that helps. I am still looking for another solution.

The question is a bit off-topic here, but it is natural that newlines between calls give blank lines. You can remove them, or put them in comments like this:
{{#vardefine:CC1|background:#CB0000}}<!-- First Character Menu Color 
Patrick1 (talk) 11:59, 4 March 2012 (UTC)[]

#titleparts with PAGENAMEEdit

i tried {{#titleparts:{{PAGENAME}}|1}} to get only the first title part of the page, but it somehow didn't work out. does anyone know why?

You probably don't have subpages enabled in the namespace you're trying to use the function in. Happymelon 23:00, 1 March 2010 (UTC)[]

Switch defaultEdit

Guys, I think the implied default is broken. I had to use the explicit "#default". Check it out, in case I'm right. --JokerXtreme 12:32, 4 March 2010 (UTC)[]

Works for me. I bet your implied default contains an equals sign. You must use "#default" if the implied default contains an equals sign, as this is normal behavior (the first equals is always the delimiter). Splarka 08:06, 5 March 2010 (UTC)[]
I think that the documentation should be updated to reflect the difference between the two default variants. I will leave this to others as I'm too frightened to even think about modifying this page. Neil Smithline (talk) 21:53, 17 February 2013 (UTC)[]
I always use #default= regardless because it makes it easier for myself a week up the road and other editors to see what's what. Also, we use {{=}} and {{!}} any time we are inside of any magic word, parser function, string function, etc... It's just safer. -- ShoeMaker   ( Contributions Message )   14:12, 18 February 2013 (UTC)[]


Is there a way to convert a page name to its name without the namespace? For example:

Category:Extensions                      ---->    Extensions
Help talk:Extension:ParserFunctions      ---->    Extension:ParserFunctions

Unfortunately, "#denamespace" isn't an actual function, so I was wondering if there were ways to do this. Regards, Arbitrarily0 (talk) 00:51, 6 March 2010 (UTC)[]

Please refer to Help:Magic words#Page names. Hamilton Abreu 23:25, 8 March 2010 (UTC)[]
Ah, thanks! I didn't think of using this. For those of whom it interests, {{BASEPAGENAME}} can be used to do this. For example {{BASEPAGENAME:Help talk:Extension:ParserFunctions}} yields Extension:ParserFunctions. Cheers, Arbitrarily0 (talk) 16:28, 9 March 2010 (UTC)[]

#time utc offset bugEdit

  • {{#time:Y-m-d H:i:s|2010-03-11T13:30:00+00:00}} result 2010-03-11 13:30:00
  • {{#time:Y-m-d H:i:s|2010-03-11T13:30:00+02:00}} result 2010-03-11 13:30:00

TimeCurrency 18:28, 12 March 2010 (UTC)[]


is there something that would split a number up. link if i had 1923 and make it 1, 9, 2, 3 or something? Gman124 20:27, 16 March 2010 (UTC)[]

Use "y" to get 23. For everything else, there's Extension:StringFunctions. :) --Church of emacs talk · contrib 20:31, 16 March 2010 (UTC)[]
ok thank you.—The preceding unsigned comment was added by Gman124 (talkcontribs) . Please sign your posts with ~~~~!
See also m:Template:Digit.--Patrick 09:59, 12 September 2010 (UTC)[]

new sectionEdit

when i use these functions on my language wiki, the time always comes in the my language's number form so these always mess up. So, is there a way to make the time come in english numbers or make these or make these functions right?

like for the following:

{{#expr:{{{year|{{CURRENTYEAR}}}}}-1}} it should give 2020

but on my wiki it gives an error because {{CURRENTYEAR}} giving ੨੦੧੦ as year value so get error like

Expression error: Unrecognized punctuation character "੨".

so is the expr thing expecting 2010 instead? and how would that be fixed. so that it takes the value in my language. or is there a way to turn number from one lagunage version to another? Gman124 21:13, 16 March 2010 (UTC)[]

Check UsernameEdit

Is there a way (a magic word maybe?) to make an if-function that checks the username? Like: if username=thisname show that.

Yes, it's possible to display something according to the last page editor, with {{#ifeq:{{REVISIONUSER}}|JackPotte|Validated|Not validated}} (Not validated), but for more you'll need JavaScript. JackPotte 18:40, 11 May 2010 (UTC)[]

titleparts misinterprets underscoresEdit

{{#titleparts:foo/foo/bar_baz||3}} = bar baz, but it should be bar_baz. This is buggy behaviour when handling with URLs. A fix requires ugly double replacing. --Subfader 13:50, 18 May 2010 (UTC)[]

Would using:
{{urlencode:{{#titleparts:foo/foo/bar_baz||3}}}} = bar+baz
{{anchorencode:{{#titleparts:foo/foo/bar_baz||3}}}} = bar_baz
depending on where in the url you're going to place it, be of any help? Hamilton Abreu 15:06, 18 May 2010 (UTC)[]
I know how to fix it, I just wanted to report it. Dunno if this is intended behaviour tho. --Subfader 12:21, 19 May 2010 (UTC)[]

Another bug: {{#titleparts:foo/bar_||2}} = bar, but it should be bar_. I also know how to fix this but it's just too much of "smart" behaviour :( --Subfader 23:13, 19 May 2010 (UTC)[]

Ok, I see. But reporting it here will yield no results. Please report all MediaWiki bugs in bugzilla. Hamilton Abreu 01:42, 20 May 2010 (UTC)[]
Done. I wasn't sure if all this is intended behaviour tho. --Subfader 12:11, 20 May 2010 (UTC)[]
To be honest, neither am I. Hamilton Abreu 13:59, 20 May 2010 (UTC)[]

switch Foo & Bar!=...Edit

I want to use #switch for page names, but it doesn't work for me when the title uses & (and !) ([[:Category:Foo & Bar!]] in this case):

|Foo & Bar!=...

I tried using |Foo {{&}} Bar{{!}}=Bar, but that doesn't do the trick either. Anyone knows a workaround? It works with {{PAGENAMEE}} and Foo_%26_Bar! but actually I want to keep using {{PAGENAME}}. --Subfader 17:28, 5 June 2010 (UTC)[]

for & " ' you have to use &amp; &quot; &#39;. These are (currently) the only three characters allowed in titles that need to be escaped for XML/html parsing. A quick way to see the raw comparison is to use Special:ExpandTemplates which gives you the 'result' pre-rendering, eg here. Splarka 07:29, 6 June 2010 (UTC)[]
Aaah. Thanks for enlighting me :) --Subfader 20:02, 6 June 2010 (UTC)[]

using #time in other languagesEdit

I tried to use #time word for tamil but its throwing error. {{PAGENAME}} gives something like ஜூன் 7 (=June 7) passing {{#time|ஜூன் 7}} throws error. How can i achieve it? thanks -Mahir78 07:09, 13 June 2010 (UTC)[]

#time limitEdit

There seems to be a limit on the number of occurrences of #time in a single wiki page. This was observed on the Wikipedia page w:en:List_of_oil_spills (see the changes in this difference:

The page contains a huge sortable table of dates, using the {{dts}} template, which was using #time to help parse its input parameters (in the form yyyy-mm-dd). After the table grew to a certain size, we started seeing "Expression error: Unexpected < operator" cropping up in {{cite}} templates down in the reference section. (This error wasn't very helpful, so we couldn't figure it out.) Eventually the table grew big enough that we got a "Error: too many #time calls" in one cell, which was more helpful. This enabled us to fix the problem by changing the {{dts}} input parameters to the form yyyy|mm|dd, which doesn't use #time.

I don't know why there's a limit on #time, but I suggest discovering the source of the limitation and posting it on this ParserFunctions page, to help others who might encounter this problem.

(Wikipedia user: Johnson487682) 14:28, 15 June 2010 (UTC)[]

Done.--Patrick 10:04, 12 September 2010 (UTC)[]
For future googlers, if you need to increase the 6000 char limit so you can use #time more, update the limit of 6000 in the parserfunctions source after understanding what that implies. - Lbillett (talk) 12:51, 7 October 2020 (UTC)[]

Understanding this page for non-computer programmersEdit

In my edits, I have tried to address what this I feel this page needs:

  1. Real life examples. {{#switch: baz | foo = Foo | baz = Baz | Bar }} → Baz is too complex, and is not as good as real life examples.
  2. Explanation of the practical uses of these parsers. What can be done with these parsers?

I added [1] to the switch section in an attempt to make this page easier to understand. Adamtheclown 17:14, 1 July 2010 (UTC)[]

At the very least, such examples shouldn't be enwiki-centric, because not so many people in the world know what the hell infobox is. Max Semenik 17:23, 1 July 2010 (UTC)[]
Hi Adamtheclown. I understand you put a lot of work into creating this material and recognized so in the initial rollback comment. Your continued contribution to improve the documentation is welcome, but I believe this was not the case here. Could you please consider the following:
  • Examples should as simple, clear and concise as possible. Simply put, the examples used are confusing; altogether, they use two templates and three pages to attempt to illustrate a basic use of #switch. It took me several reads just to understand what they are trying to demonstrate. They also require an understanding of templates, template parameters, named template parameters, wikitable formatting and magic words just to read them. None of this helps understand, nor is central, to what the function does.
  • Real life examples go at the bottom. It is illogical to interrupt a description of the function and present to readers three complex examples of its use, before that function has been described.
  • Being in the wrong place and not being simple, clear and concise, these examples actually have the opposite effect to what you intend: they are unhelpful and distract and confuse the reader.
Now, generally I agree with your key points of real life examples and practical uses. But surely you know that if we were to do so for all functions on this page in the manner of these examples, the page would more than duplicate in size and become dense and probably unreadable.
At all times, we're trying to reach a balance between two extremes, those of being clear and of being real, and it's difficult. But if you're gonna fail one way or the other, you should fail in the latter, not in the former. For example, please consider that users usually come here in order to understand a real life example they found elsewhere.
And it's natural that at times different people will have different views on this. But if you understand the points above, you'll surely understand that, for the benefit of the page as a whole, the edit should be rolled back again. However, I will leave it up to you to please do so. Hamilton Abreu 19:13, 1 July 2010 (UTC)[]
Thank you for your comments, is there anyway to make a real life example which is easier to understand? A middle ground between my "confusing" real life examples and {{#switch: baz | foo = Foo | baz = Baz | Bar }} → Baz which to me, is much more confusing.
Imagine yourself being first introduced to parser functions, with little computer programming experience, is the current format descriptive enough to teach you how to learn? For me, the answer was no. I had to go to wikipedia and look for examples, and ask on village pump how to use these functions.
RE: "It is illogical to interrupt a description of the function and present to readers three complex examples of its use, before that function has been described."
By bottom do you mean bottom of the page?
My attempt at improving this page, was simply an attempt, and was not the ideal examples, I just saw the page as being to complex right now. Lets work together to come up with better examples, which makes the page easier to understand. Examples could maybe be collapsed in each section.Adamtheclown 15:12, 2 July 2010 (UTC)[]

Examples of useEdit

How can examples of switch be written more clearly? Feel free to completely start from scratch.


Usually to update the information on a wiki, an editor would have to update manually both pages. This results in information on one page being different on another page. But by using #switch, all template information is kept in one central location.

The page "Fruits" has a list of food in a template. Each one of these food items on the "Fruits" page have their own page, with templates in a different format. So the template on the page "Apple" has the same template information as the page "Fruits".

Coding example
Template:apple Fruit Apple

| type = Northern United States
| color= red
| taste= delicious

|type = {{apple|out=type}}
|color = {{apple|out=color}}
|taste = {{apple|out=taste}}

|type = {{apple|out=type}}
|color = {{apple|out=color}}


(The picture "apple.png")
Northern United States

Northern United States

Adding information from several templates into one template

Switch will also allow an editor to add information from several templates which have the {{#switch:{{{out}}} coding into one template.


For example, if an editor editing the page "Fruit" wanted to add information in one section from:

  1. "Template:apple" (type: Northern United States) and
  2. "Template:grapes" (color: purple)

...and both of these templates used {{#switch:{{{out}}}, the editor could type:

Coding Result

|type = {{apple|out=type}}
|color = {{grapes|out=color}}

(The picture "apple.png")

Northern United States

Pages with the same name as the template

If the page has the same name as the template, the editor can use {{PAGENAME}}


In the example of template:apple, an editor could add the following to the "apple" page (See m:Help:Magic words for more details):

Coding on "Apple" Result

|type = {{{{PAGENAME|out=type}}
|color = {{PAGENAME|out=color}}

Northern United States


Return to "Extension:ParserFunctions/2010" page.