Difference between revisions of "Yyy"

Revision as of 22:00, 27 August 2008

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)

  Wow, this took me quite a bit longer than I expected ;-). Anyway, I have hacked together a rough patch for anyone interested - it's a bit on the big side, so I've put it on my user page to avoid cluttering up this page. Bear in mind that due to the rough nature of the patch and the fact that it isn't feature complete, it's probably best described as a "proof of concept" patch, rather than something that can be directly rolled in to a running wiki.

  Eclecticdave 01:52, 24 April 2008 (CEST)

  In regard to character escaping (e.g. ²{ }²), it might be time for DPL 3.0, I put together an extension under 1.11 that required character escapes to work. Like DPL2, it broke under 1.12+, but I found out that it was far easier to rewrite the extension, because I no longer need character escapes to get the functionality I was trying to achieve. There's a slew of open issues I've been trying to tackle by hacking DPL2, but I think it might be best for a completely new version (which will include syntax changes, so unfortunately, it won't be backwards compatible). —Sledged (talk) 20:30, 21 July 2008 (CEST)

• Undoubtedly I am missing something, but as a preliminary result, I got both the above Article random and my own ²{ }² test to render correctly under DPL 1.6.9 and MediaWiki 1.12.0 (both new parser and old) by applying this to DynamicPageList2.php:

3767c3767
< 		return $r;
---
> 		return $this->mParser->transformMsg($r, $this->mParser->mOptions);

--Rezyk 01:06, 26 April 2008 (CEST)

• Hmm..one thing I missed is that Parser Extension mode doesn't work with this (only Parser Function mode). --Rezyk 01:18, 26 April 2008 (CEST)

• I can confirm that this fix works for me too. Kicking myself now, obviously :-(

Your patch misses escaped templates in 'resultsheader/footer' parameters, but it just needs the equivalent change made in a second place ... additional patch below ...

Eclecticdave 03:04, 27 April 2008 (CEST)

diff --git a/DynamicPageList2.php b/DynamicPageList2.php
index a980059..c76cf1c 100644
--- a/DynamicPageList2.php
+++ b/DynamicPageList2.php
@@ -3055,6 +3055,9 @@ class ExtDynamicPageList2
         $footer = str_replace( '\n', "\n", str_replace( "¶", "\n", $footer ));
         $footer = str_replace('%VERSION%', self::VERSION, $footer);
 
+        $header = $parser->transformMsg($header, $parser->mOptions);
+        $footer = $parser->transformMsg($footer, $parser->mOptions);
+        
         $output .= $header . $dpl2result . $footer;
         
         // The following requires an extra parser step which may consume some time

• Further development: The root reason for this issue is that the old parser would do further recursive processing on the parser function result by calling replaceVariables on it from within braceSubstitution, but this step (or its equivalent) was simply skipped in the new parser. Calling transformMsg is one way to do the equivalent processing, but it has unwanted side-effects (because it clears the parser state). Here is a patch for DynamicPageList2.php of DPL 1.7.2 that (as far as I've seen) fixes everything without breaking anything else:

898c898,904
<         return self::dynamicPageList($input, $params, $parser, $reset, 'func');
---
>         $dplresult = self::dynamicPageList($input, $params, $parser, $reset, 'func');
>         global $wgVersion;
>         if (version_compare($wgVersion, '1.12.0')<0 || $parser instanceof Parser_OldPP) return $dplresult; // old parser does further recursive processing by default
>         return array( // normal parser needs to be coaxed to do further recursive processing
>           $parser->getPreprocessor()->preprocessToObj($dplresult, Parser::PTD_FOR_INCLUSION ),
>           "isChildObj" => true
>         );

--Rezyk 08:04, 2 May 2008 (CEST)