| Revision as of 07:06, 31 January 2006 editNetoholic (talk | contribs)Autopatrolled, Extended confirmed users39,916 editsm →Template links← Previous edit | Latest revision as of 19:16, 14 May 2020 edit undoBoldLuis (talk | contribs)Extended confirmed users6,187 edits →See also | ||
| (161 intermediate revisions by 44 users not shown) | |||
| Line 1: | Line 1: | ||
| {{ |
{{rejected|WP:AUM}} | ||
| ] | |||
| {{proposed}} | |||
| ⚫ | ] allow certain standard text to be included on many pages, usually with the idea that in the future, any changes to that text block can be changed in one place. The term "'''meta-templates'''", as used in this article, refers to nested templates which are created and used to add functions or formatting to other ''templates''. | ||
| {{Guideline in a nutshell|Avoid using templates within other templates as the result can be complex, fragile, and increases the server-side processing requirements.}} | |||
| While they can be extremely useful and convenient, it is proposed that they be avoided due to concerns that may not be immediately obvious: Meta-template schemes can be fragile and hard for new editors to understand. They may also provide an avenue for mass-vandalism and impact maintenance efforts. The reasons listed on this page argue against using meta-templates. | |||
| ⚫ | ] allow certain standard text to be included on many pages, usually with the idea that in the future, any changes to that text block can be changed in one place. The term "'''meta-templates'''", as used in this article, refers to nested templates which are created and used to add functions or formatting to other ''templates'' |
||
| Meta-template schemes can be fragile and hard for new editors to understand. They increase the number of database reads per page view and therefore impact back-end server performance; though the developers are not in agreement over whether such server impacts are significant and there is no developer mandate to that effect. | |||
| For these reasons, it is better to avoid meta-templates when clearer and more robust alternatives are available. In short, messy unintuitive structures in articles ''and'' in templates are undesireable. | |||
| == Harmful effects == | == Harmful effects == | ||
| The impacts of meta-templates include not only direct ] effects but also indirect effects, such as creating ] vulnerabilities. | |||
| === Complexity === | === Complexity === | ||
| Nested template schemes are complex and prohibitively difficult for the average editor to grasp. This is particularly true in non-technical areas where the subject expert, who knows best what information should be presented in a template, is not able to edit the template due to the use of esoteric coding. As a result, routine maintenance and changes are neglected, improper usage can proliferate, and innovation suffers. The solution, meant to become an easy replacement, becomes more difficult than the function it was meant to improve. Clear article source ''and'' clear template source are most preferred, though it is understandable if complex code is moved to the template. If this is the case, steps should be taken to reduce complexity to a minimum. | |||
| === |
=== Template links === | ||
| ⚫ | When a page is edited, a list of all templates in use on that page is stored in the database. This list can be seen when in edit mode as a list of links at the bottom. Not only are the templates that are directly called listed there, but any higher-level meta-templates as well. This feature was created as a helpful aid for editors, in order that they can easily tell what templates are being used on a page in case they want to edit one of them. Meta-templates clutter this list, making it unclear to editors exactly which link is correct. | ||
| The developers have noted that nested templates increase the number of back-end database calls, as each nested template is fetched and evaluated internally. As is typical of websites that use a database and cache scheme, extra database processing is more "costly" in terms of resource availability than the page caching mechanism. How much more costly meta-templates are than templates, and whether this has a noticable impact on server load, is (as of early 2006) a matter of debate. Also, when a nested template is edited, that change results in the cached version of every page using that template, whether directly or indirectly, to be marked invalidated. Pages using nested templates must be rebuilt, bringing a lot of activity onto the database servers. In some cases, editing meta-templates has caused enough server stress to temporarily lock the database. | |||
| ⚫ | Template links created by meta-templates also frequently cause problems for template namespace maintenance. If a Template:A is in use on several pages, but then is changed to either add or remove Template:B, any article-level template links to "B" are not updated until each article is edited or "touched". Since the links can't be fully trusted, template maintenance work which relies on that information is made difficult or impossible. ] rely on those links as well, such as when performing ] or migrating from one template to another. | ||
| === Vandalism === | === Vandalism === | ||
| Any template which is used on a very high percentage of pages is an excellent ] vector, since changing it or any component used in it would flush a substantial percentage of the site caches, which are critical to site performance and normally serve some 75–80% of all hits. Making even one subtle change, like the addition of a space, causes the effect. | |||
| Thus, caution is warranted for those nested templates which are widely used indirectly. A sub-sub-sub-template could be vandalised with offensive content. These could be difficult to notice immediately, because the sub-template is not edited often and appears on only one or a few Watchlists, and difficult to track down in a timely manner. | |||
| ⚫ | |||
| ⚫ | Because of the problems above, several ] have had to be ], so that they can only be edited by administrators. If the meta-template is rarely changed, then any daughter templates probably don't change either, so it may make sense to move the formatting into the daughter templates. This was done with ], which now no longer use a meta-template scheme. Remember also: ]. | ||
| It should remembered, however, that it is possible and useful to write a meta-template which will only be used on a few or even a few hundred pages. Conversely, there are templates, such as cross-reference templates, which are very widely used without being meta-templates. | |||
| === Template links === | |||
| ⚫ | When a page is edited, a list of all templates in use on that page is stored in the database. This list can be seen when in edit mode as a list of links at the bottom. |
||
| ⚫ | == Protection == | ||
| ⚫ | Template links created by meta-templates also frequently cause problems for template namespace maintenance. If a Template:A |
||
| ⚫ | Because of vandalism and the potential server load problems described above, several ] have had to be ], so that they can only be edited by administrators. If the meta-template is rarely changed, then any daughter templates probably don't change either, so it may make sense to move the formatting into the daughter templates. This was done with ], which now no longer use a meta-template scheme. Remember also: ]. | ||
| == Conditionals == | == Conditionals == | ||
| Schemes using layers of nested templates to mimic conditional expressions — to selectively hide or show text or images based on the ] which have been set - are sometimes created by users who are unfamiliar with the better alternatives. Conditionals should generally be avoided, unless there is a significant advantage in their use. If they must be used, then the following methods for conditional logic are available and highly preferred over using nested templates: | |||
| * ], and related templates -- these perform a wide range of functions, but the mechanism can only be used by resorting to nested templates. The template source code is often difficult to understand. Cannot be used with "]". | |||
| * ] -- This method is very common and designed to display default alternative text only if a particular parameter is -not- set. Very simple, but not very powerful for complex needs. | |||
| * ] -- this makes use of CSS to hide text from view. Because this is handled by the browser, the hidden text is still sent to the client. It fails if CSS is disabled or not supported; such as on older versions of text browsers and ]s. | |||
| * ] -- Provides a framework for conditional statements within templates. Since it is built into the MediaWiki code, it is relatively efficient on the back-end, but can be very complex for non-technical editors. | |||
| * Blank parameter (aka "Weeble") -- this method requires that each template call includes a blank parameter (<nowiki> {{</nowiki>template|'''if=|'''param=data}} ). Requiring this on every page using a template is difficlut, and the template source code is often ''very'' hard to understand. Cannot be used with "]". | |||
| == Alternatives == | == Alternatives == | ||
| # '''Design, document, and then implement''' — To give an example in the case of ], a proposal was made to use a meta-template. In this area, it is much better to decide on a common look and format, document that standard for easy reference in case new related templates are needed, and then implement it across the few templates being used. When changes are needed, this gives one central place for discussion and revision. After there is consensus for the change, interested editors can quickly apply them. Creating a page which displays each template also helps to locate templates which don't follow the agreed upon format. | # '''Design, document, and then implement''' — To give an example in the case of ], a proposal was made to use a meta-template. In this area, it is much better to decide on a common look and format, document that standard for easy reference in case new related templates are needed, and then implement it across the few templates being used. When changes are needed, this gives one central place for discussion and revision. After there is consensus for the change, interested editors can quickly apply them. Creating a page which displays each template also helps to locate templates which don't follow the agreed upon format. | ||
| # '''Make use of CSS''' — Some meta-templates serve only to produce a specific visual format — such as size, position, color. If these were identified, ] classes could be added to the site's global stylesheets. The meta-templates could then be replaced with the CSS classes in relevant pages. |
# '''Make use of CSS''' — Some meta-templates serve only to produce a specific visual format — such as size, position, color. If these were identified, ] classes could be added to the site's global stylesheets. The meta-templates could then be replaced with the CSS classes in relevant pages. This would accomplish the same purpose — maintaining uniform style across the site — without placing a burden on the server. This also allows the visual style to be personally customized. | ||
| # '''Use lists, not templates or ]''' — Some templates and categories are used with the goal of helping editors find articles under a specific topic area of interest. For this use, it is often more valuable to create a ], which can be annotated and prioritized. Many ] already maintain an area for reporting articles that need work. (Note that categories also heavily load the servers, for similar reasons.) See ] | # '''Use lists, not templates or ]''' — Some templates and categories are used with the goal of helping editors find articles under a specific topic area of interest. For this use, it is often more valuable to create a ], which can be annotated and prioritized. Many ] already maintain an area for reporting articles that need work. (Note that categories also heavily load the servers, for similar reasons.) See ] | ||
| # '''Use <nowiki>{{subst: }}</nowiki>''' — ] copies the template's text to any daughter templates(<em>subst</em>itution) rather than causing a ], thus eliminating the second template call. Of course, this means that when the meta-template is changed, the daughter templates won't update, and won't be tracked by the ] feature. This is a good solution for any template that doesn't change often or where the exact text need not be kept up-to-date on ''every'' page. | # '''Use <nowiki>{{subst: }}</nowiki>''' — ] copies the template's text to any daughter templates(<em>subst</em>itution) rather than causing a ], thus eliminating the second template call. Of course, this means that when the meta-template is changed, the daughter templates won't update, and won't be tracked by the ] feature. This is a good solution for any template that doesn't change often or where the exact text need not be kept up-to-date on ''every'' page. | ||
| # '''MediaWiki needs developers.''' Mechanisms that provide desired template functions, yet avoid meta-templates, could be of great benefit to the project. See ]. | |||
| == Still want to use them? == | == Still want to use them? == | ||
| If you are considering using a meta-template, ask these questions: | |||
| # Is the end product '' |
# Is the end product ''useful'' to Misplaced Pages, or is it a primarily decorative feature? Even useful templates should be weighed against the problems above. | ||
| # Is the template likely to be high-profile? High-profile templates cause more server load, and so are less appropriate for meta-templates. | # Is the template likely to be high-profile? High-profile templates cause more server load, and so are less appropriate for meta-templates. | ||
| # Is the desired effect only achievable through a meta-template, or can a template of basically the same appearance be made without them? If the same effect can be achieved differently, |
# Is the desired effect only achievable through a meta-template, or can a template of basically the same appearance be made without them? If the same effect can be achieved differently, without significantly more trouble, a meta-template should be avoided. | ||
| # Will later editors understand how this works? | # Will later editors understand how this works? On the other hand, will later editors understand the alternative method? | ||
| You should not use meta-templates |
You should not use meta-templates without good reason. If you do create one, be open to other methods which achieve the same end, and be prepared to trade functionality in favor of avoiding the problems with meta-templates. | ||
| == See also == | == See also == | ||
| * ] | |||
| * ] | * ] | ||
| * ] | * ] | ||
| * ] | |||
| * ] | * ] | ||
| * ] (see page history) | |||
| ] | ] | ||
Latest revision as of 19:16, 14 May 2020
 | This is a failed proposal. Consensus for its implementation was not established within a reasonable period of time. If you want to revive discussion, please use the talk page or initiate a thread at the village pump. | Shortcut |
Template messages allow certain standard text to be included on many pages, usually with the idea that in the future, any changes to that text block can be changed in one place. The term "meta-templates", as used in this article, refers to nested templates which are created and used to add functions or formatting to other templates.
While they can be extremely useful and convenient, it is proposed that they be avoided due to concerns that may not be immediately obvious: Meta-template schemes can be fragile and hard for new editors to understand. They may also provide an avenue for mass-vandalism and impact maintenance efforts. The reasons listed on this page argue against using meta-templates.
Harmful effects
Complexity
Nested template schemes are complex and prohibitively difficult for the average editor to grasp. This is particularly true in non-technical areas where the subject expert, who knows best what information should be presented in a template, is not able to edit the template due to the use of esoteric coding. As a result, routine maintenance and changes are neglected, improper usage can proliferate, and innovation suffers. The solution, meant to become an easy replacement, becomes more difficult than the function it was meant to improve. Clear article source and clear template source are most preferred, though it is understandable if complex code is moved to the template. If this is the case, steps should be taken to reduce complexity to a minimum.
Template links
When a page is edited, a list of all templates in use on that page is stored in the database. This list can be seen when in edit mode as a list of links at the bottom. Not only are the templates that are directly called listed there, but any higher-level meta-templates as well. This feature was created as a helpful aid for editors, in order that they can easily tell what templates are being used on a page in case they want to edit one of them. Meta-templates clutter this list, making it unclear to editors exactly which link is correct.
Template links created by meta-templates also frequently cause problems for template namespace maintenance. If a Template:A is in use on several pages, but then is changed to either add or remove Template:B, any article-level template links to "B" are not updated until each article is edited or "touched". Since the links can't be fully trusted, template maintenance work which relies on that information is made difficult or impossible. Automated bots rely on those links as well, such as when performing Template substitution or migrating from one template to another.
Vandalism
Any template which is used on a very high percentage of pages is an excellent denial-of-service attack vector, since changing it or any component used in it would flush a substantial percentage of the site caches, which are critical to site performance and normally serve some 75–80% of all hits. Making even one subtle change, like the addition of a space, causes the effect.
Thus, caution is warranted for those nested templates which are widely used indirectly. A sub-sub-sub-template could be vandalised with offensive content. These could be difficult to notice immediately, because the sub-template is not edited often and appears on only one or a few Watchlists, and difficult to track down in a timely manner.
It should remembered, however, that it is possible and useful to write a meta-template which will only be used on a few or even a few hundred pages. Conversely, there are templates, such as cross-reference templates, which are very widely used without being meta-templates.
Protection
Because of vandalism and the potential server load problems described above, several high-use meta-templates have had to be protected, so that they can only be edited by administrators. If the meta-template is rarely changed, then any daughter templates probably don't change either, so it may make sense to move the formatting into the daughter templates. This was done with stub templates, which now no longer use a meta-template scheme. Remember also: meta:Protected pages considered harmful.
Conditionals
Schemes using layers of nested templates to mimic conditional expressions — to selectively hide or show text or images based on the parameters which have been set - are sometimes created by users who are unfamiliar with the better alternatives. Conditionals should generally be avoided, unless there is a significant advantage in their use. If they must be used, then the following methods for conditional logic are available and highly preferred over using nested templates:
- Parameter default -- This method is very common and designed to display default alternative text only if a particular parameter is -not- set. Very simple, but not very powerful for complex needs.
- m:ParserFunctions -- Provides a framework for conditional statements within templates. Since it is built into the MediaWiki code, it is relatively efficient on the back-end, but can be very complex for non-technical editors.
Alternatives
- Design, document, and then implement — To give an example in the case of Misplaced Pages:Sister projects, a proposal was made to use a meta-template. In this area, it is much better to decide on a common look and format, document that standard for easy reference in case new related templates are needed, and then implement it across the few templates being used. When changes are needed, this gives one central place for discussion and revision. After there is consensus for the change, interested editors can quickly apply them. Creating a page which displays each template also helps to locate templates which don't follow the agreed upon format.
- Make use of CSS — Some meta-templates serve only to produce a specific visual format — such as size, position, color. If these were identified, CSS classes could be added to the site's global stylesheets. The meta-templates could then be replaced with the CSS classes in relevant pages. This would accomplish the same purpose — maintaining uniform style across the site — without placing a burden on the server. This also allows the visual style to be personally customized.
- Use lists, not templates or categories — Some templates and categories are used with the goal of helping editors find articles under a specific topic area of interest. For this use, it is often more valuable to create a list, which can be annotated and prioritized. Many WikiProjects already maintain an area for reporting articles that need work. (Note that categories also heavily load the servers, for similar reasons.) See Misplaced Pages:Categories, lists, and series boxes
- Use {{subst: }} — Template substitution copies the template's text to any daughter templates(substitution) rather than causing a transclusion, thus eliminating the second template call. Of course, this means that when the meta-template is changed, the daughter templates won't update, and won't be tracked by the What links here feature. This is a good solution for any template that doesn't change often or where the exact text need not be kept up-to-date on every page.
Still want to use them?
If you are considering using a meta-template, ask these questions:
- Is the end product useful to Misplaced Pages, or is it a primarily decorative feature? Even useful templates should be weighed against the problems above.
- Is the template likely to be high-profile? High-profile templates cause more server load, and so are less appropriate for meta-templates.
- Is the desired effect only achievable through a meta-template, or can a template of basically the same appearance be made without them? If the same effect can be achieved differently, without significantly more trouble, a meta-template should be avoided.
- Will later editors understand how this works? On the other hand, will later editors understand the alternative method?
You should not use meta-templates without good reason. If you do create one, be open to other methods which achieve the same end, and be prepared to trade functionality in favor of avoiding the problems with meta-templates.
See also
- Category:Misplaced Pages metatemplates
- Misplaced Pages:Transclusion costs and benefits
- Misplaced Pages:High-risk templates
- m:ParserFunctions
- Misplaced Pages:HiddenStructure
- Misplaced Pages:Qif conditionals (see page history)