self-inclusion is only allowed once in MediaWiki

[GoogleCodeExporter]

What steps will reproduce the problem?
from https://en.wikipedia.org/wiki/Help:Template#Nesting_templates:
"A template can call itself, but will stop after one iteration to prevent an 
infinite loop."

What is the expected output? What do you see instead?
at the moment, self-inclusion goes as far as the template recursion limit
(see attached unit test - the exact format of the warning message can of course 
be changed, but we can also leave it the same as MediaWiki...)

Please use labels and text to provide additional information.

Original issue reported on code.google.com by nico.kru...@googlemail.com on 6 Dec 2012 at 6:02

Attachments:

• 0001-unit-test-for-recognising-self-inclusions.patch

[GoogleCodeExporter]

Commit r8672 needs to be refined to use the IWikiModel#addTemplate() method.

Original comment by axelclk@gmail.com on 6 Dec 2012 at 7:13

[GoogleCodeExporter]

I just checked whether this is recursive in MediaWiki, too, e.g.
Template1 -(includes)-> Template2 -> Template 1
instead of just
Template1 -> Template1

and it seems that way. I adapted the unit test (see attached).
For indirect loops, MediaWiki seems to append a link to the inclusion which 
created the loop (in this case, viewing)

Original comment by nico.kru...@googlemail.com on 7 Dec 2012 at 11:12

Attachments:

• 0001-Issue133-unit-test-for-recognising-self-inclusions.patch

[GoogleCodeExporter]

...
in this case,
* viewing Template1, it says that the second inclusion of Template2 caused the 
loop, and
* viewing Template2, the offending include would be Template1

Original comment by nico.kru...@googlemail.com on 7 Dec 2012 at 11:13

[GoogleCodeExporter]

I just had a closer look at your code while I was porting all my recent changes 
to 3.1 and there are 2 issues with it:
1) the loop detection must be active for all transclusions, i.e. also the ones 
not using the template namespace
2) the counter must start with 1, not 0

I changed both things in the attached patch but now, a template cannot be 
called twice - right now, I can't see why, so I'm not committing but instead 
appending the updated patch with unit tests here

Original comment by nico.kru...@googlemail.com on 7 Dec 2012 at 6:18

Attachments:

• 0001-Issue133-unit-test-for-recognising-self-inclusions.patch

[GoogleCodeExporter]

Commited r8707.
Could you please check again if it works in all cases?

Original comment by axelclk@gmail.com on 8 Dec 2012 at 5:15

[GoogleCodeExporter]

the commented-out test case was actually valid here's a simpler one:

"{{1x|{{1x|a}}}}"

-> there is no recursion leading to an _endless_ loop here so those kind of 
calls are valid

taking the parameters into the key for fTemplates is no solution either - r8772 
for further test cases for indirect recursions with changing parameter 
(counting up) - they currently fail but that's imho better than a silent 
regression :)

Original comment by nico.kru...@googlemail.com on 10 Dec 2012 at 2:49

[GoogleCodeExporter]

The attached patch could solve this issue but conflicts with issue 77.

Original comment by axelclk@gmail.com on 18 Dec 2012 at 11:22

Attachments:

• patch_issue_133.txt

[GoogleCodeExporter]

actually, this problem existed before but until this patch only for named 
parameters and has to do with the (too early) replacement of the {{!}} 
parameter which then conflicts with the parameters of the #if parser function 
(or any other template parameter substitution) - see r8805
-> we could probably apply the patch, close this issue and create a new one for 
that

Original comment by nico.kru...@googlemail.com on 20 Dec 2012 at 2:18

[GoogleCodeExporter]

I created a new patch with an ugly workaround for the  {{!}} template.
Could you please verify if this is a usable patch?

Original comment by axelclk@gmail.com on 30 Dec 2012 at 12:13

• Changed state: Started

Attachments:

• patch_issue_133_2.txt