Last modified: 2014-02-17 09:35:42 UTC
action=raw&templates=expand should return the source code of a page, with templates within the page expanded. However, if these templates contains extension tag that contains template parameters as value, these parameters are not expanded. For instance, take extension RawFile (http://www.mediawiki.org/wiki/Extension:RawFile). This extension introduce a tag <file>: <file name="myfile" tag="pre">download</file> <pre>some text</pre> When parsed, this tag generates HTML that allows downloading easily the content of the <pre> block. Now lets create a template {{download}}: <file name="{{{name}}}" tag="source">download</file> {{{content}}} If I create a page with as content: {{download|name=myfile|content=<pre> some text </pre> Then downloading that page with ?action=raw&templates=expand would produce: <file name="{{{name}}}" tag="source">download</file> <pre> some text </pre> When I would in fact expect: <file name="myfile" tag="source">download</file> <pre> some text </pre> The strange thing is that the non-replacement only occurs if the tag is indeed a registered tag. If the tag is not known, then all template parameters are replace as in regular wikitext. I think this the same problem that requires tag parser hook to call $parser->recursiveTagParse( $text, $frame ) to have template parameters expanded. I would recommend to expand recursively as well with option templates=expand, or at least foresee another option (like templates=recurse or template=expandrecurse) that would do the same.
Try to use: {{#tag:file|name={{{name}}}|tag=source|download}} {{{content}}} to support template arguments in tags
Thanks for the tip db!!! Actually, I had to use: {{#tag:file|download|name={{{name}}}|tag=source}} {{{content}}} But this indeed works. Writing this in a template {{download}}, uses this template in a page, and then fetch that page with ?action=raw?templates=expand indeed gives the desired expansion: <file name="myfile" tag="source">download</file> <pre> some text </pre> And viewing the page normally indeed gives a clickable "download" link. So this is indeed a work-around that suits my needs perfectly. Now I don't know about this bug report. Tmo this is still a bug, but not a high prio one I guess.