Help talk:ParserFunctions/Archive 3

Rand removed?

I saw that Tim Starling has removed the random-function. So {{#rand:1|10}} will now be displayed as normal text. Is this permanent removed from the parserfunctions? I did some testing with it to display random images, and it was working fine. It was just a function I have waited for since a long time, so I was happy that it was included in the parserfunctions. JePe 12:24, 18 April 2006 (UTC)

I understand that this function was being abused and has therefore been removed; it would seem that this is likely to be permanent, which is unfortunate but apparently necessary. HTH HAND —Phil | Talk 12:41, 18 April 2006 (UTC)

I think this is unfortunate as well, and would like to see #rand brought back. Apparently there was some concern about it being used for creative vandalism (pages that randomly display a penis picture or whatever), but as most Recent Changes patrollers work via diffs, they'd see any attempt to insert a penis picture, even if it was only displayed randomly. —Locke Cole • t • c 13:28, 18 April 2006 (UTC)

Anyone smart enough to do this could easily obfuscate that. You assume every RC patroller can read understand this crap enough to recognize vandalism. -- Netoholic @ 14:09, 18 April 2006 (UTC)

Uh, they can already do similar things with the templates and magic words available now (just use the switch template for example and only make it show vandalism on certain days or so forth). #rand isn't any more of a vandal vector than anything else available now. Especially considering #rand didn't invalidate the cache (meaning you needed to action=purge or edit the page to get a new number); so as a "random vandal" thing, it wouldn't have worked anyways (either it would have never shown vandalism, or it always would have). —Locke Cole • t • c 14:16, 18 April 2006 (UTC)

I haven't been able to locate any discussion on how the rand function was being mis-used and the bit above just says 'vandalism' without specifics. The comments about randomized images or something don't explain why that's more of a problem than just inserting the image directly or through a 'switch' or whatever. What precisely was the problem? --CBDunkerson 15:16, 18 April 2006 (UTC)

I think discussion was on IRC in either #mediawiki or #wikimedia-tech. Tim Starling knows for certain, and I would definitely like to discuss this more before giving up on it altogether. —Locke Cole • t • c 16:42, 18 April 2006 (UTC)

I don't see many useful applications for #rand:, a random tip of the day maybe? OTOH I also fail to see dangerous applications, and given #expr: and #switch: folks could emulate it anyway. -- Omniplex (w:t) 19:11, 18 April 2006 (UTC)

Were there {{CURRENTHOUR}}, {{CURRENTMINUTE}}, {{CURRENTSECOND}} provided as well (for what reason aren't they?), a quite good randomness could be achieved by other means (check this counter tommorow). Misza13 21:31, 19 April 2006 (UTC)

There is one page on WikiEn which has used an hour/minute 'random' seed for a couple of months. However, #rand: was much simpler and could be updated more frequently than every sixty seconds. --CBDunkerson 23:57, 21 April 2006 (UTC)

I would suppose that #rand was removed because it totally broke caching. — Ambush Commander^(Talk) 06:54, 22 June 2006 (UTC)

#language:

Although #language is defined at parser.php not parserfunctions.php, I add #language here because it has the same syntax ({{#.. : }}) and already implemented to wikimedia project (StringFunctions hasn't implemented yet). Please correct me if i'm wrong. Borgx 04:03, 31 May 2006 (UTC)

It is also listed on Magic words since #language is a magic word. WebBoy 10:25, 21 June 2006 (UTC)

JFTR, that section was moved (more or less as is) to colon functions. -- Omniplex (w:t) 18:46, 23 June 2006 (UTC)

Backporting to 1.6

I'm interested in using ParserFunctions in the 1.6 branch of MediaWiki, since this is the current stable branch. However, as noted, #if: doesn't work properly in 1.6.

Since I have my own custom 1.6 branch with a few of my own customizations, it is not a problem changing it to support ParserFunctions. So, I would like to know what exactly has made it possible for #if: to work under 1.7, so I can backport it to my custom 1.6 branch. I tried looking at the 1.7 branch SVN Log to find out what changes made it possible, but it is huge and proved being really difficult to find. If possible, could someone point me what changes are necessary to backport from 1.7 to make ParserFunctions work?

Thank you very much. Best regards, -- en:Juliano 19:06, 3 June 2006 (UTC)

Multiple parameter absence testing

• I've previously had some failled attempts at upgrading the en:Template:Drugbox (e.g. this) to use #IF to exlude rows that do not have a particular defined parameter or to display alternative link so that the data can be lookedup (instead another user kindly used 'hiddenStructure class' which I have even less idea about).
  • Currently the template shows the image defined by the parameter 'image', else as a default shows {{PAGENAME}}.png. What would be nice is add additional test to only show the default {{PAGENAME}}.png if such an image exits.
• What we particular seek is to have whole optional sections. Obviously a test can be applied for each parameter row as to whether or not to discplay, but this would still leave the header title row for the whole section. So how can one test for mutiple parameters not having been defined: presumeably I seek either 'P1=blank AND P2=blank AND P3=blank' or concanate the paramenters to make a single string eg 'P1 & P2 & P3=blank'. Does placing {{{p1}}}{{{p2}}}{{{p3}}} act to test the combination joined text presence ? en:Davidruben ^Talk 11:28, 10 June 2006 (UTC)

Yes, {{#if: {{{p1|}}}{{{p2|}}}{{{p3|}}} | ? | all empty or undefined}}. -- Omniplex (w:t) 03:14, 18 June 2006 (UTC)

Expression error: (?)

I've seen some templates that seem to work correctly, even though they show the following error message:

Expression error: unrecognised punctuation character "{"

An example is at w:Template:Three digit. Can anyone help me understand what is going on? Thanks, Rfrisbie 22:24, 17 June 2006 (UTC)

No default value is specified, so {{{1}}} gets passed (obviously bad input). Not related to ParserFunctions. — Ambush Commander^(Talk) 23:03, 17 June 2006 (UTC)

I assumed it was something "simple" like that, I just couldn't figure it out. But I knew someone here would see it in a flash. Thanks! :-) Rfrisbie 02:41, 18 June 2006 (UTC)

Round functionality?

expr works well, but I was wondering if it would be difficult for round to look at the number it processes and then spit out a number with the correct decimal places. For example, #expr: 35.2 / 2 round n = 18, but #expr: 35.2 / 2.0 round n = 17.6 — 65.174.225.5 13:29, 23 June 2006 (UTC)

It doesn't work that way. Both 35.2 / 2 and 35.2 / 2.0 result in the same 17.6. If you want 18 add round 0, if you want 20 add round -1, if you want it as is leave it as is or in this case use round 1. You're not looking for {{Len}}, or are you? -- Omniplex (w:t) 17:40, 23 June 2006 (UTC)

#ifexist - interwiki

Will there be interwiki support for #ifexist? That is, will it be able to detect the existance of pages on other wikis? 80.178.224.145 01:41, 9 July 2006 (UTC)

Guessing, never. I've no clue how access on commons works internally. If you look at a page with an arbitrary image link, would it show up as "red" link if the image doesn't exist on commons ? -- Omniplex (w:t) 23:16, 9 July 2006 (UTC)

#ifeq not working the way I understand it to

The way I read the #ifeq section is that:

{{ifeq: {{{x| }}}|{{{x|u}}}|undefined|{{{x|}}}}}

should return "undefined" if not set in the template, otherwise it should return the value of the named parameter. For instance:

{{myWonderfulTemplate
x = 1
y = 2
}}

given the template:

{{{x| }}}|{{{x|u}}}|undefined|{{{x|}}}}} or {{{y| }}}|{{{y|u}}}|undefined|{{{y|}}}}}

would show: "1 or 2"

Whereas:

{{myWonderfulTemplate
y = 2}}

would show: "undefined or 2"

My template doesn't show the "undefined" in all cases, but just shows blank space. My template looks like this:

==Executive Members==
* '''President:''' {{ifeq: {{{president| }}}|{{{president|u}}}|None elected|{{{president|}}}}}
* '''Vice-President:''' {{ifeq: {{{vicepresident| }}}|{{{vicepresident|u}}}|None elected|{{{vicepresident|}}}}}
* '''Treasurer:''' {{ifeq: {{{treasurer| }}}|{{{treasurer|u}}}|None elected|{{{treasurer|}}}}}
* '''Secretary:''' {{ifeq: {{{secretary| }}}|{{{secretary|u}}}|None elected|{{{secretary|}}}}}
==CIS Representatives==
* '''First Year Rep:''' {{ifeq: {{{1styrrep| }}}|{{{1styrrep|u}}}|None elected|{{{1styrrep|}}}}}
* '''Second Year Rep:''' {{ifeq: {{{2ndyrrep| }}}|{{{2ndyrrep|u}}}|None elected|{{{2ndyrrep|}}}}}
* '''Third Year Rep:''' {{ifeq: {{{3rdyrrep| }}}|{{{3rdyrrep|u}}}|None elected|{{{3rdyrrep|}}}}}
* '''Fourth Year Rep:''' {{ifeq: {{{4thyrrep| }}}|{{{4thyrrep|u}}}|None elected|{{{4thyrrep|}}}}}
==Other People of Importance==
* '''Webmaster:''' {{ifeq: {{{webmaster| }}}|{{{webmaster|u}}}|None elected|{{{webmaster|}}}}}
* '''SCC Manager:''' {{ifeq: {{{sccmanager| }}}|{{{sccmanager|u}}}|None elected|{{{sccmanager|}}}}}
* '''Referal Manager:''' {{ifeq: {{{referal| }}}|{{{referal|u}}}|None elected|{{{referal|}}}}}
* '''Student Life Liason:''' {{ifeq: {{{studentlife| }}}|{{{studentlife|u}}}|None elected|{{{studentlife|}}}}}

And I'm using it like:

{{CISSA Elective
|president = a
|vicepresident =b
|treasurer = c
|secretary =d
|1styrrep = e
|2ndyrrep = f
|3rdyrrep = g
|4thyrrep = h
|referal = j
|studentlife = k
}}

I would expect the top 2 items under ==Other People of Importance== to show "None elected", not the blank space it currently shows.

Am I doing something wrong, or is this expected behaviour? In either case, is there something I can do to get the expected behaviour I want?

Thanks,

Superwad 08:37, 12 July 2006 (UTC)

I haven't really analysed all you said, and what you wrote somehow looks right (assuming you didn't miss the | and # missing from some of your examples); but looking at your first piece of code

{{#ifeq: {{{x| }}}|{{{x|u}}}|undefined|{{{x|}}}}}

I immediately ask myself why you're making this so complicated.

You say you want to return the value of {{{x}}} if it's defined, and "undefined" if it's not. Why not just use {{{x|undefined}}}? —da Pete 14:49, 13 July 2006 (UTC)

Although I haven't tried this - could it be that you got this the wrong way around? Actually, the first two parts are equal if {{{x}}} is defined. So the result should be "undefined". If it's not defined, {{{x|}}} will be rendered, which returns an empty string. —da Pete 14:54, 13 July 2006 (UTC)

Thanks to both of you. I opted to use the simple approach Pete mentioned, and things are working out famously! Superwad 18:41, 27 July 2006 (UTC)

Where to get help

Where can one go to get help when a parser function doesn't work or to get debugging help with a parser function? - Lady Aleena @ 09:26, 23 July 2006 (UTC)

Here? — Ambush Commander^(Talk) 18:46, 23 July 2006 (UTC)

#if inside table

The code below doesn't work. I'm fairly sure it's because at some point the return value gets surrounded in <pre></pre> tags, making the thrid row do crazy things. Can anyone tell me where this is happening, it doesn't appear to be obvious from the code and i've tried removing them using str_replace() before the $then value is returned in the ifHook() function...unless it gets returned somewhere else...

<table border="1">

   <tr>
       <th>first row</th>
   </tr>
   <tr>
      <td>second row</td>
   </tr>

{{ if: {{{foo|}}} |

   <tr>
      <td>third row</td>
   </tr>

}}

</table>

Thanks for your time --212.248.219.10

I fear I didn't quite get what's your problem. What makes me thinking here is that you left away the # in front of the "if". --Ligulem 22:57, 25 July 2006 (UTC)

According to this if you are using MediaWiki version 1.6 (which I am), you should not include the #. I have also applied the "if" fix so the function does actually work. The problem is it isn't doing what you would expect, hiding the third row if "foo" has no value, and showing the third row if "foo" does have a value. --212.248.219.10

On meta it works (of course with the #). See here. BTW: please sign your posts with --~~~~ (second rightmost button above the edit window) so your signature includes the timestamp. --Ligulem 14:49, 26 July 2006 (UTC)

Hmm, that's quite strage. I wonder if meta uses a different version of ParserFunctions? The only difference I can see is the MediaWiki version meta uses is 1.8alpha and I have 1.6.3. The PHP versions are identical and I have a slightly later version of MySQL... --212.248.219.10 15:47, 26 July 2006 (UTC)

I figured out a fix, add </html> before the variable, and <html> after the variable. and put html tags around your table. it works out. so... --User:xjumper84 9:46, 01, Aug 2006 (UTC)

<html>
<table border="1">

   <tr>
       <th>first row</th>
   </tr>
   <tr>
      <td>second row</td>
   </tr>
</html>
{{ if: {{{foo|}}} |<html>

   <tr>
      <td>third row</td>
   </tr>
</html>
}}
<html>
</table>

I'm getting the same problem -- mostly coming up in Infobox templates I've cribbed from Wikipedia -- and the above workaround isn't doing it. Any ideas? Could it be because I'm running MediaWiki on a CGI module of PHP5? --Akabaka 20:57, 27 September 2006 (UTC)

HI! I have MediaWiki 1.82 running. I'm trying to make a template with a table. I'd like to use #if so if there is a value to add an table-line. If there isn't, I won't print a blank line.

<table class="standard">
<tr><th>test:</th></tr>
{{#if: {{{Name1|}}} | <tr><td>{{{Name1}}}</td></tr> | }}
{{#if: {{{Name2|}}} | <tr><td>{{{Name2}}}</td></tr> | }}
</table>

The problem is, that #if: parse the content as TEXT not as HTML! The result is <tr><td>Name1</td></tr> Whats wrong? 80.109.151.113 11:16, 1 November 2006 (UTC)

A number of us have had the same problem. The solution (for me, at least) is actually in the instructions. Just add the line $wgUseTidy=true; to your LocalSettings file. --Akabaka 22:07, 3 November 2006 (UTC)

Had the same problem, your solution seems to partitially work for me. I got the Problems with tr and td fixed, but now I am having an error message Warning: proc_open(/dev/null) function.proc-open: failed to open stream: No such file or directory in ...htdocs\wiki\includes\Parser.php on line 732 . It HTML Tidy actually required for this fix? If yes, this appears to be quite a dirty workaround... There should be a fix in the parserfunctions.php code itself to avoid this problem! --84.178.77.128 13:37, 4 November 2006 (UTC)

Solution

I had the same problem, and I found the solution: enable $wgUseTidy (you will need the tidy package). I think the ParserFunctions are somehow buggy - without tidy, they _escape_ the special characters used for HTML. < becomes &lt; and > becomes &gt; - of course, that can't work. I am not sure how tidy changes this behaviour, but at least, it does - problem solved. --Martin von Wittich 14:31, 4 November 2006 (UTC)

Solution results in following..

Warning: proc_open() [function.proc-open]: open_basedir restriction in effect. File(/dev/null) is not within the allowed path(s): (/usr/share/php:/usr/share/pear:/var/www/sites/libregamewiki/) in /var/www/sites/libregamewiki/HTML/includes/Parser.php on line 759

Warning: proc_open(/dev/null) [function.proc-open]: failed to open stream: Operation not permitted in /var/www/sites/libregamewiki/HTML/includes/Parser.php on line 759

--77.185.77.147 01:59, 5 January 2008 (UTC)

Using regex

Is it possible to use regular expressions (regex) in ParserFunctions? Basically, we'd like to be able to read a Bible verse in the {{pagename}}, e.g. Genesis 1:1, and have a template on that page be able to separate Genesis, 1, and 1 automatically. If regex isn't possibly, does anyone have any other ideas? See the discussion for details: [1] --J. J. 15:20, 2 August 2006 (UTC)

Sure. It's pretty easy to add it to ParserFunctions.php, using preg_replace. Add the following to Class ExtParserFunctions (I put it above function time (...)).

class ExtParserFunctions {
   ...
        function regex( &$parser, $string, $pattern, $replace ) {
                static $mRegexCache = array();
                if ( isset( $mRegexCache[$string][$pattern][$replace] )) {
                        return $mRegexCache[$string][$pattern][$replace];
                }
                $result = preg_replace($pattern, $replace, $string);
                $mRegexCache[$string][$pattern][$replace] = $result;
                return $result;
        }
   ...
}

Then register it with all the other parser functions, as in here:

function wfSetupParserFunctions() {
   ...
   $wgParser->setFunctionHook( 'regex', array( &$wgExtParserFunctions, 'regex' ) );
   ...
}

and add the GetMagic (I only added English; I have no idea how the others are generated, as I'm editing it in w:vi):

function wfParserFunctionsLanguageGetMagic( &$magicWords, $langCode ) {
   ...
    switch ( $langCode ) {
       ...
       default:
       ...
       $magicWords['regex']   = array( 0, 'regex' );
       ...
   }
}

Then, in your wiki, something like this will work:

 {{ #regex: string | pattern | replace }} 

such that

{{ #regex: April 15, 2003 | /(\w+) (\d+), (\d+)/i | ${1}71,$3 }}

will print

April71,2003

Hope that helps. Bmh ca 19:18, 23 October 2006 (UTC)

Installing these functions?

I am running a 1.6.8 wiki and am looking to install these functions:

I added the line listed above to my localsettings.php, and uploaded the parserfunctions.php file listed above for the 1.6 fellow, but it hasn't affected my site (specifically #if functions). Is there a way to test if the file is successfully installed, and if it is, can I get #if to work (or a substitute for it?) Thanks! TheHYPO 07:08, 4 August 2006 (UTC)

#ifexist

I use following sceme in an article (for example named "X"):

{{ #ifexist: Template:A | {{A}} | {{B}} }}

In other words, when "Template:A" exists, it should be invoked, else "Template:B".

I expect, that article "X" uses only that branch which fulfills the condition.

But in fact, when I go to either of the templates, I find "X" in the "What links here"-list. Also, when I edit "X" I find under "Templates used on this page" "Template:A" and "Template:B" as well.

The problem is, if there are many dummy entries in the "What links here"-list, it cannot be decided easily, whether the template is in use or not, and whether it could be deleted or should be created, apart from the waste entry in the "Wanted pages"-list.

Who could help me, solving this problem? Hubert22 10:32, 11 August 2006 (UTC)

I guess this is a desired behaviour. I have the same problem with things like this: {{ #if: {{{1|}}} | {{deprecated}} | }}. The {{deprecated}} template is linked from everywhere although the {{{1}}} is okay..

This is how the parser works and it can not (and should not) be fixed.. Why? Because your page is parsed and then cached on the condition of {{#ifexist: Template:A}}. If the condition changes (in any possible way), the cache must be invalidated. The same, however, applies to all used templates, even Template:B. And this invalidation is done by using the "What links here"-list. No sophisticated method is used to tell what matters if..

The only solution (as I see it) to this could be reached by deciding what is important, what matters for each similar function (#if, #ifeq, #ifexists, ...). That is faaar, faaar away right now... --jsimlo 12:36, 11 August 2006 (UTC)

I thank you. Even so I didn't understand everything you said, I understood that it is impossible to solve the problem. Hubert22 23:07, 11 August 2006 (UTC)

I am sorry for not being a bit simpler.. :)) Long story short:

1. If a template is modified, all articles that include the template must be re-rendered to become up-to-date.
2. If a template occur somewhere in an article, such occurrence must be remembered. It is remembered by the "What links here"-list.
3. Right now, there is no way to tell, which part of your {{ #ifexists: }} function does matter and which does not. Therefore all used templates are remembered, even those that seem to be unused.

Hope that I have helped more.. :)) I tried.. --jsimlo 09:07, 12 August 2006 (UTC)

Instead of

{{ #ifexist: Template:A | {{A}} | {{B}} }}

you can use

{{ {{ #ifexist: Template:A | A | B }} }}

Now "What links here" and the list of embedded pages on the edit page only give the actual embedding. I am not sure whether this has effect on updating issues.--Patrick 12:28, 12 August 2006 (UTC)

It works just fine and with no updating issues.. Nice. :)) --jsimlo 18:28, 12 August 2006 (UTC)

@Patrick: You are great. You helped me much. For this I award you a golden gummybear.

@jsimlo: Thank you also very much, because you attended to my problem. :)))

Hubert22 15:51, 13 August 2006 (UTC)

Thanks!--Patrick 22:50, 13 August 2006 (UTC)

Detect absence of vertical bars

I've been testing a pair of templates that affect each other for several hours now. The main template takes parameters from the secondary template and uses ParserFunctions on these parameters. I'd like the template to be able to detect when there are none, one, or two parameters being passed to it without having to add additional vertical bars. E.g. {{Romtest}} produces errors, but {{Romtest||}} works. I'd like to be able to have the former with the same results as the latter. (Same request for {{Romtest|6}} vs. {{Romtest|6|}}, too.) The link I've provided has more details if you need them. --J. J. 15:00, 14 August 2006 (UTC)

Maybe I did not understand your problem, but.. Why don't you use {{{1|}}} instead of {{{1}}}? If {{{1}}} is undefined, {{{1|}}} returns an empty string, which is what you need, isn't it? --jsimlo 19:36, 14 August 2006 (UTC)

I've tried that and the results are exactly the same for both. Go ahead and edit it yourself (you don't have to register) if you'd like. --J. J. 22:43, 18 August 2006 (UTC)

I fixed it, the bars are needed in Template:Romtest. If the undefined {{{1}}} is transferred to another template, there is no longer an undefined parameter but one containing the text "{{{1}}}".--Patrick 11:07, 19 August 2006 (UTC)

Woo hoo! I wasted so many hours on that. I really appreciate it! --J. J. 15:16, 19 August 2006 (UTC)

Nested template calls in switch

I'm trying to get the following to work, but fail: in a template, i want to call another template IFF the template wasn't called from certain pages. I thought i could achieve this by saying

 <!-- my regular template stuff -->
 {{#switch: {{PAGENAME}}
 |page1
 |page2
 |page3=<!-- do nothing if called from page1, page2 or page 3 -->
 |{{nav {{{FOO}}} }} <!-- else, include Template:nav {{{FOO}}}
 }} <!-- end switch -->
 

Is this possible at all? If so, how? TIA! --213.61.160.10 12:42, 15 August 2006 (UTC)

gnaa. found the answer myself, it's the same trick that Patrick suggests above for #ifexist. --213.61.160.10 13:16, 15 August 2006 (UTC)

Notable error in 1.6.8

I get the following PHP errors on pages associated with a template that has #switch in it.

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

I'm running 1.6.8 with the 'line 10' removal discussed and the altering from 'switch' to '#switch'. I am having trouble tracking down the actual cause of the issue in the switch. I can get it to a point that it won't cause the error, but I can't figure out what makes that edit notably different than another edit. Sometimes it feels as though reverting to a working edit no longer has it working anymore. Anyone encounter anything like this? TheHYPO 15:14, 15 August 2006 (UTC)

I've been forced to result to nested #ifeq functions which works, but is far more "tricky" to get working properly. I'm still not sure why switch was causing php errors TheHYPO 06:40, 16 August 2006 (UTC)

I've had similar problems - my solution was to ditch #switch and create a template called switch, containing simply '{{{{{{1}}}}}}'. It can then be called using the exact same syntax as #switch but with the colon replaced with a pipe. Anyone see why this is a bad idea? Cooperised 22:36, 28 August 2006 (UTC)

--Update: If you want the 'default' functionality, ie. to replace #switch with a like-for-like template, the following seems to work well:

{{{{{{1}}}|{{{2|}}}}}}

This uses the first unnamed parameter as a key into the named parameters; if that fails, it returns the second unnamed parameter (the 'default' string) verbatim. The pipe after the number '2' means that the template will not fail in the unfortunate situation that there is no match and no default option - it'll just return a blank string. Hope this helps someone! Cooperised 15:41, 29 August 2006 (UTC)

Has anyone actually found the root of this problem or are work arounds using nested #ifeq statements the only solution?Jrincon 17:40, 3 November 2006 (UTC)

Also same error in 1.6.8

actually found that it looked to be related to the time function... switch function works. Dsgncr8or 16:34, 2 September 2006 (UTC)

#skin on Wikipedia

From Talk:DynamicFunctions on 13:56, 11 August 2006 (UTC)...

Why doesn't #skin work on Wikipedia? It would be very useful to me to have it so that I can find my .css and .js files. - Lady Aleena @ 03:51, 16 August 2006 (UTC)

I'm not sure I understand what it is you're looking for, but Special:Prefixindex/User:Lady Aleena already lists any personal CSS and JS files you have at this wiki. – Minh Nguyễn (talk, contribs) 05:57, 16 August 2006 (UTC)

Mxn, I was thinking that I could put this in a nice console for users. Also, Prefindex is not an easy find for the newbie. Also, when the skin is changed, the link will change. It may be blue for monobook, but red for classic, etc. It will let the user know if there is user based css or js added for the current skin. How do I go about having this function added? - Lady Aleena @ 09:25, 20 August 2006 (UTC)

If you want this functionality for a non-Wikimedia wiki, you can find someone who knows enough PHP to write an extension for you. But if you want this enabled on any Wikimedia wiki (such as Wikipedia), you'd have to somehow convince one of the developers, such as Tim Starling. But it'd be unlikely: others have brought up caching issues as reasons why #skin: won't ever be implemented here... – Minh Nguyễn (talk, contribs) 03:56, 21 August 2006 (UTC)

Request: make ParserFunctions MagicWords available to all parsers

It would be helpful for extension developers if the magicWords were available to other parser objects besides wgParser.

I modified wfSetupParserFunctions to take a parser object as a parameter:

-function wfSetupParserFunctions() {
+function wfSetupParserFunctions(&$parser) {

changing the reference from $wgParser to $parser in the function ... and changed where it gets loaded:

-$wgExtensionFunctions[] = 'wfSetupParserFunctions';
+$wgHooks['ParserClearState'][] = 'wfSetupParserFunctions';

The most elegant solution? Not sure, but i'm up against a deadline. Thanks for a most useful extension. --Jerobins 02:23, 18 August 2006 (UTC)

#switch and categories

'''[[{{#switch:{{{1|}}}|CSI=CSI: Crime Scene Investigation|Miami=CSI: Miami|NY=CSI:NY|:Category:CSI}}|follows the evidence]]'''

Why does the default, which is a category not create a link to the category, but instead creates a new line? - Lady Aleena @ 07:06, 19 August 2006 (UTC)

The colon is interpreted as indenting code. A workaround is to put it in front of the switch:

follows the evidence

follows the evidence

Patrick 11:18, 19 August 2006 (UTC)

Non-current #time?

Tim, could an optional parameter be added to allow #time calculations from a starting point other than 'now' (or time cached). If you look at w:Template:Day+1 (brace yourself) I think you'll understand why I ask. I want to be able to take a page like w:Wikipedia:Tip of the day/June 13, 2006 and perform something like {{#time: F d, Y|+1 day|{{SUBPAGENAME}}}}... where it would add one to the date specified in the subpagename ('June 13, 2006' in this case) rather than adding one to the current date. The 'day+1' template is currently used on such 'dated sub-pages' to create links to the sub-page for the next day (and a corresponding 'day-1' template for the other direction). If all of the existing 'date math' logic in the #time template could be leveraged to work from a different starting date/time this could obviously be vastly simplified. Another (equally horrifying) example, displaying a time six hours after a specified moment, can be seen at w:Template:DYK-Refresh... if this and its numerous sub-templates could be replaced with {{#time: l, j F Y H:i|+6 hours|20240424041240}} it would obviously be much simpler. --CBDunkerson 12:34, 1 September 2006 (UTC)

An offset is also possible, {{#time: l, j F Y H:i|20060901020000 +6hours}} gives Friday, 1 September 2006 08:00 - JePe 14:01, 1 September 2006 (UTC)

Yippee! Thanks for that. Didn't see it on the project page so didn't realize it was possible. --CBDunkerson 18:40, 1 September 2006 (UTC)

#time vs Magic words?

Are there any pros and cons for using things like {{#time: H:i}} vs {{CURRENTTIME}}? The 'page caching' issue comes to mind. Does that impact the 'magic words' too, or just #time? Couldn't calls to #time always get around it by using '|+0 seconds' or somesuch? --CBDunkerson 13:19, 1 September 2006 (UTC)

Doesn't work with Cite/Cite.php

I'm running MediaWIki 1.7.1, trying to use ParserFunctions. It was working fine until I installed Cite/Cite.php. Now I get these errors:

array(2) { ["LanguageGetMagic"]=> array(1) { [0]=> string(33) "wfParserFunctionsLanguageGetMagic" } ["ParserClearState"]=> array(2) { [0]=> array(2) { [0]=> &NULL [1]=> string(10) "clearState" } [1]=> array(2) { [0]=> &object(ExtParserFunctions)#20 (4) { ["mExprParser"]=> NULL ["mTimeCache"]=> array(0) { } ["mTimeChars"]=> int(0) ["mMaxTimeChars"]=> int(1000) } [1]=> string(10) "clearState" } } } array(2) { ["LanguageGetMagic"]=> array(1) { [0]=> string(33) "wfParserFunctionsLanguageGetMagic" } ["ParserClearState"]=> array(2) { [0]=> array(2) { [0]=> &NULL [1]=> string(10) "clearState" } [1]=> array(2) { [0]=> &object(ExtParserFunctions)#20 (4) { ["mExprParser"]=> NULL ["mTimeCache"]=> array(0) { } ["mTimeChars"]=> int(0) ["mMaxTimeChars"]=> int(1000) } [1]=> string(10) "clearState" } } } MediaWiki internal error.

Original exception: exception 'MWException' with message 'Unknown datatype in hooks for ParserClearState
' in /home/pensaped/public_html/mediawiki/includes/Hooks.php:85
Stack trace:
#0 /home/pensaped/public_html/mediawiki/includes/Parser.php(230): wfRunHooks('ParserClearStat...', Array)
#1 /home/pensaped/public_html/mediawiki/includes/Parser.php(266): Parser->clearState()
#2 /home/pensaped/public_html/mediawiki/includes/OutputPage.php(369): Parser->parse('This page has b...', Object(Title), Object(ParserOptions), true, true, NULL)
#3 /home/pensaped/public_html/mediawiki/includes/GlobalFunctions.php(573): OutputPage->parse('This page has b...', true, true)
#4 /home/pensaped/public_html/mediawiki/includes/SkinTemplate.php(315): wfMsgExt('viewcount', Array, '88')
#5 /home/pensaped/public_html/mediawiki/includes/OutputPage.php(594): SkinTemplate->outputPage(Object(OutputPage))
#6 /home/pensaped/public_html/mediawiki/includes/Wiki.php(250): OutputPage->output()
#7 /home/pensaped/public_html/mediawiki/index.php(124): MediaWiki->finalCleanup(Array, Object(LoadBalancer), Object(OutputPage))
#8 {main}

Exception caught inside exception handler: exception 'MWException' with message 'Unknown datatype in hooks for ParserClearState
' in /home/pensaped/public_html/mediawiki/includes/Hooks.php:85
Stack trace:
#0 /home/pensaped/public_html/mediawiki/includes/Parser.php(230): wfRunHooks('ParserClearStat...', Array)
#1 /home/pensaped/public_html/mediawiki/includes/Parser.php(3740): Parser->clearState()
#2 /home/pensaped/public_html/mediawiki/includes/MessageCache.php(534): Parser->transformMsg('$1 - {{SITENAME...', Object(ParserOptions))
#3 /home/pensaped/public_html/mediawiki/includes/MessageCache.php(476): MessageCache->transform('$1 - {{SITENAME...')
#4 /home/pensaped/public_html/mediawiki/includes/GlobalFunctions.php(450): MessageCache->get('pagetitle', true, false)
#5 /home/pensaped/public_html/mediawiki/includes/GlobalFunctions.php(409): wfMsgGetKey('pagetitle', true, false, true)
#6 /home/pensaped/public_html/mediawiki/includes/GlobalFunctions.php(316): wfMsgReal('pagetitle', Array, true)
#7 /home/pensaped/public_html/mediawiki/includes/OutputPage.php(178): wfMsg('pagetitle', 'Internal error')
#8 /home/pensaped/public_html/mediawiki/includes/Exception.php(46): OutputPage->setPageTitle('Internal error')
#9 /home/pensaped/public_html/mediawiki/includes/Exception.php(70): MWException->reportHTML()
#10 /home/pensaped/public_html/mediawiki/includes/Exception.php(145): MWException->report()
#11 /home/pensaped/public_html/mediawiki/includes/Exception.php(179): wfReportException(Object(MWException))
#12 [internal function]: wfExceptionHandler(Object(MWException))
#13 {main}

Internal error
Unknown datatype in hooks for ParserClearState
Backtrace:
#0 /home/pensaped/public_html/mediawiki/includes/Parser.php(230): wfRunHooks('ParserClearStat...', Array)
#1 /home/pensaped/public_html/mediawiki/includes/Parser.php(3740): Parser->clearState()
#2 /home/pensaped/public_html/mediawiki/includes/MessageCache.php(534): Parser->transformMsg('$1 - {{SITENAME...', Object(ParserOptions))
#3 /home/pensaped/public_html/mediawiki/includes/MessageCache.php(476): MessageCache->transform('$1 - {{SITENAME...')
#4 /home/pensaped/public_html/mediawiki/includes/GlobalFunctions.php(450): MessageCache->get('pagetitle', true, false)
#5 /home/pensaped/public_html/mediawiki/includes/GlobalFunctions.php(409): wfMsgGetKey('pagetitle', true, false, true)
#6 /home/pensaped/public_html/mediawiki/includes/GlobalFunctions.php(316): wfMsgReal('pagetitle', Array, true)
#7 /home/pensaped/public_html/mediawiki/includes/OutputPage.php(178): wfMsg('pagetitle', 'Main Page')
#8 /home/pensaped/public_html/mediawiki/includes/Article.php(820): OutputPage->setPageTitle('Main Page')
#9 /home/pensaped/public_html/mediawiki/includes/Wiki.php(327): Article->view()
#10 /home/pensaped/public_html/mediawiki/includes/Wiki.php(50): MediaWiki->performAction(Object(OutputPage), Object(Article), Object(Title), Object(User), Object(WebRequest))
#11 /home/pensaped/public_html/mediawiki/index.php(123): MediaWiki->initialize(Object(Title), Object(OutputPage), Object(User), Object(WebRequest))
#12 {main}

Either seems to work fine without the other. Unfortunately, I really need both Cite & ParserFunctions to work concurrently. Any ideas? —The preceding unsigned comment was added by 24.254.117.203 (talk • contribs) 12:19, 2 September 2006 (UTC)

Seems to be a bug. I'll file a report. For now, you can get the old versions of Cite and ParserFunctions from here (you can use an SVN client to grab revision 15387 or thereabouts, otherwise just copy-paste all the files). —Simetrical (talk • contribs) 20:56, 3 September 2006 (UTC)

Can you provide a link to a relevant bug-tracking page? Downgrading to 15387 works because this version of ParserFunctions does not set a ParserClearState hook (but Cite does). If multiple extensions try to set a ParserClearState hook...

  $wgHooks['ParserClearState'][] = array( &$wgMyParserFunctions, 'clearState' );

... then previous array entries get corrupted:

  ["ParserClearState"]=>
  array(2) {
    [0]=>
    array(2) {
      [0]=>
      &NULL    <-- Hey, where did the object reference go?
      [1]=>
      string(10) "clearState"
    }
    [1]=>
    array(2) {
      [0]=>
      &object(MyParserFunctions)#18 (0) {
      }
      [1]=>
      string(10) "clearState"
    }
  }

This causes trouble when I want to write my own extensions. Any help would be appreciated. (I'm using MW 1.7.1.) -- graham 14:39, 13 September 2006 (UTC)

I think I've found the problem: wfRunHooks() loops through the array of hooks, and on each iteration, clears its local working variables.

  $object = NULL;

But if this was reference-bound during the previous iteration:

  $object =& $wgHooks[$event][$index];

then setting $object to NULL destroys $wgHooks. This seems to work better:

  unset( $object );

I've just started learning PHP; could someone with more experience please check this? -- graham 16:12, 13 September 2006 (UTC)

This appears to be fixed in MW 1.8.0. [2] -- graham 14:15, 19 October 2006 (UTC)

#If i can make something disappear

Is there a way to make a template be replaced by a space if said template doesn't exist using the #if function? Or is there another method entirely? 209.137.182.35 03:37, 9 September 2006 (UTC)

You can test a given return value; an inexistant template should return "Template:template" instead of the return value, which can be used to trigger #ifeq into outputting a space. For example, I created User:Pathoschild/Template:Test with this return value defined, but left User:Pathoschild/Template:Test2 uncreated. Respectively, the checks (see below) output "blah blah foo" (exists) and " " (doesn't exist).

• Template code:

  {{#ifeq:{{{test|}}}|1|one|blah blah foo}}

• Check code:

  {{#ifeq:{{template|test=1}}|one|{{template}}| }}

// [admin] Pathoschild (^talk/_map) 05:06, 9 September 2006 (UTC)

There is also #ifexist:

"blah blah foo" (exists) and " " (doesn't exist).

Patrick 10:59, 9 September 2006 (UTC)

Thank you both! 209.137.182.35 20:20, 9 September 2006 (UTC)

New format specifier for #time

Would it be possible to have a custom format specifier to #time that would output the specified date/time according to the user preferences? I'm not sure what the caching implications are, but I was under the assumption that logged-in users don't get any cached output. Also, I'm not sure if it's even possible to access the user preferences from a ParserFunction.

Still, it'd be nice to be able to do something like this to format a date: {{#time:xu|2006-09-12}}, and have it output a non-linked, formatted date.

This would solve the whole problem of waiting on a fix for bugzilla:4582. The whole thing could be wrapped up in a nice short template like this: {{dt|2006-09-12}}.

—TheMuuj ^Talk 21:28, 12 September 2006 (UTC)

Call to undefined method LanguageEn::sprintfDate()

{{ #time:H:i|6:04p + 5 hours}}

Here it works: 14:04

On my wiki I get a fatal error aborting the page render:

Fatal error: Call to undefined method LanguageEn::sprintfDate() in /var/www/html/wiki/extensions/ParserFunctions/ParserFunctions.php on line 134

BTW, why can't I do this? {{ #time:H:i|6:04p - 5:12p}}

Thanks-- 216.185.177.136 06:01, 13 September 2006 (UTC)

What is p?--Patrick 12:42, 13 September 2006 (UTC)

pm. It seems to be understood by the extension when it's working; then again I'll gladly change my time format to 24h or pm or whatever if I can make it work. But it seems that I'm missing a library or file somewhere? I'm running:

• MediaWiki: 1.7.1
• PHP: 5.1.4 (apache2handler)
• MySQL: 4.1.20
• Extensions:
  • Parser hooks:
    • ParserFunctions by Tim Starling
  • Extension functions:
    • wfSetupParserFunctions
  • Parser extension tags:
• Hooks:
  • LanguageGetMagic: wfParserFunctionsLanguageGetMagic
  • ParserClearState: (ExtParserFunctions, clearState)

--216.185.177.136 15:29, 13 September 2006 (UTC)

This is fixed in the latest version of ParserFunctions. -- Tim Starling 09:29, 30 September 2006 (UTC)

Parsing translated variables

Is any chance for proper parsing constructions like {{{EnglishNamed|{{{LanguageNamed}}}}}} (See {{{сипаттамасы}}} in kk:Template:Information)? See also kk:User:AlefZet/Template:Infobox Citykk:User:AlefZet/Атырау--AlefZet 12:34, 13 September 2006 (UTC)

Seems to work fine [3].--Patrick 13:09, 13 September 2006 (UTC)

Fatal error: Call to undefined method LanguageEn::sprintfDate() in /home/xxxx/public_html/extensions/ParserFunctions/ParserFunctions.php on line 134

I saw someone else complaining of this error. Any resoltion for this?

Here is the statement I am executing:

  {{ #time:F Y| 1/1/2006 }}

Here is my version info from MediaWiki:

• MediaWiki: 1.7.1
• PHP: 5.0.4 (cgi)
• MySQL: 4.1.21-standard-log
• Extensions:
  • Parser hooks:
    • ParserFunctions by Tim Starling
  • Extension functions:
    • wfSetupParserFunctions
  • Parser extension tags:
    • <pre>
• Hooks:
  • LanguageGetMagic: wfParserFunctionsLanguageGetMagic
  • ParserClearState: (ExtParserFunctions, clearState)

I did a quick search through the source for MediaWiki versions 1.7.0 & 1.7.1 and was unable to find any function in any file named sprintfDate() -- 68.254.179.254

It appears sprintfDate is only available in the 1.8 version of MediaWiki - it is found in the languages/Language.php file. I copied to my 1.7.1 version and it appears to work fine. -- 68.254.179.254

This is fixed in the latest version of ParserFunctions. -- Tim Starling 09:29, 30 September 2006 (UTC)

case sensitivity

Is #switch case sensitive or case insensitive? Dread Lord CyberSkull ✎☠ 23:32, 22 September 2006 (UTC)

Case-sensitive, I added that.--Patrick 08:41, 23 September 2006 (UTC)