Extension talk:Variables/Archive

The following discussion has been transferred from Meta-Wiki.
Any user names refer to users of that site, who are not necessarily users of MediaWiki.org (even if they share the same username).

Variables and Conditional Parser Functions

It must be noted that everything in conditionals gets executed (though only one result gets displayed). Because of this, every instance of #vardefine will always get executed, regardless of to what the conditional gets evaluated.

Given the following:

{{#vardefine:variable|value}}{{
#ifeq:
    {{#var:variable}}|
    value|
    {{#vardefine:variable|nextvalue}}|
    {{#vardefine:variable|prevvalue}}
}}

{{#var:variable}} gives prevvalue.

Instead you have to nest the conditional inside #vardefine:

{{#vardefine:variable|value}}{{
#vardefine:variable|
    {{#ifeq:
        {{#var:variable}}|
        value|
        nextvalue|
        prevvalue
    }}
}}

In this case, {{#var:variable}} gives nextvalue.

—Sledged 16:12, 24 October 2006 (UTC)

Multiple assignments

It would be good if this extension allowed multiple assignments. Say I have a template data that contains a=1|b=2 . I call {{usedata|data}} and usedata gets one template-variable, a, with value 1|b=2. If I could make data say a=1,b=2 and usedata could call variablesextension to set both variables at once, that would be useful.--201.216.136.95 18:24, 10 January 2007 (UTC)

Bugzilla request

The bug requesting this to be added for the big sites (wikipedia, etc.) is bugzilla:8570. If you really want these functions, go (register and) vote for that bug. If you have an concern, that bug would also be an appropriate place to express it.--201.216.136.95 18:24, 10 January 2007 (UTC)

MediaWiki version 1.9

How is the compability with MediaWiki version 1.9?

End of content from meta.wikimedia.org.
Note that the above conversation may have been edited or added to since the transfer. If in doubt, check the edit history.

use of undefined variables

Sometimes you want to use a variable which has not been set before and you expect it to return an empty string. I suggest to change the code of function "varf" as follows:

 function varf( &$parser, $expr = '' ) {
   if (isset($this->mVariables) && array_key_exists($expr,$this->mVariables)) return $this->mVariables[$expr];
   return '';
 }

84.58.192.102 09:11, 28 January 2008 (UTC)

Number incrementing through page

I'm trying to write a template, two templates in fact, that will increment a number through a page, ie.

{{@@}}
{{@}}
{{@}}
{{@}}
{{@@}}
{{@}}
{{@}}

@@ starts the counter at 1 and prints it and @ increments the number and prints it.

I expect the following to appear:

1 2 3 4 1 2 3

But I get the following:

1 2 2 2 1 2 2

I'm using the following code for the templates.

Template: @@

{{#vardefine:n|1}}{{#var:n}}

Template: @

{{#vardefine:n | {{#expr:{{#var:n}} + 1}}}}{{#var:n}}

Thanks.

--Wahooney 14:05, 11 April 2008 (UTC)

Your problem is that variables don't persist across templates, so you need to pass the value of n from @@ to @. So, your page needs to be:

{{@@}}
{{@|{{#var:n}}}}
{{@|{{#var:n}}}}
{{@|{{#var:n}}}}
{{@@}}
{{@|{{#var:n}}}}
{{@|{{#var:n}}}}

--Snuck 05:31, 15 April 2008 (UTC)

• On a 1.12 version of MediaWiki, I get 1 2 3 4 1 5 6 which is not what was expected, but:

{{@@|{{#var:n}}}}
{{@|{{#var:n}}}}
{{@|{{#var:n}}}}
{{@|{{#var:n}}}}
{{@@|{{#var:n}}}}
{{@|{{#var:n}}}}
{{@|{{#var:n}}}}

gives (to me): 1 2 3 4 1 2 3 . --Nbrouard 14:38, 25 June 2008 (UTC)

{{@@|}}
{{@|}}
{{@|}}
{{@|}}
{{@@|}}
{{@|}}
{{@|}}

is also working with the new parser. --Nbrouard 15:14, 26 June 2008 (UTC)

Multiple inclusions in a template, still counting

Let funcone be the following template:

{{@|}}
{{@|}}
{{@|}}
{{@|}} Inclusion of content
{{{content}}}
Redefining n for second inclusion
{{#vardefine: n|36}}
{{@|}}
{{@|}}
Second inclusion of content
{{{content}}}
after second content

Trying on the following wiki text:

Testing Funcone
{{@@|}}
{{funcone|content=
{{@|}}
{{@|}}
{{@|}}
{{@|}}
{{@|}}
}}
{{@|}}

I get:

Testing Funcone 1 2 3 4 5 Inclusion of content 6 7 8 9 10 Redefining n for second inclusion

37 38 Second inclusion of content 6 7 8 9 10 after second content 39

instead of:

Testing Funcone 1 2 3 4 5 Inclusion of content 6 7 8 9 10 Redefining n for second inclusion

37 38 Second inclusion of content 39 40 41 42 43 after second content 44

Any idea to make substitution earlier? --Nbrouard 13:10, 30 June 2008 (UTC)

Mmmh, until now I thought the default behaviour is, that a variable is global (global means all over the article for all templates which are called from the article). I often use a variable with very special name like "<var:tmp>countCalls</var:tmp>" as "global variable" which is defined in template X. In another call of Template X or another Template Y I can see if the template was already called in this article or not.

Perhaps it should be possible to define local variables {{#vardefine|name|value}} and global vars like {{globalvardefine:name|value}}. So the default would be local variables which are only available at the current call of the template or on the article page but NOT in sub-calls of templates.

On the other hand, perhaps default behaviour should be global variable like it's now in the current version of MW so you would have {{#localvardefine:name|value}} for local ones and {{#vardefine:name|value}} for global ones. Than you could call it with {{#localvar:name}} btw. {{#var:name}}. Global variables are also good for using them as a kind of template parameters in very complex templates which work with semantic forms arraymap function or something like that where you can call a template but can't give common template parameter values.

Normally I would say that local must be the default behaviour of such a variable. But the compatibility to the oder versions of these plugins should be as big as possible and it looks like currently (MW 1.13) all variables are “global”. But perhaps here should be a cut and everybody who wants to use the new version perhaps must change some templates. I hope this is going to be implemented, would be very useful and it would ensure that we could avoid such strange behaviours in the future. --Danwe 22:04, 11 February 2009 (UTC)

I thought about page global variables again and I just came to the conclusion that additional functions to define global/private variables would be to much functions. better would be to define a prefix in globalsettings.php (or an default prefix) which defines global or private variables. The default (private or global) could be defined in the globalsettings as well, so the compatibility to the actual version would be given to each wiki.

{{#vardefine:<GLOBAL>name |value}} for example could define a page global var you can use it with {{#var:<GLOBAL>name}}. Each var which is defined without the prefix would be private by default.

An alternative would be a third parameter in #vardefine like {{#vardefine:name|value|global}}, the default behaviour should be configurable in the localsettings.php too.

I prefer the first method because I already use the prefix <GLOBAL> for variables which I use as global vars yet. But the main reason is that this method has no name conflicts like a private and a global var with same names. --Danwe 11:12, 28 March 2009 (UTC)

Complications

The wiki I work on is on the brink of updating from 1.11 to 1.13 (two days from now). We use a huge number of variables, mostly so we can get data in and out of templates. Some of our templates set many variables meanwhile other templates utilize multiple dynamic variables. We use the variables and templates to centralize information and make editing easier on the user. They can utilize a template that accesses many variables and not have to deal with the very ugly logistics of where the data is coming from.

If you need some examples:

• http://wiki.secondlife.com/wiki/Template:LSL_Param - Variable parameters get floating text by taking the variable name and plucking the description from memory. The user need not know where the information is to have it accessible.
• http://wiki.secondlife.com/wiki/Template:LSL_Constants/PrimitiveParams - Utilizes a huge number of templates to set the values of a huge number of variables, the end result is a table and many additional variables that have accumulated in the process.
• http://wiki.secondlife.com/wiki/llSetPrimitiveParams utilizes the previous templates, the actual source of this articles is very light compared to what it is actually doing for the articles.

What can I do so that I literally don't have to rework 50 to 100 templates and thousands of articles? -- BlindWanderer 21:54, 21 October 2008 (UTC)

How did this turn out? Badon 02:09, 23 September 2011 (UTC)

Default Value

Am I missing how to declare a default value when recalling it? Or does that need to be defined only when defining it? 68.226.0.35 16:58, 8 December 2008 (UTC)

It's not possible to use a default value like {{#var: myVar |defaultvalue if not definded or void}}. I think that would be a great improvement. I really often have to use something like: {{#var:myVar}} what is much more code than only {{#var:myVar |alternativeValue}} would be!

Please, would you add this feature into the plugin? --Danwe 21:46, 11 February 2009 (UTC)

Looks like there is no one left who's developing this plugin. So I decided to release a new version 1.2 which contains this feature. --Danwe 12:53, 28 March 2009 (UTC)

Use in Wikiprojects

Is it planned to install this extension in Wikipedia and other projects too? It would be extremelly useful for creating templates. Nevertheless, now it doesn't work. --Petrus Adamus 22:06, 19 February 2009 (UTC)

I think this is the wrong place to discuss this. Perhaps you should ask that on the wikipedia project page. But I don't think they will use it because every new extension could be a security hole and maybe they are afraid of it would be to complicated and to much for some users. --Danwe 17:01, 21 February 2009 (UTC)

It has been requested here, but the answer was (and still is) "no." —Sledged (talk) 23:47, 25 February 2009 (UTC)

Caching bug?

I think I've found a bug in the extension, using version 1.1 on MediaWiki 1.13.3. Assuming you have ParserFunctions installed, say you have a template called Startthevariable containing {{#vardefineecho:i|1}} and a template called Increasevariable containing {{#vardefineecho:i|{{#expr:{{#var:i}}+1}}}}. Let's say you then run this code in a page:

{{startthevariable}}
{{increasevariable}}
{{increasevariable}}
{{increasevariable}}
{{increasevariable|}}
{{increasevariable}}
{{increasevariable}}
{{increasevariable|}}
{{increasevariable|a}}
{{increasevariable|b}}
{{increasevariable|a}}
{{increasevariable|c}}
{{increasevariable|}}
{{increasevariable|}}
{{increasevariable|}}
{{increasevariable|}}
{{increasevariable}}
{{increasevariable}}
{{increasevariable}}
{{increasevariable}}

The result for this should ideally be 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20. However, the actual result comes out as 1 2 2 2 3 2 2 4 5 6 7 8 9 10 11 12 2 2 2 2. Note the various ways Increasevariable is called, some with a |, and some actually specifying a parameter after it. Also note that it does not have any place to accept those parameters in the template itself. So, to recap, if it isn't called with a parameter, it will always return what it returned the first time it was run. If it is called with a parameter, no matter what the parameter is, it will increment it how it should have been incremented in the first place. It won't cache even if you run it with the same parameter multiple times.

Sorry if this seems a little wordy or weird, or if I haven't explained myself well enough. 98.15.203.22 23:30, 21 March 2009 (UTC)

This is exactly the same what we discussed above under Number incrementing through page.

But this is very strange it's obviously a bug!

My explenation for this phenomenon is that Mediawiki simply calculates the content of templates without parameter one thime and after that all the calls for this template without any parameter getting replaced. After that alle the templates with parameters are calculated one after another because they could have dynamic contents because of the parameters. Template calls without parameter normaly have the same text because there is no variable content inside them. At least untill the variables extension came.

Try the following code as code of increasevariable:

{{#var:i}} '''{{#vardefineecho:i | {{#expr:{{#var:i}}+1}} }}''' &#123;&#123;{{#ifeq:{{{1|<%&>}}}|<%&>|Increasevariable|Increasevariable&#124;{{{1|}}}}}&#125;&#125;<br/>

with this code:

{{#vardefine:i | 1}}
{{increasevariable}}
{{increasevariable}}
{{increasevariable|}}
{{increasevariable}}
{{increasevariable}}
{{increasevariable|}}
{{increasevariable|a}}
{{increasevariable|b}}
{{increasevariable|c}}
{{increasevariable|}}
{{increasevariable|}}
{{increasevariable}}
{{increasevariable}}
{{increasevariable}}

the result is:

1 2 {{Increasevariable}}
1 2 {{Increasevariable}}
2 3 {{Increasevariable|}}
1 2 {{Increasevariable}}
1 2 {{Increasevariable}}
3 4 {{Increasevariable|}}
4 5 {{Increasevariable|a}}
5 6 {{Increasevariable|b}}
6 7 {{Increasevariable|c}}
7 8 {{Increasevariable|}}
8 9 {{Increasevariable|}}
1 2 {{Increasevariable}}
1 2 {{Increasevariable}}
1 2 {{Increasevariable}}

The first number shows the value of #var:i before the template call, the second the value after the call. Behind that you can see the exact template call.

This shows us that the #vardefine and #expr functions itself woriking as expected. I think actually variables only should be used inside one template or page but not as page global variables. I'd love to see such global page variables working like expected. It would be very helpful for some issues. Adding a (void) parameter to any template wich won't need a parameter should help too. --77.191.250.232 02:15, 28 March 2009 (UTC)

Implementation of variable scopes like private, public and static

I am just about to implement the above mentioned private and public variables scope. But there is a big problem and I found no possibility to get rid of it:

I am just able to add the hook Manual:Hooks/BeforeParserFetchTemplateAndtitle into the class which tells me when the parser calls a template, I also can get the name of the template so I know when I have to enter into a new private scope or something. But I still can't find a hook which tells me when the parser is thru with a template. But I need to know wich part of the template the parser handles when he found an variables parserfunction so I could take the variable from the right variables scope. Any ideas? --Danwe 23:32, 11 May 2009 (UTC)

varexists function

A function with which it's possible to check if a variable already is defined would be helpful. You can use {{#if: {{#var:i}} |defined |void/undefined}} but it could be possible that a variable is defined but only has an void content, it's not possible to differ between void but defined and undefinet variables yet. --77.191.148.245 10:54, 28 March 2009 (UTC)

I just added this and released a new version 1.2 with varexists function and the possibility to add a parameter to var function which contains a string which is the output when the variable is void or undefined. --Danwe 12:50, 28 March 2009 (UTC)

The #varexists: function of the 1.2 version seems to have a slight bug, in that it assumes there is at least one variable already defined on your page (to have triggered creation of the mVariables array). Invoking it on a page where there are (yet) no variables defined generates a PHP error message complaining about the second argument to array_key_exists(). See #Accept Command Line Args below for the code. --Paul Lustgarten 20:45, 30 March 2009 (UTC)

Thanks, I just added this little change in the extension code. --Danwe 18:27, 6 April 2009 (UTC)

Accept Command Line Args

In using this extension, we find it useful to have the option of defining variables within the page's URL (e.g., tacking on "&fish=swimming&cow=moo" to define the variables "fish" & "cow" to have the values "swimming" and "moo", respectively). This is like assimilating the function of the #arg: parser function from the Extension:DynamicFunctions extension.

Also, specific to the new 1.2 version, we find some boundary conditions where the mVariables array is referenced before being defined, so propose that it be automatically defined as part of the class.

Here are the modified portions of the v1.2 Variables.php code incorporating these changes, for your consideration:

class ExtVariables {
	var $mVariables = array();
		
	function varf( &$parser, $expr = '', $defaultVal = '' ) {        
		global $wgRequest;
		if (!array_key_exists($expr, $this->mVariables)) {
			$val = $wgRequest->getVal($expr);  # pull value from command line, err, URL
			if ($val != NULL) {
				$this->mVariables[$expr] = $val;
			}
		}
		if (array_key_exists($expr, $this->mVariables)) {
			return $this->mVariables[$expr];
		}
		return $defaultVal;
	}
	
	function varexists( &$parser, $expr = '' ) {
		global $wgRequest;
		if (!array_key_exists($expr, $this->mVariables)) {
			$val = $wgRequest->getVal($expr);  # pull value from command line, err, URL
			if ($val != NULL) {
				$this->mVariables[$expr] = $val;
			}
		}
		return array_key_exists($expr, $this->mVariables);
	}
}

This extends the #var: and #varexists: functions to pull a variable's definition from this page's URL (if a definition is present there), if that variable is not already defined in the mVariables array.

It also guarantees that the mVariables array always exists, so we can successfully call #varexists: on a wiki page in which no variables have yet been defined. --Paul Lustgarten 20:55, 30 March 2009 (UTC)

I'am not sure if I understood that poperly. You want to use page parameters to define vars. But what if you'd like to define a var called action which is a page parameter which already has a meaning on MW? Isn't a syntax like &var_fish=swimming&var_cow=moo a better one?

Your code is not working for me, I tried &fish=swimming&cow=moo in the url and added {{#var:fish|fish not defined!}} and {{#var:cow|cow not defined!}} to the page. The result was the alternative text. Shouldn't be the result swimming and moo? --Danwe 18:40, 6 April 2009 (UTC)

The first character of the query portion of a URL needs to be a "?", not a "&". Try adding ?fish=swimming&cow=moo to the URL.
--Paul Lustgarten 15:00, 17 April 2009 (UTC)

There is also still another bug in your modified code. Void variables with default values like {{var:definedbutvoid |defaultvalue}} return a void string instead of defaultvalue. Per definition in the current version 1.2.2 the output for defined but void variables AND for undefined variables should be defaultvalue. --Danwe 14:03, 15 April 2009 (UTC)

Danwe - Those are good points you raise.
I, likewise, had run into the collision with internally-used variable names such as "action". The solution I have implemented now works, but yours (using a "var_" prefix on each variable) is probably better. Part of the challenge (which I have now solved but hadn't when I first posted this) is how to change the core wiki code itself (in includes/Title.php) so that one can provide variables as part of an internal page link - the best syntax for which I've been able to come up with being this:
  [[Some page ?fish=swimming&cow=moo|Nice name for what that does]]
(I'd love to simplify/improve on that syntax somehow - any suggestions?.) And that then motivates changing includes/parser/Parser.php to remove the suppression of selflinks, so that we can even do this:
  [[{{PAGENAME}} ?fish=swimming&cow=moo|Nice name for what that does]]
Combined with some #if:'s, we can start to craft some interestingly adaptive pages!
And I hadn't noticed that refs to a void var return its default value. I'm working to meet a deadline these next couple weeks (to demo the stuff I'm building for which this is one of the building blocks, in fact), and will post a new & improved set of changes after I'm clear of that. (And I fixed my email prefs on this wiki so I'll be notified of comments; I didn't see yours until yesterday :-( )
--Paul Lustgarten 15:00, 17 April 2009 (UTC)

dead and unused code

1. Why is "author" defined twice?
2. Why is "$wgMessageCache" included twice but never used?

I think the answer to these questions is that people forgot to remove them. -- BlindWanderer 16:03, 11 May 2009 (UTC)

I think I forgot to remove the first one perhaps. Removing $wgMessageCache shouldn't be a problem, don't know why this was declared perhaps it was used before. --Danwe 23:23, 11 May 2009 (UTC)

Minor bug: Undefined index in Variables.php on line 33 (function varf)

Replace

    function varf( &$parser, $expr = '', $defaultVal = '' ) {        
        if ( $this->mVariables[$expr] != '' ) {
            return $this->mVariables[$expr];
        } else {
            return $defaultVal;
        }
    }

by

    function varf( &$parser, $expr = '', $defaultVal = '' ) {
        if ( array_key_exists($expr, $this->mVariables) && $this->mVariables[$expr] != '' ) {
            return $this->mVariables[$expr];
        } else {
            return $defaultVal;
        }
    }

--F.trott 09:27, 28 August 2009 (UTC)

Toggle Variable

Just a simple solution I needed to toggle a variable between two values. Maybe someone can use it.

    function vartoggle( &$parser, $expr = '', $val1 = '1', $val2 = '0' ) {                                         
        if ( $this->mVariables[$expr] != $val1 ) {                                                                 
            $this->mVariables[$expr] = $val1;                                                                      
        } else {                                                                                                   
            $this->mVariables[$expr] = $val2;                                                                      
        }                                                                                                          
        return '';                                                                                                 
    }                                                                                                              
                                                                                                                   
    function vartoggleecho( &$parser, $expr = '', $val1 = '1', $val2 = '0' ) {                                     
        if ( $this->mVariables[$expr] != $val1 ) {                                                                 
            return $this->mVariables[$expr] = $val1;                                                               
        } else {                                                                                                   
            return $this->mVariables[$expr] = $val2;                                                               
        }                                                                                                          
    }

Usage:

{{#vartoggle:variablename |value1|value2}}

Toggle variable between value1 and value2. value1 will be the default value if the variable is undefined or has no matching value. If no values are specified the default values 1 and 0 will be used.

{{#vartoggleecho:variablename |value1|value2}}

Same as #vartoggle but with output.

Examples:

{{#vartoggle:bool}}

Toggle variable bool between 1 and 0.

{{#vartoggleecho:foo|odd|even}}

Toggle variable foo between odd and even with output.

—Cbaoth 18:06, 05 December 2009 (CET)

Perhaps for $val2 $val2='' would be a better default value because it would be like true and false than. 0 is not really like false when you ask with parser functions for true it will return true.

All in all I think that this is a very particular function which would be better off in a common template than as a variable function --Danwe 16:35, 18 December 2009 (UTC)

vardefineecho works, but vardefine doesn't?

I'm trying to use vardefine in a template, but it doesn't seem to work. Vardefineecho does, however. If I use the following code:

{{#vardefine:testvar|testvalue}}
{{#varexists:testvar}}

the page shows this:

{{#vardefine:testvar|testvalue}}

which seems to imply the vardefine function doesn't even get called. However, if I use this:

{{#vardefineecho:testvar|testvalue}}
{{#varexists:testvar}}

the page shows this:

testvalue 1

which is what you would expect. I looked at the extension's source, and the only difference between the two functions is that vardefine returns an empty string and vardefineecho returns the variable's value. What is going on here? RdeRoos 09:09, 24 January 2010 (UTC)

Strange. It works for me both ways. The first example simply displays 1. I even tried it in a void template. --Danwe 22:52, 26 January 2010 (UTC)

Yeah, I'm completely baffled by this. Guess I'm going to randomly try things and hope I find a solution. If I find one, I'll post it here, should anyone else run into this problem --RdeRoos 11:21, 28 January 2010 (UTC)

Here is my fix for the problem. Open the Language.php, which you can find in the folder languages, search there for the row with the following content: "function getMagic( &$mw )" that you have to replace with "function getMagic( $mw )". After that edit the article and save it again and it works. --H3llGost 22:47, 28 January 2010 (UTC+1)

#varundefine suggested

This seems like a very nice extension, which would be useful for avoiding error in repeatedly coalling the approprate form of a template -- for example, in switching between showing and suppressing endnote "superscripts" in fact-checked children's books like the Wikijunior books. (bugzilla:3264).

I think it might be useful to include #varundefine in the extension. Would something like the following be appropriate for the associative splice

    function varundefine( &$parser, $expr = '', $defaultVal = '' ) {   

	if array_key_exists($expr, $this->mVariables) {
		$keys=$array_keys($this->mVariables);
		$vals=$array_vals($this->mVariables);
	
		$index=array_search($expr, $keys, true);
	
		array_splice($keys, $index, 1);
		array_splice($vals, $index, 1);
		$this->mVariables=array_Combine($keys, $values);
		return $defaultVal;
	}
        else return '';
}

--SV Resolution 15:58, 29 January 2010 (UTC)

Please describe what exactly this function should be good for and what the function is supposed to do. --Danwe 08:18, 1 August 2010 (UTC)

Extension breaks code

This extension is breaking the coding on my wiki here. I don't know how to make it work correctly. Any suggestions?Neo of ZW 18:01, 13 February 2010 (UTC)

Nevermind. I resolved the problem.Neo of ZW 07:03, 14 February 2010 (UTC)

Big Job Queue/Import bug solved in 1.3

There was a critical bug which lead to variable values being global between pages. When you import pages with Special:Import and the first page A uses a variable x, your second page B uses this variable to but doesn't define it first, the value from page A is the value which gets printed in page B when calling #var: function. I solved this bug in version 1.3 by using the ParserClearState hook. The bug also happened in some job queue scenarios and on Extension:Semantic MediaWiki data refreshments. I solved this bug in Extension:ArrayExtension and Extension:HashTables as well. --Danwe 12:22, 20 July 2010 (UTC)

Well, I'm using the VariablesExtension and ArrayExtension here. A few weeks ago I updated the MediaWiki-Software (1.16.0) and, by the way, the used extensions, too. Both extensions, VariablesExtension (1.3) as well as ArrayExtension (1.3.1), do not operate accurate. You define a variable ({{#vardefine:x|12}}). Followed by some template calls using this Extension:DynamicPageList (third-party). And after those calls you need the data of the before defined variable. With VariablesExtension (1.2.2) no problems, I get 12. Using the current version, I get an empty string. And it's no matter whether those templates using variables or not- --Wgkderdicke 00:44, 30 August 2010 (UTC)

Sounds like a bug provoked by the DynamicPageList extension. Somehow this extension seems to trigger the ParserClearState hook even before the parser has finished rendering the current article. This can cause bugs in several extensions. Somebody should look into this, I will add a topic on the DynamicPageList talk page.

Most interesting would be to know, did this happen with MW before 1.16 as well? --Danwe 04:30, 31 August 2010 (UTC)

Update/Solution: I have found the source of this problem, it's because of that extensions calling Parser::parse() while it shouldn't. See Extension talk:DynamicPageList (third-party)#Problems with VariableExtension. --Danwe 00:35, 24 July 2011 (UTC)

actually, Parser::parse() will also be called in case of $wgOut->parse() and therefore with some of the wfMsg() functions which use that function in some cases! So you shouldn't use these functions during main parsing process or it will call ParserClearState as well! --Danwe 21:03, 27 September 2011 (UTC)

Can we add this to the MW SVN?

So we can get it i18n'd properly etc?

You can apply for commit access at Commit_access_requests

Reedy 21:08, 31 July 2010 (UTC)

No ?> ending tag?

Is it correct that Variables.php and Variables.i18n.php both have the opening <?php tag, but no closing ?> tag? --DragoonWraith 15:27, 2 November 2010 (UTC)

They're neither needed nor useful, so MediaWiki's coding standard requires them to be absent. Max Semenik 15:53, 2 November 2010 (UTC)

Substitution

Is there a way to do a substitution with variables? For example I have a variable defined, say {{#vardefine:NAME|Joe}}, and now i want to do a {{subst:#var:NAME}}, in order to have only the value of the NAME-variable "Joe" edited in? --Theaitetos 09:11, 4 February 2011 (UTC)

I don't get the point here. subst is a function for the use with templates, not parser functions, isn't it? --Danwe 05:13, 7 February 2011 (UTC)

My specific problem: I generated a template {{CLEAN}} with the VariablesExtension that cleans up special characters in the specified parameter (usually a page) and replaces them with normal characters, e.g. é → e, û → u, ä → a, et.al. I define the template parameter as my variable XCLEANX, then I run a replace function for every special character that needs to be replaced on that variable in succession (can't run them all nested due to expansion depth limit), i.e. {{#vardefine:XCLEANX|{{#replace:{{#var:XCLEANX}}|é|e}} }}, {{#vardefine:XCLEANX|{{#replace:{{#var:XCLEANX}}|ê|e}} }}, ... The template works the way it should, so no problem there. Now I'm trying to figure out how to get the final cleaned up text into a page. Subst:template would just insert the entire template code itself into the page, which is completely unnecessary, since all I want is to have the value of {{#var:XCLEANX}} inserted, the purged text. I called it a "substitution" since that is pretty intuitive, although I tried coding it as a parameter inside the template, i.e. "if: , then xxx". Now I'm trying to figure out a way, so that the template, when given "subst=yes" (e.g. {{CLEAN|subst=yes}}, will just edit in the value of the variable like the substitution of a magic word so to speak ({{subst:PAGENAME}}). It's really annoying to have that depth limit around; when coded with nested replace functions, i.e. {{#replace:{{#replace:{{#replace: ... {{{1}}} |á|a}}à|a}} ... }} it can be easily substituted, but only with 40 replacement calls. When coded with successive variables, I get all the calls I need, but can't substitute it... Is there a way, will I have to create such a new magic word with the MagicWordExtension or do I have to give up on it altogether? --Theaitetos 17:44, 7 February 2011 (UTC)

+1 for this one, I also need to calculate an expression but variables are not substituted correctly.

For example, I have a template "Sum" like

{{#expr: {{#var:{{{1|}}}}} + {{#var:{{{2|}}}}} }}

Using

{{#vardefine:A|1}}{{#vardefine:B|2}}{{Sum|A|B}}

gives 3, but the wikitext is still

{{#vardefine:A|1}}{{#vardefine:B|2}}{{Sum|A|B}}

But if I want to substitute it, so that the resulting wikitext is just "3", then "Sum" would have to be:

{{ {{{|safesubst:}}}#expr: {{ {{{|safesubst:}}}#var:{{{1|}}} }} + {{ {{{|safesubst:}}}#var:{{{2|}}} }} }}

but using

{{#vardefine:A|1}}{{#vardefine:B|2}}{{subst:Sum|A|B}}

returns

{{#vardefine:A|1}}{{#vardefine:B|2}}<strong class="error">Expression error: Unrecognised punctuation character "{"</strong>

Instead, if I define "Sum" as:

{{#expr: {{ {{{|safesubst:}}}#var:{{{1|}}} }} + {{ {{{|safesubst:}}}#var:{{{2|}}} }} }}

using

{{#vardefine:A|1}}{{#vardefine:B|2}}{{subst:Sum|A|B}}

I get

{{#vardefine:A|1}}{{#vardefine:B|2}}{{#expr: + }}

Thanks, --Mindrones 17:01, 23 July 2011 (UTC)

Thank you so much Mindrones, it may not have worked for you, but it did for me, silly as I am. My template – which can even be replaced now – looks like this:

{{ {{{|safesubst:}}}#vardefine:CLEAN|{{{1|{{ {{{|safesubst:}}}PAGENAME}} }}} }}{{ {{{|safesubst:}}}#vardefine:CLEAN|{{ {{{|safesubst:}}}#replace:{{ {{{|safesubst:}}}#var:CLEAN}}|ä|a}}}}
{{ {{{|safesubst:}}}#vardefine:CLEAN|{{ {{{|safesubst:}}}#replace:{{ {{{|safesubst:}}}#var:CLEAN}}|â|a}}}}
{{ {{{|safesubst:}}}#vardefine:CLEAN|{{ {{{|safesubst:}}}#replace:{{ {{{|safesubst:}}}#var:CLEAN}}|á|a}}}}
{{ {{{|safesubst:}}}#vardefine:CLEAN|{{ {{{|safesubst:}}}#replace:{{ {{{|safesubst:}}}#var:CLEAN}}|à|a}}}}
{{ {{{|safesubst:}}}#vardefine:CLEAN|{{ {{{|safesubst:}}}#replace:{{ {{{|safesubst:}}}#var:CLEAN}}|Ä|A}}}}
{{ {{{|safesubst:}}}#vardefine:CLEAN|{{ {{{|safesubst:}}}#replace:{{ {{{|safesubst:}}}#var:CLEAN}}|Â|A}}}}
{{ {{{|safesubst:}}}#vardefine:CLEAN|{{ {{{|safesubst:}}}#replace:{{ {{{|safesubst:}}}#var:CLEAN}}|Á|A}}}}
{{ {{{|safesubst:}}}#vardefine:CLEAN|{{ {{{|safesubst:}}}#replace:{{ {{{|safesubst:}}}#var:CLEAN}}|À|A}}}}
{{ {{{|safesubst:}}}#vardefine:CLEAN|{{ {{{|safesubst:}}}#replace:{{ {{{|safesubst:}}}#var:CLEAN}}|ö|o}}}}
{{ {{{|safesubst:}}}#vardefine:CLEAN|{{ {{{|safesubst:}}}#replace:{{ {{{|safesubst:}}}#var:CLEAN}}|ô|o}}}}
{{ {{{|safesubst:}}}#vardefine:CLEAN|{{ {{{|safesubst:}}}#replace:{{ {{{|safesubst:}}}#var:CLEAN}}|ó|o}}}}
{{ {{{|safesubst:}}}#vardefine:CLEAN|{{ {{{|safesubst:}}}#replace:{{ {{{|safesubst:}}}#var:CLEAN}}|ò|o}}}}
...
{{ {{{|safesubst:}}}#vardefine:CLEAN|{{ {{{|safesubst:}}}#replace:{{ {{{|safesubst:}}}#var:CLEAN}}|ß|ss}}}}
{{ {{{|safesubst:}}}#var:CLEAN}}

--Theaitetos 09:31, 26 August 2011 (UTC)

Determing value of a variable at a given article position when executing hook script

Before saving an article we scan in our ArticleSave hook article WikiText if there is used a special tag.

If so we have to generate additional actions depending on parameter value of this tag.

At this point parameter can be variables - so we need to determine the value of this variable.

{{#var:variablename}}

is useful only in original WikiText context...

Any suggestions?

Baumbuwewiki 14:05, 10 February 2011 (UTC)

(Great extension BTW!)

I think I understand what you're asking. If you want to get the value of a variable, from within an extension, i would think that you could set a variable equal to the wikitext, such as: $var1 = '{{#var:variablename}}'; Then you parse $var1, and that would give you the value. I think this should work. Hopefully that's what you were trying to get. --Duke33 18:04, 17 March 2011 (UTC)

Variables Become Unset When Transcluding a Special Page (solved in 2.0)

When the script was upgraded from 1.2.2 to 1.30, a new bug was introduced. If you transclude a special page, all of the defined variables will be lost. Here's an example:

{{#vardefineecho:a|123}} {{Special:Newpages/3}} {{#var:a}}

It will print "123" the first time, but it won't print the 2nd time, which is after the transclusion of the special page. The culprit is the fact that the ParserClearState hook is clearing the variables. It was introduced to stop passing variables from page to page on imports and job queue jobs. However, it had this unintentional side effect. Does anyone have any ideas on how it could be fixed? --Duke33 14:08, 17 March 2011 (UTC)

I chatted in the MW irc about this problem, I think this bug is related to MW bug 16129

Transcluding a special page doesn't create a new parser instance, that seems to be the problem. I see no clean workaround right now since the parser object is the same for each call of ParserClearState which makes it impossible to find out whether the hook is called from transcluding a Special page or after finishing the parsing of the current page.

Just got an idea how to work around another way: Whenever accessing the variables array we've got to check whether the parser object is still the same, if so, we restore the old array. Therefore we have to make a copy of the array during ParserClearState. This could have other side effects though, I don't really know whether the parser object changes after the one ParserClearState call where we actually really want to reset that variables array (in case of page imports or job queue). Another solution would be to find other hooks where we could empty the array. For example before imports and job queue but it has to be reseted after each page within the import/job queue as well! --Danwe 14:55, 19 March 2011 (UTC)

I have just released Variables 2.0 which solves the problem entirely. This bug was not really related to bug 16129 entirely, just the fact that there are several Parser instances and when one of them finishes, it would reset all variables. Old Variable extension versions didn't have the problem therefore they had another bug which I resolved in Variables 1.3 but which has introduced this bug (which is less critical though). Since this has changed the whole extensions structure, its 2.0 now. Should also work much better with certain other extensions. --Danwe 16:28, 17 November 2011 (UTC)

Variables become unset when using TreeAndMenu extension

Variables are deleted after I use the {{#tree:....}} markup.

Example:

{{#vardefine:name|John}}
My name is {{#var:name}}.
{{#tree:
*Root1
**Sub-item
**Another sub-item
*Root2
**Sub-item
**Another sub-item
}}
My name is {{#var:name}}.

returns:

My name is John.
<collapsible tree>
My name is .

--Mindrones 10:55, 18 June 2011 (UTC)

The only explanation (without looking into this too deep) I can think of is that this extensions is triggering the ParserClearState hook early, had the same problem with Extension:DynamicPageList (third-party) apparently (see Extension talk:Variables/Archive#Big_Job_Queue.2FImport_bug_solved_in_1.3). You should post the same report there since there is not much we can do about this. The hook is essential to prevent Variables extension from that super global variables mess described above. Off course you could take your chance and disable the use of that hook and see whether it works. The chance that this will mess up a lot in your Wiki is not that high, depends on how excessive you are using variables extension, your Job queue configuration and some other circumstances. --Danwe 00:04, 24 July 2011 (UTC)

Edit: I have looked into it a bit deeper and posted the result at Extension talk:TreeAndMenu#Don't use Parser::parse(), so it's up to them to fix this problem now.

Great, many many thanks for being so responsive :) --Mindrones 12:41, 24 July 2011 (UTC)

Special:Version won't display

For some reason when i enable this extension my special:version page ceases to display. I get a HTTP 500 Internal Server Error. Everything else seems to work alright. I am using MW 1.16.5 with PHP 5.3.2 (Apache) and MySQL (5.0.41-log)

Solving multiple parser issues

Apparently, some extensions such as Extension:DynamicPageList are having problems with Variables Extension. This might be due to their own fold when they are using recursive calls to Parser::parse() (which is also used by a few other core functions, including some rare cases of wfMsg...() ) but it might be the fold of this extension as well. Whats happening is that when one parser clears its state (on ParserClearState) all variables will be flushed. This is actually happening on most parser initializations. I think MW itself doesn't really use several parser instances for anything, at least I never ran into problems with that. But extensions might do. We can solve this by:

1. Using ParserFirstCallInit instead of $wgExtensionFunctions[]-array to initialize (should be done anyway!)
2. Binding variables to parser instances. This means instead of having one global variable scope, we have one per parser and therefore this scope is only valid during one parser objects parsing process until THIS parser object is clearing its state. We can simply set $parser->mExtVariables to bind it to the object, just not sure whether it is good coding style to add a public member from outside the object but I can't see why. And with each call of a Variables parser function we will get the parser object.

Perhaps I will write a new Variables Extension for that since everything will work a little bit different. It also would be worth a thought to make the new Variables Extension a requirement for Extension:ArrayExtension and Extension:HashTables which could adopt the system in an object oriented manner so it wouldn't be necessary to change the system in each extension at every time when we had to make any adjustments. Also, nobody really feels responsible for this extension I guess and since the original author vanished without leaving any copyright information, I would prefer starting from the scratch. --Danwe 01:08, 19 October 2011 (UTC)

I pretty much rewrote the extension as described above now. It should work with MW 1.12+ up to MW 1.19 trunk (tested with 1.17 and 1.19). It's going to be Variables 2.0 and will introduce a new parser function #var_final as well. You can get it here and test it if you wan't, I'll have to adjust other extensions using Variables (like Extension:Loops) to ensure compatibility before releasing it. ArrayExtension and HashTable extensions will be next for getting the same internal changes done. --Danwe 02:44, 14 November 2011 (UTC)

Thank you so much! I came here to see if I could find a fix/workaround for the global variables issue (which I do not need and causes problems), and this appears to be exactly what I need. I will test it soon. Also, I think you meant to link here: Special:Code/MediaWiki/102931 (same, without preceding '/'). Also, some people would probably just want the svn link. --Dror Snir 18:56, 17 November 2011 (UTC)

Magic word 'var' not found

I installed the Variables extention (on MW 1.15.1, php 5.2.9.2). You state that the extention is compatible with MW 1.12+, but I get an error: "Magic word 'var' not found". Is the extention really compatible? Upgrading the wiki is not an option, but I would like to try previous versions of your extention. But at the download page I only have the option to download the development version. I understand that version 2.0 is a rewrite, so maybe versions <2.0 will work for me.

I am also hoping to use Loops, but again I only have the development version available.

So can you make previous versions downloadable? --ArjenCW 12:04, 10 January 2012 (UTC)

ArjenCW, I found 1.3.1.1 worked for my MW 1.15, PHP 5.3. Got it straight from SVN: svn co svn://svn.wikimedia.org/svnroot/mediawiki/tags/extensions/Variables/REL_1_3_1_1 Variables-1.3.1.1. 2001:470:1F08:1336:0:0:0:2

#vardefine generates linebreak

Each time I set a new vardefine in my wiki code a line break is generated on the processed content. How can I avoid this line break?

1. vardefine should not output anything to the wiki page, right?

Are you sure it's the vardefine that's outputting a linebreak and not that you have it on a separate line? --Nad (talk) 16:57, 2 July 2012 (UTC)

I have this same issue. I have thirty vardefines on separate lines. This is intentional, as users come to this page to add and update these variables and I want it to be clear where the data they need to enter is to be input. Having a vardefine on a separate line makes this very obvious. There is no linebreak issue if I delete the separate lines, but it makes the source harder to understand. Is there a way to keep the vardefines on separate lines in the source, but to prevent or avoid the linebreaks appearing on the page? --Mjollnir (talk) 23:21, 5 March 2013 (UTC)

I had the same issue until I put <!--

--> in. I still had the code separated out and easy to read and it didn't create the 'empty space' (im at work and it wouldnt let me log in, Tregelen)

I tried using a standard HTML comment as suggested above, but this broke the variable definitions and the variable usages were blank. I solved this problem by wrapping my variable defs inside a floating div that essentially renders empty (since the variable def contents are just empty p and br tags.

 <div style="float:right;"><!-- yes, this a bit of a hack -->
    // variable definitions //
 </div>

--Planoie (talk) 18:57, 14 May 2014 (UTC)

Nested templates

Good time of day! I have a question about variables in nested templates.

I have template Begin which starts new table of items and increase current level by 1. Something like this:

{{#vardefine:level|{{#expr:{{#var:level|0}}+1}}}}

and consistent code in the End template. Page tries to use nested templates, like this:

{{Begin}}
 {{Item
 | …
 |list=
  {{Begin}}
  {{Item|…}}
  {{End}}
 }}
{{End}}

In this situation low-level template is parsed the first, so my first code doesn't work. Is here some workaround?

I've looked at subst and safesubst, but haven't found that it can be applied in this case. --Grv87 (talk) 20:01, 8 December 2012 (UTC)

What do you mean by low level template? Are you referring to the {{End}} template? This is not parsed first, but it will be cached when used the first time because it doesn't use parameters, so the parser thinks that it can cache the template and rather than re-parsing it each time, it will just insert the cached output from the first time. So if you calculate something dynamically there, you should use {{End|}} instead, this will work. --Danwe (talk) 23:23, 9 December 2012 (UTC)

Calling variable from another page in the same template

Hi all,

I've been wondering how do I call a variable of a particular page found in the same template which I've defined the variable in? The thing is, even though the variables are of the same name, the values for each particular page is unique (or at least, may differ). Can I just simply use something in the likes of {{#ask: {{{Fullpagename}}} {{#var: variablename}} }} or how do I go about doing it?

Cheers, Jonathan

Sorry, I really do not understand. What do you mean with "a variable of a particular page"? The variable does not matter during whose pages rendering process it got generated and you can not magically get the variable created during another pages rendering process. The livecycle of a variable is the rendering of one page. Also, there is no #ask or are you referring to Semantic MediaWiki in some way? --Danwe (talk) 20:16, 14 August 2013 (UTC)

Default values for vardefine and vardefineecho

There are situations, particularly in complicated template code where variables are being used for parameter preprocessing, where being able to use default values on #vardefine and #vardefineecho (that is, {{ #vardefine: myVar | value | default }}, mirroring the syntax for #var) would allow the code to be simplified. Consider the following code (note that it also makes use of Extension:Arrays; if you'd like an explanation of what any of it does, or what it's for, leave me a message on my talk page =) ):

{{ #vardefine: $size | {{ #replace: {{{size|}}} | px }} }}<!--
-->{{
  #if: {{ #pos: {{ #var: $size }} | x }}
  | {{ #arraydefine: $size | {{ #var: $size }} | x }}<!--
    -->{{ #vardefine: $size_w | {{ #iferror: {{ #expr: {{ #arrayindex: $size | 0 }} }} }} }}<!--
    -->{{ #vardefine: $size_h | {{ #iferror: {{ #expr: {{ #arrayindex: $size | 1 }} }} }} }}
  | {{ #vardefine: $size | {{ #iferror: {{ #expr: {{ #var: $size }} }} }} }}
}}

-->{{ #vardefine: $width  | {{ #iferror: {{ #expr: {{ #replace: {{{width|}}} | px }} }} }} }}<!--
-->{{ #vardefine: $width  | {{ #var: $width | {{ #var: $size_w }} }} }}<!--

-->{{ #vardefine: $height | {{ #iferror: {{ #expr: {{ #replace: {{{height|}}} | px }} }} }} }}<!--
-->{{ #vardefine: $height | {{ #var: $height | {{ #var: $size_h }} }} }}<!--

-->{{ #vardefine: $size   | {{
  #if: {{ #var: $height }}
  | {{ #var: $width }}x{{ #var: $height }}
  | {{ #var: $size | {{ #var: $width | 122 }} }}
}} }}

If #vardefine and #vardefineecho offered default value functionality, the code could be simplified as follows:

{{ #vardefine: $size | {{ #replace: {{{size|}}} | px }} }}<!--
-->{{
  #if: {{ #pos: {{ #var: $size }} | x }}
  | {{ #arraydefine: $size | {{ #var: $size }} | x }}<!--
    -->{{ #vardefine: $size_w | {{ #iferror: {{ #expr: {{ #arrayindex: $size | 0 }} }} }} }}<!--
    -->{{ #vardefine: $size_h | {{ #iferror: {{ #expr: {{ #arrayindex: $size | 1 }} }} }} }}
  | {{ #vardefine: $size | {{ #iferror: {{ #expr: {{ #var: $size }} }} }} }}
}}<!--

-->{{ #vardefine: $width  | {{ #iferror: {{ #expr: {{ #replace: {{{width|}}} | px }} }} }}  | {{ #var: $size_w }} }}<!--
-->{{ #vardefine: $height | {{ #iferror: {{ #expr: {{ #replace: {{{height|}}} | px }} }} }} | {{ #var: $size_h }} }}<!--
-->{{ #vardefine: $size   | {{
  #if: {{ #var: $height }}
  | {{ #var: $width }}x{{ #var: $height }}
  | {{ #var: $size | {{ #var: $width | 122 }} }}
}} }}

Of course, this is all assuming I'm missing some blatantly obvious, already-existing functionality of Extension:Variables, but as far as I can see, no such functionality is currently implemented. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 04:56, 29 July 2013 (UTC)

I've had pointed out to me a far simpler example of a case where this functionality would help simplify code. It would allow this code:

{{ #vardefine: $pagename | {{ #if: {{{name|}}} | {{{name}}} | {{PAGENAME}} }} }}

to be simplified by removing the #if:

{{ #vardefine: $pagename | {{{name|}}} | {{PAGENAME}} }}

「ディノ奴千？！」^{? · ☎ Dinoguy1000} 10:52, 12 August 2013 (UTC)

First, what you were pointed out to is a wrong example, it should be:

{{ #vardefine: pagename | {{{name|{{PAGENAME}}}}} }}

BUT {{{name|{{PAGENAME}}}}}} will still result in an empty string in case you call the template with an empty parameter, e.g. {{myTemplate|name=}}. So depending on how you want this to behave, you don't want to use that and still use {{ #if: {{{name|}}} | {{{name}}} | {{PAGENAME}} }} }} instead!

Now, about your actual suggestion. If I understand you right, you want

"{{#vardefineecho:foo|<!--empty-->|no foo}}" to output "no foo", just like "{{#vardefine:foo|}}{{#var:foo|no foo}}" would do it? That sounds reasonable and kind of consistent. Or did I misunderstand anything?
--Danwe (talk) 20:36, 14 August 2013 (UTC)

I assure you, I know the difference between {{{param|DEFAULT}}} and {{ #if: {{{param|}}} | {{{param}}} | DEFAULT }} quite well; I wrote exactly what I meant to in my second example (I can offer a more in-depth explanation of my reasoning, but it'd be rather out-of-scope for this page; if you're interested, drop me a message on my talk page). =)

Nope, you got it exactly right. At the risk of pointing out something that may already be obvious to you, I'm requesting it for both #vardefine and #vardefineecho. =) 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 04:12, 15 August 2013 (UTC)

I see, you did just propose the {{ #if: {{{param|}}} | {{{param}}} | DEFAULT }}, not actually expect it would work, so I misunderstood you. If we should do that, than even better {{ #if: {{{param|}}} | {{{param}}} | DEFAULT1 | DEFAULT2 | ... | DEFAULT N }}. BUT, I am not really convinced. Especially in case of the #vardefineecho it just adds complexity since there are two unnamed parameters with a different meaning already {{#vardefineecho:name|value|alternative-echo1|alternative-echo2|...|alternative-echoN}} vs. {{#vardefineecho:name|value|alternative-value1|alternative-value1|...|alternative-valueN}}. In case of #vardefine it would be an alternative-value, in case of #var it will be (and already is) an alternative-echo. So since #vardefineecho is a combination of #var and #vardefine, it is not obvious whether those additional parameters should just have an influence on the echo part or already on the define. An alternative approach would be to introduce a new parserfunction like {{#or:{{#vardefineecho:name|{{{name|}}} }}|{{{foo|}}}|{{{bar|}}}|last-default}} and {{#vardefineecho:name|{{#or:{{{name|}}}|{{{foo|}}}|{{{bar|}}}|last-default}} }}. I would prefer that solution since it is a lot more flexible and self-explanatory when reading the code. This should probably go into a separate parser function extension or perhaps there already is such a parser function somewhere. --Danwe (talk) 16:35, 15 August 2013 (UTC)

As you said yourself, #vardefineecho is a combination of #var and #vardefine; therefore, I'd expect its default input(s) to work the same as its first one: to both store the value in the variable, and output that value. Certainly, that's the behavior I'd be looking for in uses of the default functionality. I would expect to just use combinations of the three to achieve finer-grained control of display versus storage in more complicated cases.

The possibility for multiple default values is something I thought about too, but I wasn't sure if it would be generally useful enough to make implementing worthwhile. But if you want to do it, don't let me stop you! =) 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 18:09, 15 August 2013 (UTC)

Scribunto Lua support

I have written some lines of code that make the extension directly available to Lua modules when Extension:Scribunto is installed, by providing functions mw.ext.variables.{vardefine, var, varexists} that directly translate the corresponding Parser functions, using the public interface of class ExtVariables. This is easier to use and probably more efficient than invoking the parser functions from Lua.

I'd be very happy if this could be integrated into the Variables extension since it seems to me that this combination is extremely powerful. I'd mail you the code if you are interested. It's rather trivial, 95% is boilerplate, and the Variables extension continues to work normally if Extension:Scribunto is not installed. - RV1971 (talk) 12:14, 5 September 2013 (UTC)

Sorry for long reply time, must have overseen your post in my watch list. Please send me the code, looks like a useful extension. Alternatively, you could also commit the code to gerrit so we can go the usual code reviewing process. --Danwe (talk) 15:58, 15 October 2013 (UTC)

Is there a way to get a value from one page from another page?

I'm trying to have a template take only 1 parameter and from that populate data by retrieving values from another page.

for example: template format is

{{character|Artemisia (Priestess of the Holy Arrow)}}

In the same wikia there is a page called Artemisia (Priestess of the Holy Arrow) with data such as HP, ATK, etc.

I need to get those values to show up in a different page.

Is this possible? Or should I just go for the JS approach?

There are many ways to do something similar, depending on what exactly you'd like to do.

a) With the variables extension, you can simply

• Put the entire content of the Artemisia-page into <noinclude> tags.
• Define the variables in the Artemisia-page (outside these tags).
• Include the Artemisia-page as a template in the pages where you need the variables.

b) If your goal is to present a summary of the data in the Artemisia-page on other pages, an alternative approach could be:

• Define a page Template:Artemisia (Priestess of the Holy Arrow) like this:

{{{{{1}}}|HP=hp data|ATK=atk value}}

I.e. that page calls a template passed as a positional parameter and provides its data as named parameters.

• Write a template Template:your-formatting-template taking the named parameters HP and ATK and presenting them the way you like.
• Call {{Artemisia (Priestess of the Holy Arrow)|your-formatting-template}} where you want to show the data.

Obviously you may write several formatting templates presenting the data in different ways.

This approach uses only MediaWiki core functionality and does not require any extensions.- RV1971 (talk) 10:00, 24 January 2014 (UTC)

• Neither of those answers really answer the question as the OP asked it as far as I can tell. To answer that question, I would say no, there is no way unless.... You want to do one of the things above or install an extension like Extension:DynamicPageList (third-party) that is designed specifically for that purpose. Good luck! Technical 13 (talk) 12:06, 24 January 2014 (UTC)

OP: Thanks for the reply. I guess I gotta use JS for what I'm trying to do.

Edit intros

https://www.thetestwiki.org/w/index.php?title=Sandbox&action=edit&editintro=Sandbox/Editnotice

Sandbox contains this:

{{#vardefine:variablename|specifiedvalue}}

Sandbox/Editnotice contains this:

var is {{#var:variablename}}

Instead of showing "var is specifiedvalue", the edit intro says "var is". Bug? --Gryllida (Please don't ping me, I have Echo turned off.) 23:31, 18 September 2014 (UTC)

using vars for templates

Hi. I'm writing a template which generates an infobox using variables and the forargs loop from Extension:Loops. I want to be able to call a template using a var (eg {{{{#var:myvar}}}}), but whenever I try to encapsulate myvar within normal template inclusion syntax, it just prints {{{{#var:myvar}}}} on the page, instead of actually replacing the value of myvar with {{output}}. Any advise? Thanks! --86.165.19.177 17:01, 8 January 2015 (UTC)

Never mind, I just had to add a space to form the template. Cheers! --86.165.19.177 17:03, 8 January 2015 (UTC)