Help talk:ParserFunctions

From Meta

(Redirected from Talk:ParserFunctions)
Jump to: navigation, search

Archives: /Archive1

Contents

[edit] Bugs

Some known bugs (not necessarily limited to parser functions) are mentioned on the subject page, see also:
  1. substall 2777 = Optional substitution,
  2. corrupted defaults 5678 = ParserFunctions/5678,
  3. DIV and MOD 6068 = Help talk:Calculation,
  4. incorrect MOD results 6356 = ParserFunctions/MOD10000.

[edit] #time

I'm not sure why this is happening:

If I enter {{ #time: d M Y | 2007-10-08 }} I get 07 Oct 2007; I'm always one day behind, yet {{ #time: c | 2007-10-08 }} gives the correct date (2007-10-08T00:00:00+01:00). Anyone any clues as to what's happening here?

Sushiguru 21:02, 8 October 2007 (UTC)


I found a workaround for this issue:

When I add a timezone statement as described in help page like {{ #time: d M Y | 20080425 -0000}} the date is displayed correctly. In my case the timezone setting have to be negative because a positive setting will show the date one day behind. With a negative timezone setting the day is displayed correctly. 141.30.103.214 07:36, 28 April 2008 (UTC)

[edit] #Time

I am tring to use the #Time statement {{ #time: Y }} but I do see any result. The statement is not executed. The statements {{#expr: (30 + 7) * 7 }} and {{ #if: 1=1 | Yes | No }} are exectuted well, so the installation of ParserFunction should be correct. What can be the problem? --Bernard 10:15, 28 January 2007 (UTC)

[edit] #time language

  • #time do not work with russian, but work with english.--78.106.97.53 18:10, 1 March 2008 (UTC)
    • for example:
{{ #time: U | 4 March 2007 }} gives : 1172966400 , its ok.
But {{ #time: U | 4 марта 2007 }} gives : Error: invalid time - it is not right :( Berserkerus 16:08, 31 March 2008 (UTC)

[edit] HTML Rendering Issues

I'm sure this is not specific to ParserFunctions, but others MUST have encountered this, the table tags that are conditionally added in a template (the stuff in the #if statements) is being rendered awkwardly. Instead of:

<tr><td colspan="2" align="center">

I am instead getting:

&lt;tr&gt;&lt;td colspan="2" align="center"&gt;

Does anyone know how to prevent this from happening? I just need to figure out where and why those characters are being substituted.

See below Talk:ParserFunctions#Solution_to_Tables_Problems --Dr DBW 21:23, 5 December 2006 (UTC)

[edit] Further HTML (Tables) Problems

I have been trying to use the #if expression within tables, in a similar manner to the Template:Taxobox on the Wikipedia. Using the wikitext for tables, with the pipe character simple doesn't work how I want it to, even when using the exclaimation mark template.

Using the exclaimation marks works, correctly displaying a row if a parameter is displayed, and leaving the row out if that parameter isn't. The problem is that the text has a different format to the rest of the text on the page and it does not wrap within a cell, forcing the table to go to the width to accommodate the length of the line within the cell. Any ideas on solution around that or what is causing it to do that? Can't see with the Wikipedia code what is causing it for them to display correctly.

The other alternative I was trying out was to simple use HTML coding for the table instead. And that fails totally to work when used in conjunction with the #if expression. Any HTML code that is contained within the #if is not rendered / translated correctly, it is simply left as text and you see . I have been looking around for awhile now in as many different places as I could, and can't see any mention why this happens and the possible solution to that issue. Appears that anything within the #if is considered as text only, not as any code / formatting instructions. This is also pointed out on these pages that I have manage to find in further searching:

--Dr DBW 21:01, 5 December 2006 (UTC)

[edit] Solution to Tables Problems

Yah, think I have found the solution. New it would be out there somewhere. Missed the fact that there are achives of this discussion page, and it is on there. See here:

The solution is to enable $wgUseTidy. This is actually mentioned on the content page here for ParserFunctions:

  • ParserFunctions#Tables. I am not 100% sure if it is part of the mediawiki package or not, or whether it is something that needs to be installed. Anyway, off to try that out and see if it works --Dr DBW 21:11, 5 December 2006 (UTC)

YES this solution works and there is nothing additional to install. Simply add $wgUseTidy = true; to your LocalSettings.php file. --Dr DBW 21:22, 5 December 2006 (UTC)

OK, knew there would be a reason that it is mentioned on the ParserFunctions#Tables page that it is a last resort. Everything seems to work fine after I installed it and couldn't find any issues. I got a note from another user, saying they tried it and it messed up their main page. I hadn't seen that, are using the CologneBlue skin. Checked the Main Page of my wiki today, and the coding is messed up. Effected is the images generated by the RandomImage extension. Some of the opening and closing tags of the code is generated as & gt; and then things fail. The code was working fine before enabling $wgUseTidy. --Dr DBW 20:57, 6 December 2006 (UTC)
Have now worked out that it is a problem with displaying images, all images. Not just the RandomImage extension. So now all images within my wiki don't display correctly. I don't really know where I should be posting this problem now, so I have put full details on the MediaWiki site on the discussion page for $wgUseTidy: here: Manual talk:$wgUseTidy Any suggestions, am I putting this in the best location? --Dr DBW 00:02, 8 December 2006 (UTC)
Cell contents
I have now worked out the Tidy only messes up the code generated by the gallery function or RandomImage extension. All other images displayed on pages is fine. Appears that those two components generate something that Tidy doesn't know how to handle correctly.--Dr DBW 22:21, 19 December 2006 (UTC)
I am still having problems with having Tidy activated and messing up some of the code. Anyone have any suggestions on what can do, who can ask, any sense of what should be trying, who I should be bugging, anything? ;-) --Dr DBW 23:00, 8 February 2007 (UTC) Also appears that my indentations aren't working here, strange ....
Upgraded to 1.9.3 and the problem still occurs --Dr DBW 23:47, 27 February 2007 (UTC)
The issue with $UseTidy has been solved. See [[1]], appears that Tidy requires a configuration file (default on server either isn't valid or not present). --Dr DBW 03:43, 13 March 2007 (UTC)

[edit] MediaWiki rendering versus Tidy

a‎ ‎ ‎ ‎ ‎ ‎z

Gangleri · Th · T 04:19, 15 April 2006 (UTC)
Gangleri, I know this behaviour very well. This has nothing to do with ParserFunctions. This is current general behaviour of template inclusion. I've been circumventing the resulting newline by arranging it like this:
a{{ #ifeq: comparison text 1 | comparison text 2 | equal text | }}{{
    #ifeq: comparison text 1 | comparison text 2 | equal text | }}{{ 
    #ifeq: comparison text 1 | comparison text 2 | equal text | }}{{
    #ifeq: comparison text 1 | comparison text 2 | equal text | }}{{
    #ifeq: comparison text 1 | comparison text 2 | equal text | }}{{
    #ifeq: comparison text 1 | comparison text 2 | equal text | }}z
I write this just to report how I solve that problem in my everyday wikiwork.
Another very common problem that has occured quite often ist that when people add a <noinclude> to templates like en:template:cite web they tend do add that on a new line, which produces a new line in the output of the inclusion. This happens a lot when people add interwiki links to templates. This is especially a pain when done wrong on a high use template. And an even greater pain when such a template is protected and this fault is done by an admin and I can't fix it due to the protection of the template (but that is a wiki-politics question which has nothing to do with the dev side of the wiki world). However, I'm not sure if the adding of the \ will significantly improve the situation as this is another construct from the "programmers" world and sure difficult to understand for the non-programmer editors.
I just write here about my experience. And I am not sure about what to do to improve the situation. As for the \ if there are no solid arguments against it, it might be help.
However, I even suspect that part of the fear that editors feel when they start editing these kind of themplates is caused by this "surprising" newline behaviour. I have already asked myself if this shouldn't simply trimmed away from the output. But before doing this, some thorough thinking and investigation would be in order. But it might help lower the barrier for editing templates containing conditional code significantly. If anybody can point me to a case were trimming away the newlines would hurt, please let me know. --Ligulem 08:04, 15 April 2006 (UTC)
Thanks Ligulem! It looks quite practical in LTR and a simple RTL example looks like this:
א{{ #ifeq: {{{יאָר}}} | 2006 | אַקטועל | }}ת


א{{ #ifeq: {{{יאָר}}} | 2006 | אַקטועל | }}{{
    #ifeq: {{{יאָר}}} | 2006 | אַקטועל | }}{{
    #ifeq: {{{יאָר}}} | 2006 | אַקטועל | }}{{
    #ifeq: {{{יאָר}}} | 2006 | אַקטועל | }}ת
The longer the statements are the more time you need to write / read / understand it. Gangleri · Th · T 12:10, 15 April 2006 (UTC)
about 'noinclude' and 'includeonly': Again it is a metter of practice. Personaly I feel that
<noinclude>wikitext noinclude_1
wikitext noinclude_1_continued</noinclude>wikitext common_part
wikitext common_part_continued<includeonly>wikitext includeonly
wikitext includeonly_continued</includeonly><noinclude>wikitext noinclude_2
wikitext noinclude_2_continued</noinclude>
could be / should be written as
<noinclude>\
wikitext noinclude_1
wikitext noinclude_1_continued\
</noinclude>\
wikitext common_part
wikitext common_part_continued\
<includeonly>\
wikitext includeonly
wikitext includeonly_continued\
</includeonly>\
<noinclude>\
wikitext noinclude_2
wikitext noinclude_2_continued\
</noinclude>
It is easier to read, mark / copy the blocks and would be much easier to edit if both LTR and RTL characters are used. Gangleri · Th · T 11:51, 15 April 2006 (UTC)

You can always use blockquote-tag, inside such tag, newlines are ignored (but then you have to add newlines by your self and hange thew margin to inherit etc.... 81.235.249.75 20:29, 15 April 2006 (UTC)

[edit] Problems with #time

I've just installed the extension, and everything works fine except #time functions. If I include any of these, I just get an entirely blank page returned. I'm using Mediawiki version 1.6.8. Has anyone else had this problem? 161.72.11.196 16:33, 25 October 2006 (UTC)

Nobody answered you, but I've just hit the same issue, and worked round it. You need Tim Starling's fix (see #New features, 1.7 compatibility above), including the third file which he didn't mention. --ColinFine 17:00, 15 January 2007 (UTC)

[edit] ifexist created WantedPages in MediaWiki 1.10

I'm currently busy finding how and why there are WantedPages created with page names I am probing with "ifexist". This occured after having MediaWiki 1.10alpha installed, also on 1.10 (final). Problem to see here.

For episode links, there can be three types of writing because of disambiguation: "Episode-Name (Episode)", "Episode-Name (SER)" (SER can be DS9, TNG, ENT,...), or plain "Episode-Name". Even without linking to the episode, there are Wanted Pages lists created for all kinds of writing which renders this list to be useless. This is where the magic is: Template:EpLink. Anyone with similar problems or solutions? -- Florian K 08:25, 7 June 2007 (UTC)

I made an addition to Help:ParserFunctions#Code_execution. It also gives a workaround.--Patrick 09:36, 7 June 2007 (UTC)
this problem still exists as of today (2007-11-18). the double #if "trick" in Help:ParserFunctions#Code_execution does not work for this, only for template or category calls, because in this case the "link" is being added to the parser link list by the ifexist function on a lower level.
i've traced it down to the line $parser->mOutput->addLink( $title, $id ); that was added by tstarling in revision 19892 on Mon Feb 12 10:24:23 2007 UTC with the reason Register a link on #ifexist. Otherwise this breaks cache coherency..
i can find no reasoning for this change. all it is doing is checking if the target exists, and outputting one of two user supplied text blocks. it is not making a link to target, nor does it display a link to target anywhere in the scope of this functions code so why does the target need to be added to the link list?
--Uberfuzzy 10:05, 18 November 2007 (UTC)
Have you tried removing that bit o' code and seeing what happens? Does anything break? —Sledged (talk) 19:17, 19 November 2007 (UTC)

[edit] Installed, but #if still not recognized?

Hi, I've tried installing ParserFunctions at my wiki, but when I try a template which makes use of #if, it doesn't seem to be responding properly. Anyone knows what could be the problem? According to http://rommedahlen.dk/wiki/index.php?title=Speciel:Version Speciel:Version] it is installed. --Lhademmor 15:59, 23 February 2007 (UTC)

What if you don't use a template but just on a page? --Dr DBW 03:03, 27 February 2007 (UTC)
I'm having the same problem as Lhademmor on my Wiki. The #if function is used a lot in the Infoboxes, which are very useful; has anyone figured out why sometimes this does this? Is an additional extension or something needed?--Azurite 09:14, 29 July 2007 (UTC)

Exactly the same problem here on MediaWiki version 1.11. Downloaded the ParserFunction pages to the specified folder, amended LocalSettings.php, but Special:Version still says nothing about ParserFunctions being installed. Main purpose of installing is to get #if working. Am I missing something obvious? 137.191.225.18 14:50, 10 December 2007 (UTC)

Same problem again. I have MediaWiki 1.6. I have php4 and downloaded the older versions of the files for ParserFunctions. The infobox templates I had copied into my wiki show up as a complete mess along with a bunch of #if references. They were no affected by installing ParserFunctions.Corsulian 06:57, 29 December 2007 (UTC)

[edit] Using #if or #ifexist...not to sure...

I am wondering what to use, if applicble to use (I've seen it used on Memory Alpha...). I use the code below for a character template, and want to know what would i use, and how I would use it (I don't seem to understand how it is written, and example here would give me a better idea). I've tried to adapt what I saw on Memory Alpha, but it didn't seem to work, so, what I'd like to know is...how do I do this?

<includeonly>{| align="right" border="1"
|-
| colspan="2" align="center" | '''{{{name}}}'''<br/>[[Image:{{{image1name}}}|{{{image1size}}}px]]
|-
| '''Name:'''
| {{{name}}}
|-
| '''Affiliation:'''
| {{{affiliation}}}
|-
| '''Rank:'''
| {{{rank}}}
|-
| '''Homeworld:'''
| {{{homeworld}}}
|-
| '''Species:'''
| {{{species}}}
|-
| '''Gender:'''
| {{{gender}}}
|-
| '''Date of Birth:'''
| {{{dateofbirth}}}
|-
| '''Age:'''
| {{{age}}}
|-
| '''Height:'''
| {{{height}}}
|-
| '''Weight:'''
| {{{weight}}}
|-
| '''Status:'''
| {{{status}}} <small>({{{statusyear}}})</small>
|}</includeonly>

--CaptainBrooks 23:51, 19 August 2007 (UTC)

If you're asking how to hide empty values, try this:
| '''Name:''' || {{#if:{{{name|}}}|{{{name}}}|}}
(or put whatever after the last |, like a question mark--?) —Eep² 02:26, 20 August 2007 (UTC)

This doesn't work, I copies the code and placed it like you did, and I get...."{{#if:" in the area that would be filled in if I filled it in, and a new column is made, where I get "}}" Any ideas what I could be doing wrong? Man, my fustration right now is through the roof.--CaptainBrooks 02:51, 20 August 2007 (UTC)

Perhaps you try to use it on a wiki where ParserFunctions is not installed.--Patrick (talk) 08:48, 20 August 2007 (UTC)

How do you tell if ParserFunctions arer installed or not? That makes a differnence on what will work or not?--CaptainBrooks 21:14, 20 August 2007 (UTC)

Special:Version.--Patrick (talk) 23:54, 20 August 2007 (UTC)

Apparently, there are no extensions at all, all I see on there is "This wiki is powered by MediaWiki, copyright (C) 2001-2006

Verbiage removed Noel (talk) 21:04, 13 March 2008 (UTC)

   * MediaWiki: 1.8.4
   * PHP: 5.1.6 (cgi)
   * MySQL: 4.1.22-standard"

Does that mean that I don't have ParserFunctions installed?--CaptainBrooks 17:36, 21 August 2007 (UTC)

Alright, I didn't even had paserfunctions installed apparently. Long story short, I installed the stuff, set the permissions and... it still does not work. Any ideas? --CaptainBrooks 02:11, 15 September 2007 (UTC)

[edit] installs, but doesn't parse

Greetings I've read everything here, and then some. I just can't get #switch to work. I'm using

  • MediaWiki: 1.10.1
  • PHP: 5.1.6 (apache2handler)
  • MySQL: 5.0.27

on special:version it says it's installed, and I've made sure I'm using the current versions, I even tried the old versions, the wiki just won't do anything with it. Any ideas would be wonderfully appreciated. ThePoet444 14:51, 21 August 2007 (UTC)

Hi, please try asking that over at MediaWiki's official website, or on #mediawiki on IRC. Thunderhead 11:52, 21 August 2007 (UTC)
Searching Mediawiki leads me back here, so I'm stuck back at phase one. It seems there's something in this program that doesn't like the latest version of the wiki software, and I'm curious as to what. It's also bad form to go to the mediawiki site and say "hey, this third party extension doesn't work, can you help?" They'll point me back here. This talk page and the main page is the home of these functions, or so everything searching tells me. Perhaps I missed something? ThePoet444 14:51, 21 August 2007 (UTC)
Having done more research, it seems Mediawiki has not moved this function over yet, so asking there on a page that doesn't exist yet is also silly. being an amateur coder, I haven't been much help trying to track this error down, but if I had to guess I would say that Parser.php isn't recognizing the ParserFunctions file, despite the fact it is installed as Special:Versions sees it. Any help would be wonderful. ThePoet444 10:36, 25 August 2007 (UTC)
Can you give a markup/output example of what it's doing? —Sledged (talk) 02:55, 4 October 2007 (UTC)

[edit] Unable to Install

[edit] Can't install..

Just in case this answers any of the problems above {or below - JNC} ....
... if everything seems to go okay but Special:Version does not register the installation, make sure you are using the correct version. For Mediawiki_1.11.0 and above you need the trunk version http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/ParserFunctions/

[edit] Cannot instal the extension

Hello,

I have a problem with the ParserFunctions extension. My MediaWiki runs on version 1.7.1 with Php 5.0 and I used the standard method to install the extension: Copy Expr.php and ParserFunctions.php in the extension directoy and write the command: require_once( "$IP/extensions/ParserFunctions/ParserFunctions.php" ); in LocalSettings.php

Unfortunately, when I open my wiki, lots of error messages appear and it doesn't work any more! How can I do to install correctly the Parser Functions? Without them, it is very difficult to build good templates...

Thank you for your help.

It sounds like you've installed it correctly, what are the errors that come up? does it show up in Special:Version?
You wrote: "Copy Expr.php and ParserFunctions.php in the extension directoy" Did you create a ParserFunctions subdirectory to put them in? --217.230.63.66 10:10, 8 June 2007 (UTC)

[edit] Unable To Install 7

After I install ParserFunctions my wiki shows as a blank page in both IE and Firefox. What I did:

  1. Download Expr.php and ParserFunctions.php
  2. Put both into extensions/ParserFunctions
  3. Add to LocalSettings (at the bottom, directly above "?>"):
    require_once( "extensions/ParserFunctions/ParserFunctions.php" );

I'm running MediaWiki: 1.9.3, PHP: 5.2.1 (apache2handler), MySQL: 5.0.37-community-nt-log. If I comment out the a.m. line in LocalSettings the wiki works fine! I've doublechecked spelling of both LocalSettings and file names/path. I'm clueless. The only thing that is "special" about my setup is the fact that I'm running MediaWiki on a Windows Vista machine. Does that make any difference for ParserFunctions.php? Any help would be appreciated. Tetris L --217.230.63.66 10:21, 8 June 2007 (UTC)

I just tried the php<5 (older versions of php prior to php5) version of Expr.php and ParserFunctions.php and it works fine with these, so my install setup really is okay. It must have to do with the latest version not being compatible with my system. Tetris L --217.230.63.66 10:31, 8 June 2007 (UTC)
Further investigation: I can use the php5 version of Expr.php, and it'll still work, but I have to use the php<5 version of ParserFunctions.php. Weird. I'm definetly running php5. Tetris L --217.230.63.66 10:36, 8 June 2007 (UTC)
Note: Registered. 217.230.63.66 is me. --Tetris L 11:18, 8 June 2007 (UTC)

[edit] Unable to Install 8

I tried just a basic install, but instead of working correctly, every page on my wiki now puts out:

array( 0, 'expr' ), 'if' => array( 0, 'if' ), 'ifeq' => array( 0, 'ifeq' ), 'ifexpr' => array( 0, 'ifexpr' ), 'iferror' => array( 0, 'iferror' ), 'switch' => array( 0, 'switch' ), 'default' => array( 0, '#default' ), 'ifexist' => array( 0, 'ifexist' ), 'time' => array( 0, 'time' ), 'timel' => array( 0, 'timel' ), 'rel2abs' => array( 0, 'rel2abs' ), 'titleparts' => array( 0, 'titleparts' ), ); /** * Farsi-Persian */ $words['fa'] = array( 'expr' => array( 0, 'حساب', 'expr' ), 'if' => array( 0, 'اگر', 'if' ), 'ifeq' => array( 0, 'اگرمساوی', 'ifeq' ), 'ifexpr' => array( 0, 'اگرحساب', 'ifexpr' ), 'switch' => array( 0, 'گزینه', 'switch' ), 'default' => array( 0, '#پیش‌فرض', '#default' ), 'ifexist' => array( 0, 'اگرموجود', 'ifexist' ), 'time' => array( 0, 'زمان', 'time' ), 'rel2abs' => array( 0, 'نسبی‌به‌مطلق', 'rel2abs' ), ); /** * Hebrew */ $words['he'] = array( 'expr' => array( 0, 'חשב', 'expr' ), 'if' => array( 0, 'תנאי', 'if' ), 'ifeq' => array( 0, 'שווה', 'ifeq' ), 'ifexpr' => array( 0, 'חשב תנאי', 'ifexpr' ), 'iferror' => array( 0, 'תנאי שגיאה', 'iferror' ), 'switch' => array( 0, 'בחר', 'switch' ), 'default' => array( 0, '#ברירת מחדל', '#default' ), 'ifexist' => array( 0, 'קיים', 'ifexist' ), 'time' => array( 0, 'זמן', 'time' ), 'timel' => array( 0, 'זמןמ', 'timel' ), 'rel2abs' => array( 0, 'יחסי למוחלט', 'rel2abs' ), 'titleparts' => array( 0, 'חלק בכותרת', 'titleparts' ), ); /** * Indonesian */ $words['id'] = array( 'expr' => array( 0, 'hitung', 'expr' ), 'if' => array( 0, 'jika', 'if' ), 'ifeq' => array( 0, 'jikasama', 'ifeq' ), 'ifexpr' => array( 0, 'jikahitung', 'ifexpr' ), 'switch' => array( 0, 'pilih', 'switch' ), 'default' => array( 0, '#baku', '#default' ), 'ifexist' => array( 0, 'jikaada', 'ifexist' ), 'time' => array( 0, 'waktu', 'time' ), 'rel2abs' => array( 0, 'rel2abs' ), 'titleparts' => array( 0, 'bagianjudul', 'titleparts' ), ); # English is used as a fallback, and the English synonyms are # used if a translation has not been provided for a given word return ( $lang == 'en' || !isset( $words[$lang] ) ) ? $words['en'] : array_merge( $words['en'], $words[$lang] ); } 戼⁲㸯㰊㹢慆慴牥潲㱲戯㨾†慃汬琠湵敤楦敮⁤畦据楴湯†晥慰獲牥畦据楴湯睳牯獤⤨椠戼䔾尺慸灭屰瑨潤獣硜浡灰浜摥慩楷楫敜瑸湥楳湯屳慐獲牥畆据楴湯屳慐獲牥畆据楴湯⹳桰㱰戯‾湯氠湩⁥戼㔾㌱⼼㹢戼⁲㸯

Could somebody help! I just installed version 1.11 last week and everything seemed to be working fine. We're running: MediaWiki: 1.11.0, PHP: 5.2.5 (apache2handler), & MySQL: 5.0.51. Mountiandew1986 23:32, 22 January 2008 (UTC)

[edit] Unable to Install 9

Recently upgraded from an older version of the ParserFunctions to the latest trunk and for some reason the functions stopped working even through the extension is listed as being installed in the version special page. Using the latest stable MW, 1.12.

By not working I mean every parser I try to use comes out unprocessed. Any ideas? -- Tufloc

[edit] Requests and proposals

[edit] MOD and DIV

Please comment mediazilla:6068 if I got it wrong, for a copy or discussion here see Help talk:Calculation. -- Omniplex (w:t) 03:06, 24 May 2006 (UTC)

Patch has been created and is awaiting commitment. — Ambush Commander(Talk) 23:24, 16 June 2006 (UTC)
Please look at Mediazilla for additional comments about your proposed patch (which breaks the compatibility). I propose introducing new operators instead, and leave "round" and "div" unchanged. Also I propose making the new "trunc" operator binary (like it is for "round"). See formula details and the rationale behind this in mediazilla:6068. When #expr were introduced, div and mod operators were really poorly designed, taking the existing poor design of the corresponding operators of PHP. But we must continue to live with that.
Various fixes have been proposed in the PHP development project, but all have been rejected for compatibility reasons with various PHP applications (not only MediaWiki). PHP designers have decided not to fix it, and consistently send people to the PHP supported math module instead. So the best is to stop using PHP's mod and div operators in newer Wiki operators based on functions found of this PHP math module. 86.221.90.101 21:46, 8 November 2006 (UTC)

[edit] Request for string functions

Despite the great #expr function, I think string handling functions are also important and helpful to Wikipedia's editors. After looking into those PHP string functions which are really helpful, I suppose maybe the following are some:

  1. chr
  2. count_chars
  3. ltrim
  4. number_format
  5. ord
  6. rtrim
  7. str_ireplace
  8. str_pad
  9. str_repeat
  10. str_replace
  11. str_shuffle
  12. str_split
  13. str_word_count
  14. strcasecmp
  15. strchr
  16. strcmp
  17. strcoll
  18. strcspn
  19. strip_tags
  20. stripos
  21. stristr
  22. strlen
  23. strpbrk
  24. strpos
  25. strrchr
  26. strrev
  27. strripos
  28. strrpos
  29. strspn
  30. strstr
  31. strtok
  32. strtr
  33. substr_compare
  34. substr_count
  35. substr_replace
  36. substr
  37. trim
  38. ucfirst (implemented)
  39. ucwords
  40. wordwrap

I suppose this won't be a hard job, but just a normal form of function in ParserFunctions.php. If Tim thinks this is too difficult to implement, I just advise Tim to implement a few of them. Only a few will give much convenience for editors. Upssdr 05:47, 15 April 2006 (UTC)

If this is done, I strongly suggest using the ANSI C function names rather than PHPs bastardized names. :P Some of these use ANSI C names, some of them, like strcasecmp, use new names (strcasecmp appears to be identical to ANSI C's stricmp). —Locke Cole • t • c 06:56, 15 April 2006 (UTC)
Ternary operator, C names, string operators, etc.: If we really want slang let's add it, not reinvent it. -- Omniplex (w:t) 00:12, 16 April 2006 (UTC)
I don't follow: we're not reinventing anything, just suggesting functionality be exposed. —Locke Cole • t • c 02:04, 16 April 2006 (UTC)
Why I suggest these PHP functions is because they are easy to develop. No matter whether they're bastardized or ugly or disliked by you, they're always easy for Tim. Upssdr 03:40, 16 April 2006 (UTC) Also MediaWiki is not ANSI C++ compiler. Upssdr
That's nice. That has absolutely nothing to do with what I said. —Locke Cole • t • c 09:07, 16 April 2006 (UTC)
He's referring to the fact that it's not always a clear switch between the PHP behavior and C++ behavior. The worst thing we could do is a name a PHP function C++ style when it actually deviates in behavior. — Ambush Commander(Talk) 06:58, 22 June 2006 (UTC)

I don't intend on implementing any functions which have a worst-case performance of O(N^2) or worse in the input size. Any such function would constitute a DoS vulnerability. This rules out str_replace and friends, str_pad, str_repeat, strspn and friends, and probably others, unless their time and memory usage can be appropriately limited. Since there's no array type, I can't see the point in implementing functions which act on or return arrays, such as count_chars and str_split. -- Tim Starling 10:57, 17 April 2006 (UTC)

OK. Despite the O(n^2) and O(m*n) functions, there are still a few functions which is absolutely O(n) and contribute nothing to DoS vulnerability. Upssdr 05:52, 19 April 2006 (UTC)

[edit] strlen & substr

These are the most important and basic string handling function. Upssdr 05:52, 19 April 2006 (UTC)

I strongly support the addition of these two functions, if nothing else. --Algorithm 23:35, 30 April 2006 (UTC)
I strongly support the addition of these two functions, and nothing else. --Alfakim 16:25, 27 May 2006 (UTC)
One of the See Also entries is to StringFunctions. See that. (SEWilco 00:29, 28 May 2006 (UTC))

There is an easy way to calculate the length of a string with the magic word padright. For example, a template with the folowing contents gives the length of the given string with a maximum of 10 characters:

{{#switch: {{{1}}}
|{{padright:{{{1}}}|10|*}} = 10
|{{padright:{{{1}}}|9 |*}} = 9 
|{{padright:{{{1}}}|8 |*}} = 8 
|{{padright:{{{1}}}|7 |*}} = 7 
|{{padright:{{{1}}}|6 |*}} = 6 
|{{padright:{{{1}}}|5 |*}} = 5 
|{{padright:{{{1}}}|4 |*}} = 4 
|{{padright:{{{1}}}|3 |*}} = 3 
|{{padright:{{{1}}}|2 |*}} = 2 
|{{padright:{{{1}}}|1 |*}} = 1 
}}

JePe 01:49, 20 November 2006 (UTC)

The idea is very good, but there are problems. It fails when fed non-ASCII characters. The following example
{{#switch: inglés
|{{padright:inglés|10|*}} = 10
|{{padright:inglés|9 |*}} = 9 
|{{padright:inglés|8 |*}} = 8 
|{{padright:inglés|7 |*}} = 7 
|{{padright:inglés|6 |*}} = 6 
|{{padright:inglés|5 |*}} = 5 
|{{padright:inglés|4 |*}} = 4 
|{{padright:inglés|3 |*}} = 3 
|{{padright:inglés|2 |*}} = 2 
|{{padright:inglés|1 |*}} = 1 
}}

evaluates to 7 instead of 6.

I suppose this is a bug with padright:, but I know too little about the mechanics behind it to properly report it. Taragui 15:26, 12 December 2006 (UTC)

That is probably because the symbol 'é' is a unicode character, so it's two bytes (to give 65536 possibilities), so the function treats it as two chars instead of 1. Also, I have created en:Template:Strlen based on this method (that will only work when feed ASCII chars. Polonium 17:36, 2 January 2007 (UTC)
I guessed as much. However, I don't think that would be the intended behaviour for padright:, as width is measured in characters, not in bytes. I simply hoped someone more knowledgeable than me on the mechanichs of PHP would file the bug. Faute de mieux, I'll do so myself. Taragui 13:34, 12 January 2007 (UTC)
Are there any objections to installing strlen and substr (native support, not the strlen hack described above). They would be useful and are DOS safe. Please raise any objections to these 2 functions (not other ones) here. Polonium 20:35, 12 January 2007 (UTC)
I support adding these two. I also note that StringFunctions claims that all its members are O(n), and that at least one search-type function would be useful too.--69.79.73.143 17:52, 13 January 2007 (UTC)

[edit] Request: Additional Functions

[edit] Loop Functions

Damnedmage 11:23, 24 June 2006 (UTC)

When I found the parser functions, I fell in love. All that's left, now, is the ability to do repeats. Thus do I request the following parser functions:

#do
#for
#foreach
#loop
#until
#while
#wend
What would you use it for? Wiki is not a programming language! Platonides 21:04, 25 June 2006 (UTC)
Why shouldn't it be? :) #if and #switch make it a pseudo-programming language! I see no reason an extension for these shouldn't be added. Mostly, though, I want to be able to do repeating rows. I do a lot of table-work in my Wiki dealing with tables of 20 rows that often hold specific mathematical information that could be calculated if I could build the table all at once, rather than having to build it one row at a time. :) --Damnedmage 16:47, 7 July 2006 (UTC)
Not to mention if you have a template that puts together a table whose length is dependant on parameters. —Sledged 22:35, 23 October 2006 (UTC)

I've made a template which has input structure like this

{{works
|author =
|work_1 =
|work_2 =
|work_3 =
|work_4 =
|work_5 =
}}

Because of that I support to request for #for parser function. Nein 17:16, 19 November 2006 (UTC)

The big issue with these is puttting the server into a huge loop.  I do support adding a "for" function however. 204.62.68.23 21:18, 16 December 2006 (UTC)
Have made an extension to allow some limited looping functionality, see mw:Extension:LoopFunctions, dunno if it would ever be included into pedia :) AzaToth 02:39, 17 December 2006 (UTC)
Here is a foreach loop. it takes a text, pattern, replacement (from preg family) and input and output separators. it separates the text, then uses preg_replace and then joins it. e.g., {{ #foreach: one,two,three,thirteen| /th(.*)ee/ | [[xx${1}yy]] }} will give one,two,xxryy,xxirtyyn. Ittayd 07:54, 2 January 2007 (UTC)
    public function foreach2Hook(&$parser, $text, $pattern, $replacement, $insep = ',', $outsep = ',' ) {
               $text = trim($text);
               $pattern = trim($pattern);
               $replacement = trim($replacement);
               $insep = trim($insep);
               $outsep = trim($outsep);

               $text = $parser->unstrip($text, $parser->mStripState);
               $localParser = new Parser();
               $output = $localParser->parse($text, $parser->mTitle, $parser->mOptions, false);
               $text = $output->getText();

               #return "got: text=$text,pattern=$pattern,replacement=$replacement,";
               $variables = explode($insep, $text);
               $result = preg_replace($pattern, $replacement, $variables);
               #return "" . $variables[0] . '=>' . $result[0] . "";   
               $result = implode($outsep, $result);
               return $result;
    }

The main problem with any LoopFunction is that it could be used for DOS attacks. For example, a vandal could enter {{#repeat:HAHA|9999999999}} or anything along those lines. The mass repetition of the string "HAHA" would overload and crash the servers. I actually support adding LoopFunctions, but they would have to be limited somehow (maybe a output maximum of 1.2 megabytes could work). Polonium 17:31, 2 January 2007 (UTC)

Template limits already exist, so I so reason why "loop limits" could not be implemented for LoopFunctions. Polonium 20:16, 20 January 2007 (UTC)

[edit] Advanced Math

I want to make templates that do math as part of their rendering. The #expr: function already does some of this, but I have been working for a while on gettign a square root - it hasn't worked very well. I suggest adding the basic scientific calculator functions such as exponentation (squar root simply being an exponent of .5) and trigonometric functions. The loop implementation would be a very inefficient substitute for this. 204.62.68.23 21:18, 16 December 2006 (UTC)

See MathStatFunctions. Polonium 17:33, 2 January 2007 (UTC)
As for a function that finds the square root, I have created a template that finds the square root of a number on en-wiki. See en:Template:Root. Polonium 15:31, 5 January 2007 (UTC)
See also category:recursive conversion templates. I have tried to write one for the ex in wikiversity:en:, but I have encounted the problem that very large numbers are output as exponenets (something like 1234e5). Hillgentleman 15:48, 18 November 2007 (UTC)

[edit] Request: Variables

This is probably needed much more when trying to make an super-inteligent template, which parses the name of a sub-sub-page (e.g. /page/subpage/sub-subpage) and includes other templates/images accoring to what the sub-parts of the entire path are. While doing so I often calculated the same thing again and again. So I came to an idea of storing values in temporary variables. An easy examaple:

 {{#set:a|1}}
 {{#set:b|2}}

 {{#expr: {{#var:a}} + {{#var:b}} }}

Is it possible to implement such support? (considering that a template that uses a specific variable name may be used in a template that uses the same variable name) --jsimlo 10:02, 22 July 2006 (UTC)

Some motivation from real life:

{{#set:first| {{#pos:{{PAGENAME}}|/}} }}
{{#set:second| {{#pos:{{PAGENAME}}|/| {{#expr: {{#var:first}} + 1 }} }} }}
{{#set:third| {{#pos:{{PAGENAME}}|/| {{#expr: {{#var:second}} + 1 }} }} }}

Navigation:
[[{{#sub:{{PAGENAME}}| 0 | {{#var:first}} }}]],
[[{{#sub:{{PAGENAME}}| 0 | {{#var:second}} }}]],
[[{{#sub:{{PAGENAME}}| 0 | {{#var:third}} }}]],

Vs.:

Navigation:
[[{{#sub:{{PAGENAME}}|0|{{#pos:{{PAGENAME}}|/}} }}]],
[[{{#sub:{{PAGENAME}}|0|{{#pos:{{PAGENAME}}|/|{{#expr:{{#pos:{{PAGENAME}}|/}}+1}} }} }}]],
[[{{#sub:{{PAGENAME}}|0|{{#pos:{{PAGENAME}}|/|{{#expr:{{#pos:{{PAGENAME}}|/|{{#expr:{{#pos:{{PAGENAME}}|/}}+1}} }}+1}}

--jsimlo 10:15, 22 July 2006 (UTC)

Try the variables extension. —Sledged 15:46, 24 October 2006 (UTC)

[edit] Request #time-parameter o - ISO-8601 year number

In PHP-date there's a "o" parameter "ISO-8601 year number. This has the same value as Y, except that if the ISO week number (W) belongs to the previous or next year, that year is used instead. (added in PHP 5.1.0)"[2]. Is it possible to add this? See also The Mathematics of the ISO 8601 Calendar for an ecxelent explanation.

Then it's possible to denote the ISO 8601 YYYY-Ww-D format: o-W27-7

Nsaa 13:32, 17 October 2006 (UTC)

I didn't want to add a PHP 5.1 dependency just yet, that's why I left it out. Presumably we could simulate it, but I didn't think anyone would want it that badly. Was I wrong? -- Tim Starling 02:08, 18 October 2006 (UTC)
In most of Europe people uses the ISO weeks, but not together with the year (most people doesn't realize the difference between the gregorian year and the ISO year - I've corrected a lot of PL/SQL stements from YYYYIW to IYYYIW ... IYYY denotes the ISO year in PL/SQL). Although I hope it's possible to implement further down the road. Here's the bug reported in PHP [3]. Nsaa 20:16, 18 October 2006 (UTC)
Found a solution using Template:Isoyear like
this:{{isoyear|{{#time:Y}}|{{#time:n}}|{{#time:j}}}}{{#time:-\WW-N}}
and this gives: 2008-W27-7
I'm asuming the calculation in the ISOYear template is correct. Regards Nsaa 14:57, 10 November 2006 (UTC)

[edit] StringFunctions

Please install the StringFunctions and DynamicFunctions. I often work on templates (at Wikipedia), and these functions would be very useful for some things. As they already exist, they should be installed.

StringFunctions is poorly protected against DoS attacks. DynamicFunctions appears to disable the cache on any page where it appears, thus it is unacceptable for Wikimedia. Features on Wikimedia which require access to these variables should preferably be implemented on the client side, in JavaScript. -- Tim Starling 02:00, 18 October 2006 (UTC)
Ok, then no DynamicFunctions, but why not simply limit the length of a StringFunction string to 1024 bytes or something like that to stop DOS attacks? 72.139.119.165 19:41, 18 October 2006 (UTC)
StringFunctions could be installed, but only ones which are completely O(n) (linear increase with string size) could be accepted because ones that increase exponentially could be used in DOS attacks (unless they are somehow limited, as suggested above). I support adding the substr and strlen functions because other functions could be made from them, they are DOS-safe, and very useful. Since DynamicFunctions break the cache, they cannot be installed on the MediaWiki servers. Polonium 15:37, 3 January 2007 (UTC)

[edit] Variables

Are there any good reasons not to install the VariablesExtension? If not, the extension should be installed. Polonium 15:29, 5 January 2007 (UTC)

[edit] Request #ifregex

Here's a simple one (patterend after #ifeq):

        function ifregex( &$parser, $pattern = '', $search = '', $then = '', $else = '' ) {
                if ( ereg( $pattern, $search ) ) {
                        return $then;
                } else {
                        return $else;
                }
        }

Maybe also do a #ifregexi (case insensitive). WsW 11:03, 15 April 2007 (UTC)

[edit] formatnum:

See Bug 10454

First, the formatnum: parser function won't introduce separators as expected in the decimal part. For example, {{formatnum:0.1234567}} should render "0.123,456,7". This may be a localisation issue, but the option to format decimals in this way should at least be offered.

Secondly, formatnum: expects its input in a specific format, which is incongruous once localised. For example, French wikipedia templates that mix formatnum: parameters with non-formatnum: ones will force the user to specify the first ones with a period, the second ones with a comma. There should be an option (or an alternate parser function) that expects the input to be already localised, as far as the decimal separator goes.

For example, {{formatnum:123456.789012}} should give "123,456.789,012" under English localisation, "123 456,789 012" under French. But what most French contributors will want to write is "{{formatnum:123456,789012}}".

Urhixidur 15:18, 7 July 2007 (UTC)

[edit] String Expressions

I would love to see additional string expressions such as "alphabetical > orthographical" so that I can make a self-sorting tables or lists. If this exists please tell me where I can find info. ~RayLast «Talk!» 17:15, 1 March 2008 (UTC)


[edit] Other

[edit] Switch and equal signs

Maybe no bug, but interesting, apparently #switch: doen't support equal signs at all in compared values. It's of course possible to match urlencode-d values, and #ifeq: can handle equal signs. Another observation, #ifeq: (and probably also #switch) support numerical comparisons also for numbers in exponential format, see Help:Calculation#Comparisons. -- Omniplex (w:t) 06:50, 6 June 2006 (UTC)

I ALSO have the same problem : http://encyclopedia.meta99.com/wiki/Cats Warning: Missing argument 2 for wfParserFunctionsLanguageGetMagic() in /home/httpd/vhosts/encyclopedia.meta99.com/httpdocs/extensions/ParserFunctions/ParserFunctions.php on line 144

[edit] Incorrect in #time

{{#time:H|12:00:00 -0100}} gives 13 instead of 11--っ 14:53, 8 September 2006 (UTC)

This is expected, it is just the way strtotime works. -0100 means "the preceding time specification was in the timezone -01:00 UTC". The function then converts it to UTC by adding one hour. -- Tim Starling 09:22, 30 September 2006 (UTC)
Thank you for your answer. Well, I see, but I don't think it is very good because, for example, {{#time:H:i:s|-0100}} has no relation to the timezone -0100 UTC.--っ 06:16, 13 October 2006 (UTC)
I can see no explanation in the documentation of what should be the format of the time parameter. I would have expected that

{#time:H|12:00:00 -0100}}

gives just 12 (that is, the hour in the given timezone). Or is implied (but not described in the documentation) that all time are converted to UTC before printing it with the format specified? What we are suppose to think the following code

{#time:H e|12:00:00 -0100}}

is going to produce? (according to [4] e should print the timezone identifier (added in PHP 5.1.0)).
Is the time always converted to UTC or it is converted to the local timezone? (if different from UTC)
Again I have to said that the origin of ambiguities is that it is not defined the format of the parameter time. In the documentation at [5] (where it is called timestamp) it is said that it is an int not a string of character string. Below in the same documentation it is said that to generate this parameter form a string the function strtotime() should be use. So what happens when the mediawiki function #time is called? The second parameter (time) is passed to strtotime first? And this made time expressed as "12:00:00 -0100" to be silent convert to "13:00:00 UTC" (if local timezone is UTC)? (well perhaps I am too lazy, I could look up in the code, if I only have learnt php). -- AnyFile 10:24, 26 September 2007 (UTC)

[edit] Year 2038 problem

I seem that Y2038 appears now.

  • {{#time:r|2038-1-19 03:14:07}} -> Tue, 19 Jan 2038 03:14:07 +0000
  • {{#time:r|2038-1-19 03:14:08}} -> Error: invalid time

--cpro 10:19, 27 September 2006 (UTC)

This is a limitation in PHP's strtotime(), and also in date() for format characters which use it. I have no intention to fix it. -- Tim Starling 09:25, 30 September 2006 (UTC)

[edit] Problem with #switch

When i use the #switch function, i get this error message:

Warning:  array_slice(): The first argument should be an array in/home/www/***/w/languages/Language.php on line 858
Warning:  Invalid argument supplied for foreach() in /home/www/***/w/includes/MagicWord.php on line 183

I use the "old" version, because i have PHP 4.

Anyone knows what is wrong? --193.90.237.253 14:15, 20 December 2006 (edit) (undo)

I have the same problem and it seems the suggestion from Talk:ParserFunctions/Archive_3#Notable_error_in_1.6.8 works. --Flominator 07:08, 21 March 2007 (UTC)

[edit] New features, 1.7 compatibility

I've added extra format characters to #time, namely NwzWtLaAgGhcrU and the extension xN. I've also bundled a copy of sprintfDate with the extension, so it will now work with MW 1.7. -- Tim Starling 06:08, 25 September 2006 (UTC)

Thanks for the terrific work you've done with this extension. However, I'm still experiencing two problems:
  1. Any HTML inside an #if statement (Infobox tables copied from Wikipedia, for example) seems to be converted to preformatted text.
  2. It completely breaks MW 1.7 when running concurrently with the Cite extension.
These errors have been mentioned here and elsewhere, but they don't seem to be widespread. Not sure why we're having these problems. I'm forced to run PHP5 as a CGI module on my server; could that be to blame? Any other thoughts? Thanks --Akabaka 20:23, 1 October 2006 (UTC)

I got around your problem number 2 by copying a newer version of Hooks.php: http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/Hooks.php?revision=16282 However, I am still experiencing the issue with HTML inside #ifs being converted to "html entities". Did anyone have luck with running those on 1.7.1? Svemir Brkic 03:00, 9 October 2006 (UTC)

Oops, I guess I should really read the instructions. As it suggests when "all else fails," adding the line $wgUseTidy=true; to my LocalSettings file did the trick. No more preformatted table code! Hooray! --Akabaka 20:58, 26 October 2006 (UTC)

Tim Starling's fix seems to need a third file: SprintfDateCompat.php. I would add it to the list of links on the main page, but I've now got thoroughly confused as to what is neeeded for different versions of MW and different versions of PHP, so I'd probably add it in the wrong place. --ColinFine 16:34, 15 January 2007 (UTC)

And SprintfDateCompat.php is inconsistent with PHP4. Oh joy. --ColinFine 16:52, 15 January 2007 (UTC)

Relating to the SprinfDateCompat.php fix, if the system does not have class SprintfDateCompat or method sprintfDate or the file SprintfDateCompat.php, it crashes. Line 209 of ParserFunctions.php should check for file existence first and gracefully fail rather than crashing by attempting to load a nonexistent file.

To make SprintfDateCompat.php PHP4 compatible, simply remove the "static" keywords from lines 203 and 204.

[edit] Defining a parameter

Hello there, I want to use boolean parameters (as a flag): either there or absent. In this manner I want to set it like this:

{{zh|kurz|c=香港|p=Xiānggǎng}}

Obviously that doesn't work, and I have to add the equal sign to make it do so:

{{zh|kurz=|c=香港|p=Xiānggǎng}}

The testing I do is:

{{#ifeq: {{{kurz| }}}|{{{kurz|u}}} …

Is that the only way? Is it this way on purpose? Thanks for any clues. --Chrislb 21:44, 20 October 2006 (UTC)

To use "kurz" (or any other non-empty string) instead of "kurz=", I would use an unnamed parameter: {{#if: {{{1| }}}| ….--Patrick 22:54, 20 October 2006 (UTC)
I see the difference now. This solution doesn't work for me, as I already have several parameters (all named). As I see it's MediaWiki's implementation to treat "kurz=" as an empty parameter and "kurz" as a unnamed parameter with the content "kurz".
As I have several parameters I have to hold on to the named version: requesting to use the flag as first parameter (and then unnamed would work) might be to restrictive (users might screw it up and place it last instead). And as the numbers of parameters can vary in my template even checking the count of parameters is no solution...
Any other hints? Thanks for yours Patrick, it opened my eyes a bit for the understanding of MediaWikis handling.
Hmm, while typing this it comes to my mind that I can check with all given parameters for the value "kurz", though I can't check if it's for an unnamed variable or a named one, so {{zh|kurz}} will be the same as {{zh|p=kurz}}. Or is there a way to check that the variable for the given value is unnamed? --Chrislb 13:38, 21 October 2006 (UTC)
{{{1}}} means the first unnamed parameter, the value can be provided after the named parameters. If there are more unnamed parameters, then you can check each for the value "kurz".--Patrick 00:21, 22 October 2006 (UTC)
Oh, I didn't know that. Thanks, I think that's what I need. It should be the only unnamed one. I wonder why I didn't find that piece of information in the documentation. Maybe I'm blind. You really helped me. Thanks again. --Chrislb 21:09, 22 October 2006 (UTC)

[edit] Inserting commas

We have an infobox that converts area in km2 to sq mi. For this to work, the input is not allowed to contain commas and the output does not contain commas - so it looks a bit messy. Is there any way around this? - 131.174.21.230 14:50, 9 November 2006 (UTC)

For output you can use formatnum, see Help:Magic_words#Formatting.--Patrick 02:01, 10 November 2006 (UTC)
Fantastic! Just the thing. Thanks! - 84.169.242.33 09:33, 10 November 2006 (UTC)

[edit] Colors using #

While fiddleing with en:Template:Infobox mineral I stumbled upon a problem with colors written using #xxxxxx and #if in tables. I tried to do (template variables already eliminated):

{|
|- align=center style="background-color:{{#if:  |  |  #ff0000}}"
! colspan=2 align=center | a name
|}

gives:

  1. ff0000"
a name

With the #if eliminated:

{|
|- align=center style="background-color:#ff0000"
! colspan=2 align=center | a name
|}

gives:

a name


If I use named web colors it works:

{|
|- align=center style="background-color:{{#if:  |   |  red }}"
! colspan=2 align=center | a name
|}

gives:

a name

How can I use html hex colors in #if constructs in tables? --Ligulem 16:45, 18 November 2006 (UTC)

Type like this:

{|
|- align=center style="background-color:{{#if: | |{{#color:#ff0000}}}}"
! colspan=2 align=center | a name
|}

Wich will result in:

{|
|- align=center style="background-color:rgb(255,0,0)"
! colspan=2 align=center | a name
|}

after adding this code to the ParserFunction.php:

 function colorHook( &$parser, $color='') {
 if(strpos($color, '#') !== false) {
 $hex = preg_replace('#[^A-Fa-f0-9]#', '', $color);
 switch(strlen($color)) {
 case 3:
 $r = hexdec($hex[0].$hex[0]);
 $g = hexdec($hex[1].$hex[1]);
 $b = hexdec($hex[2].$hex[2]);
 return "rgb($r,$g,$b)";
 case 6:
 $r = hexdec($hex[0].$hex[1]);
 $g = hexdec($hex[2].$hex[3]);
 $b = hexdec($hex[4].$hex[5]);
 return "rgb($r,$g,$b)";
 default:
 return $color;
 }
 } else {
 return $color;
 }
 }

and hooking it up properly. AzaToth 21:02, 18 November 2006 (UTC)

Also:

{|
|- align=center style="background-color:#{{#if:  |  |  ff0000}}"
! colspan=2 align=center | a name
|}

gives:

a name

Patrick 01:48, 19 November 2006 (UTC)

Sure, yes. But that would require the user specifying the color in hex for *all* calls of en:Template:Infobox mineral. Ideally the calls should be allowed to say "boxbgcolor = #ff0000" and "boxbgcolor = red". I just wonder why the parsing software interprets the # as being like at the beginning of a line (and thus emitting a numbered list). Nevertheless, thanks to both of you for responding. --Ligulem 09:45, 19 November 2006 (UTC)

I think I found a workaround: Don't use wiki-table syntax:

<table>
<tr align=center style="background-color:{{#if:  |  |  #ff0000}}">
<th colspan=2 align=center>a name</th></tr>
</table>

gives:

a name

--Ligulem 17:13, 20 November 2006 (UTC)

You can still use the wiki-table syntax. You just have to throw an empty nowiki tag in front of the #:

{|
|- align=center style="background-color:{{#if:  |  |  <nowiki/>#ff0000}}"
! colspan=2 align=center | a name
|}

gives:

a name

—Sledged 17:51, 15 December 2006 (UTC)

{|
|- align=center style="background-color:{{#if:  |  |  #ff0000}}"
! colspan=2 align=center | a name
|}

gives:

a name

It looks the same as the first example, but it isn't. ;) JePe 21:09, 15 December 2006 (UTC)

[edit] Working with math tag

Is there any way around to work the parser function to work with math tag, for example instead of typing an atom symbol of {}_2^4\hbox{He}^{2+} with math, it can be done with just {{atom|name=He|number=2|mass=4|charge=2+}}. I've tried to made it with CSS, but now work perfectly. With LaTex (math), it doesn't work because math environment doesn't pass the variable. Nein 17:27, 19 November 2006 (UTC)

[edit] When is #ifexist evaluated?

I'm thinking of writing an #ifexist statement that automatically adds a template to a page if another page is deleted or missing. Is this possible? Kimchi.sg 12:51, 28 November 2006 (UTC)

Yes, see en:Template:Todo AzaToth 16:28, 28 November 2006 (UTC)

[edit] Infobox_Company template

I am trying to make use of the Infobox_Company template on my site, but it is not rendering out correctly, I was told to install these parserfunctions, which I did, but still doesn't look right. I have a 1.8.2 MW install. Here's a link to the page: [6] . It's not rendering the table info like

<tr><th style="text-align:right; padding-right:0.75em;">Key people</th><td>Wayne C Fox (Chairman)
Richard W Nesbitt

Just hoping someone can see what I did wrong. I appreciate any assistance. Thanks Rovo79 22:58, 30 November 2006 (UTC)

I do not know the answer, but it seems a setting regarding HTML in wikitext needs to be changed to allow td-tags etc. even if not within table-tags, because this seems to be checked within #if instead of for the full wikitext after evaluating #if.--Patrick 13:13, 1 December 2006 (UTC)
See above Talk:ParserFunctions#Solution_to_Tables_Problems --Dr DBW 21:27, 5 December 2006 (UTC)

[edit] Logical and/or question

Sorry if this is the wrong place to post this, but I have a question I'm hoping someone can help with. Is there any way to do boolean and/or with parameters and #if, short of using nested if blocks? For instance,

{{#if {{{param1|}}} or {{{param2|}}}|then case|else case}}

Any help would be much appreciated. 67.168.181.152 10:19, 6 December 2006 (UTC)

{{{param1|}}} is a string, not a boolean, so you cannot apply and/or on it. You can on a Boolean such as {{#if|{{{param1|}}}|1|0}}.--Patrick 10:54, 6 December 2006 (UTC)
However, [(string1 is non-empty) or (string2 is non-empty)] can conveniently be checked by checking whether the concatenation is non-empty:
{{#if:{{{param1|}}}{{{param2|}}}|then case|else case}}
Patrick 12:41, 6 December 2006 (UTC)

[edit] Bug when using colon in #ifeq:

If I use the following parser code in a category sub-page, e.g. Category:Test/subpage:

[[{{#ifeq: {{NAMESPACE}} | Category |:}}{{NAMESPACE}}:{{BASEPAGENAME}}]]

I would expect a link back to the root page (Category:Test):

Category:Test (wiki code: [[:Category:Test]])

Instead I get:

 [[

    Category:Test]]

Which, in wiki code is :

[[
:Category:Test]]

In other words, a newline is inserted before the colon, causing it to be treated as a blockquote.

This may also affect the other functions, and other symbols, e.g. *.

Logged as bugzilla:8199.

--HappyDog 14:54, 9 December 2006 (UTC)

As a workaround you can use the escape sequence for a colon: &#58;
then the result is what you may predict. JePe 00:20, 10 December 2006 (UTC)
Unfortunately, that doesn't seem to work. Please see mw:Template:Languages/Lang to see the page where the problem exists - it is quite a complicated template (called from mw:Template:Languages). See how it currently appears on a category page at mw:Category:Help. --HappyDog 01:58, 11 December 2006 (UTC)
It is to complicated to test it there. But I think if you place the links within the parserfunction instead of the parserfunctions within the link, it shall work:
{{#ifeq: {{NAMESPACE}} | Category
| [[:{{NAMESPACE}}:{{BASEPAGENAME}}]] 
| [[{{NAMESPACE}}:{{BASEPAGENAME}}]] 
}}
Another possibility for this specific case is to avoid the the test for the category-namespace and place a colon for every link. That's possible for every namespace and you don't see the colon in the resulting link. JePe 12:38, 11 December 2006 (UTC)
I'll try that. I believe I was doing that before, and added the test case because it wasn't working properly, but perhaps I was solving the wrong problem. --HappyDog 19:44, 11 December 2006 (UTC)
Interestingly, I hard-coded the colon and the same problem exists (see [7]). Therefore the problem may not be with the #ifeq: function at all, but with the way parserfunctions are handled in general. Any thoughts? --HappyDog 19:48, 11 December 2006 (UTC)
As suggested above I have put the links inside, that seems to work.--Patrick 00:29, 9 January 2007 (UTC)
I thought I had tried that, but either I didn't get it right or there has been a code update since then as it didn't work. The new template code works fine now, but I should point out that the bug is not fixed, just worked around. Our reason for needing a fix has now been removed, so I won't be actively monitoring this, but it would be good if problem could be fixed properly sometime. Good luck! --HappyDog 01:28, 9 January 2007 (UTC)

[edit] Possible bug in ParserFunctions version on en.wikipedia.org

Could someone please have a look at en:Template talk:Year in other calendars#Japanese calendar is back? I'm pretty sure the behavior I'm seeing is some kind of state leak bug. My second comment in that section points to three revisions of en:Template talk:Japanese year that demonstrate the odd behavior. Please contact me at en:User talk:Mike Dillon if you have any questions. Mike Dillon 19:23, 10 December 2006 (UTC)

There is a more targeted test at en:User:Mike Dillon/Sandbox#Japanese dates involving only en:Template:Nengo and en:Template:Japanese era. It seems to be related to the use of en:Template:! in the case values of #switch, but that's just a guess at this point. Mike Dillon 20:36, 10 December 2006 (UTC)

It seems some limitation on how much can be on one page. I don't know what the bottleneck is, perhaps the amount of wikitext after resolving the templates, or something like that.--Patrick 00:20, 11 December 2006 (UTC)
Is there any way I can help diagnose the problem, or should I start looking for workarounds? I did notice that there is a difference in behavior when previewing the "Japanese dates" section on my sandbox versus viewing the whole page, so you may be right that it is related to size or call count. That being said, there are tons of ParserFunctions calls in the "Generic infobox" section on my sandbox (above "Japanese dates") and it doesn't seem that the preview of just the "Japanese dates" section would trigger the problem given that some of the ParserFunctions calls in that section work when viewing the full sandbox page. I hope my explanation wasn't too confusing, but I haven't been able to make heads or tails of the problem. I haven't yet resorted to "use the source Luke", since I'm not exactly sure which versions are deployed on English Wikipedia. Mike Dillon 01:38, 11 December 2006 (UTC)
Apparently one cannot call w:template:Japanese era ( talk edit history links ), which has 36 switches, more than 931 times, so 33,512 switches on one page, directly or indirectly, are still allowed, a little more are not.--Patrick 13:28, 11 December 2006 (UTC)
In an mxn array like w:template:Japanese era ( talk edit