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. |
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.
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.
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.
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.
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.
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:
If you are considering using a meta-template, ask these questions:
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.
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. |
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.
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.
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.
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.
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.
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:
If you are considering using a meta-template, ask these questions:
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.