Hidden power of MediaWiki AbuseFilter extension

MediaWiki ships with a surprisingly flexible anti‑vandalism engine: AbuseFilter. While most administrators use it for the obvious tasks—blocking spam links or preventing mass edits—there are a handful of lesser‑known features that can turn a modest filter set into a proactive guard against sophisticated abuse.

1. Dynamic variables & conditionals

Filters can reference a wealth of runtime information via variables. Beyond the common user_name or page_title, you have access to:

• user_editcount – total edits of the actor.
• user_groups – group membership (useful for whitelisting).
• page_namespace and page_is_redirect.
• revision_text – the raw wikitext of the edit.
• metadata – any custom key/value stored via setmetadata.

Combine them with if expressions to target only the most suspicious edits:

if( user_editcount < 10 && revision_text contains "http://" ) {

2. Regular‑expression power

AbuseFilter supports PCRE, allowing you to match complex patterns without resorting to multiple filters. Example: block URLs that use a known URL‑shortening service but hide the real target.

if( revision_text matches "(?i)\bhttps?://(bit\.ly|t\.co|goo\.gl)/[\w-]+" ) {

3. Rate‑limiting & burst detection

The user_recent_actions variable returns a pipe‑separated list of the user’s latest actions. By counting occurrences you can detect edit bursts that are typical of bots.

$actions = split( "|", user_recent_actions );
if( array_length( $actions ) >= 5 && $actions[0] == "edit" && $actions[1] == "edit" ) {

4. Global filters & filter groups

In a multi‑wiki federation (e.g., Wikimedia Commons & Wikipedia) you can share a single filter definition across all wikis using the global flag. Group filters by purpose (spam, vandalism, login abuse) and enable/disable a whole category with a single toggle.

5. Auto‑blocking & tag‑based actions

When a filter matches, you can automatically add a block, add a tag, or trigger a custom log entry. The block action can be fine‑tuned with parameters:

block( user_name, "AbuseFilter: spam link", 7d, "auto" )

Tagging the edit (addtag) lets you later run reports or feed the data into CheckUser queries.

6. Test mode & debugging

Before pushing a filter live, use the testfilter API or the built‑in test interface. It shows you which variables were evaluated and why a rule did or didn’t fire—essential for crafting precise regular expressions.

7. Real‑world example: hidden‑trackers

Many spam campaigns embed tracking pixels in user‑generated content. The following filter catches img tags that load from a list of known tracker domains, even when the URL is URL‑encoded.

if( revision_text matches "(?i)<img[^>]*src=\s*['\"]?(?:https?://)?(?:track|pixel)\.example\.com/" ) {
    addTag( "abusefilter-tracker" );
    block( user_name, "AbuseFilter: hidden tracker", 30d, "auto" );
}

Deploying these hidden capabilities turns AbuseFilter from a simple spam filter into a proactive, context‑aware defense layer.

Explore the official manual for the exhaustive list of variables and actions. The real power lies in combining them creatively—experiment, test, and iterate.