Extension talk:Winter

Improving and Extending Winter
Winter is still in active development. If you spot any bugs or have ideas to add any new features or make other improvements, please feel free to comment.

addFunction method
New functions can be added via the hooking method addFunction provided by the Winter parser $Winter->addFunction('Winter_function_name','PHP_function_to_call');

PHP_function_to_call will take a single parameter: an array of the parameters of the Winter function. The value of the 0 index is the name of the calling function (e.g. 'Winter_function_name'). This allows for the same PHP function to handle multiple hooks for Winter functions.

v2.1.1
hello i'm using MW-1.12 and i'm getting this error

Notice: Undefined index: SCRIPT_URL in /opt/mediawiki-1.12.0-ZCUEdition/extensions/Winter.php on line 121 Notice: Undefined index: SCRIPT_URI in /opt/mediawiki-1.12.0-ZCUEdition/extensions/Winter.php on line 120

seems that problem is in these lines

$this->scriptVars['_system']['uri'] = $_SERVER['SCRIPT_URI']; $this->scriptVars['_system']['url'] = $_SERVER['SCRIPT_URL'];

after commenting them everythink works fine (i think)

It seems that Winter 2.1.1 inhibits templates from parsing particularly long pieces of data. We use Winter on WikiPaltz (http://www.wikipaltz.com) and it's like a dream come true. However, after upgrading to 2.1.1, certain templates ceased to function when called with long strings of text. An example can be found here:


 * http://www.wikipaltz.com/index.php?title=Test&oldid=43226

The "WriteLeg" template simply stopped showing with this code with Winter 2.1.1. Thus, we had to revert to 2.1.0. -RadicalHarmony on WikiPedia, JustinHolmes on WikiPaltz

v1.0
All bugs below from v1.0 have been fixed in v1.1 [2 bugs added 05:01, 18 November 2005 (UTC)]
 * nested functions with spaces inbetween the function name and the first pipe cause a time out error. ex: {#var | a  }} .  a work around for this bug is to omit the space.  The followin code works  '{#var| a  }}  This bug was dure to an error in a regular expression and has been fixed for later versions
 * the operator != does not always work as expected. Current work around is to avoid using this operator.  This error was caused because the mediawiki parser prepends an &amp;nbps; to ! if there is a space inbetween it and a |

Questions

 * I tried to run the extension on Mediawiki 1.5.3. It seemed to work, until i tried nested functions like the Example 1 from the mainpage. I always get Error messages about Timouts. Now the server is killed - though i am not sure, if the extension has something to do with it, but it seems so. Any ideas, what i can do about it? mail: tiefling at gmx.de -- Phonkeal


 * strange.. I haven't tested it on 1.5.3 but it works fine on 1.5.2 . You copied example 1 directly and it's not working? Frantik 23:33, 17 November 2005 (UTC)
 * Your email revealed a bug in Winter code.. it doesn't like it if you put a space in between the function name and the first pipe (|). This has been fixed for future releases Frantik 05:01, 18 November 2005 (UTC)

How to enable this extension?
I'v dropped it into extensions directory, but it does not seem to work. It's mediawiki 1.5.2.


 * you need to add require_once("extensions/Winter.php"); to the bottom of LocalSettings.php

Small improvements
Hello, your extension ist very good. But I have a few small improvements still.
 * 1) It could be contained version information
 * 2) The function "wfWinterScriptExtension" needs a return value, since otherwise different extension could not fade in itself into the hook.

to 1. the code

// Process page text using Winter scripting engine function wfWinterScriptExtension( &$parser, &$text) { global $Winter;

$text = $Winter->processText($text);

return true; }

to 2. the code

$wgExtensionCredits['parserhook'][] = array(                                   	    'name' => 'Winter (Wiki INTERpreter)',	                                    'author' => 'frantik',	                                    'url' => 'http://meta.wikimedia.org/wiki/User:Frantik/Winter',                                            'description' => 'Is an extension which adds an interpreted language to Mediawiki pages.',                                            'version' => '1.3.1');

--Thomas Klein 18:40, 11 December 2005 (UTC)


 * Cheers for the advice. I will include these changes in the next update.  Glad you like the extension :) --Frantik 14:23, 14 December 2005 (UTC)

Problems with tables in templates
I have a template with a table. So lines in the table don't include in the table, if the parameter is null.

Template source:

Template call:

What is wrong? --Thomas Klein 21:12, 11 December 2005 (UTC)


 * You need to tell Winter the default values of any value that may be NULL. Include this text at the top of your template page:


 * --Frantik 14:18, 14 December 2005 (UTC)


 * That works!


 * style="background:#FAFAF5"
 * }
 * But not that,


 * }
 * and not that

{{#if| | {{#if| {{{Besonderheit}}} | Why not? --Thomas Klein 21:56, 14 December 2005 (UTC)
 * Besonderes:||
 * style="background:#FAFAF5" }}
 * }


 * It seems as if not all of the code is passed to Winter if it is inside a table. I'll try to see if I can make this work as I'm sure it would be a popular feature --Frantik 23:02, 14 December 2005 (UTC)


 * Ok, I see the problem. The closing }} for the if statement needs to be on a new line, otherwise mediawiki assumes it is part of the table definition.  Try this:

{| border="0" cellpadding="2" cellspacing="1" style="background:#8CAFE6; float:right; margin-left:15px; margin-top:10px; margin-bottom:10px" width="30%" ! colspan="2" align="left" | Mitarbeiter
 * style="background:#FAFAF5"
 * Name:||
 * style="background:#FAFAF5"
 * Tel:||
 * style="background:#FAFAF5"

{{#if| {{{Besonderheit}}} | }}
 * Besonderheit: ||{{{Besonderheit}}}
 * style="background:#FAFAF5"


 * --Frantik 06:30, 15 December 2005 (UTC)


 * That is ok, but not if i use the varibale more than one. --Thomas Klein 07:53, 16 December 2005 (UTC)
 * What do you mean? Can you give an example? --Frantik 11:23, 17 December 2005 (UTC)

nowiki is not honored!
This is really a minor nit -- so far, I love Winter! But I was making an example page for my users, showing entered versus displayed and it appears that Winter merrily cruises right through  tags! So I went to see how you made your Winter code show up, and it appears your examples have formatting inside, which must keep Winter from taking action. --Bytesmiths 05:19, 20 December 2005 (UTC)
 * The example code displays here on meta.wikimedia.org because Winter isn't installed. Nowiki isn't honored because Winter isn't part of the wiki rendering engine, though I can see how there is a need for a way to display Winter code on a wiki that is running Winter so i'll have to add a command --Frantik 16:19, 21 December 2005 (UTC)

Fatal error
returned Fatal error: Call to undefined function: hasparamnum in /wiki/extensions/Winter.php on line 602

Thought you'd want to know. Simetrical 06:08, 9 January 2006 (UTC)


 * To clarify, I was trying to create a function that, given an input x, would go to the page "Units:x" (Units: is a namespace on the wiki I'm using) and return all text between "|dictionary=                 " and "            |category=" (with no quote marks in the file). Simetrical 06:22, 9 January 2006 (UTC)


 * oops, there is a bug in the strpos code. I fixed it for the next release.  The syntax of your function definition has quite a few errors in it though.  You probably only want two } after each var call.. the set of 4 is actualy closing the strpos function before you tell it the string.. ie: your code translates to this:  (strpos (var 1)) "string") when it should be (strpost, (var 1) "string) Frantik 02:02, 12 January 2006 (UTC)
 * actually, i see what you're trying to do.. you need to use a 'trans:' call to get the text of the wiki page. you also might want to use escape characters because mediawiki might try to trans  instead of trans:(pagenane). Frantik 02:59, 12 January 2006 (UTC)

Thanks. I figured I may well have been doing something wrong, but I'm glad to hear I could help you fix a bug as well. What do you mean by a trans: call? , for instance, just gives a redlink to Template:Trans:User:Frantik, and Help:Template makes no mention of a trans: prefix. Simetrical 05:20, 12 January 2006 (UTC)
 * You need to transclude the page. it's not done by trans: like i thought, just by prepending a : to the link (eg  ) Frantik 09:01, 12 January 2006 (UTC)
 * Actually, transclusion works differently depending on the namespace.. your use is probably fine, though you still may want to use escape characters [Transclusion_costs_and_benefits] Frantik 09:28, 12 January 2006 (UTC)

Inefficiency
How resource-efficient is Winter? I would think a string-position search should take near-zero processing time regardless of string length, but a strpos of the form   seems to take forever if I don't get a server error. I'm worried that I'll exceed my server capacity if I use too many of these commands. Is this normal? Simetrical 06:51, 9 January 2006 (UTC)
 * Hmm I would expect it to take very little time as well. let me investigate.  Frantik 01:50, 12 January 2006 (UTC)
 * I fixed this problem as well.. the error was created when strpos returned false. Your query was returning false due to your use of whitespace; strpos was searching for word&lt;/pre> and not just word.    try this:   instread.  Unline most languages, whitespace IS important in Winter.  This is because certain text formatting will cause Mediawiki to add html to it, before Winter sees the code --Frantik 02:15, 12 January 2006 (UTC)
 * On a more general note, I've tried to make Winter as resource efficient as possible. I also have made it a goal to never allow Winter to cause a server 500 error.. if you ever get one please let me know how you got it so i can fix it :) Frantik 02:41, 12 January 2006 (UTC)

Hmm, I've gotten a number of server 500 errors. I'll be sure to make a note of them in the future and tell you.

As for the specific strpos I mentioned, would adding quotes to the string allow me to split it up across lines? It's much easier to read that way for more complicated functions. Simetrical 05:22, 12 January 2006 (UTC)
 * since the problem is wikimedia adding formatting before winter sees it, you might try putting the code inside of a &lt;nowiki> block. Frantik 09:05, 12 January 2006 (UTC)

Problems with Variablename
I have problems with variable some minus sign to have (example: super-param). This variables are not correctly recognized! --Thomas Klein 07:56, 6 February 2006 (UTC)
 * Only alphanumeric characters and _ are allowed in a variable name if you want to use the variable shortcut syntax (ie as opposed to
 * try using "super_param" instead :)
 * Frantik 18:16, 11 February 2006 (UTC)
 * With _, i have the same problem. --Thomas Klein 11:43, 14 February 2006 (UTC)
 * When I add this to a page, it displays 2
 * I'm not sure why _ isn't working on your system. --Frantik 08:07, 16 February 2006 (UTC)
 * I'm not sure why _ isn't working on your system. --Frantik 08:07, 16 February 2006 (UTC)

Simple questions
I have some questions. Can Winter variable be a string or only number? When I write template in Winter, can i use template parametr as Winter variable?
 * variable names and values can be numbers or strings. You can use template parameters just you you normally would in templates:
 * --Frantik 10:41, 24 March 2006 (UTC)

Arrays
I'm trying to get array functionality out of winter. I have a template with the following code in it:

The line in question here is the one with the wiki Image markup. What I'm looking to do is access the template parameter number (i*height)+j+3. This is just the math needed to store a matrix in a 1d array, with an offset since params 1 and 2 are width and height. Right now a call like this:

Evaluates like this: If only those were parsed by the template I'd have my solution! I already tried using ^( instead of ^_(, but that causes the curly braces to be interpreted wrong. Thanks in advance for your help.
 * this problem is occuring because the triple brace variable replacement only occurs once before control is passed to Winter. The best way to solve this is to set the parameters to Winter variables.  Unfortunately you'll have to set them all explicitly, so the code will not allow for an unlimited amount of parameters.


 * Try this:


 * --Frantik 08:48, 11 August 2006 (UTC)

Dynamic categories
I've been using (and loving) Winter now, but came across something I just haven't been able to do. In Winter, this code:

doesn't parse as I'd like it. The hope is to create categories that group items together. Their value is sent to a template and the grouping/categories are done by the template.

The categories seem to be evaluated before winter gets to them, however. In the above example, all items are put in that category.

This: 

Adds either or  to the text of the article - it is not turned into a link or category note.

I've tried some other variations (using #if to add/remove statements, for instance), but haven't had luck. It just seems every way I try the category check is done before Winter is run. I was hoping there was some way or another I could fool the system, but no luck so far. Is there any way this can be done with Winter (or some other tool you know off hand, if Winter runs too late in the process)?
 * I'm not sure if this is possible unfortunately --Frantik 22:35, 11 August 2006 (UTC)

Question on variable scoping
I couldn't find any description of variable scoping. Can I reference a varaiable defined outside of a function inside the function? For example:

foo= rate=

Gives me: foo= rate=20


 * Variables are always local, never global. If you define one outside a function, you cannot use it inside the function, and vice-verse
 * --Frantik 10:58, 17 December 2006 (UTC)

"Call-time pass-by-reference"
I just installed Winter 2.0.1 on MediaWiki 1.10.0 with PHP 5.2.2. I did nothing other than place Winter.php in the extensions directory and add 'require_once("extensions/Winter.php");' to the bottom of LocalSettings.php (similar to many other extensions I have installed). I started getting the error following error on all pages on my site immeditely after installing Winter:

Warning: Call-time pass-by-reference has been deprecated; If you would like to pass it by reference, modify the declaration of call_user_func. If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. in /..../extensions/Winter.php on line 1658

I'm very new to PHP but the documentation on my web host's site seems to incdicate that I can change this setting (allow_call_time_pass_reference) but am advised not to (ie to change the offending PHP instead). Did I install something wrong? Does this PHP setting normally have to be changed when using Winter? Is this indicative of some other problem? Possibly a conflict with another extension I have installed already?

Any help would be greatly appreciated!

Graham. 70.18.28.113 06:02, 12 August 2007 (UTC)
 * Hi Graham,


 * I’ve solved the issue, which I missed because allow_call_time_pass_reference is enabled by default. However it is disabled in the "recommended" setup.  I will release another version shortly. In the meantime you can change these lines to solve the problem:

Line 1643: $ret = call_user_func($functionString[1],&$arr); to $ret = $functionString[1]($arr);

Line 1658 $ret = call_user_func($functionString[1],&$arr, $flag); to $ret = $functionString[1]($arr, $flag);
 * --Frantik 09:58, 12 August 2007 (UTC)

This issue has been resolved in Winter 2.0.2 --Frantik 13:25, 12 August 2007 (UTC)

Hi - I just tried the workaround and the update (2.0.2) - both appear to work just as advertized. Thanks much for the quick fix! - Graham 70.18.28.113 03:47, 13 August 2007 (UTC)

Usage of Winter in MediaWiki Templates
Hello, and thanks for a great extension! We are using mediawiki to arrange a rather large set of articles for our company, and we use templates to automatically generate categories.

The code we have in the article is as follows:

and in the template "Article info", the code is as follows:

This generates the following:

Frameworks: 	Category:ISO 9000Category: ISO 20000

But we would like to have an actual link to the category itself, not just the text.

I understand that this has something to do with the order MW and Winter executes the parser, and I've tried using the &lt;WinterPreWiki&gt; tags.

Is there anything we can do to get this to work?

Thanks a lot for your time in advance, Gustavo
 * The problem comes from the fact that Templates are not loaded until the MediaWiki engine has parsed the page. So you can't load the contents of a template and process it before MediaWiki, and thus you can't create dynamic links using templates.  You might try creating URLs with HTML instead of relying on the MediaWiki parser to create the links. --Frantik 00:40, 20 January 2009 (UTC)
 * Some of this functionality might be possible with Winter 2.2.0 and the include functions --Frantik 10:50, 21 May 2009 (UTC)

strpos returns empty string for first string
Hi there.

This might just be the way I'm using this but consider this example:

{{#strpos|{{#var|Text|hello}} {{#strpos|{{#var|Text|goodbye}} {{#strpos|{{#var|Text|good day}} {{#strpos|{{#var|Text|good night}} The 2nd, 3rd and 4th strpos return a number. However, the first strpos returns null. No doubt because coders always start at zero ;) However, I would expect it to return a zero rather than null though in this case, but it doesn't. So, if you then want to do a #if based on the strpos result, you will never get it to evaluate on the first strpos string. Any idea how I can get around that? I'm using Winter 2.2.0 Thanks! --Mitchelln 17:15, 2 March 2010 (UTC)
 * indeed.. i've fixed it in my source, but i'm not sur when I will release an update. You may wish to update your source code as well.

case 'strpos': if ($param = $this->hasParamNum(3,$functionString)) { $wReturn = strpos($param[1],$param[2], $param[3]); $wReturn = ($wReturn !== false)?$wReturn:''; }						else if ($param = $this->hasParamNum(2,$functionString)) { $wReturn = strpos($param[1],$param[2]); $wReturn = ($wReturn !== false)?$wReturn:'';

is the new source code..

btw you could rewrite your code like this

{{#Text| @= |hello, goodbye, good day, good night}}

{{#strpos|{{#Text}}|hello}} {{#strpos|{{#Text}}|goodbye}} {{#strpos|{{#Text}}|good day}} {{#strpos|{{#Text}}|good night}}
 * --Frantik 15:52, 3 March 2010 (UTC)

Oh, fantastic stuff! Thanks for the quick fix. Saves me a lot of string concat bother to get round the problem Thanks for the usage tip as well, much neater than mine :)
 * --Mitchelln 13:42, 5 March 2010 (UTC)
 * Hmm, just tried the fix above and it still does not work, the following #if does not evaluate true on the first string :(

{{#if|{{#strpos|{{#Text}}|hello}}}} Any ideas? Thanks for your help with this
 * --Mitchelln 13:49, 5 March 2010 (UTC)
 * 0 still evaluates as false, so you need to check that strpos is not an empty string

{{#ThePos | @= | {{#strpos| {{#Text}} | hello}} }} {{#if| {{ {{#ThePos}} | != | "" }} || ....
 * I think that should do it --Frantik 18:15, 6 March 2010 (UTC)


 * Hi. Thanks for getting back to me. Sorry to be a pain, but I just can't get this to work properly. I have:

{{#ThePos | @= | {{#strpos| {{{Icons Codes}}} | Wheelchair Access}} }} {{#if| {{{{#ThePos}} | != | "" }} || {{#Icon:Wheelchair Access.png|Wheelchair Access||Wheelchair Access}}}} and what I get is: !=|| }}

I've tried everything I can think of, I think I must be going crazy! Sorry to be a pain.
 * --Mitchelln 9:03, 8 March 2010 (UTC)


 * my bad.. there's a syntax error..

{{#if| {{{{#ThePos}} | != | "" }} || ...


 * should be either

{{#if| {{#ThePos | != | "" }} || ...


 * or

{{#if| {{#op |{{#ThePos}} | != | "" }} || ...


 * also, i'm not sure if there should be a double pipe in your #Icon code..
 * --Frantik 09:46, 20 March 2010 (UTC)
 * Thanks for that. Got it working! The double pipe in the #icon is the correct syntax for that extension. I use the link= functionality of MW image handling now though - saves an extension!.
 * --Mitchelln 14:03, 21st April 2010 (UTC)

#If statement displays rubbish if bool is a URL
Hi. I've got the following which shows external links if any are present:

Instead of the URL showing, for example: http://www.example.com

What I see is: class="external free" title="http://www.example.com

I'm using Winter 2.2.0 and MW 1.15.1. Any ideas what might be going on?

Thanks! Mitchelln 16:43, 28th April 2010 (UTC)
 * The first thing I notice is the syntax is wrong


 * not sure if that will fix your problem though --Frantik 23:15, 7 May 2010 (UTC)
 * Hi there. Thanks for your reply. Sorry, missing | was a typo in my post. Still doesn't work I'm afraid :(
 * Mitchelln 09:33, 17th May 2010 (UTC)
 * What is the value of Links? I tried using standard wiki text and it worked fine.. these all work as expected:


 * Make sure you read this section of the manual for more info.. it's probably some weird problem with Mediawiki processing the HTML.. class="external  is part of the HTML for a link --Frantik 12:00, 18 May 2010 (UTC)

Operating on spaces
How do I pass explicit space (ascii 32) characters to #strpos and other function? (Winter 2.2.0 on MW 1.15.0)


 * Position of 'W' in 'Robin Williams': returns 6
 * Position of ' ' in 'Robin Williams': returns (empty) not 5

Similarly, { {#explode| |Robin Williams}} does not split at the space delimiter. These functions seem to think nothing is being passed - possibly trimming the input?

How do I force searching for a space in #strpos? The "escape" characters do not list a way to escape a space character.

Oddly, returns (empty), not 0. I suppose false is evaluated as 0 when used in a numeric context, but 0 should be returned so one can test if the string is found (0) vs not found (empty).

--DavidBiesack 14:11, 21 September 2010 (UTC)
 * To define a space you need to use quotes.
 * I'm not sure if i fixed strpos since the last version but it's returning 0 on my wiki  --Frantik 04:47, 24 September 2010 (UTC)

Bug with #if
With this expression:

I expect to get:



but on the Winter Sandbox running 2.2.1 the result is missing the last quote:



On my install running 2.2.0 I get an error:



Will 2.2.1 be available for download soon?

--DavidBiesack 15:37, 24 September 2010 (UTC)
 * it's not a bug.. the trailing " is interpreted differently.. see this section of the manual
 * I still consider this a bug. The parameter does not begin with a, so the last   should not be interpreted as a string close character. (Perhaps if you recognize   as an escaped quote, then I could use that at the end instead of a bare   ?)--DavidBiesack 00:14, 26 September 2010 (UTC)
 * as for when 2.2.1 will be out, i need to check it for security holes for some of the newer functions i added.. but i guess there are some other bug fixes i did like this one so perhaps ill try to do it soon --Frantik 02:01, 25 September 2010 (UTC)
 * thanks. Even a bug fix release would help me integrate this. currently we only have Winter in our test environment; we can't put it into production until this above bug (the ERROR (3): Syntax error" bug above) is fixed/released. --DavidBiesack 00:14, 26 September 2010 (UTC)
 * 2.2.1 released :) --Frantik 03:59, 27 September 2010 (UTC)

Nested #if issues
should yield "level one level two level three", but instead it yields "level one {{#if | 1 ". It looks like the double-pipe from the second #if is being interpreted as the "if false" flag for the first #if. But if you only have two nested #ifs, then it comes out right. --MidnightLightning 13:33, 25 October 2010 (UTC)
 * thanks for pointing this out.. i'll look into it when i get a chance --Frantik 23:05, 26 October 2010 (UTC)
 * this problem has been solved and will be fixed in the next release.. nesting in general just got a whole lot better --Frantik 01:23, 4 November 2010 (UTC)

Security and Winter
Winter allows you to edit the generated HTML, which potentially could allow someone to insert javascript or other malicious html. I'm looking into ways to use the Mediawiki sanitizer to clean the output, but for now it should not be enabled on sites where untrusted users can edit the code. --Frantik 10:09, 4 November 2010 (UTC)
 * I think one way to avoid security issues is to make Winter default to "WinterPreWiki" status, and then add a "WinterPostWiki" tag which will work like Winter does currently. Then i will make "WinterPostWiki" optional. This will ensure that public sites could use Winter without worry of users being able to create arbitrary html/javascript code.  It will cause backwards compatibility problems though unfortunately.  Any comments on this idea? --Frantik 04:05, 5 November 2010 (UTC)