KidzSearch Encyclopedia:Advanced template coding

This essay, Wikipedia:Advanced template coding, describes some techniques to improve the display or editing of templates in Wikipedia. Some ways are explained for debugging template parameters in the MediaWiki markup language. Most of the tips involve use of common text-editors. While some special software packages exist, to allow customized editing, they are often not available when travelling to other computers for wiki-editing.

Perhaps the most important issue to note, about complex templates, is the fact that the markup language is very reliable for complex template coding, even with complex calculations, so most template problems are often caused by obscure coding errors, rather than by bugs inside the MediaWiki software. The bugs inside the parser are so rare that most people will never experience one. Most problems are due to awkward features in the markup language, which lead to coding errors. For example, omitting a leading brace "{" at parameter {{1}}} causes it to be read as "{{1}} }", as meaning to invoke Template:1 + "}".

Some techniques here are beyond the basics written about in the Wikipedia help-page "Help:Template" which lists almost all basic options of template coding, also showing examples of each.

Nesting levels limited to 40

Inside a single template, the nesting limit is 40 nested expressions, such as 40 multiple "if-then-else-if...". At the 41st nested "if" keyword, then an error message might appear as: "Exceeded nesting limit". However, when not nested beyond 40 levels, then a template can contain hundreds of if-expressions and switch-branches (but not all nested inside the others).

Some templates have contained complex conditional calculations nested over 19 levels deep, for years. Also, some templates have contained hundreds of if-expressions, for years, just NOT all nested as one, giant: if-then-else-else-else-else-else....

MediaWiki wiki-formats the clauses inside #if

An issue which complicates template processing, for parameters, is the wiki-formatting of parameter contents when inside of if-logic (such as #if or #ifeq). As of August 2010, the MediaWiki markup parser is wiki-formatting the contents of parameters when inside #if-expressions (but not outside). This means that parameters containing spaces/semicolon can change their values while inside the if-clauses (surprise!). So, for example, a parameter {{{4}}} when outside an #if can display differently than inside {{#if: {{{4}}} ...}}. The worst shock is when parameter 4 contains a leading semicolon, which triggers formatting to become ye-olde bolded semicolon-header-line:

TEST99:

<== yes, semicolon

TEST1: {{#if:{{{4|}}}|{{{4|;}}} <== yes, semicolon|no, 4=empty}}

TEST2: {{#if:{{{4|;}}}|{{{4|;}}} <== yes, semicolon|no, 4=empty}}

TEST1: no, 4=empty TEST2: <== yes, semicolon <== Separate example of semicolon-header

The problem occurs whether inside of #if, #ifexpr or #ifeq markup expressions. If the parameter is preceded by text, in either of the then/else clauses, then the wiki-formatting inside the parameter does not occur. This situation might be relatively rare, but this is just a reminder: for showing the true contents of a template parameter, try to display a parameter outside the start of any if-statement clauses, or else prepare for some shocking results when a parameter is wiki-formatted for display inside the if-logic.

Debugging

Many coding errors can be debugged, more easily, by attempting to isolate the code section where coding errors most likely occurred. Intense proofreading, of the logic flow, is most often the quickest fix, such as checking for typical syntax errors (see below: Common coding errors). Sometimes, a section of troublesome code could be copied into a short test page, then edit-preview tested there, separately. However, if editing that extra-page window seems like too much effort, then consider merely copying the code to the top of the current template. Similarly, a template could be developed, in the early stages, as multiple sections of code, each to be debugged separately, then eventually joined together, such as nested sections with if-then-else-if.

As a review of those options, consider:

• Try carefully proofreading troublesome code, matching "{{" with "}}".
• Copy a template section into a test-page edit-window, for debug.
• Copy a template section to the top of the template, for debug.
• Restructure a template so that each section is more separated.

The basic strategy: isolate the code section to be debugged.

Next, the testing, of each section of code, is crucial. There are some age-old adages to heed:

• If it hasn't been tested, then it doesn't work.
• You can expect what you inspect. (W. Edwards Deming)

Perhaps put a variety of examples on each template's doc subpage, to help detect problems early in development. However, for complex templates, then the talk-page, or a special subpage "/testcases", should contain a section of numerous examples (a whole lot of them) to demonstrate the full scope of template features.

Defaulting parameters in expressions and if-logic

When developing sections of markup that use template parameters, try to always set each parameter with a default value, especially inside expressions or if-logic coding:

• {{#expr: 109.75 / {{{1|1}}} }} → default {1} as 1 not zero.
• {{#ifeq: {{{anwser|y}}}|y|show yes}}

If a particular parameter is given the same default value across the whole page, then that value could be easily changed, in a text editor, by a global search-and-replace string substitution, to change the default value to some other value, for testing each case.

If those parameters are not given default values, then those sections of code cannot be tested, during edit-preview, while editing the template. Any parameter without a default value will become the literal triple-brace text (such as the literal 7 characters: {{{x}}}), and non-defaulted parameters cannot be evaluated, in expressions or if-logic, during an edit-preview of the template page.

Common coding errors

There are several common coding errors which will cause problems when processing templates. The following can be used as a checklist, to help debug problems, when a template seems to be acting bizarre:

• Too few closing braces: A common problem is to put only 2 closing-braces around a parameter number or name, such as "{{{1}}". Having only 2 closing-braces "}}" might treat the parameter as a template named "Template:1" (preceded by a lone "{" brace). Many people with dyslexia cannot easily count the open/close braces.

• Unopened comments: Forgetting to insert "<!--" at the start of an HTML comment can cause bizarre results, with no error message. Forgetting the exclamation point is very common: "<--" should be "<!--".
• Unclosed comments: Forgetting to insert "-->" at the end of an HTML comment can cause bizarre results, with no error message.

• Omitting colon or "#" on "#ifexpr": Forgetting to insert "#" or colon for "#ifexpr:" or "#expr:" can produce bizarre results, when passed into other subtemplates.

Omitting colon becomes literal text: {{#ifexpr y=0|then zero|else not}}

Note that those common coding errors could have been easily spotted by a simple syntax checker, such as warning that 3&2 braces could be trouble: "{{{size|180px}}" is treated as "{Template:Size" trying to pass 180px as the parameter because of only 2 end-braces.

Again, always checking first for common errors, as the first step, can avoid time hunting for "complex errors" which never really existed. Remember: the MediaWiki markup language is extremely error-prone, so that's why so many coding errors occur, and that's why:

Consider the above as a checklist to try first, as a type of sanity-check for the template.

Many hideous problems truly are merely 1-minute syntax fixes.

Related pages

WP:Wikimedia Foundation error WP:Advanced Convert coding WP:Advanced article editing WP:Advanced footnote formatting WP:Advanced table formatting WP:Advanced text formatting WP:Alert

WP:Thinking outside the infobox WP:Pruning article revisions WP:Overlink crisis WP:Authors of Wikipedia WP:Avoiding difficult users

Notes

[ This essay is a draft to be expanded later. ]