Last modified: 2009-07-29 02:00:11 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T3689, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 1689 - Handling of variable number of parameters, if- and loop-statements in templates
Handling of variable number of parameters, if- and loop-statements in templates
Product: MediaWiki
Classification: Unclassified
Templates (Other open bugs)
All All
: Normal enhancement with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: parser
: 9653 10053 (view as bug list)
Depends on:
Blocks: 2376
  Show dependency treegraph
Reported: 2005-03-12 12:12 UTC by Brian McKellar
Modified: 2009-07-29 02:00 UTC (History)
3 users (show)

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

Prototype code with example pages (65.96 KB, application/octet-stream)
2005-03-12 12:18 UTC, Brian McKellar

Description Brian McKellar 2005-03-12 12:12:06 UTC

I have only used the MediaWiki software for two weeks, and found the need to have variable number of 
parameters, if-statements to check on them and loop-statements to process them. I did find one page 
discussing this topic:

After I have played around a little, I decided to make a complete proposal, and to build a prototype. I 
will attach all my relevant files.

However, please keep in mind that my MediaWiki and Wikipedia experience is limited until now. Also, 
this is my very first PHP programming! As such, I apologize if nettique are not perfectly correct in 
all handling. I have softly asked around, and it was recommended to open this "bug" for easier tracking.

What really would be needed is someone with extensive experience to review the suggested syntax, plus 
the prototype code (especially aspect performance), to ensure that it is acceptable as proposal. Once 
this is accepted, I can also write some maintenance/parserTest examples. I will attach my work.

regards, brian
Comment 1 Brian McKellar 2005-03-12 12:18:02 UTC
Created attachment 367 [details]
Prototype code with example pages

I could not find a reference to the diff tool used by other people, and have
just added both the original and new Parser.PHP files. A diff between the two
files can then easily be made. The other files are example pages from the
MediaWiki on which the prototype was build.
Comment 3 Brion Vibber 2005-03-12 12:57:13 UTC
I think this is a very wrong direction to go in; wiki is meant to be *simple* 
freeform text and not a fancy macro language with looping constructs.

Leaning towards marking this WONTFIX.
Comment 4 Erik Moeller 2005-03-12 16:01:22 UTC
Would it be acceptable if it was optional, Brion?
Comment 5 Brion Vibber 2005-03-12 21:27:39 UTC
There's no such thing as optional; either it's there or it isn't. There but 
turned off is still churning up the code base with the extra stuff.

Either we need to kill it, or somebody needs to defend it, and the 
implementation needs to be as clean (and safe!) as possible.
Comment 6 Brian McKellar 2005-03-12 22:42:03 UTC
Hallo Brion,

You are right that this is not unfortunately not perfectly simple. Let me give you an example of what I wanted to do.

Assume we have different software releases, and we discover a bug. We would like to write a small page about the problem 
(testing MediaWiki for this), and show the releases that contains the problem. Also we have a category per release for 
bugs. So someone can just look at the relevant category to see all bugs for their release.

For all the people in the group, this must be a simple process. They write a new page to describe a bug, and add the 

  {{Bug|title=Brian made stupid mistake|rel=1.3|rel=1.4a|rel=1.4b|critical=true}}

The above template usuage takes any number of releases, and also an optional flag critical. The template itself could be:

  '''Title:''' {{{title}}}
  '''Releases:''' {{rel#1}} up to {{rel#N}}}
  '''Critical:''' Must Install!
  {{{loop|rel}}} [[Category:OurSoftware{{{rel#}}}|{{PAGENAME}}]] {{{endloop}}}

At the template usage level, it still feels very much the same as before. The additional features are only interested to 
those that write the templates on which the rest builds the information.

For the coding I have to make all apologies. It is my first attempt at PHP. I took your advice to "Hack up the parser" to 
make a small contribution. If there should be an interest to use this code, then of course, a thorough review by someone 
experienced with both PHP and MediaWiki should be done. I have tried to writeup as much as possible, and build a number 
of examples (in the attached files). If there is anymore help that I can provide with this, just email me.

regards, brian

Comment 7 Brion Vibber 2005-03-12 22:58:49 UTC
That sounds like structured data, for which a wiki isn't an appropriate tool. For instance, we use a 
special-purpose bug tracker (bugzilla) for bug tracking.
Comment 8 Garth Wallace 2005-03-14 03:53:36 UTC
The thing is, this would complicate some templates, but in doing so would make
the code for articles using those templates potentially simpler and cleaner. I
think the priority should me towards making article code simpler. Templates are
already a kind of back-end thing.
Comment 9 Daniel Kinzler 2005-03-19 17:13:53 UTC
please also have a look at Bug 364
(, it's basically the same
thing. I personally think that default values for parameters would be a good
idea (the template-as-default-value thing does *not* really work). An if-syntax
would indeed be helpfunl and  reduce the number of templates / would help to
clean up some crufty workarounds (like template1, template2, template3...), but
we would need a "nice" way to write that. More advanced things like for-each are
probably over-the-top. The template-system does not need to have turing-power.
Comment 10 Rob Church 2006-06-01 01:43:13 UTC
We have the ParserFunctions extension now.
Comment 11 Brion Vibber 2007-04-25 21:08:32 UTC
*** Bug 9653 has been marked as a duplicate of this bug. ***
Comment 12 Brion Vibber 2007-06-04 18:37:43 UTC
*** Bug 10053 has been marked as a duplicate of this bug. ***
Comment 13 Chad H. 2009-07-29 02:00:11 UTC
Marking FIXED per comment #10. The basic premise of this is long-since finished.

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