rowan.collins wrote:

*** Bug 104 has been marked as a duplicate of this bug. ***

timwi wrote:

*** Bug 155 has been marked as a duplicate of this bug. ***

alanyst wrote:

Proposed patch for parameterized template substitution

I've developed a patch to enable substituted templates to make use of
parameters at the time of substitution. I've done some quick tests of the
patched code on a local test installation of MediaWiki from the latest CVS
sources and things seem to work fine, but I don't know enough to do adequate
regression testing. I have limited the effect of my changes to template
substitution performed when mOutputType == OT_WIKI, so if there's any reason to
include other output types (such as OT_MSG) then the code will have to be
adjusted accordingly.

This is my first-ever contribution to MediaWiki code and I'm not a PHP guru, so
please scrutinize my code carefully because there's a good chance that I
haven't a clue what I'm doing. :)

Attached:

wmahan_04 wrote:

Alan, thanks for looking at the code and submitting a patch. I am also
inexperienced in MediaWiki development, so I'm not an expert on this area
either. But I think you have the right idea for how to implement this change.

I noticed a problem, however; if I understand your patch correctly, it causes
variables to be substituted during the preSaveTransform phase, whereas before
your patch only {{subst:}} type templates were substituted.

For example, if I create a page using the current CVS code with the magic
variable {{CURRENTTIME}}, it is saved to the database without substitution, so
every time I view the page it displays the current time. But with your patch
applied, if I create the same page, the parser substitutes the current time when
I save the page. Thus the page will always display the fixed time at which I
saved the page, rather than dynamically updating as intended.

I don't think it will be difficult to address this issue. Thanks again for the
patch.

wmahan_04 wrote:

Fixed in HEAD (Parser.php revision 1.294). Thanks to Alan for the patch, which I
modified to address the problem I mentioned and to work with other recent Parser
changes.

Resolving as fixed with 1.4 release imminent.