This page can be used to requestedit filters, or changes to existing filters. Edit filters are primarily used to address common patterns of harmful editing.
Private filters should not be discussed in detail. If you wish to discuss creating an LTA filter, or changing an existing one, please instead email details towikipedia-en-editfilterslists.wikimedia.org.
Otherwise, please add a new sectionat the bottom using the following format:
== Brief description of filter ==*'''Task''': What is the filter supposed to do? To what pages and editors does it apply?*'''Reason''': Why is the filter needed?*'''Diffs''': Diffs of sample edits/cases. If the diffs are revdelled, consider emailing their contents to the mailing list.~~~~
Please note the following:
Edit filters are used primarily toprevent abuse. Contributors are not expected to have read all 200+ policies, guidelines and style pages before editing. Trivial formatting mistakes and edits that at first glance look fine but go against some obscure style guideline or arbitration ruling are not suitable candidates for an edit filter.
Filters are applied toall edits onall pages. Problematic changes that apply to a single page are likely not suitable for an edit filter.Page protection may be more appropriate in such cases.
Non-essential tasks or those that require access to complex criteria, especially information that the filter does not have access to, may be more appropriate for abot task or external software.
I originally started this discussion as 98.235.155.81, but later removed it after 9 days of inactivity, but in my opinion, if 833 is to log actions that contain, "Unreferenced or improperly referenced material". Then shouldn't the filter warn the user first, and then tag the edit in recent changes and page histories, because I see that making more sense than just logging the edit itself. Any thoughts or suggestions you would like to share?~2026-55845-4 (talk)13:13, 26 January 2026 (UTC)[reply]
Reason: Seen multiple instances where other users redirectWP:SANDBOX to another page, which is amisuse of the sandbox. Having this abuse filter in place will definitely save some time having to revert.
I recently attempted to decline an AfC draft for copyvio, and part of that involves pasting the URL for the copyvio'd site into theArticles for Creation helper script interface, which adds the url to the AfC submission template. I'm not sure if I just wasn't paying attention or if the AfC helper script somehow hid the warning, but I had to re-fill the form again to get it to get past the warning. (I didn't realize the issue until I then requested{{cv-revdel}}). I understand why the latter would be difficult to exclude from the filter, but I think edits that are already tagged to be using the AfC helper script could be excluded to avoid this confusion, as I don't think this filter could reasonably be triggered while using the script other than this particular circumstance.
A filter would be useful to catch instances of "Widely considered to be the [best|greatest]" without a source added, given these edits almost always get reverted.Somepinkdude (talk)18:17, 8 February 2026 (UTC)[reply]
Filter to warn users about adding A-series CSD tags to non-articles
Task: Warn editors against adding citations to Google Translate in article space.
Reason: The original web page should be cited, not a machine-generated translation, and the language noted. Editors who only speak English can get their own translation if need be.{{cite web}} has fields for English translations of title and quotation, but no citation is needed for the translations, only for the original text.
Task: What is the filter supposed to do? To what pages and editors does it apply?
This filter is intended to prevent the proliferation of duplicate headers like "Discussion" or "Survey" on high-traffic discussion pages (Village Pump pages, possibly also AN/ANI). Thanks toAhecht for suggesting that this be raised here.
Reason: Why is the filter needed?
Occasionally editors will start a discussion on one of the Village Pump subpages and create a subheader with a title like "Discussion" or "Survey", which inevitably creates navigation, linking, and editing problems when there end up being multiple identical subheaders on the page under different discussions. It should not be technically possible to create a generic subheader on these pages. If someone tries to create one, they should be prevented from saving until they change it a unique subject-specifics subheader (like "Discussion (section header)").
Diffs: Diffs of sample edits/cases. If the diffs are revdelled, consider emailing their contents to the mailing list.
Another EFH/EFM is welcome to weigh in, but personally, I would like to see a wider consensus before a filter like this (especially if it was set to disallow, as suggested) is implemented. Firstly, the diff you linked is from over three months ago. Has this been an issue more recently? Also, would simply a header or edit notice suffice? The diff linked here is from an administrator who was certainly acting in good faith.
As the header at the top of this page mentions, filters are intended primarily to prevent abuse across a wide number of pages. Preventing good-faith formatting errors on a select few pages doesn't seem needed to me. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆(𝒕𝒂𝒍𝒌)🔥02:43, 13 February 2026 (UTC)[reply]
The issue is perennial and arises from good faith edits all the time. I have also seen it recently, but usually when it starts to trip people up someone comes and adjusts the header. Of course, by then any incoming links will be derailed (and these pages have way too many incoming links to start fixing those after the fact).BD2412T02:49, 13 February 2026 (UTC)[reply]
I completely get that it's a problem; however, I am unsure whether or not an abusefilter is the best solution. I'll have to mull on it, or someone that actually knows what they're talking about can comment. :) - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆(𝒕𝒂𝒍𝒌)🔥02:54, 13 February 2026 (UTC)[reply]
Can a filter just be a filter without being an "abuse" filter? We can pause people from saving edits without edit summaries, or from saving a redirect to a nonexistent page, without these particularly being considered abuses.BD2412T03:57, 13 February 2026 (UTC)[reply]
Abusefilter is the name of the extension and the technical name for a lot of stuff. The page here on the English Wikipedia is Edit Filter for just the reason you gave. It doesn't necessarily have to be for abuse.
I personally feel like this should be a fine use for an edit filter. The scope is clear and false positives not an issue. I don't think the difference between a warning and disallow should be big here since most good faith editor would presumably change the title if warned.Trialpears (talk)12:28, 13 February 2026 (UTC)[reply]
I did a spot check on VPPR's contents over the last ~6 months. At any given point in time, there are about four sections where this might have triggered. Many of these are on the page for longer than 30 days, so I would expect such a filter to trigger maybe three times a month.
But: Most of these are RFCs, and I'd like to draw attention to a point made inWP:RFCOPEN:
If someone is setting up ===Discussion=== subsections, then that's a sign that they probably shouldn't be posting their RFC at VPPR in the first place. Maybe the warning should instead tell them to give their discussion its own page, with instructions such as these:
If you are expecting a normal-size discussion, you should not need "Discussion" or "Survey" section headings.
If you are expecting a larger discussion than average, please do not post it on this page. Follow the directions inWP:RFCOPEN to create andappropriately advertise a stand-alone page.
This page requires unique section headings. If you are adding a ===Break=== or ===Discussion=== heading, please make sure it does not duplicate any existing section headings (e.g., use ===Discussion about cake===).
@WhatamIdoing: I agree with most of these points. As to the final one, even if there is no current conflicting ===Discussion=== heading or the like, they should always preemptively be made with some kind of qualifier, in case they end up getting archived to an archive with earlier existing headings.BD2412T21:28, 16 February 2026 (UTC)[reply]
There will always be some chance of duplication, which is why MediaWiki was changed a while ago to automatically issue unique section headings. The second ===Discussion=== heading is automatically going to be#Discussion_2 in the URL, etc.WhatamIdoing (talk)21:34, 16 February 2026 (UTC)[reply]
I do think that it would still be better all-around if rather than an otherwise meaningless number, section headers indicated something about the section content.BD2412T23:32, 16 February 2026 (UTC)[reply]
Task: The filter is supposed to warn editors who make an edit that adds a clickable link (almost certainly via a reference) to Archive.is, or any mirror (the two I am aware of are archive.today and archive.ph). It will warn editors with the text "Warning - You have added a link to Archive.today, or one of it's mirrors. That website is currently running malicious code on the computers of people who visit it. For more information, seeour info page. If you can replace archive.today with an equivalent source, please do so. If you cannot, you can click "Save Changes" again to save your edit." or something similar. This filter should apply in all namespaces, although I expect it to be much rarer and somewhat less important outside of article space. This filter applies to all editors. This filter does not disallow edits, it simply warns, and probably logs.
Reason: Archive.is currently runs code on visitor machines to DDoS a third party website when it is accessed. We are currently holdinga RFC to determine what the long term response should be. Within the discussion section of that RFC, I proposed some stopgaps, among them an edit filter to warn on new additions of links to Archive.is. This proposal has attracted significant support, both explicit and implicit, and has zero opposition currently after explicitly calling for it.
Diffs: The description "adding a clickable link to archive.is, or a mirror" is controlling. An example of an addition is here: If more examples are helpful I can provide them - there's no shortage[1]. Note: Archive.org is a different site and not included.Tazerdadog (talk)18:52, 16 February 2026 (UTC)[reply]
Hello, I'm here from the relevant RfC.
Some editors there may find your proposed wording to be non-neutral (at least some would seem to believe that "malicious code" is disingenous). It might be better to be more specific, that it's a DDoS. I think there is, so far, a supermajority of editors who agree that a DDoS is what is happening (although I might be too involved to say for sure).
For the edit filter manager who may or may not decide to do this: please verify for yourself that the DDoS code is still live before you implement the filter, as a last minute check.MEN KISSING(she/they)T -C -Email me!22:25, 16 February 2026 (UTC)[reply]
ADDoS is what's happening, and DDoSing is malicious. The wordmalicious appears in that article three times, in fact. The problem with "it's a DDoS" is that ordinary people don't necessarily know all of the abbreviations or names for various malicious actions. What they care about is the fact that it's malicious. The exact category of malicious behavior doesn't matter to ordinary people. If you think "malicious code" isdisingenuous ("lacking in candor; giving a false appearance of simple frankness; calculating"[2]) – though there's no world in which that code could be considered benevolent, so words likecasuistry andhair-splitting tend to spring to mind – then we could trycyberattack, which is (a) what a DDoS is and (b) something that non-technical people would probably understand.WhatamIdoing (talk)23:04, 16 February 2026 (UTC)[reply]
For the record, I am one of the editors who agrees that "hosting malware" is accurate, both in letter and in spirit, and I do not think "malicious code" is at all disingenuous. I am just pointing out that there exist participants in the RfC who seem to disagree, and would likely take issue with that wording. Neutrality in the edit filter notice is non-negotiable in these circumstances, given the RfC is far from finished.
Saying "cyberattack" leaves out the important detail that it is based on code being run on the reader's device. I think it would be best to say it's a DDoS attack, and then clarify what that means. Maybe something like: "Archive.is is enacting aDDoS (Distributed Denial of Service) attack via this URL against a website they are in dispute with. Readers who click on the link and encounter a CAPTCHA page will load a script which repeatedly spams the targeted website with network requests."MEN KISSING(she/they)T -C -Email me!23:29, 16 February 2026 (UTC)[reply]
This is my feeling too, especially as it's unarguable there is no overwhelming consensus for any of the three options.If the RFC closes with consensus for option B,then an edit filter may be appropriate (it would presumably not be relevant if the consensus is for option A?).Thryduulf (talk)22:51, 16 February 2026 (UTC)[reply]
I concur, I'd like to see some authority for such a filter. I see the RfC has a small bit where it says "quite a few people have seemed to be supportive". In fact, I'd prefer to see a more explicit (sectioned) discussion of the filter. We should be able to rustle up a draft filter which would log-only for the time being. We havedeleted disabled filter559 from last time, but might as well start again. There are complications to consider such as bots and people reverting page-blanking. --zzuuzz(talk)23:05, 16 February 2026 (UTC)[reply]
I have a suggestion: we should use559 (hist·log) instead of1402 (hist·log) (given that 1402 is probably a duplicate of 559), in an attempt to reduce the condition count and for said filter to run faster:
There's room for optimisation. We might still want to check if it's a link (though probably without usingadded_links). We can probably also narrow the namespace scope at some point. One thing the current filter format does is to check domain switching, which is probably worth an initial look. Incidentally, this is something thatUser:GreenC bot is currently doing. I get the impression there are some tools still adding links to archive.today. The second filter hit references #IABot in the edit summary, and I'd find it surprising if everyone was able to find the archiveurl= parameter on their own. --zzuuzz(talk)10:08, 17 February 2026 (UTC)[reply]
If I'm reading that code correctly, we're excluding bots in this filter. The random diff I found is actually from a bot, and was the first addition I found. Do we have a sense of what fraction of new link additions are from bots? If it's significant, that might address a large portion of our issue quickly.Tazerdadog (talk)16:37, 17 February 2026 (UTC)[reply]
I've (probably temporarily) removed bots from the filter, so we can get an idea. Talk-page archiving bots are one consideration here - they can override the spam blacklist, but can't get around a filter (and its warning).User:GreenC's bot will hit this filter as it stands. There are probably other situations with bots. --zzuuzz(talk)18:30, 17 February 2026 (UTC)[reply]
The idea here was to get a stopgap in place while we wait for the RFC to conclude. If option B winds up being the close, presumably the filter would be set to disallow instead of warn. The points on bots and reversions are well-taken. I'd like to encourage working on that now, even if we're stuck in log only, in anticipation of a potential option b close if nothing else. I'll go fire up that section unless someone else wants to or has something to add before I do.Tazerdadog (talk)16:43, 17 February 2026 (UTC)[reply]
lists.wikimedia.org.