Last modified: 2008-08-11 20:40:12 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 5678 - Double-parse in parser function results
Double-parse in parser function results
Product: MediaWiki
Classification: Unclassified
Templates (Other open bugs)
All All
: High major with 6 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: need-parsertest, patch, patch-need-review
: 9054 12488 12828 (view as bug list)
Depends on: 12652
  Show dependency treegraph
Reported: 2006-04-22 01:56 UTC by Get_It
Modified: 2008-08-11 20:40 UTC (History)
8 users (show)

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

possible solution to the problem (2.23 KB, patch)
2006-11-22 13:45 UTC, Carl Fürstenberg
updated patch (10.74 KB, patch)
2007-03-17 15:00 UTC, Carl Fürstenberg
YAP (5.18 KB, patch)
2007-10-11 17:16 UTC, Carl Fürstenberg

Description Get_It 2006-04-22 01:56:13 UTC
Using {{{vars}}} in the else text of a ParserFunctions
( #if causes a bug, in which both
the "then" and the else text are showed.

#if syntax and example:
{{ #if: <condition> | <then text> | <else text> }}
{{ #if: {{{parameter|}}} | Parameter is defined. | Parameter is undefined, or
empty }}

For example, lets say that I want to change the text of a template depending on
the number of variables set. In this case, if {{{2}}} is defined the text will
be in the plural and both variables {{{1}}} and {{{2}}} will be showed.
* {{ #if: {{{2|}}} | The articles {{{1}}} and {{{2}}} are nice. |  The article
{{{1}}} is nice. }}

The problem is that, because of the use of variables in the else text the #if
will output the following:
* The article The articles {{{1}}} and {{{2}}} are nice. is nice.

A duplication of the bug may be seen on the sandbox at Wikipedia (EN):

Best regards,
Comment 1 Andrew Miller 2006-04-22 11:31:57 UTC
I have tried this on the latest SVN checkout, and it doesn't happen, although it
still happens on Wikipedia, so this has presumably been fixed.
Comment 2 omniplex 2006-04-26 05:58:02 UTC
"then clause clobbers {{{1}}}" is the issue reported in
[[m:Talk:Parser functions]] as "Odd bevaviour: {{{1}}} in {{#if:}}".

My test page [[m:User:Omniplex/Pathoschild]] still shows
it, so if it's already fixed then it's not yet installed
on Meta. A variant is "else clause clobbers {{{2}}}".  
Comment 3 omniplex 2006-05-04 10:58:20 UTC
[[m:Talk:ParserFunctions#New_5678_test_results]] shows that 
this bug is less harmful than I feared, and also predictable.

Comment 4 omniplex 2006-05-11 19:07:03 UTC
5678 affects also "plural:", it's not limited to the new parser functions.
Example given on [[m:ParserFunctions]] below "known problems". So far all
"bugs" related to ParserFunctions turned out to be either features or more
general oddities like this one. Could somebody please reclassify 5678 ? 
Comment 5 omniplex 2006-06-15 07:28:42 UTC
New observation, 5678 does NOT affect #ifeq:,
for examples see

PITA, I was about to document that 5678 is at
least completely predictable, but apparently
#ifeq: somehow gets something right where 
similar "colon functions" with more than two
parameters have serious (wrt subst:) issues.
Comment 6 omniplex 2006-06-17 08:58:24 UTC
Please ignore comment #5, hallucination on my side, it's 100% predictable for 
all "colon functions", and it can even hit named parameters. So "#ifeq:" is no
special case, it's only less likely to get it wrong with "#ifeq:". 
Comment 7 Carl Fürstenberg 2006-11-20 12:12:48 UTC
This is an example what might happen:

if a template contains following code:
* {{ #if: {{{1}}} | {{{2}}} | {{{1}}} -  {{{1}}} article {{{1}}} is nice. }}

and is called by:

result will be:
* foo - foo article foo is nice.
Comment 8 Carl Fürstenberg 2006-11-22 13:45:04 UTC
Created attachment 2755 [details]
possible solution to the problem

when I was reading on meta page for wikimedia extension, I found that the
functions could return an array instead of a string, and that array could take
a couple of flags. this patch returns the flag 'noparse', and that seems to fix
the problem.
Comment 9 Steve Sanbeg 2006-12-08 17:46:24 UTC
The patch returns the 'noargs' flag, not noparse (which wouldn't do what you want).

Currently, it seems that you can pass arbitrary arguments into the parser
functions, which would substitue into the result.  i.e. changing the first
example to

{{ #if: {{{2|}}} | The articles {{{1}}} and {{{2}}} are nice. | The article
{{{1}}} is nice. |1={{{1}}}|2={{{2}}} }}

Should replace the clobbered arguments.

The patch would break some functionalty, i.e. {{#if:{{{1}}}|have {{{text}}}|no
{{{text}}} found|text=some long string...}} would stop working.  But that
probably wasn't intentional, so it shouldn't be missed.
Comment 10 Rob Church 2007-03-15 16:36:46 UTC
(Not a blocker.)
Comment 11 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-03-15 21:42:54 UTC
*** Bug 9054 has been marked as a duplicate of this bug. ***
Comment 12 Carl Fürstenberg 2007-03-17 15:00:43 UTC
Created attachment 3358 [details]
updated patch

Have updated the patch to work with the current branch. it includes also fix
for CoreParserfunctions.php

a test page can be found, if my computer is online at
Comment 13 Carl Fürstenberg 2007-10-06 20:52:11 UTC
bumping up the priority as people are getting more and more angry of the bug, and as it's pretty difficult to explain why it wont work as expected to ordinary editors, this bug should be prioritized.
Comment 14 Carl Fürstenberg 2007-10-11 17:16:37 UTC
Created attachment 4249 [details]

Comment 15 Rich Farmbrough 2007-10-15 12:40:52 UTC
This sort of bug, if extant, is a. worrying, b. eating loads of template developers time.
Comment 16 Brion Vibber 2007-10-15 19:42:04 UTC
Can you create a parser test case for this to illustrate the problem and the fix? Probably adding a basic test case file for ParserFunctions would be a good start here.

Also, can you explain 'YAP'? :)
Comment 17 Rich Farmbrough 2007-10-15 22:09:10 UTC
Like yip but not quite as much.  
Comment 18 Carl Fürstenberg 2008-01-11 01:42:59 UTC
Fixed in the new parser (not live yet)
Comment 19 Tim Starling 2008-01-11 04:46:03 UTC
I'll close all the bugs the new parser fixes *when* it goes live. There are a lot.
Comment 20 Tim Starling 2008-01-14 01:28:47 UTC
We're moving closer to deploying this fix on Wikimedia now. We (especially Splarka, MZMcBride and me) have found quite a few templates that rely on this bug. No doubt when the fix goes live, some things will be broken.

For instance, incorrect use of {{!}}. Due to this bug, {{!}} can be used to separate template parameters, if the template call is inside a parser function. 

For instance, where [[Template:Passthru]] contains {{{1}}}:

No template call in either parser:
{{passthru {{!}} foo}}                -> {{passthru | foo}} 

Template call due to bug 5678:
{{#if: 1 | {{passthru {{!}} foo}} }}  -> foo

Behaviour in new parser:
{{#if: 1 | {{passthru {{!}} foo}} }}  -> {{passthru | foo}}


We have also seen a case where a pipe was passed through to a template in the middle of an argument, and then that template used a parser function and bug 5678 to split the argument at the pipe. Then the resulting two arguments were passed through to a second template.


Such syntax will need to be migrated.
Comment 21 Tim Starling 2008-01-16 08:17:05 UTC
*** Bug 12488 has been marked as a duplicate of this bug. ***
Comment 22 Jelte (WebBoy) 2008-08-11 20:40:12 UTC
*** Bug 12828 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.