RESOLVED

This has been resolved with T191574.

---

I recently advised someone to use this in a template but I was wrong: multiple instances of such a template will print a series of 1, 1, 1, 1, etc., while use of the same syntax without a template will give you a series of 1, 2, 3, 4, etc. Is this intended behaviour? Cavila 13:26, 24 November 2015 (UTC)

If you repeatedly call a template without parameters, it will reuse the output of the first call. To make sure the template is evaluated each time you need to add an empty parameter: {{template|}}. 92.21.226.2 (talk) 21:19, 20 December 2015 (UTC)

Great, that should do it - thanks for this! Cavila 21:39, 20 December 2015 (UTC)

Ouch! This makes using variables and templates much more difficult. Is there some way to bypass the cache behavior so the template is expanded every time? DavidBiesack (talk) 20:04, 17 June 2016 (UTC)

When I last worked on the extension this didn't seem possible if I remember correctly. Or it was more effort than I thought was justified to solve this.

Just call the template with an empty parameter as pointed out above. Danwe (talk) 13:43, 10 July 2016 (UTC)

This is tracked in T191574 and hopefully fixed soon. MGChecker (talk) 13:44, 6 April 2018 (UTC)

So theres still no easy way to increment the variable to count anything? Gunnar.offel (talk) 08:32, 23 June 2020 (UTC)

There is. This is resolved in Variables 2.4+, which has been released in 2018. MGChecker (talk) 12:31, 23 June 2020 (UTC)

RESOLVED

Use <nowiki /> tags.

---

I'd like to use text values on my page like this:

" any text with preceding spaces"

how can i define it? 145.236.252.35 (talk) 08:42, 28 June 2016 (UTC)

{{#vardefine:text| any text with preceding spaces}} Ioannis Protonotarios 11:32, 26 January 2017 (UTC)

This works… unless you want to put the result of a model inside a {{#tag:syntaxhighlight}} template where the   tag will show (which is the problem, I am having right now…)

To me, there should be a "trim" parameter to the #vardefine template :

• {{#vardefine:text| text }}/{{#vardefine:text| text |true}}/{{#vardefine:text| text |trim}}
  → stores “text”
• {{#vardefine:text| text |false}}
  → stores “  text  ”

Or if the problem comes from the way mediawiki handles template :

• {{#vardefine:text| my text is "my text" }}
  → stores “my text is "my text"”
• {{#vardefine:text| ""my text is my text"" }}
  → stores “"my text is my text"”
• {{#vardefine:text| " my text is "my text" " }}
  → stores “  my text is "my text"  ”
• {{#vardefine:text|" my text is "my text" "}}
  → stores “  my text is "my text"  ”

Or a combination of the above (parameter allowing the use of “"” to delimit text that would otherwise be trimmed). Loizbec (talk) 12:46, 27 February 2020 (UTC)

You can do this by using <nowiki /> tags:

{{#vardefine:text|<nowiki /> any text with preceding spaces}} MGChecker (talk) 12:34, 23 June 2020 (UTC)

RESOLVED

No. And it most likely never will be.

---

Just asking. I was testing it on this page. Yhynerson1 (talk) 09:27, 18 February 2017 (UTC)

No, see in Special:Version. wargo (talk) 10:59, 18 February 2017 (UTC)

RESOLVED

No, but a feature like this could be added and is tracked in T191575.

---

Sample page using variables: http://tales-of-link.wikia.com/wiki/%28Artes_Wand_User%29_Agria 174.97.28.4 (talk) 16:07, 6 August 2017 (UTC)

That's not supported by the extension. You'd need to write a new extension on top of Variables to achieve this but it's not impossible. Danwe (talk) 10:14, 1 January 2018 (UTC)

It's an interesting thought to save the distinct var_final values in page_props to make it queryable… Maybe I will put some effort in implementing this additional functionality at some point in the future. MGChecker (talk) 22:30, 15 February 2018 (UTC)

This is tracked in T191575. MGChecker (talk) 13:43, 6 April 2018 (UTC)

RESOLVED

This extension works up to MW 1.35, but will possibly stop working when the new Parser is released.

---

can someone say if this extension works with MW1.30.x? Yukii (talk) 18:27, 11 January 2018 (UTC)

It does, yes. 「ディノ奴千？！」^{☎ Dinoguy1000} 19:07, 11 January 2018 (UTC)

RESOLVED

Read the docs.

---

The bundle available for MW 1.30 via the ExtensionDistributor, i.e REL1_30-c75b9d4, is missing the file "extension.json", causing installation through wfLoadExtension( 'Variables' ); to fail. Ahmad Gharbeia أحمد غربية (talk) 12:59, 17 April 2018 (UTC)

The docu states: "To users running MediaWiki 1.30 or earlier", so for MW 1.30 this extension has to be invoked via require_once .... [[kgh]] (talk) 16:14, 17 April 2018 (UTC)

RESOLVED

Variables is not involved into HTML sanitization, out of scope.

---

If template contains:

<nowiki><!-- this is a comment --></nowiki>

then the whole thing gets rendered as visible text on the host page. If template contains:

<!-- this is a comment -->

then none of it gets transcluded.

Really just want to put some invisible text on the host page-- doesn't have to be an HTML-comment.

This doesn't get transcluded either:

<span style="display:none">Hidden Span</span>

Johnywhy (talk) 17:27, 3 June 2018 (UTC)

RESOLVED

There is no limit immanent in this extension. However, the general parser limits (passed nodes etc.) still apply. You would probably have to try to make that a problem though.

---

I've never encountered a problem before when using many variables, but a thought came to me; How many variables can I have at once on a single page?

As an example, if I were to use, say, 100 variables one page for whatever reason, would I be able to do that without encountering a problem?

Asking out of curiosity. Diriector Doc (talk) 00:42, 14 August 2018 (UTC)

There shouldn't be any issue with a large number of variables; I've used well over a hundred variables in a template without issue. 「ディノ奴千？！」^{☎ Dinoguy1000} 00:54, 14 August 2018 (UTC)

RESOLVED

This is possible.

---

I'm pretty new to this so it's still confusing to me.

So I have template1 and template 2. Template 1 does usd=12345, template 2 on the other hand has prize=5000. Is it possible to do match between these two tho they're on two different templates? I was trying the following but can't make it work and I'm stuck.

{{#vardefine:{{{result}}}|{{#expr:{{#var:prize}}*{{#var:usd}}}}}} 119.92.13.245 (talk) 21:25, 20 August 2018 (UTC)

If the current template designs allow for it, I would recommend explicitly passing the needed values as template parameters, instead of relying on Variables. Not only does this bypass the problems you're facing now, but it also avoids a whole host of maintenance and code comprehension issues into the future. 「ディノ奴千？！」^{☎ Dinoguy1000} 13:25, 21 August 2018 (UTC)

RESOLVED

{{#vardefine:x|{{#expr:2*{{#var:a}}+{{#var:b}}}}}} => {{#var: x }}

---

Simple question, but the article did not answer it to me: if I have defined x as {{#vardefine:x|{{#expr:2*{{#var:a}}+{{#var:b}}}}}} like here – how can I call x?

Thanks – Ciciban (talk) 06:56, 15 September 2019 (UTC)

{{ #var: x }} 「ディノ奴千？！」^{☎ Dinoguy1000} 09:11, 15 September 2019 (UTC)

RESOLVED

Variables have no length limitation, but string functions do. Out of scope here.

---

I encounter bugs when I seek to allocate a variable of more than 1000 characters. The error I get is (in french) :

<strong class="error">Erreur : la chaîne dépasse la limite maximale de 1 000 caractères.</strong>

meaning the string exceedes the maximal size of one thousand characters.

Yet I did not find any configuration parameter to allow for more than one thousand characters (I probably need 5000 or possibly more).

Any idea how I could fix this ?

Frederic.

for web site dufal.fr

e.g. you'll find the problem in page dufal.fr/index.php/Sp%C3%A9cial:Parcourir/:F.AGSO.S0001 2A01:CB15:258:1A00:3C42:E043:373C:AD79 (talk) 21:35, 8 August 2020 (UTC)

This is confusing, as Variables have no such limit. Are you combining them with the Loops extension, by chance?

Can you reproduce this on a normal page, given that this case is kind of weird? I do not know how this special page comes together. MGChecker (talk) 21:42, 8 August 2020 (UTC)

Are you using StringFunctions as well? These have a length limit of 1000 characters for strings. (I tried checking myself, but I don't speak French so I had a hard time telling what was going on.) 「ディノ奴千？！」^{☎ Dinoguy1000} 00:07, 9 August 2020 (UTC)

Thanks for your prompt help. I'm using ParsingFunctions, Variables, and MyVariables (loaded in this order).

By adding the line

$wgPFStringLengthLimit=9996;

at the end of my LocalSettings.php rather than just after the loading of ParsingFunctions, it solved my problem. (I'm not sure I fully understand why).

Many thanks again.

Frederic. 2A01:CB15:258:1A00:74BC:4610:8CC4:F7CE (talk) 16:15, 9 August 2020 (UTC)

That means you're using StringFunctions somewhere in the templates that page uses. The limit you increased is important for preventing denial-of-service attacks against your wiki, and the better solution here is to redesign your templates so they're not trying to pass extremely long strings through StringFunctions. 「ディノ奴千？！」^{☎ Dinoguy1000} 10:19, 10 August 2020 (UTC)

It would probably be better (more efficient and more versatile) to use Scribunto for string processing, instead of StringFunctions. MGChecker (talk) 11:54, 10 August 2020 (UTC)

RESOLVED

There are no plans to support undefining a previously defined variable for minuscle performance benfits.

---

I have a template whose behavior changes based on the existence of a variable. It uses {{#varexists...}} for this purpose. I'd like to be able to define/undefine this variable multiple times, e.g.

#vardefine:debug_flag}}
{{My Template}}
{{#varundef:debug_flag}}
{{My Template}}

But currently there is no way that I know of to undefine a variable after defining it. --~ 2600:1700:1B0:BA0:A82F:CAEB:C7F7:8FAF (talk) 02:18, 9 October 2020 (UTC)

To be honest, I've never had any use for #varexists; instead, I just define variables with a dummy value (e.g. {{#vardefine: foo | 1 }}) and then test if the variable has a value with an #if. That way, if I need to later undefine the variable, I can simply clear its value via {{#vardefine: foo }}. 「ディノ奴千？！」^{☎ Dinoguy1000} 02:28, 9 October 2020 (UTC)

It is a feature that this is not possible, thus a definition of a variable can never be done.

Instead, I recommend Dinoguys approach of checking if a variable is empty. --MGC 194.230.155.242 (talk) 05:40, 9 October 2020 (UTC)

What do you mean by "it is a feature"? What is the advantage of {{#varundef}} not existing? I guess I will have to do it the way Dinoguy1000 suggested. Equivalently, no one ever needs to use {{#varexists}} -- they can always use {{#if}}. But then, why does {{#varexists}} exist? 2600:1700:1B0:BA0:988E:1F3E:9575:814C (talk) 08:13, 9 October 2020 (UTC)

I would have to check this, but at a glance I'd guess that {{#varexists: foo | ... }} is very slightly more efficient than {{ #if: {{ #var: foo }} | ... }} (at the very least, it does make the intention of the code clearer). I wouldn't say to avoid using #varexists entirely, but to use it only for variables that are fully static flags (i.e. the variable is defined - or not - in only one place in the template, and it isn't touched afterwards except to check for it). Certainly, now that I've taken a closer look and thought about it a bit, I'll be going over my own templates and using it where appropriate (after testing to see how it stacks up to #if: #var:, in terms of template limits, at least). 「ディノ奴千？！」^{☎ Dinoguy1000} 16:48, 9 October 2020 (UTC)

I wouldn't recommend you change all of your templates for an infinitesimal efficiency improvement. You will be giving up the option of doing what I mentioned in my initial post. If you have a thousand references to your template on a page, and you only want the variable to be defined for the first half of them (maybe you're doing a binary search), you won't be able to do it. 2600:1700:1B0:BA0:2D95:883D:C0D7:C5DC (talk) 21:59, 9 October 2020 (UTC)

I'm keenly aware of the gotcha's here, believe me. The changeover would be to benefit code readability (and thus maintainability); any potential efficiency improvement (even an infinitesimal one) would just be a nice bonus. 「ディノ奴千？！」^{☎ Dinoguy1000} 22:09, 9 October 2020 (UTC)

Revisiting this now that I've looked a bit more into it: careful use of #varexists can save a significant amount on the NewPP parser report metrics (in particular "Preprocessor visited node count", "Post-expand include size", and "Template argument size"), over my go-to {{ #if: {{ #var: construction.

For example, this version of "Template:Chapter" on my wiki (the current version as of writing this, but it won't be for long), as used on the current version of the page "Dark Yugi (manga)" (where the template is transcluded 338 times), results in the following NewPP report:

NewPP limit report
Cached time: 20210907163321
Cache expiry: 1209600
Dynamic content: false
[SMW] In‐text annotation parser time: 0.017 seconds
CPU time usage: 4.748 seconds
Real time usage: 8.358 seconds
Preprocessor visited node count: 64228/1000000
Preprocessor generated node count: 60933/1000000
Post‐expand include size: 418313/2097152 bytes
Template argument size: 35083/2097152 bytes
Highest expansion depth: 17/40
Expensive parser function count: 0/100
Unstrip recursion depth: 1/20
Unstrip post‐expand size: 112756/5000000 bytes
Lua time usage: 2.450/20.000 seconds
Lua virtual size: 14.27 MB/50 MB
Lua estimated memory usage: 0 bytes

However, changing the first line in the template:

<includeonly>{{ #vardefine: $smw | {{ #var: $smw | {{ #if: {{ #show: }} | off | on }} }}<!-- standard implementation -->

to

<includeonly>{{ #varexists: $smw || {{ #vardefine: $smw | {{ #if: {{ #show: }} || 1 }} }}<!-- standard implementation -->

and line 40 from

}}{{ #vardefine: $chapter-name | {{ #ifeq: {{ #var: $chapter-mode }} | number || {{ #ifeq: {{ #var: $smw }} | on | {{ #show: {{ #var: $chapter-pagename }} |?English name }} }} }}

to

}}{{ #vardefine: $chapter-name | {{ #ifeq: {{ #var: $chapter-mode }} | number || {{ #if: {{ #var: $smw }} | {{ #show: {{ #var: $chapter-pagename }} |?English name }} }} }}

...results in the following report:

NewPP limit report
Cached time: 20210907165826
Cache expiry: 1209600
Dynamic content: false
[SMW] In‐text annotation parser time: 0.015 seconds
CPU time usage: 4.776 seconds
Real time usage: 8.623 seconds
Preprocessor visited node count: 63678/1000000
Preprocessor generated node count: 60933/1000000
Post‐expand include size: 417637/2097152 bytes
Template argument size: 35083/2097152 bytes
Highest expansion depth: 17/40
Expensive parser function count: 0/100
Unstrip recursion depth: 1/20
Unstrip post‐expand size: 112756/5000000 bytes
Lua time usage: 2.570/20.000 seconds
Lua virtual size: 14.3 MB/50 MB
Lua estimated memory usage: 0 bytes

Note in particular that "Preprocessor visited node count" dropped from 64228 to 63678, and "Post-expand include size" dropped from 418313 to 417637.

However, as things stand, I am unable to use this method in more places in "Template:Chapter", since other variables I'd like to use it on are always defined, and communicate meaningful state if they are empty (there is no way around this, since subsequent transclusions may store nonempty values to these variables, and then empty values again, and so on). For example, changing line 28 from

}}{{ #vardefine: $chapter-subseries | {{ #if: {{ #var: $chapter-series }}

to

}}{{ #vardefine: $chapter-subseries | {{ #varexists: $chapter-series

...would result in "Preprocessor visited node count" dropping further to 60641, and "Post-expand include size" dropping to 371846, but would not work correctly in some cases of multiple transclusions of the template on the same page, as explained above. However, you don't even need to look past $smw to find suboptimal behavior: because it can be defined but empty, it must be tested on line 40 via {{ #if: {{ #var: $smw }} ..., instead of being able to just use {{ #varexists: $smw ...!

This could be fixed in one of two ways: add a function to undefine a variable entirely, or add a way to test for variable existence that considers empty-but-defined variables to not exist (whether by a modification of #varexists, or the introduction of a new parser function).

(I am, of course, aware of Scribunto and Lua - and we do use modules for a number of things on the wiki already - but we currently only have one editor who is able and willing to develop and maintain modules for us, and they don't have much time to spend on the wiki; I've tried learning myself, but could never get the hang of it.) 「ディノ奴千？！」^{☎ Dinoguy1000} 18:06, 7 September 2021 (UTC)

RESOLVED

Interactions of parser functions with references are complex, and unexpected behavior is unlikely to be fixed.

---

I would like to use a expression to check a length.

{{#ifexpr:{{#len:{{#var:refs|}} }} > 10 | [..]

That provides no exeption, as far as good, but the

{{#len:{{#var:refs|}} }}

provides always 0 so the check doesn't work. Any Idea how to solve the issue or change the behavior?

____ i wrote the ask allready in Help_talk:Extension:ParserFunctions but maybe this point is the better choice. Gunnar.offel (talk) 14:14, 22 October 2020 (UTC)

i tried also the given alternatives, but sadly they also doesn't work in my case. :S Gunnar.offel (talk) 14:16, 22 October 2020 (UTC)

Are you sure the refs variable is populated? If this is not the case, you get an empty string out of `refs`, matching your reports. MGChecker (talk) 14:27, 22 October 2020 (UTC)

At least

{{#vardefineecho: refs | Tree }}
{{#ifeq: {{#var: refs }} | Tree | 1 | 0 }}

works properly for me, on the contrary to the reports on the ParserFunctions. Sadly, I have no wiki with StringFunctions and Variables at hand at the moment, so I can not reproduce your claims. MGChecker (talk) 14:31, 22 October 2020 (UTC)

On my own wiki with ParserFunctions, StringFunctions, and Variables, I have never had any issue using the three together as described here. @Gunnar.offel: could you provide what versions of MediaWiki, Ext:ParserFunctions, and Ext:Variables your wiki has installed? 「ディノ奴千？！」^{☎ Dinoguy1000} 19:12, 22 October 2020 (UTC)

Actually, based on the name of the variable, is it meant to store references? Trying to work with <ref> tags with parser functions is difficult, because of the special parsing that takes place around them. If it's an option for you, you may have better luck using Scribunto/Lua for this instead. 「ディノ奴千？！」^{☎ Dinoguy1000} 19:15, 22 October 2020 (UTC)

@MGChecker, if i use vardefineecho and also if i call the #var it outputs the wanted things. So i'm pretty sure, that i populate the variable. i just can't get it to work with the parser function.

@Dinoguy1000: sure,

- MediaWiki 1.34.0

- ParserFunctions 1.6.0

- Variables 2.5.1 (d6ce860) 08:16, 4. Sep. 2019

Yes, the variable stores the references and it works, but at the moment not in the parser functions. actually i just want to hide an empty table and only show if content is available. That's a big gun on a little problem, sure but keeps me up for a better understanding how to use/solve the extension. Gunnar.offel (talk) 20:45, 22 October 2020 (UTC)

As Dinoguy said, this is properly a really hard problem. References are a really complicated feature, kind of using variables as internal counter as well, and being evaluated at a different time during parsing. This leads to many features of stock MediaWiki already to behave weird when used together with references – especially advanced syntax features offered by extensions.

What is properly happening here that the references are not populated at the (quite early) point during parsing when variables are evaluated in this logic. I do not know exactly what is happening, but trying to get the references at multiple points, at different parsing stages, is quite typical for problems related to references.

Hence, your references var is always empty for parser functions. On the other hand, variables not encapsulated into the template tree can properly evaluated properly. MGChecker (talk) 00:53, 23 October 2020 (UTC)

RESOLVED

Beware of trailing whitespace.

---

I am using the variable extension to us define some variables which I use later in my wiki. But adding these variables adds extra undesirable space at the top of the wiki. Am I missing something? 84.46.53.105 (talk) 08:44, 5 September 2021 (UTC)

Did you use newlines? Avoid them, wrap a div around your vardefines with display:none, or comment out each line break (I just tried to demonstrate this with pre-tags, but MediaWiki messed up my code). Cavila 09:39, 5 September 2021 (UTC)

Cool! Thanks Cavila. display:none did the trick. :) 84.46.52.252 (talk) 10:35, 5 September 2021 (UTC)

Just to add one more option, my preferred method is to place the closing braces for each vardefine on the same line as the opening braces for the next vardefine, e.g.

{{ #vardefine: var1 | foo
}}{{ #vardefine: var2 | bar
}}{{ #vardefine: ...

「ディノ奴千？！」^{☎ Dinoguy1000} 17:44, 5 September 2021 (UTC)

RESOLVED

Known and documented.

---

This extension does not work with the latest Mediawiki build. 149.167.172.126 (talk) 04:22, 11 September 2022 (UTC)

It works, it just yields deprecation warnings. More information is indicated on the front side. MGChecker (talk) 19:11, 11 September 2022 (UTC)

RESOLVED

Known issue, see front page for workaround.

---

Hello

How can i resolve this problem?

PHP message: PHP Deprecated:  Use of InternalParseBeforeSanitize hook (used in VariablesHooks::onInternalParseBeforeSanitize) was deprecated in MediaWiki 1.35.

Thanks for any help Lokipr (talk) 14:33, 21 September 2022 (UTC)

See the various notices at the top of Extension:Variables, and in particular the various Phabricator tasks linked from them. Basically, this notice is known and expected breakage from recent changes to the parser in MediaWiki and the way the extension is currently written, and fixing it would require some more-or-less extensive rewrites of the extension. 「ディノ奴千？！」^{☎ Dinoguy1000} 18:47, 21 September 2022 (UTC)

---

I noticed that this extension is said to be supported in MediaWiki 1.29+ but I'm quite sure that it breaks MediaWiki 1.39.

https://phabricator.wikimedia.org/T348426#9305340

Premising that:

• yes, I've seen the red-warning in the extension page
• yes, I've read the full discussion at phabricator:T2509637

Probably it would be a good idea to evaluate if:

• explicitly flag this extension as not compatible with MediaWiki 1.39+
• and/or, mark this extension as "Unmaintained" (it has sense to say it at a certain point if it's not possible to continue the development because of MediaWiki deprecations) Valerio Bozzolan (talk) 16:42, 3 November 2023 (UTC)

I've edited the template to indicate "1.29-1.35" since the deprecation literally talks about 1.35 but feel free to clarify that in a better way. Valerio Bozzolan (talk) 16:49, 3 November 2023 (UTC)

What I did (and forgot about until now) was to remove support for the #var_final parser function, which relies on the deprecated InternalParseBeforeSanitize hook. That way it's working for me fine on MW 1.39 so it should be possible to release a new version. Rand(1,2022) (talk) 17:25, 3 November 2023 (UTC)

Is the only symptom the PHP Deprecated: Use of InternalParseBeforeSanitize hook (used in VariablesHooks::onInternalParseBeforeSanitize) was deprecated in MediaWiki 1.35. [Called from MediaWiki\HookContainer\HookContainer::run] message? Those deprecation notices should be hidden from public view. I mean, it's not an error, just a warning that it will break in the future, it can be silenced and you'll be able to use 1.39 until EOL at least. Ciencia Al Poder (talk) 11:47, 4 November 2023 (UTC)

Thanks for this information. I tried playing with the `extension.json` to remove that hook call, and indeed it seems it was not the cause of our white screen of death. Originally I thought something was escalating the deprecation warning to an exception, but I'm quite sure this is not the case, and it's safe to keep that deprecation warning right there.

Thanks again for your work and I'm sorry that MediaWiki is doing these breaking changes affecting some of your users. But fortunately it seems we are not affected. I will revert my edits in the main page to restore 1.26+ compatibility.

If you are reading this message and if you are affected: enable the MediaWiki logs, and inspect other exception messages, for example the examining any other line marked with "[exception]". Valerio Bozzolan (talk) 14:39, 5 November 2023 (UTC)