Last modified: 2011-09-06 15:11:25 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 2257 - Template parameters unavailable to XML-style parser tags
Template parameters unavailable to XML-style parser tags
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.11.x
All All
: Normal normal with 34 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
: 591 4529 5435 7591 7673 8600 8828 9005 9645 9930 10712 10766 10860 10961 11684 12236 14389 14792 15307 16010 16825 18417 23572 30782 (view as bug list)
Depends on:
Blocks: 8600
  Show dependency treegraph
 
Reported: 2005-05-27 18:39 UTC by Dashiva
Modified: 2011-09-06 15:11 UTC (History)
46 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Fix for REL1_4 (1.41 KB, patch)
2005-05-27 23:54 UTC, Dashiva
Details
Fix for HEAD (1.50 KB, patch)
2005-05-27 23:55 UTC, Dashiva
Details
Adds methods to Parser for parsing of text (1.21 KB, patch)
2005-07-29 18:05 UTC, Jamie Bliss
Details
Parser.php method for extensions to interpolate template vars (1.9-svn) (1.94 KB, patch)
2006-10-22 20:12 UTC, Evan Miller
Details
Attempt to work with <includeonly> (1.9-svn) (1.98 KB, patch)
2006-10-25 04:15 UTC, Evan Miller
Details
Patch for REL1_9 (3.67 KB, patch)
2007-05-03 22:19 UTC, Sean J
Details
Patch for parser.php (3.54 KB, patch)
2007-05-08 21:36 UTC, Sean J
Details
Proposed solution: Extension TagParser (1.32 KB, text/plain)
2008-01-06 22:11 UTC, René Kijewski
Details
Allow PPFrames to be used to truly make template variables available (3.35 KB, patch)
2009-04-24 17:03 UTC, nephele
Details

Description Dashiva 2005-05-27 18:39:13 UTC
Say I have Template:Custom with content:
<mycustomtag>Param1 = {{{1}}}</mycustomtag>
I call it on another page using {{Custom|parameter}}

This results in the parser giving the hook's function "Param1 = {{{1}}}" as input. Since extension 
output isn't parsed further at all, and the extension itself has no way of recovering it (the 
recursion stack is inaccessible), the parameter is lost.

Possible solutions:
* Substitute parameters in parser hook input
* Give extensions access to the stack containing the parameters

I imagine the second would be a huge mess, so I would greatly prefer the first alternative.
Comment 1 Dashiva 2005-05-27 23:54:32 UTC
Created attachment 576 [details]
Fix for REL1_4

Before starting recursive parsing of templates, stores the parameters of that
template. Uses these parameters to parse variables in extension input.

Does not change non-extension functionality at all, so should be safe.
Comment 2 Dashiva 2005-05-27 23:55:04 UTC
Created attachment 577 [details]
Fix for HEAD

As above.
Comment 3 Zigger 2005-05-28 01:50:40 UTC
See also bug 684.
Comment 4 Jamie Bliss 2005-07-29 18:05:25 UTC
Created attachment 753 [details]
Adds methods to Parser for parsing of text

Takes another approach on this. Instead of having the parser automactically
parse template arguments, have the extension call a function for the purpose of
expanding templates and parameters. Also includes a stub for doing a full
parse. (Currently only calls htmlentities() on the input, since any attempt to
parse was disasterous in my testing.)

(Maybe this should be moved to a new bug?)
Comment 5 Dashiva 2005-07-30 13:32:41 UTC
It is my opinion that extensions should be substitution-agnostic. If someone wants 
to put {{PAGENAME}} into an extension, that should work without the extension author 
having to predict it and add variable parsing to his extension. Furthermore, it's 
much easier to handle it once in Parser.php than in all kinds of different 
extensions.
Comment 6 Brion Vibber 2006-04-03 07:23:34 UTC
*** Bug 5435 has been marked as a duplicate of this bug. ***
Comment 7 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-10-16 00:53:38 UTC
*** Bug 7591 has been marked as a duplicate of this bug. ***
Comment 8 Evan Miller 2006-10-22 19:53:11 UTC
*** Bug 4529 has been marked as a duplicate of this bug. ***
Comment 9 Evan Miller 2006-10-22 20:12:04 UTC
Created attachment 2536 [details]
Parser.php method for extensions to interpolate template vars (1.9-svn)

I've written a patch for this against 1.9-svn (rev. 17200). It defines a method
called replaceTemplateVariables that extension authors can use. Sample usage:

function myExtension_Render($source, $argv, &$parser) {
    $source = $parser->replaceTemplateVariables($source);
    ...
}

Making this function available but not mandating it I think preserves the
greatest flexibility and backward-compatibility.

This functionality is something that users of my extension have been asking
for, and I think a lot of people will appreciate it. Thanks for reviewing it!
Comment 10 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-10-24 05:00:01 UTC
*** Bug 7673 has been marked as a duplicate of this bug. ***
Comment 11 Brian 2006-10-24 15:06:08 UTC
I had some problems with patch 2536 when using <includeonly> and </includeonly>,
getting the error:

<b>Warning</b>:  array_key_exists() [<a
href='function.array-key-exists'>function.array-key-exists</a>]: The second
argument should be either an array or an object in
<b>/home/www/public_html/w/includes/Parser.php</b> on line <b>3277</b>

The extension is using the $parser->replaceTemplateVariables() rather
generically, so I suspect it's an issue in Parser.php. The error appears when
viewing/editing the Template, and the Template essentially reduces to something
likeso:

{{{1}}}
<includeonly>
<extension>
argument={{{1}}}
</extension>
</includeonly>

Calling the template from another page works just fine, mind you.
Comment 12 Evan Miller 2006-10-25 04:15:46 UTC
Created attachment 2550 [details]
Attempt to work with <includeonly> (1.9-svn)

I could not reproduce the <includeonly> incompatibility, but given the symptoms
you describe I think this will fix it.
Comment 13 Tim Starling 2006-10-25 04:38:19 UTC
I would prefer to entirely separate the preprocessing stage from the HTML
generation stage. Then we should introduce a flags parameter to
Parser::setHook(), giving three possible preprocessing styles:

* PP_TRANSPARENT: Expand templates and template arguments inside the extension
tag, as if it wasn't there. This is the desired behaviour for many extensions.
* PP_OPAQUE: Treat text inside extension tags as opaque. This is the current
behaviour. 
* PP_EXPAND: Expand the tag during preprocessing, via the callback. This allows
extensions which are syntactically equivalent to tags, but functionally
equivalent to parser functions. One obvious application for this would be a
<template> tag, which provides an XML-like interface to template expansion,
thereby providing rigorous argument escaping for applications which need it.

Recursive parsing in extensions is slow, complicated and prone to failure. The
fact that we do strip() before replaceVariables() produces counterintuitive
behaviour which is mostly hidden at the moment by the lack of parser interaction
features such as this one. For example, <ref> tags exposed via template
expansion will be ordered after <ref> tags coming directly from the article
text, in the <references/> list. Counterintuitive behaviour such as this (no
doubt there are many other similar problems) can be avoided by doing extension
expansion after a complete extension-tag-aware preprocessing phase.
Comment 14 Brian 2006-10-25 05:35:39 UTC
(In reply to comment #12)
> Created an attachment (id=2550) [edit]
> Attempt to work with <includeonly> (1.9-svn)
> 
> I could not reproduce the <includeonly> incompatibility, but given the symptoms
> you describe I think this will fix it.

Yes, this is essentially the same solution I came up with, but thank you for
submitting it. Incidentally, the problem was broader than <includeonly>,
applying to any variable reference (i.e. {{{1}}}) being parsed; it was simply
coincidental that it first occurred with me while using <includeonly>.
Comment 15 Fernando Correia 2006-12-19 13:41:55 UTC
In my opinion, template parameters should always be substituted before calling
the hook, like the way it works for parser functions.
Comment 16 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-01-28 21:25:06 UTC
*** Bug 8600 has been marked as a duplicate of this bug. ***
Comment 17 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-01-30 16:41:23 UTC
*** Bug 8828 has been marked as a duplicate of this bug. ***
Comment 18 Emilien ARNAUD 2007-01-30 20:53:25 UTC
See Bug 8828 to get a working patch
Comment 19 Rob Church 2007-02-16 23:19:59 UTC
*** Bug 9005 has been marked as a duplicate of this bug. ***
Comment 20 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-04-20 21:23:39 UTC
*** Bug 9645 has been marked as a duplicate of this bug. ***
Comment 21 Sean J 2007-05-03 22:19:12 UTC
Created attachment 3574 [details]
Patch for REL1_9

The major issue, as stated above, is the strip() call before replaceVariables()
in brace_substitution(). This prevents template arguments from being added to
the stack which are therefore unavailable to an extension tags. 

As a relatively easy fix, strip() could be called from replaceVariables() as
determined by the parser output type.  This way the template arguments could be
added to the stack and accessed by any extension tags. 

Tested against ParserTests.php for 1.9.3, against same items as head parser. 
The same patch should work for 1.10, but I haven't tested it.
Comment 22 Rob Church 2007-05-03 22:26:39 UTC
Can we have patches against current trunk, HEAD revision? Non-critical fixes and
new features don't go into stable branches.
Comment 23 Sean J 2007-05-08 21:36:40 UTC
Created attachment 3602 [details]
Patch for parser.php

Same as previous "Patch for REL1_9" but against the trunk (r21994). Produces
identical ParserTests.php output as current revision.  Makes template variables
available to parser tags via the $parser->mArgStack attribute.
Comment 24 Daniel U. Thibault 2007-05-10 16:29:59 UTC
I strongly suspect [http://bugzilla.wikimedia.org/show_bug.cgi?id=8835|bug 8835]
will be fixed at the same time this bug (2257) is. They seem related.
Comment 25 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-17 00:13:21 UTC
*** Bug 9930 has been marked as a duplicate of this bug. ***
Comment 26 Betlista 2007-05-17 12:13:29 UTC
Templates not working in MediaWiki 1.9.3 when used {{TemplateName|argument}}, there is {{{1}}} showing in page instead of argument.

Using of {{TemplateName|1=argument}} works fine.
Comment 27 Sean J 2007-05-20 22:03:47 UTC
(In reply to comment #26)
> Templates not working in MediaWiki 1.9.3 when used {{TemplateName|argument}},
> there is {{{1}}} showing in page instead of argument.
> 
> Using of {{TemplateName|1=argument}} works fine.
> 

Both REL 1_9 patch and the head patch passed the "Template unnamed parameter" parser test. I can't repoduce the bug. Do you see the bug in the current trunk, head revision?
Comment 28 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-21 00:44:47 UTC
To avoid clutter, please open new bug reports to discuss different problems.  Thank you.
Comment 29 Raimond Spekking 2007-07-26 20:23:33 UTC
*** Bug 10712 has been marked as a duplicate of this bug. ***
Comment 30 Raimond Spekking 2007-08-01 06:26:08 UTC
*** Bug 10766 has been marked as a duplicate of this bug. ***
Comment 31 Timothy J. Crowell 2007-08-01 07:47:14 UTC
It has been about 2 years since this bug was submited, when is a fix going to to be put on Wikipedia?
Comment 32 Timothy J. Crowell 2007-08-03 01:00:29 UTC
Bug is still present in MediaWiki 1.11-svn, so I changed version from 1.9-svn to 1.11-svn.
Comment 33 Betlista 2007-08-04 23:12:25 UTC
Hi,

I finally found some time for test with trunk version.
I downloaded version 24597 from SVN and I had no problem to simulate the problem.
At http://wikibug.appoge.net/ I created wiki page from trunk and also created two templates:

1. template "body" with code:
<div style="font-weight: bold;">
{{{1}}}
</div>

2. template "capital" with code:
<span style="color: green;">{{{1}}}</span>

Result of testing of these two templates is at http://wikibug.appoge.net/index.php/Template_bug_test

btw: Why there are so old snapshots at http://download.wikimedia.org/mediawiki/snapshot/ ?
Comment 34 Danny B. 2007-08-09 15:40:34 UTC
*** Bug 10860 has been marked as a duplicate of this bug. ***
Comment 35 Raimond Spekking 2007-08-24 08:34:37 UTC
*** Bug 10961 has been marked as a duplicate of this bug. ***
Comment 36 Jamie Hari 2007-09-03 19:43:39 UTC
Does the patch in Comment #23 indeed resolve this issue?
Could we double-check it and incorporate if possible? 

Bug 8693 might be helped by this fix, as well.
Comment 37 Nick Jenkins 2007-09-04 07:43:00 UTC
Re comment #36:
> Does the patch in Comment #23 indeed resolve this issue?

The patch in comment #23 solved the issue for me on MediaWiki 1.9.3, but
with a few minor updates (added one line to initialize $this->mArgStack,
and added a few lines to replace template args in the parameters & content
for custom parser tags). Whether these updates are truly needed, or can be
done better, I did not investigate - it was literally a 3-minute hack-job
modification of Sean J's patch to solve a specific problem that was annoying
me (i.e. that I wanted a custom parser tag to never have to care about
templates, and to only ever see the expanded content, never the raw content).
If it you're keen, the diff is here, but it's probably inefficient crap:
http://files.nickj.org/MediaWiki/possibly-yucky-2257-parser-patch.txt
Comment 38 Steve Sanbeg 2007-09-11 21:31:45 UTC
What does the patch do?  From my testing (on 1.11) a parser function can already go through $wgParser->mArgStack to get arguments.  I'd think removing a call to strip before internalParse would just break stuff.  I don't quite see what we want to do that's not there already, or how this patch would do that; maybe things changed significantly since it was written.
Comment 39 Steve Sanbeg 2007-09-11 22:32:06 UTC
(In reply to comment #38)
> What does the patch do?  From my testing (on 1.11) a parser function can
> already go through $wgParser->mArgStack to get arguments.  I'd think removing a
> call to strip before internalParse would just break stuff.  I don't quite see
> what we want to do that's not there already, or how this patch would do that;
> maybe things changed significantly since it was written.
> 

OK, I think I understand now.  So you can't currently access args from XML-style tags, since they're parsed before the call stack is set up.  This patch tries to fix that by reordering the parse in such a way that the stack will be set up, but not breaking any core functionality; although it looks like extensions would get hosed by this (per my earlier comment).
Comment 40 Jamie Hari 2007-09-17 01:38:45 UTC
So the patch is a no go then?
Sounds like we need to make ALL the data available first, from all sources... then parse it all in a fully seperate, second step, no?
Comment 41 Steve Sanbeg 2007-09-19 16:20:52 UTC
(In reply to comment #40)
> So the patch is a no go then?
> Sounds like we need to make ALL the data available first, from all sources...
> then parse it all in a fully seperate, second step, no?
> 

It looks to me like it has the potential for too many side affects.  This could be as simple as pushing the current args on to the stack where the tag could get them, then setting a flag to indicate that was done early, so the normal processing can see that and clear the flag instead of pushing again.  That should work without reordering the parsing, and should allow adding sanity checks, to keep things safe.
Comment 42 Roan Kattouw 2007-10-17 15:23:11 UTC
*** Bug 11684 has been marked as a duplicate of this bug. ***
Comment 43 jacki buros 2007-10-22 22:45:52 UTC
Is it just me, or has this issue been resolved on Wikipedia:en? See, for example, http://en.wikipedia.org/wiki/Template:Citation/core. In fact, this kind of template use (templates within XML-style parser tags) is fairly frequent on the English-language Wikipedia site. Does anyone know why this works, and whether there is a reliable solution/patch available for REL1_11? 
Comment 44 Sergey Chernyshev 2007-10-23 19:31:35 UTC
(In reply to comment #43)
> Is it just me, or has this issue been resolved on Wikipedia:en? See, for
> example, http://en.wikipedia.org/wiki/Template:Citation/core. In fact, this
> kind of template use (templates within XML-style parser tags) is fairly
> frequent on the English-language Wikipedia site. Does anyone know why this
> works, and whether there is a reliable solution/patch available for REL1_11? 
> 

Which tag on http://en.wikipedia.org/wiki/Template:Citation/core do you refer to?
Comment 45 jacki buros 2007-10-23 21:01:36 UTC
(In reply to comment #44)
> (In reply to comment #43)
> > Is it just me, or has this issue been resolved on Wikipedia:en? See, for
> > example, http://en.wikipedia.org/wiki/Template:Citation/core. In fact, this
> > kind of template use (templates within XML-style parser tags) is fairly
> > frequent on the English-language Wikipedia site. Does anyone know why this
> > works, and whether there is a reliable solution/patch available for REL1_11? 
> > 
> 
> Which tag on http://en.wikipedia.org/wiki/Template:Citation/core do you refer
> to?
> 

Hi and thanks for your response. I was referring to the <cite> tag -- 

The relevant section of Template:Citation/core is as follows: 

 <cite 
 {{
   #if:{{{Ref|}}}
   |{{#ifeq:{{{Ref|}}}|none||id="{{{Ref|}}}"}}
   |id="CITEREF{{#if:{{{Surname1|}}}
      |{{{Surname1}}}{{{Surname2|}}}{{{Surname3|}}}{{{Surname4|}}}
      |{{{EditorSurname1|}}}{{{EditorSurname2|}}}{{{EditorSurname3|}}}{{{EditorSurname4|}}}
    }}{{{Year|{{{Date|}}}}}}"
 }}>{{
 <!--============  .... {omitted for sake of readability} ...  ============-->
 }}</cite>

If I put this same code into a Special:ExpandTemplate page (REL1_11, Cite and ParserFunctions installed) it is rendered like:

[1,1,1,1,1,1,1,... ]

This occurs both with and without the html comment, because the templates are not expanded. Pasting the same into the Special:ExpandTemplates page on Wikipedia:en will, instead, give a valid <cite ...> ... </cite> tag.

A little surprising is the fact that the following <span> tag code also within Template:Citation/core does appear to be correctly parsed on both versions:

<span
<!-- This is a COinS tag (http://ocoins.info), which allows automated tools to parse the citation information: -->
    class="Z3988"
    title="ctx_ver=Z39.88-2004&rft_val_fmt={{urlencode:info:ofi/fmt:kev:mtx:}}book{{
      #if: {{{Journal|}}}
      |&rft.genre=article&rft.atitle={{urlencode:{{{Title|}}}}}&rft.title={{urlencode:{{{Periodical|}}}}}
      |{{
         #if: {{{IncludedWorkTitle|}}}
         |&rft.genre=bookitem&rft.atitle={{urlencode:{{{IncludedWorkTitle|}}}}}
         |&rft.genre=book
       }}&rft.title={{urlencode:{{{Title|}}}}}
    }}{{
 <!--============  .... {omitted for sake of readability} ...  ============-->
}}> 

FYI I tested REL1_11 behavior on http://www.wikidoc.org; see http://www.wikidoc.org/index.php/Special:Version for specifics.

Hope this helps ...

Jacki
Comment 46 Sergey Chernyshev 2007-10-23 21:26:36 UTC
Actually, <span> behavior is not surprising since it's not a parser tag, but it seems that you're correct about cite, although I can't find a relevant change in SVN.

Can developers comment on this?
Comment 47 Sergey Chernyshev 2007-10-23 21:28:34 UTC
Actually, it seems that <cite> is not a parser tag on Wikipedia:en - see http://en.wikipedia.org/wiki/Special:Version
Comment 48 Tisza Gergő 2007-10-23 21:38:28 UTC
<cite> is a HTML tag, nothing more.
http://www.w3.org/TR/html401/struct/text.html#edef-CITE
Comment 49 Sergey Chernyshev 2007-10-23 21:52:32 UTC
(In reply to comment #48)
> <cite> is a HTML tag, nothing more.
> http://www.w3.org/TR/html401/struct/text.html#edef-CITE

<cite> was defined as parser tag on http://www.wikidoc.org/index.php/Special:Version along with </nocite> when I checked, so I got confused, it's not anymore.
Comment 50 jacki buros 2007-10-23 21:55:48 UTC
Thanks, I was unaware of this and the information is tremendously helpful. We had installed the Biblio.php extension which has a <cite> XML-style parser tag, over-riding its HTML version.

Apologies for the distraction ...  
Comment 51 sanbec 2007-11-21 08:58:19 UTC
Is the bug 12016 related?
Comment 52 Dashiva 2007-12-08 19:49:23 UTC
(In reply to comment #13)
> I would prefer to entirely separate the preprocessing stage from the HTML
> generation stage. Then we should introduce a flags parameter to
> Parser::setHook(), giving three possible preprocessing styles:
> 
> * PP_TRANSPARENT: Expand templates and template arguments inside the extension
> tag, as if it wasn't there. This is the desired behaviour for many extensions.
> * PP_OPAQUE: Treat text inside extension tags as opaque. This is the current
> behaviour. 
> * PP_EXPAND: Expand the tag during preprocessing, via the callback. This allows
> extensions which are syntactically equivalent to tags, but functionally
> equivalent to parser functions. One obvious application for this would be a
> <template> tag, which provides an XML-like interface to template expansion,
> thereby providing rigorous argument escaping for applications which need it.

To return to this idea a bit, I looked at Parser.php in trunk.

setHook behavior hasn't changed as far as I could see, so this is still PP_OPAQUE.

There's a new (1.10) function setTransparentTagHook with no documentation and commit comment "New Parser::setTransparentTagHook for parser extension and template compatibility". From what I see, it adds the custom tag to the "legal HTML tags" list, meaning they survive through parsing and get their contents parsed, and then does callback with the parsed attributes and contents. This seems close to PP_TRANSPARENT, but parses _all_ wikitext instead of just curly-brace constructs. Since we already have recursiveTagParse, this might not be optimal.

I didn't find anything resembling PP_EXPAND.
Comment 53 Raimond Spekking 2007-12-09 08:51:00 UTC
*** Bug 12236 has been marked as a duplicate of this bug. ***
Comment 54 Nathanael 2007-12-29 08:13:59 UTC
I found the following simple diff against revision 28900 of Parser.php was sufficient for my needs:

--- includes/Parser.php.orig    Fri Dec 28 13:31:20 2007
+++ includes/Parser.php Sat Dec 29 15:30:28 2007
@@ -5376,6 +5376,8 @@
                                } else {
                                        $s = $root->textContent;
                                }
+                       } elseif ( $root->nodeName == 'attr' ) {
+                               $s = $this->parser->replaceVariables($root->nodeValue, $this, 1);
                        } elseif ( $root->nodeName == 'ext' ) {
                                # Extension tag
                                $xpath = new DOMXPath( $root->ownerDocument );
Comment 55 En-Cu-Kou 2007-12-30 11:38:42 UTC
Nathanael's diff solved my problem as well.

I believe PP_TRANSPARENT for attributes would be a sane default, it's
unlikely to break existing extensions (as attrubutes are usually just
simple strings), it's easy do implement, document and remember, and
it doesn't rule out the possibility of adding the preprocessing style
flags later.
Comment 56 René Kijewski 2008-01-06 22:11:08 UTC
Created attachment 4519 [details]
Proposed solution: Extension TagParser

In the German Wikipedia we have hacked a solution to this bug.

It makes every XML tag available through a parser function {{#tag}}. E.g. {{#tag:math|e = m c^2}} will become <math>e = m c^2</math> and {{#tag:math| {{{1}}} }} will evaluate {{{1}}} as a tex-expression. Any amount of attributes is available: {{#tag:source|lang="bash"|echo "test"}}. The last parameter is the content, all others are attributes.

You may find further explanation on:
- http://www.mediawiki.org/wiki/Extension:TagParser
Comment 57 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-01-09 18:02:16 UTC
The TagParser extension has inspired the addition of an approximately identical feature to core, in r29482.  This fixes the bug for most practical purposes, i.e., complicated templates.  A clean fix is still desirable, so the bug should probably be left open.
Comment 58 Voyagerfan5761 / dgw 2008-01-09 18:05:07 UTC
(In reply to comment #57)
> The TagParser extension has inspired the addition of an approximately identical
> feature to core, in r29482.  This fixes the bug for most practical purposes,
> i.e., complicated templates.  A clean fix is still desirable, so the bug should
> probably be left open.
> 

So you're saying that parser tags that are in want of nested templates should use {{#tag:}} now? Agreed that a clean solution is available. Is it possible to let extension tags parse first perhaps, so returned wikimarkup can be parsed by MediaWiki?
Comment 59 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-01-09 18:12:35 UTC
I'm not clear what you're asking.  Currently, extension tags like <ref> *are* parsed before curly-brace syntax.  This means that when you do <myextension>{{{1}}}</myextension>, your extension receives the text "{{{1}}}", not the text of the first parameter, because template parameters and other curly-brace syntax have not been parsed yet.  What needs to happen ideally is that extension tags and curly brace constructs should be parsed at the same time, not one after the other.  r29482 allows this to happen, if I understand correctly, since you can use {{#tag:myextension|{{{1}}} }}, which behaves as expected.
Comment 60 Voyagerfan5761 / dgw 2008-01-09 18:16:03 UTC
Oh, whoops, I wasn't thinking properly. Yes, parsing templates/curly braces before or at the same times as extension tags would be ideal; I see that now. At least it's possible to do stuff like put templates in things like <imagemap> now, yes? It's just that nesting parser functions get confusing and tedious to deal with...
Comment 61 Jan-Niklas Kettenburg 2008-01-09 18:19:37 UTC
What's about <gallery width={{{1}}}>...</gallery>? Was this fixed?
Comment 62 Roan Kattouw 2008-01-09 18:20:27 UTC
(In reply to comment #61)
> What's about <gallery width={{{1}}}>...</gallery>? Was this fixed?
> 

No, but {{#tag:gallery|width={{{1}}}|...}} works.
Comment 63 Brion Vibber 2008-01-11 02:05:45 UTC
That {{#tag:}} thing looks pretty dreadful, and I'd say we definitely don't want it. Just let tags accept parameters by default (or as option).
Comment 64 Purodha Blissenbach 2008-01-11 12:11:12 UTC
Can we nevertheless have it for the next year or two, until a solution with a nicer look has been developed?
Comment 65 Oleg 2008-01-22 08:47:16 UTC
In version 1.0Beta have new tag {{#ask: }}
But how to use and where described syntax I don't know.
Comment 66 Timothy J. Crowell 2008-01-25 09:50:04 UTC
When is {{#tag:}} going to work in Wikipedia and other Wikimedia projects?

-Timothy
Comment 67 Thomas Bleher 2008-01-25 10:01:08 UTC
As soon as the new Preprocessor is activated, which should be RSN.
(You can already test it by adding &timtest=newpp to an URL, e.g. http://de.wikipedia.org/wiki/Benutzer:Tbleher/Test?timtest=newpp )
Comment 68 Thomas Bleher 2008-03-26 17:31:52 UTC
The new parser is active on all Wikimedia wikis (AFAIK) and MW 1.12 also contains the #tag:-feature, so I think we can consider this bug fixed.
Comment 69 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-03-26 23:54:00 UTC
Reopening, the bug is not fixed as stated and a real fix is still desirable.  See previous comments:

(comment #57, me)
> The TagParser extension has inspired the addition of an approximately identical
> feature to core, in r29482.  This fixes the bug for most practical purposes,
> i.e., complicated templates.  A clean fix is still desirable, so the bug should
> probably be left open.

(comment #63, Brion)
> That {{#tag:}} thing looks pretty dreadful, and I'd say we definitely don't
> want it. Just let tags accept parameters by default (or as option).
Comment 70 Roan Kattouw 2008-06-03 10:03:02 UTC
*** Bug 14389 has been marked as a duplicate of this bug. ***
Comment 71 Lilian 2008-06-03 10:36:14 UTC
Hi,

I am trying to do this (in a template) :
<inputbox>
 type=create
 default={{{1}}}
 break=no
 buttonlabel=Create
</inputbox>

But the default value is {{{1}}} and not the value of my first parameter...

Instead, is this supposed to work :
{{#tag:inputbox|default={{{1}}}|type=create|buttonlabel=Create3}}

The result is : "You have not specified the type of input box to create."

If y try this :
{{#tag:inputbox|type=create|default={{{1}}}|buttonlabel=Create3}}

it seems that parameters others than "type" are ignored.

Is there a solution ?

Thanks
Comment 72 Tisza Gergő 2008-06-03 13:44:07 UTC
(In reply to comment #71)

This should work:

{{#tag:inputbox|
 type=create
 default={{{1}}}
 break=no
 buttonlabel=Create
}}
Comment 73 Lilian 2008-06-03 13:48:55 UTC
(In reply to comment #72)
> (In reply to comment #71)
> 
> This should work:
> 
> {{#tag:inputbox|
>  type=create
>  default={{{1}}}
>  break=no
>  buttonlabel=Create
> }}
> 

Yes ! Thanks a lot :)
Comment 74 Brion Vibber 2008-08-25 19:37:25 UTC
*** Bug 15307 has been marked as a duplicate of this bug. ***
Comment 75 Roan Kattouw 2008-10-17 13:37:33 UTC
*** Bug 16010 has been marked as a duplicate of this bug. ***
Comment 76 a.h.m. 2008-12-28 10:26:02 UTC
What can I do to get ImageMap tags on version 1.13.3 to work? I need them to accept brackets....
Comment 77 Raimond Spekking 2008-12-29 08:42:35 UTC
*** Bug 16825 has been marked as a duplicate of this bug. ***
Comment 78 Greg Ubben 2009-01-25 23:19:20 UTC
Use case:  {{#tag:nowiki|{{{url}}}}}
This tag is the only way I've found to receive a template parameter and do a <nowiki> on its expanded value. Such as preventing auto-linking of a URL parameter. Please ensure this ability doesn't go away when this solution is improved.
Comment 79 Roan Kattouw 2009-04-09 13:41:27 UTC
*** Bug 18417 has been marked as a duplicate of this bug. ***
Comment 80 nephele 2009-04-24 17:03:25 UTC
Created attachment 6056 [details]
Allow PPFrames to be used to truly make template variables available

With the introduction of Preprocessor frames to the parsing process, a completely different approach to fixing this issue becomes available -- one which truly fixes the problem, instead of simply bypassing the problem through parser hooks (which do not provide identical functionality to extension tags).

The attached patch works by:
1) Passing the current $frame to the extension tag-calling hook
   ($frame is also passed to the getVariableValue hook, too, in case extension writers have a need for $frame. there. too)
   $frame is added as an extra parameter, and therefore this change is transparent to existing extensions (which simply won't realize that there's an extra parameter available).
2) Passing the $frame back to the parser through recursiveTagParse
   Again, $frame is an extra, optional parameter, so there is no effect of this patch on any existing uses of recursiveTagParse; it simply makes additional functionality available to anyone who wishes to use it.
3) Assorted other code tweaks to pass the $frame variable as an optional argument to all necessary parser functions.

In terms of usage, it means that all existing tag extensions will continue to work they way they always have.  However, tag extensions that wish to expand template variables now have the option to do so, simply by
1) changing the argument list of the extension's implementation function, e.g. change:
     function efSampleRender( $input, $args, $parser )
  to:
     function efSampleRender( $input, $args, $parser, $frame )
2) add $frame to any recursiveTagParse calls, e.g., change:
      $output = $parser->recursiveTagParse( $text );
  to:
      $output = $parser->recursiveTagParse( $text, $frame );
Comment 81 nephele 2009-04-26 22:02:05 UTC
Following up on my previous post, I've run parserTests on the submitted patch (id=6056) and confirmed that the patch passes the parser tests (or at least, it does as well as the current HEAD (r49912) -- HEAD currently fails 14 tests; after adding this patch, the code still fails those same 14 tests).  
Comment 82 Chad H. 2009-07-15 19:23:46 UTC
*** Bug 591 has been marked as a duplicate of this bug. ***
Comment 83 Chad H. 2009-08-25 22:51:28 UTC
*** Bug 14792 has been marked as a duplicate of this bug. ***
Comment 84 nephele 2009-08-30 06:40:23 UTC
Patched in r55682 (see comment #80 for example of how to modify an extension).
Comment 85 Dashiva 2009-08-30 06:45:53 UTC
(In reply to comment #0)
> Possible solutions:
> * Substitute parameters in parser hook input
> * Give extensions access to the stack containing the parameters
> 
> I imagine the second would be a huge mess, so I would greatly prefer the first alternative.

Well, here we are, four years later. Turns out I was dead wrong. :)

Much thanks for finally fixing this one.
Comment 86 Raimond Spekking 2010-05-17 20:19:34 UTC
*** Bug 23572 has been marked as a duplicate of this bug. ***
Comment 87 Adam Cuerden 2010-05-17 20:24:18 UTC
Sorry, when will Wikimedia Commons be updated to the fixed code?
Comment 88 Roan Kattouw 2010-08-13 09:33:08 UTC
*** Bug 24774 has been marked as a duplicate of this bug. ***
Comment 89 Roan Kattouw 2010-09-08 18:41:35 UTC
*** Bug 24774 has been marked as a duplicate of this bug. ***
Comment 90 The Evil IP address 2011-09-06 15:11:25 UTC
*** Bug 30782 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links