Hidden power of MediaWiki AbuseFilter extension
The less obvious AbuseFilter capabilities: dynamic condition variables, regex matching with rlike, throttle actions, global filters and the test interface.
AbuseFilter is MediaWiki's filter engine for anti-abuse automation: conditions on edits, configurable actions (tag, warn, disallow, block, throttle) and statistics. Most admins use a handful of filters; the features below are the ones that make the extension genuinely powerful. The syntax examples are real AbuseFilter syntax — condition language expressions, not PHP.
1. The condition language
Filters are boolean expressions over condition variables — built-in values like:
user_name,user_editcount,user_groupspage_namespace,page_title,page_is_redirectnew_wikitext,old_wikitext,added_lines,removed_linesaction,timestamp,user_recent_actions(number of actions in a time window)
Example — suspicious first-edit spam pattern:
user_editcount < 10
& new_wikitext contains 'http://'
& new_wikitext irlike 'https?://(bit\.ly|t\.co|goo\.gl)/'
contains, matches, rlike (regular expressions), in and ===/</> comparisons, plus string functions like str_replace, split and length cover nearly every pattern. If you reach a complex construction, a simpler split into two filters usually behaves better.
2. Throttling instead of blocking
Blunt blocks frustrate legitimate users; throttle limits how often an action is allowed and only triggers the follow-up action when the limit is exceeded:
user_editcount < 50
& editcount( user_name ) > 20 # placeholder — see note
Real throttling example — max 10 edits per hour for new users, then warn:
user_editcount < 50
& user_age < '7 days'
& throttle: 1727280, 10, edit
The throttle action takes a time window in seconds, a limit, and a key; the syntax in the editor shows the exact form. It is the difference between a wiki that fights bots quietly and one that annoys people.
3. Tags and audit trails
The tag action labels matching edits (e.g. 'possible-spam') without interfering. Tags then power: recent-change filters, CheckUser queries, and post-hoc reports. A filter that only tags in the first days of deployment is the safest way to validate a rule before enabling blocking actions.
4. Global filters for wiki farms
On multi-wiki deployments with a shared database (CentralAuth or similar), AbuseFilter supports global filters managed at the central wiki and applied on every wiki — the standard approach in Wikimedia's cluster. This keeps one spam regex or one URL blacklist in a single place instead of N copies that drift apart. Local admins can still override by enabling/disabling global filters on their wiki.
5. Variables only in some contexts
The variable set depends on the action being filtered (edit, account creation, upload, move). Checking a variable that does not exist for the current action silently evaluates to 'unspecified' — a classic source of filters that never fire. The test interface shows which variables are available per context.
6. Test before you publish
Special:AbuseFilter has a built-in test form: paste wikitext and see which filters would fire. For destructive actions (block), stage the filter with disallow or tag first, watch false-positive rates for a week, then escalate. The extension documentation lists the complete variable and action reference.
7. A production pattern
The filters that survive contact with a real wiki follow one shape: narrow condition + staged action + audit tag.
!user_groups in sysop, bot
& action == 'edit'
& new_wikitext contains 'http://'
& page_namespace == 0
Excluding trusted groups first, scoping by action and namespace, tagging instead of blocking initially — that pattern prevents 90% of the false-positive incidents, and the throttling actions handle the rest.