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)