Extension talk:Loops/LQT Archive 1

Feedback
Doesn't only work on MW 1.12 Alpha, works also on 1.12. I hope it also will work on 1.13. This extension is very helpful, for example for building well arranged templates without copy paste and change 100 times for "array" parameters. Found no Bugs as yet. Hope somone will develope on this extension that we can see it with stable Status as soon as possible! --77.191.205.221 10:13, 6 August 2008 (UTC)


 * Thanks for the feedback! Though no one has reported any bugs, I know of only three or four people who use this extension (present company included), so I don't feel comfortable updating the status to "stable" yet.  —Sledged (talk) 15:59, 6 August 2008 (UTC)


 * I use this extension! . I have a template calling it here.  We discuss the necessity of this template all the time on the mailing list. Keep up the great work! --Aquatiki 22:09, 6 August 2008 (UTC)


 * Glad to know it works well for you. I'll go ahead and change it to stable, since no bugs have been found with the bread-and-butter functions (while and dowhile).  foreachnamedarg, however, is still experimental and subject to change.  —Sledged (talk) 18:26, 21 August 2008 (UTC)


 * I use this extension, too! . It's crucial to my [|Random Image Gallery] template as used on the homepage. Awesome work! --Arodicus 22:36, 8 October 2008 (UTC)

Ok, It also works on MW 1.13.1, tested now! --77.191.216.80 15:03, 30 September 2008 (UTC)

I use this template at for a lot of templates, the most complex of which is here:  Thanks a lot Sledged! --J.nesta 14:08, 2 November 2009 (UTC)

Foreachnamedarg
Foreachnamedarg is really amazing! But why don't you allow to use it without prefix? I have some templates where I allow the users to use parameter 1, 2, 3 and so on without any limitation, I really could use it there so I would save the increment variable, the condition and the asigning of the parameter value to a variable. If Foreachnamedarg is significant faster than the common loops or it allows to do more loop runs than the other loops before you get a php error message because of memory or something, It would a fortiori make sense to allow it. With many loops in my pages they get really slow sometimes. --Danwe 21:38, 13 February 2009 (UTC)


 * I'm glad you find it useful. Foreachnamedarg is a pilot parser function for an idea I'm still fleshing out.  Eventually, I plan to replace it with foreacharg which will do exactly what you're describing while still keeping the current functionality.  I have no time frame for this though.  —Sledged (talk) 20:07, 19 February 2009 (UTC)


 * #forargs replaces #foreachnamedarg and works on all template arguments that match the supplied prefix which can be left empty. In which case it will access all template arguments.  #fornumargs will access only the numbered arguments, whether they're set explicitly or implicitly.  —Sledged (talk) 22:22, 2 May 2009 (UTC)


 * Thats amazing. I especially love the #forargs feature which allows to access ALL arguments. #fornumargs Is great as well, Its helpfull to save some code. Can you tell us if #fornumargs brings any performance bonus compared with the old method with ? Thanks for the release! --Danwe 15:22, 4 May 2009 (UTC)


 * No clue. I haven't made any benchmarks on the performance.  —Sledged (talk) 21:26, 15 May 2009 (UTC)

Bug #1 - Invisible characters around generated text of the loop
Phew, I spent two evenings now untill I found that bugs source... It seems like the Bug is, that the Loops extension creates some invisible characters arround the text which is created inside the loop. So when you run a loop to create some text for a template the length of the text the template will return is much longer than the text you can see. In some cases this behavior causes problems, for example when you use the return value with string functions or inside a Semantic Media Wiki Property.

Example: The following loop: would return the output "01234", looks like its 5 chars long. But the #len function couns exactly 220 (!) characters!

I found a litte workarround for that: You can use the sub parser function from string functions to avoid this:   but you have to store the generated return value in a variable if it is generated in the loop because the variable has to print their content behind the loop and sub function. So return values of templates dont give back some invisible characters and you can use the string wherever you want without problems.

I hope you will fix this litte bug soon, I dont like my workarround pretty much :-/

--77.191.145.123 19:20, 29 January 2009 (UTC)


 * Try it without the &lt;nowiki/&gt; tag, like so:


 * and see how it works. I use the nowiki tags in my examples so that the new line characters immediately after the tags are preserved.  —Sledged (talk) 20:39, 29 January 2009 (UTC)


 * Thank you, this works like expected! --77.191.253.66 22:33, 1 February 2009 (UTC)

Help me please
I can't seem to get this to work: In my wiki theres a table at the bottom of many pages that go to different versions of the content on the page, so i want to use a template instead. I want to make a table that has one row (starting with the row heading "Inputs" in bold and the two-input version), and in each cell links to a page called: (first parameter) then "_(" then the i value then " bit)" with a label of the value of i. the variable i increments by 2 until i is less than the second parameter. Below is my attempt but it always seems to time out.

Example: Should produce:


 * You need to hide the pipe character after &lt;nowiki/&gt; tag in a template. Otherwise, MW thinks it's the start of another parameter.  Standard practice is to create the template Template:!, whose only content that is included is a pipe character.  —Sledged (talk) 18:01, 30 December 2008 (UTC)

#while and header
i'm using MW 1.13.4

A problem with headers. if i try to create header within cycle, then only the 1st header resulted as header and the rest - as plain text. For example,

{{#while: | {{#ifexpr: {{#var: i }} < {{#var: n }} | true }} |

header
text }}

it can be half-solved using var-wrap.

{{#while: | {{#ifexpr: {{#var: i }} < {{#var: n }} | true }} | {{#vardefine: rez | {{#var:rez}}

header
text }} }}

in my real page i'm using my array extension, so my real code is useful

{{#while: | {{#ifexpr: {{#var: i }} < {{#var: n }} | true }} | {{#vardefine: rez |

}} }}

--Schthaxe 09:12, 5 March 2009 (UTC)


 * Whitespace (including newlines) is stripped from the beginning and end of all the arguments of the parser function. Add a non-whitespace character (e.g. the HTML encoding for a whitespace character &amp;#32;, or a &lt;nowiki/&gt; tag) before the newline preceding each heading. —Sledged (talk) 17:35, 6 March 2009 (UTC)

let's use for-cycle
then we can use

and get

0123456789

--Schthaxe 10:33, 12 March 2009 (UTC)


 * I used #loop instead of #for, because another extension already uses #for. It works like so:

{ {#loop: variable name | starting value | number of loops to be performed | wiki markup }}


 * if a negative value is supplied for the third argument, the value stored in the variable will decrease with each iteration. —Sledged (talk) 22:22, 2 May 2009 (UTC)

Version 0.3.0 only works with MW 1.14 and later
Since you use functions in forargs and/or fornumargs like getNamedArguments which were added in MW r38981 the Loops plugin isn't full compatible to MW <1.14 anymore. I tested it in 1.13. Perhaps you should use SVN for the project so that MW 1.13 or less users could download an older version of the plugin. --Danwe 12:06, 2 June 2009 (UTC)


 * I may do that down the road, but for now later versions can be accessed through the page's history. —Sledged (talk) 18:12, 2 November 2009 (UTC)

ExtLoops count for -1 loops
In case you config  the html comment information in the pages source code always shows. Would be usefull sometimes to know how many loops have been performed on a page. --Danwe 13:52, 11 October 2009 (UTC)


 * Sounds reasonable. —Sledged (talk) 18:12, 2 November 2009 (UTC)

Using #while to pass parameters to a subtemplate (I think I might have found a bug with Extension:Loops)
Has anybody had success in doing this? For example, the following code (with Arg1 being IceCream)

}}

will result in:

Arg1=IceCream

But the following code

}}

will not pass the argument to the subtemplate! *throws brick through computer monitor* plz hralp( --J.nesta 14:26, 2 November 2009 (UTC)

Found a work-around
It seems to work if you just use non-named arguments, like and so forth. WTF? --J.nesta 14:26, 2 November 2009 (UTC)


 * With templates, parser functions, and magic words (i.e. anything that uses the { {...}} syntax), when specifying an argument, MediaWiki only recognizes the equal sign if it's outside a nested template-like call in the argument. It doesn't process equals signs that are the result of a template-like call.  For instance, the markup sample cases
 * and
 * all set the argument arg1 to the value of val1, because the equal sign is not inside a nested { {#if:}} call. Conversely, the markup
 * implicitly sets argument 1 to arg1=val1, because the equal sign is inside the nested { {#if:}}</tt> call. —Sledged (talk) 18:12, 2 November 2009 (UTC)
 * and
 * all set the argument arg1</tt> to the value of val1</tt>, because the equal sign is not inside a nested { {#if:}}</tt> call. Conversely, the markup
 * implicitly sets argument 1</tt> to arg1=val1</tt>, because the equal sign is inside the nested { {#if:}}</tt> call. —Sledged (talk) 18:12, 2 November 2009 (UTC)
 * implicitly sets argument 1</tt> to arg1=val1</tt>, because the equal sign is inside the nested { {#if:}}</tt> call. —Sledged (talk) 18:12, 2 November 2009 (UTC)
 * implicitly sets argument 1</tt> to arg1=val1</tt>, because the equal sign is inside the nested { {#if:}}</tt> call. —Sledged (talk) 18:12, 2 November 2009 (UTC)


 * Interesting. So... is there a work-around that you know of? How would I go about programming this? =) --J.nesta 19:59, 3 November 2009 (UTC)


 * I haven't been able to think of any workaround that doesn't involve creating another extension. —Sledged (talk) 22:30, 3 November 2009 (UTC)


 * Out of curiosity, do you know of an easy way to pass all template parameters to a subtemplate? ;) Thanks for all your help Sledged. --J.nesta 00:30, 4 November 2009 (UTC)

Code for passing arguments to a subtemplate
Well, even though Sledged hasn't given me a final answer yet, I'll go ahead and post my workaround. It's not pretty, but I did a little searching on google and AFAIK this is the only code I've seen on the internet that will do this. If someone knows a better way to do this, please let me know.

The premise: since MediaWiki won't process either equals signs or pipes, you can't write up a nice little loop to pass a bunch of arguments to a subtemplate. So, I just used strings to pass them (for the noobs reading this, you have to download the StringFunctions extension for this to work).

Note: The code uses | (a.k.a. a pipe) as a separator between the arguments, but since it is a string, you can use whatever symbol of string of characters that you want.

The top template code:

The subtemplate code:

Now all the args are stored as vars in the subtemplate, i.e. Arg1, Arg2, etc.

Hopefully this helps out someone out there! And hopefully one day someone over at MediaWiki will implement something like a to automatically pass all parameters to a subtemplate so people don't have to hurt their brains figuring this shit out. =p --J.nesta 01:50, 5 November 2009 (UTC)


 * Using the VariablesExtension extension seems like a good workaround. You could use it in conjunction with the { {#forargs}}</tt> parser function:


 * And I'm not just suggesting that because I'm trying to enlist more guine&mdash; I mean "testing partners" for a still experimental parser function.  Honest!  —Sledged (talk) 21:56, 15 December 2009 (UTC)

Strange Server Errors
Hi,

I really like the functionality of this extension, but I've hit a rather strange problem.

After a random amount of time with the extension enabled on my wiki (generally no more than about 10 minutes), I start getting "500 Internal Server Errors" until I disable the Loops extension. Once I've disabled the extension, the wiki works perfectly. If I try to re-enable the extension, I get the error again.


 * OS: Windows XP
 * Server: Apache 2.2
 * Mysql: 5.1.30-community
 * PHP: 5.2.8
 * MW: 1.15.1
 * Installed extensions: StubManager, HNP, SidebarEx, CategoryTree, Cite, CountDown, CreateBox, DynamicPageList(third party), EasyTimeline, ExtensionFunctions, GroupPortal, ImageMap, LabeledSectionTransclusion, MultiBoilerplate, MultiCategorySearch, ParserFunctions, PasswordReset, RenameUser, SimpleCalendar, StringFunctions, SyntaxHighlight_GeSHi, Tabber, TagAsCategory, Variables.

Any ideas?

AerosAtar 20:25, 13 December 2009 (UTC)


 * I don't have a 1.15.1 environment running, and no else has made any other comments (favorable or otherwise) about the extension on 1.15.1. Try making Loops the only extension enabled and see if you still get the error.  If the error stops, try adding each of the other extensions back one-by-one.  —Sledged (talk) 21:56, 15 December 2009 (UTC)


 * After poking it with a stick for a while, it appears that it was as simple as my Loops.i18n being corrupted. Seems to be working fine now. Thanks. :) AerosAtar 18:02, 19 December 2009 (UTC)

Using #forargs, the "if ( !( $frame instanceof PPTemplateFrame_DOM ) )" check returns false
... and thus the Wiki prints

instead of


 * 1 = val1
 * 5 = val5
 * ument = value

when implementing the example.

This is on one MediaWiki instance, while it works on another, nearly identical MediaWiki installation (both MW 1.15.1, PHP 5.2.11, Loops 0.3.0 and an identical set of other extensions). I have no idea what could be causing it. --Patrick Nagel 07:05, 15 January 2010 (UTC)


 * After describing the issue in the IRC channel, I know more: The problem is caused by the absence of the DOM PHP extension, which can be enabled by putting 'extension=dom.so' in php.ini (if PHP has been installed with that extension, that is - it is contained in the 'php-xml' package on Red Hat based Linux distributions). TimStarling proposed to change the extension code "to say "instanceof PPTemplateFrame_Hash" instead of DOM, since it probably doesn't make any difference, the interface is virtually the same". --Patrick Nagel 08:01, 15 January 2010 (UTC)


 * I'll remember to include it with the next update. —Sledged (talk) 15:11, 1 February 2010 (UTC)

Syntax
Why is it that the syntax for every parserfunction-like extension is except for this one where it's  ? DeFender1031 20:55, 30 January 2010 (UTC)


 * Was it intentional to present this question under the same heading as its answer? —Sledged (talk) 15:11, 1 February 2010 (UTC)
 * Yes. Totally intentional. In fact, I just posted here because I'm too stupid to actually READ things under the same header as my talk posts... So... yeah, guess I shoulda looked harder... oh well. DeFender1031 17:36, 1 February 2010 (UTC)

Update for v1.16beta2 - using the new messages mechanism
Running version 1.16beta2, I was getting warnings that messagescache::addMessages was deprecated, and since I didn't want to turn off warnings in my dev environment, I decided to try and fix that. I admit this is my first attempt at hacking an extension, so I might have made a mistake somewhere along the way (I based my work on other extensions, such as ParserFunctions), but it seems to be working just fine. Basically, I removed the custom function for translation of messages, instead using the now standard wfLoadExtensionMessages. I also moved the Magic Words to their own i18n file.

Get it here: User:Drorsnir/Extension:Loops

Sledged, if you're watching this page: thanks for the extension! It works great! As mentioned above, tested and working with v1.16beta2. Would you update the version here to mine, if it seems OK to you? Also, Wouldn't it be a good idea to move it into SVN? Dror Snir 18:44, 13 April 2010 (UTC)

0 bug in #loop
When you use something like:

it will output "" for the first loop. For some reason the 0 doesn't end up in the i variable instead a void string. --Danwe 04:45, 13 July 2010 (UTC)


 * solved the problem with . You should cast the values to string in case they are a integer  . Would be saver to do the same thing for the other   calls in your extension, too. The   could be "0" as well. --Danwe 05:08, 13 July 2010 (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:07, 31 July 2010 (UTC)


 * See my comment above  - I created an i18n-ready version already. I haven't actually tested it, but it should work just fine with another language. --Dror Snir 01:14, 25 August 2010 (UTC)

Making Templates With While...
See this link for more information. 96.42.46.123 20:29, 2 November 2010 (UTC)

Where Did I Go Wrong?
Another issue, see this link as well. 96.42.46.123 20:30, 2 November 2010 (UTC)

Accessing indirect parameters (arrays)
I had a hard time figuring out how to work out an indirect access to parameters (simulating arrays) and inserting them into expressions. Finally I managed to do it. The code:

The total is:

Adds the values of the (simulated) array:

Kanor 17:14, 19 January 2011 (UTC)

#while: Create a table

 * Currently building a template that takes in 4 values and contains two #while loops, outer and inner one. Total iteration is 100 (10x10), and the majority of the while statements are doing nothing more than building a table of information.
 * Any suggestions as to what the best approach would be to get this taken care of?
 * Current Implementation:

onParserClearState functions not called
The initialization function onParserClearState isn't ever called, and this produces the result that the "Maximum number of loops have been performed" advice is going to be triggered even if it shouldn't. How? imagine you put the while cycle in a template, and this template is included many times in the page. I suppose the function is to be called every time a loop cycle is begun. Where precisely? 85.20.222.11 21:00, 30 March 2011 (UTC)
 * The function is using a hook and is called after each page rendering, after importing a page and finishing its rendering and other occasions. --Danwe 18:12, 31 March 2011 (UTC)


 * Shouldn't it be called every time a loop (while, etc.) begins? DonPaolo 20:56, 31 March 2011 (UTC)


 * I can't see why. When it gets called it will reset the loop counter and this would mean that the loop maximum would be a per loop limit instead of an per page limit as it's supposed to be. --Danwe 11:24, 6 April 2011 (UTC)

Problem with forargs and fornumargs in MediaWiki 16.1.0
Although the examples for and  work fine on my MediaWiki installation which has Extension:Loops version 0.3.1, I can't get  or  to work at all. (I know they are listed as experimental, but so is .)

I have a page Template:Loop Test that has

and I test with:

and all I get when it is rendered is: -- WilliamsJD 23:28, 18 May 2011 (UTC)


 * instead of  try  . Somehow this happened to me, that when having spaces or breaks after the first   in a template, it just won't work. It's a weird bug because further down in the source I have similar things and there the parser won't bug around... --Danwe 17:13, 2 June 2011 (UTC)

#fornumargs Bug
I have a test template like so: I have a test use case on a test page, like so: It successfully adds the page to categories "1" and "2". However, if I change it to this: the page is removed from category "2", and I get this on the screen instead:

Then if I change it to this: the page is removed from category "1", and I get this on the screen instead:

Now, if I go back to this: and I change it to this: it works. Similarly: changed to: also works. This: puts me in category "2," but I get this on the screen:

This: puts me in no categories at all, and I get this on the screen:

This: somehow works entirely. I even compressed my template code to look like this: and also attempted it with a tag, like so: but I get the exact same set of results.

I tried this same set of experiments with a bulleted list, and did not have the same problems.

So, clearly, #fornumargs hates the combination of implicit parameters, newlines, and categories. --Cogniac 02:42, 31 August 2011 (UTC)


 * Yeah, there are a few bugs already like 0 bug in #loop, your bug I guess is because checking whether the argument is a number or not is not sufficient. It only uses php "is_string" and when you have something like "2\n" where "\n" is a new-line, it will interpret as string instead as number. So we should do something like:  to check whether it is a number. And like in the #0 bug mentioned above, we should see that we use the variables extension in a proper way and deliver strings instead of integers or whatever --Danwe 13:25, 2 September 2011 (UTC)

Bug: Complex while loops malfunction
→ ,

→ ,

→ ,

The while loop should yield the same result as the three statement groups before. However, it doesn't.

The result is (compare http://glossar.hs-augsburg.de/index.php?title=GlossarWiki:Problems&oldid=19050):

A B → B, A (OK) C D → D, C (OK) E F → F, E (OK)

A B → B, A ; C D → D, C ; E F →, ; (here F, E is missing; only the comma is displayed)

Complex while loops in combination with RegexFunction functions seem not work very robust. The while loop behaves differently depending on non-destructive(!) commands stated before that loop. If, e.g., the command is added before the loop, the result of the loop alters:

B → B, A ; C D →, ; E F → , ; (here F, E  and D, C are missing) (compare: http://glossar.hs-augsburg.de/index.php?title=GlossarWiki:Problems&oldid=19046, http://glossar.hs-augsburg.de/index.php?title=GlossarWiki:Problems&oldid=19047, http://glossar.hs-augsburg.de/index.php?title=GlossarWiki:Problems&oldid=19048)

Hey, but sometimes it works! (http://glossar.hs-augsburg.de/index.php?title=GlossarWiki:Problems&oldid=19049, http://glossar.hs-augsburg.de/index.php?title=Vorlage:Quelle:Buch&oldid=19034)

BTW: In  the function   had to be used instead of  in order to make the while loop work correctly.

--Kowarschick 11:17, 9 September 2011 (UTC)

Non-working extension
With all the complaints about bugs, I suppose this extension should be considered non-working? Programming logic like this isn't something where bugs that produce inconsistent results can be tolerated, right? Badon 20:24, 16 September 2011 (UTC)
 * works perfectly for me - I just fixed a few minor bugs (those I have reported) myself, can't confirm the newest bugs though. This extension should be in SVN, I really want to fix some code but I am not sure whether to make a fork or just fix the code directly here, can't see any way to contact the author. --Danwe 13:46, 18 September 2011 (UTC)