This is {{pp-meta}}, a meta-template used to create protection message boxes.

This meta-template automatically uses the right style for each namespace. It also takes care of the code for the "small" case with just a small padlock icon at the top right corner of the page.


Note that the small padlock in the top right corner of this page also is an example created with this meta-template. This template uses a position that does not collide with other top-right-hand-corner icons.

Main space


Any talk space


Other spaces



| type = <any of "full", "semi", "indef", "move", "create" or "office" depending on protection type>
| disallowlevel = <if type is not move or create and the template should only be used on one protection level, then "autoconfirmed" or "sysop">
| small = {{{small|}}} <unless template should always be small, then "yes", or if never small, "no" or omit>
| expiry = {{{expiry|}}} <omit for indef templates>
| reason = &#32;<your reason here>
| xfd = <if type is "create", then "{{{xfd|}}}", else omit>
| demospace = {{{demospace|}}} <unless template should only be used in one mainspace, when it is then
   appropriate to set this to "main", "talk", or "other" where talk includes all odd-numbered namespaces>
| demolevel = {{{demolevel|undefined}}} <unless you want the template to strictly fail on inappropriate protection levels, or want to disable the protection checks>
| image = <your image here without Image: prefix, omit unless nonstandard>
| icon-link = <your link without any [[]] but perhaps with a #section here, applies to icon version>
| icon-text = <your *complete* alternate icon text including full stop if applicable.
   Use only plaintext. Omit unless nonstandard.>
| icon-reason = <your specific reason here without full stop, use only plaintext>
| reason-text = <your complete top line without formatting but including full stop and allowing wikilinks.>
| explanation-text = <Your full explanation here>
| categories = {{{categories|<your categories here, else replace all with "no">}}}


This template is designed to be both defining of the major types of protection notice, but flexible enough to allow exceptions. All parameters have some fallback to allow for graceful failure, but some should almost always be applied.

"Usually" required parameters

The type parameter applies most default settings for the broad classes of protection templates. It can have values equal to any of the following: full, semi, indef, move, create, and office (all case-insensitive). These values apply default boilerplate text, images, and links. This parameter should almost always be used, as the default settings require little other input, making the code of templates such as {{pp-semi-protected}} very clean. Note that not supplying this parameter causes the image to default to File:Transparent.gif.
The small parameter lets the template decide whether to display a small icon version or a large boilerplate version. It can take any value, but the only one which will be acted on is "yes" (case-insensitive). As instance templates should be able to decide, using their input, whether or not to apply small, this should usually be set to {{{small|}}}, which defaults to non-small but allows small to be specified. Not supplying this parameter will cause the template to always be expanded big.
This expiry parameter allows, when type is defined normally, the expiry date to be automatically displayed properly for both the tooltip of the small version and in text for the large version. It should typically take the input {{{expiry|}}}, which allows instances using this template to be provided input specifying the expiry date. It should be left blank for templates where type is set to indef, as it has no effect because indefinite protection templates clearly do not need expiry dates to be specified.
The dispute parameter adds some boilerplate text disclaiming against endorsement of the protected version or title. It is not dependent on the type parameter, but the explanation-text parameter described below overrides it when applicable.
The reason parameter allows a particular reason to be applied to the template to explain why the page is protected. The code used in this parameter should be prefixed with &#32; so that there are proper spaces between words as {{{reason|}}} in the code is not prefixed with a space, such that the requisite full stop is not prefixed by a space when reason is null. Instances which want to pass through the reason should use code along the general lines of {{{reason|a default reason}}}.
The categories parameter is relatively strict in the input form instances of this template should use: if the template has categories that it should apply to pages upon which it is placed, they should be implemented within the container of {{{categories| and }}}, which will cause categories to be disabled in the instances if they are given |categories=no as an argument. If the template applies no categories, there is no use for this parameter.
Although the demospace parameter is primarily useful for testing purposes, its name betrays its purpose: demonstration. Instances should generally use the code demospace={{{demospace|}}} so as to allow them to be forced to display as though they were in a particular namespace. If a template is to be always used in a particular namespace and never in another, it is also possible to set demospace to any of main, talk, or other (all case-insensitive) to specify the messagebox type typical for that namespace or namespace family such that it will never change from that type.
The demolevel parameter, like the demospace parameter, is useful for demonstration and testing. Instances should generally use the code demospace={{{demolevel|undefined}}} so as to allow them to be forced to display as though they were on a page with a particular level of protection. This must have the default of "undefined" if it is used, as a null value will cause the template to fail. Failing the demolevel test causes the template to disappear and the page to be placed into Category:Pages with incorrect protection templates.

Type-dependent parameters

If the type applied is create, and explanation-text as below does not over-ride it, then the parameter xfd should be applied as equal to {{{xfd|}}} so that this input is passed through and the explanation can be more descriptive.

Optional parameters

The image parameter allows an alternate icon to be chosen if so desired. This image should typically be chosen from Padlock icons, though any image can be chosen. Only the name of the alternate image should be applied; do not supply the "Image:" or "File:" prefix.
The icon-link parameter allows one to change the page to which the small version's icon links. This probably shouldn't generally be used if type is in use as type applies proper links to Admin Tools Wiki:Protection policy, but it allows for exceptions and can define the link to sections within that page. Input given to this parameter should not be supplied within [[double brackets]].
The icon-text parameter, like the icon-link parameter, affects only the small version. This one, however, affects the text outputted as the tooltip for the protection icon. It completely replaces, when used, the default text and any specified by type, including the final full stop.
The icon-reason parameter allows text to be added to the default text of the small version's tooltip as supplied by type. It is over-written by icon-text if that parameter is used.
This parameter, reason-text, allows one to over-ride the first, bolded line of the text of the expanded version of any instance. It, when used, over-rides input as initially defined by type, expiry, and reason, including the final full stop.
This code over-rides the explanation text following the bolded reason line; it over-rides text initially provided by the template itself, type, dispute, and, if applicable, xfd.
This code disallows a particular level of protection for templates which do not have the type move or create. It can be set to either autoconfirmed or sysop to disable the template on semi-protected or full-protected pages respectively. If the page is protected at the disallowed level and demolevel is not set to the allowed level, the template will not appear and the page will be placed into Category:Pages with incorrect protection templates.

Full list of parameters in vertical form

| type =
| disallowlevel =
| small =
| expiry =
| reason =
| xfd =
| demospace =
| demolevel =
| image =
| icon-link =
| icon-text =
| icon-reason =
| reason-text =
| explanation-text =
| categories =

See also

Category:Protection templates

Template:Protection templatesTemplate:Pp-move-indefTemplate:Pp-protected Template:Filternav Template:Shortcut Template:Policy The Edit filter is a tool used to allow trusted users to set specific controls on user activity and create automated reactions for certain behaviors.

The Abuse Filter extension was developed by Werdna with support from the Wikimedia Foundation, and went live on the English Wikipedia in March 2009. As of July 2009, nearly all user-facing elements of the filter refer to it as the Edit filter as not all the edits it flags are abusive. In the software and special pages it retains its original name.

The extension allows automatic filters/heuristics to be applied to all edits. Specific rules can be developed, such as “users with fewer than 500 edits are blocked from moving pages to titles which match this regular expression: /poop/”. Of course, the rules can get quite a bit more complicated.

Log entries are viewable by all users, and while filters are by default publicly viewable, others are set to be private. For all filters, including those hidden from public view, a brief, general summary of what the rule targets will be available, and displayed in the log, the list of active filters, and in any error messages generated by the filter.

Implementation of Extension:AbuseFilter at Admin Tools Wiki is being done with due caution — most abuse filters should be tested for a few days (in “log only” mode) before being brought to full force (“warn”, “disallow”, or “throttle” modes). Only members of specific groups are allowed to modify any of the filters, and this group is assignable by the Active Bureaucrats Group.

The assignment of the Edit filter manager user right to non-Administrators is highly restricted. It should only be requested by, and given to, highly trusted users, and only when there is a clear, demonstrated need for it. Demonstrated ability that one can and will safely use it is absolutely critical. This is because widespread disruption of the entire site can easily occur — even unintentionally — with the smallest of mistakes in changing edit filters. Therefore, demonstrated knowledge of the extension’s syntax and confidence in understanding and crafting regular expressions (i.e., “regexes”) is absolutely essential. Non-Administrators should consider helping out at requested edit filters and troubleshooting at false positives in order to help demonstrate these skills.

Requests for assignment of the group to non-Administrators can be made at the discussion page, where a discussion will be held for up to a week prior to a decision being made. Discussion may extend beyond a week if appropriate consensus, or lack of it, is not clear.

Extension documentation

Filtering criteria

For all of the following, we can do extensive normalisation, regex matching, length comparison and regular comparisons (less than, greater than, equal to) matching, combining different filters with boolean logic.


  • Edit count.
  • Account age.
  • Groups.
  • Email-confirmed status.

Titles (moved-to, moved from included)

  • Namespace.
  • Title.
  • Full text.
  • Restrictions and protection status.


  • The action type (edit, move or createaccount).
  • Edit summary.
  • Contents of the edit.


  • Filters can specify whether actions done at a certain rate are by the same IP address, account, /16 range, account-creation-date, and/or to the same page, for a consequence (below) to be invoked.
  • Any of the above conditions can be combined to produce a separate rate-limiter. For instance, we can group all accounts created on the same date, from the same /16, for the purposes of rate-limiting.
  • Any actions set for that filter will occur if, and only if, the rate-limiter is tripped. This reduces false-positives by making the filter apply only if the same user is consistently tripping a particular filter, rather than a single false-positive.

Actions which can be assigned in response to filtered edits

If a user triggers a filter, AbuseFilter can apply any of the following sanctions based on the severity of the offense:

  • All actions triggering a filter are logged at a special page.
  • The user’s action can be tagged for further review.
  • The user can be warned that their actions may be unconstructive.
  • The user’s action may be disallowed.
  • The user’s account may have its autoconfirmed status removed.
  • The user’s account may be blocked from editing, along with all IP addresses used in the last 7 days.
  • The /16 range from which the user originates, can be blocked.

The following actions are currently not available on this wiki:

  • The user’s account may be removed from all privileged groups (such as sysop, bot, rollbacker).

Template:UpdateTemplate:SpacesIndividual sanctions can be disabled selectively. Any edit filter manager can restore autoconfirmed status in case of an error.


All edits triggering an action will produce a report at Special:AbuseLog. On this page, a brief log entry is entered. Users with the appropriate permissions may view the log summary. Users with certain higher permissions may view details on the log entry. This includes all information available to the filter when it ran, and may be useful for debugging purposes. Users with the highest level of log-viewing permissions may view private data about the action which caused the log event, such as the user’s IP address. See the AbuseFilter documentation for more details on the permissions structure.

Sample abuse log entries

  • 06:43, 23 June 2008: Andrew (Talk | contribs | block) triggered an abuse filter, making an edit on Main Page. Actions taken: warn,disallow; Filter description: Test Filter
  • 06:43, 23 June 2008: Andrew (Talk | contribs | block) triggered an abuse filter, making an edit on Main Page. Actions taken: none; Filter description: Test Filter

Sample detailed abuse log entries

  • 06:43, 23 June 2008: Andrew (Talk | contribs | block) triggered filter 1, making an edit on Main Page. Actions taken: warn,disallow; Filter description: Test Filter (details)
  • 06:43, 23 June 2008: Andrew (Talk | contribs | block) triggered filter 2, making an edit on Main Page. Actions taken: none; Filter description: Test Filter (details)
  • 06:42, 23 June 2008: Andrew (Talk | contribs | block) triggered filter 1, making an edit on Main Page. Actions taken: warn; Filter description: Test Filter (details)
  • 06:42, 23 June 2008: Andrew (Talk | contribs | block) triggered filter 2, making an edit on Main Page. Actions taken: none; Filter description: Test Filter (details)
  • 06:22, 23 June 2008: Andrew (Talk | contribs | block) triggered filter 1, making an edit on Main Page. Actions taken: warn,disallow; Filter description: Test Filter (details)
  • 06:22, 23 June 2008: Andrew (Talk | contribs | block) triggered filter 2, making an edit on Main Page. Actions taken: none; Filter description: Test Filter (details)

The details link brings up a screen like that on the right.


To protect the wiki against poorly configured filters, a technical limit is imposed on the maximum percentage of actions that will trigger a given filter. Other technical limits are in the process of being written.


All notifications are based on the template {{edit filter warning}}.

Standard notifications shown to a user triggering a filter action:

Message name Message text
abusefilter-disallowed This action has been automatically identified as harmful, and therefore disallowed.

If you believe your edit was constructive, please inform an administrator of what you were trying to do. A brief description of the abuse rule which your action matched is: $1

abusefilter-degrouped This action has been automatically identified as harmful.

Consequently, it has been disallowed, and, since your account is suspected of being compromised, all rights have been revoked. If you believe this to have been in error, please contact a bureaucrat with an explanation of this action, and your rights may be restored. A brief description of the abuse rule which your action matched is: $1

abusefilter-autopromote-blocked This action has been automatically identified as harmful, and it has been disallowed.

In addition, as a security measure, some privileges routinely granted to established accounts have been temporarily revoked from your account. A brief description of the abuse rule which your action matched is: $1

Generic warning message is below. Admins are advised to use custom warnings.

Message name Message text
abusefilter-warning Thanks for your edit. Please check this is what you meant to do before pressing Publish.

Your edit will be flagged as $1

Some existing filters and their warnings:

Filter and message Message text
3: blanking articles


30: large deletions


If a filter is set to warn and disallow, then a user clicking “Save” will alternatively see that warning and standard disallowed message.

Known issues

When the extension is initially installed, the available actions will not include blocking or removing from privileged groups. This restricted usage has been determined by community consensus, and if the extension is successful, the community may decide to enable the block, rangeblock or degroup actions for use on this wiki. Administrators wishing to block users for triggering the abuse filter can use the [[wikipedia:Template:uw-afblock|Template:Tlc]] template.

The full technical details of implementation are available on the MediaWiki bug tracker as Template:Bugzilla.

Ad blocker interference detected!

Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.