Issue:Including nested templates no longer works with MW 1.12's new parser behaviour

Description:	Including nested templates no longer works with MW 1.12's new parser behaviour
Extension / Version:	DPL   /   1.6.8
Type / Status:	Bug   /   open

Problem

Including nested templates no longer works with MW 1.12's new parser behaviour.

Pre 1.12 behaviour

{{#dpl:title=Random|include={Template Name}:Parameter}}

Which until 1.12 outputted the contents of the field, even if it contained another (nested) template.

Article random contents

{{Template Name
Parameter = {{Another Template|Something}} 
}}

Post 1.12 behaviour

{{#dpl:title=Random|include={Template Name}:Parameter}}

Now outputs:

{{Another Template|Something}} (Without parsing it)

Reply

This is surprising! As far as I understand the new MW parser version will never allow the kind of constructs you mention. http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_12_0RC1/phase3/RELEASE-NOTES contains a chapter on parser changes which states that the parsing sequence has intentionally been changed and now no longer supports the construction of template code by other templates.

Could somebody find out how to nest templates in future (regardless of DPL)? I think the developers of the MW parser should be told that they are going to cut down a useful behaviour. What alternative do they offer? I would be pleased if you could find out!

citation:

 Uncovered preprocessor syntax is generally not recognised. For example, if you
 have "{{a" in Template:A and "b}}" in Template:B, then "{{a}}{{b}}" will be
 converted to a literal "{{ab}}" rather than the contents of Template:Ab. This
 was the case previously in HTML output mode, and is now uniformly the case in
 the other modes as well. HTML-style comments uncovered by template expansion
 will not be recognised by the preprocessor and hence will not prevent template
 expansion within them, but they will be stripped by the following HTML security
 pass

Gero 08:07, 28 March 2008 (CET)

Third-party comments

• Bug 5678 is a calamity for DPL2. All ²{ }² calls are now broken! What's gotten into their minds, breaking stuff and not even suggesting a workaround? -- Rasqual 15:42, 6 April 2008 (CEST)

• I invested several hours to find a workaround (diving into the new parser sources) and I COULD NOT find a way. Even calling a second recursiveParse within DPL (if the user used ²{}²) did NOT help. Unless the MW developers offer an option for downward compatibility some very useful features of DPL will no longer be available. I am not good at lobbying myself, but I would really appreciate if DPL users could vote on the MW website for having this resolved. Gero 17:17, 6 April 2008 (CEST)
  • I filed a bug on MediaWiki's bugzilla, where it has a much higher chance of it being seen by devs that know enough about the parser to fix this (me not being one of them, unfortunately). Here's hoping for something other than a WONTFIX :D --Skizzerz 03:16, 10 April 2008 (CEST)

Thank you for that report. The required minimum solution could probably look like this:

If a DPL query needs recursive template expansion DPL should be able to activate this kind of behaviour for the current parsing process. It would even be sufficient to use that kind of behaviour for only the portion of wiki code which is processed by DPL. DPL could detect the necessity for recursive template expansion either implicitly (if the DPL statement contained certain constructs) or it could explicitly be told by a new DPL parameter to do so.

Regarding the use of DPL you are absolutely right: It is quite useful for medium size wikis which want to use an elaborated semantic model. There are numerous such wikis out in the world, some of them not being exposed to the public as they reside behind enterprise firewalls. I think it is legitimate to consider these wikis as being a significant part of the MW community .. Gero 07:37, 10 April 2008 (CEST)

I'll dive into the parser source pretty soon and see if I can't code a hook or something for you to use in parsing recursively-defined templates. Can't guarantee much, and if I do manage to do this it will only appear in the latest 1.13 alpha build, not the 1.12 branch. --Skizzerz 02:42, 11 April 2008 (CEST)

• It looks like it should be possible to get the ²{ }² formats working at least. Escaping templates is no longer possible, but there is a way of putting some control over template expansion into the hands of DPL, which will hopefully have the same effect. There's a new flag, SFH_OBJECT_ARGS that can be passed to setFunctionHook, which causes DPL to be sent partially parsed code and allows final parsing to be deferred until DPL is ready. I'm working on a patch, but I haven't quite got it working yet.

Eclecticdave 18:24, 13 April 2008 (CEST)