Wikipedia:Edit filter noticeboard

"WP:EFN" redirects here. For information on the {{efn}} template, see WP:EXPLNOTE.

Welcome to the edit filter noticeboard

Shortcuts

• WP:EFNWP:EFN
• WP:EF/NWP:EF/N

WATCH

Recent filter changes (purge):

Filter 856 — Pattern modified

Last changed at 14:32, 25 September 2025 (UTC)

Filter 1295 (deleted) &mdash

Last changed at 19:59, 23 September 2025 (UTC)

Filter 54 — Pattern modified

Last changed at 22:56, 21 September 2025 (UTC)

Filter 614 — Pattern modified

Last changed at 22:47, 21 September 2025 (UTC)

Filter 46 — Pattern modified

Last changed at 13:06, 21 September 2025 (UTC)

Filter 981 — Pattern modified

Last changed at 13:02, 21 September 2025 (UTC)

This is the edit filter noticeboard, for coordination and discussion of edit filter use and management.

If you wish to request an edit filter or changes to existing filters, please post at Wikipedia:Edit filter/Requested. If you would like to report a false positive, please post at Wikipedia:Edit filter/False positives.

Private filters should not be discussed in detail here; please email an edit filter manager if you have specific concerns or questions about the content of hidden filters.

---

There are currently 360 enabled filters and 48 stale filters with no hits in the past 30 days. Filter condition use is ~1030, out of a maximum of 2000. (Purge).

Click here to start a new discussion

TAIV and EFM/EFH rights

Looking Special:UserGroupRights:

• temporary-account-viewer: View IP addresses used by temporary accounts (checkuser-temporary-account)
• abusefilter and abusefilter-helper: View and create filters that use protected variables (abusefilter-access-protected-vars)

Might it make more sense for all these groups to have both rights? If someone is trusted to view temporary account IPs in one place, they should be trusted to view them everywhere, yes? Suffusion of Yellow (talk) 23:53, 30 August 2025 (UTC)[reply]

It definitely makes sense in my mind. – PharyngealImplosive7 (talk) 00:43, 31 August 2025 (UTC)[reply]

If you look at the global temporary account IP viewer permission in Meta-Wiki, you will see that it also has (abusefilter-access-protected-vars) per m:Special:Permalink/28876252. Therefore, it does make sense to me.

In addition, regarding temporary accounts, see phab:T402181. It’s coming (for all wikis except some specific wikis, including the English Wikipedia) on the week of September 2, but we still have time to implement user_unnamed_ip on some filters, and replace user_type == "ip" to user_type != "named", per my previous notification. Codename Noreste (talk) 10:36, 31 August 2025 (UTC)[reply]

I see no reason not to. However, I should note that the Foundation objects to assigning checkuser-temporary-account to any user-group other than temporary account IP viewer, per m:Limits to configuration changes: checkuser-temporary-account is intended to be a standalone right. I imagine there would also be a similar problem with assigning abusefilter-access-protected-vars to every TAIV (as it would no longer make checkuser-temporary-account a standalone right, but a right bundled into a more expansive usergroup), though I see that one as less likely to cause an objection from the Foundation than adding checkuser-temporary-account to other groups. EggRoll97 ^(talk) 01:34, 3 September 2025 (UTC)[reply]

Since the only protected variable currently in the AbuseFilter extension is user_unnamed_ip, I think the latter option makes more sense (adding abusefilter-access-protected-vars to temporary-account-viewer). Aydoh8^{[what have I done now?]} 09:31, 13 September 2025 (UTC)[reply]

Also I highly doubt the WMF would approve of adding checkuser-temporary-account to any permission other than TAIV. Sysop and CU have checkuser-temporary-account-auto-reveal. Aydoh8^{[what have I done now?]} 00:14, 20 September 2025 (UTC)[reply]

Setting 1381 to warn or disallow?

After being created on request on 24 August and having since recorded 5 hits and no false positives, I think we should set this filter to either warn or disallow. I'm not particularly versed on either, I thought it would be better to get a consensus on what option we should take. Aydoh8^{[what have I done now?]} 15:31, 15 September 2025 (UTC)[reply]

5 hits is not a particularly large amount of hits. I would prefer waiting for more hits rather than setting the filter to disallow now. – PharyngealImplosive7 (talk) 16:31, 15 September 2025 (UTC)[reply]

Interestingly Draft:Agrajeet Chowdhury doesn't seem to have any filter hits by this filter (when it was not deleted), seems like a false negative. Tenshi! (Talk page) 16:57, 15 September 2025 (UTC)[reply]

Interesting. I'm not a sysop so I can't see the deleted contribs; if any sysop reading this would be able to temporarily undelete or copy the diff so we can troubleshoot, that would be appreciated. (Please ping) Aydoh8^{[what have I done now?]} 04:41, 16 September 2025 (UTC)[reply]

@Aydoh8: This would likely be at Special:AbuseLog/42122172. See the old_wikitext generated variable for the text of the article. It appears it didn't hit since the user in question manually submitted with {{subst:submit}}, thus bypassing the edit summary check (by simply not leaving one), and bypassing the added_lines check by using "submit" instead of anything matching the "submission" string. EggRoll97 ^(talk) 05:09, 18 September 2025 (UTC)[reply]

I’ll have a look when I’m back on my computer. Thanks for the message. Aydoh8^{[what have I done now?]} 05:11, 18 September 2025 (UTC)[reply]

Of course. I will admit, this seems a bit of a roundabout way to get deleted history, and it seems like it would be easier to just add deletedtext/deletedhistory to EFMs, though I don't see that gaining consensus. EggRoll97 ^(talk) 05:13, 18 September 2025 (UTC)[reply]

I’m quite sure WMF once said that users should go through RfA or RfA-equivalent process in order to see deleted contributions. A09|(talk) 14:24, 19 September 2025 (UTC)[reply]

@EggRoll97: I've had a look, would you (or any EFM reading) be able to change submission := "\{\{afc(?:\ssubmission)?\|\|\|" to submission := "\{\{afc(?:\ssubmission)?\|\|\||\{\{(subst:)?submit\}\}"? That should fix that false negative, matching both {{subst:submit}} and the non-substituted {{submit}}. Aydoh8^{[what have I done now?]} 09:18, 18 September 2025 (UTC)[reply]

I'm getting a syntax error from that when I try to test it in /test. I believe there's a bracket missing in there, but I'll check later. EggRoll97 ^(talk) 06:12, 19 September 2025 (UTC)[reply]

@EggRoll97: Perhaps its because you forgot the semicolon at the end? With the semicolon, the code does not seem to give any errors. – PharyngealImplosive7 (talk) 13:38, 19 September 2025 (UTC)[reply]

@PharyngealImplosive7: You are correct, silly me. I've edited the filter accordingly. EggRoll97 ^(talk) 03:47, 20 September 2025 (UTC)[reply]

Looks like the decision to include {{subst:submit}} in the filter was a good one, since it has picked up 3 more hits in the past week all using the manual subst. Aydoh8^{[what have I done now?]} 18:03, 28 September 2025 (UTC)[reply]

Disallow filter at Donald Trump

Over the past month or so, Salebot1 has been targeting Donald Trump with extended-confirmed accounts, and the page has been fully protected. MOs are varied and evolving, while checkuser and other admin tools are not a great preemptive help. To help deal with this and to move away from full protection I propose a 'disallow' filter. To be effective the filter needs to set some hard limits, such as the number of edits and age of account. Those limits will need to be in excess of extended-confirmed. They will also likely need to be variable, as well as in place for as long as is necessary. While I feel comfortable discussing the filter in public, discussing these limits in public is likely to be unproductive. I think it would be easiest, subject to 'passing' here, if I just point to Special:AbuseFilter/1380. Note: having pondered where to post this, I ended here. If anyone wants to notify WP:AN, they're welcome to do that. Courtesy pings go to @Daniel Quinlan, Ymblanter, QuicoleJR, and Mandruss:. -- zzuuzz ^(talk) 12:37, 20 September 2025 (UTC)[reply]

Subscribed! ―Mandruss ☎ IMO. 13:02, 20 September 2025 (UTC)[reply]

I appreciate the ping. I'd probably be okay with it as long as this doesn't become a frequent occurrence and the limit isn't too excessive. QuicoleJR (talk) 13:19, 20 September 2025 (UTC)[reply]

Update: I agree with Daniel below on possible solutions. I'm also not convinced that this one LTA is enough of a problem to warrant reworking the entire system, and we probably don't need to keep Trump fully protected for more than a couple more days. QuicoleJR (talk) 17:22, 20 September 2025 (UTC)[reply]

The article should not be fully protected for so long, but edit filters are not the solution:

• If we think a higher level of protection above ECP is needed for articles, we should be doing it via the protection system.
• I don't think your proposal will be effective for this vandal. They have already moved to other pages whenever their target was protected. Taylor Swift has already been vandalized because Donald Trump was fully protected. And Donald Trump is only the most recent target. There is no shortage of high profile pages.

However, I am in favor of making some changes to how extended confirmed works. This is based on what I said earlier on Ymblanter's talk page:

• The main issue is that it's easy to run up edit counts to 500 edits very quickly. Even though most extreme gaming is detected fairly quickly in several different ways, 5 to 15 minutes is long enough to seriously disrupt ECP articles, and some accounts are going to slip through even with multiple measures in place.
• My preferred solution is adding a significant delay between reaching the requirements for the extended-confirmed group and granting the right. At least several days, not hours or minutes. We may also want to consider changing the 30 day requirement from account age to time since first edit although that may be unnecessary if the delay was long enough (e.g., 10 or 15 days). Ideally, this would take the form of an "extended-confirmed pending" group or some other implementation that allows pending grants to be listed so they can be reviewed. I'm not sure, but I suspect that will require a new mw:Manual:Hooks/AutopromoteCondition extension or other code changes.

Given the seriousness of the issues we're having, I think the WMF may be open to this approach. Daniel Quinlan (talk) 16:16, 20 September 2025 (UTC)[reply]

It probably takes the WMF a month to make cup of coffee. OK, well I tried but full protection it is then. -- zzuuzz ^(talk) 16:56, 20 September 2025 (UTC)[reply]

Sounds like you're proposing changing ECP from 30/500 to 40/500. In effect. If we're going to do it in effect, why not just do it? Much simpler than what you're proposing. I still favor a new 365/10000. We could call it MAXP, but then we'd be proven wrong when something more is needed. For best future-proofing: Unprotected=PROT0, Semi=PROT1, ECP=PROT2, MAXP=PROT3. ―Mandruss ☎ IMO. 17:20, 20 September 2025 (UTC)[reply]

Yes, although that's not actually a requirement for the proposal. We could lower the base requirement to 25 days with 500 edits and add a 5 day delay. That being said, I think 40 or 45 days would be reasonable, and I'd rather not have some new users focused on trying to reach 500 edits in 25 days instead of 30 days. It's been a long time since ECP was first added. Wikipedia is more complex, there are more topics with general sanctions, and there are more abusive LTAs than ever. Daniel Quinlan (talk) 17:35, 20 September 2025 (UTC)[reply]

If you make it 40/500 or 45/500 without a delay, disruptive and abusive users will just wait the extra 10 or 15 days before doing the permission gaming. The delay changes the automatic grant in a way that's fundamentally different from simply increasing the requirements. And it gives the community sufficient time to detect gaming between the requirements being met and the permission being granted. Daniel Quinlan (talk) 17:44, 20 September 2025 (UTC)[reply]

The delay changes the automatic grant in a way that's fundamentally different from simply increasing the requirements. I'm failing to see the fundamental difference, or at least enough fundamental difference to significantly address the problem. ―Mandruss ☎ IMO. 18:16, 20 September 2025 (UTC)[reply]

Raising the requirements only moves the finish line. LTAs can still create sleeper accounts, meet the requirements quickly with a spree of edits, and immediately gain the permission. A delay decouples meeting the requirements from receiving the permission, creating a review window where gaming or suspicious behavior can be detected (by both manual and automated means) so the accounts can be actioned before the permission is granted. Daniel Quinlan (talk) 19:26, 20 September 2025 (UTC)[reply]

General-purpose hmmm. :D. Carry on. ―Mandruss ☎ IMO. 19:49, 20 September 2025 (UTC)[reply]

@Daniel Quinlan and Mandruss: We could also just make this "MAXP" a manually requested and manually added permission, which would, unfortunately, add another backlog to PERM, but I imagine that would make it much harder to game, considering it would require an actual human to review edits prior to granting. EggRoll97 ^(talk) 21:06, 20 September 2025 (UTC)[reply]

Stop calling it MAXP, per my earlier comment. lol. We want to nip that in the bud. Call it PROT3. ―Mandruss ☎ IMO. 21:21, 20 September 2025 (UTC)[reply]

Still though, we could just grant MAXP PROT3 manually, and that would quash a lot of the Salebot stuff. EggRoll97 ^(talk) 21:32, 20 September 2025 (UTC)[reply]

That's just a little above my unpay grade. Maybe Daniel will have something to say about it. ―Mandruss ☎ IMO. 21:34, 20 September 2025 (UTC)[reply]

After some discussion with several others, it seems like there may be an easier solution we should try before any of the above: allowing edit filters to prevent extended confirmed from being granted. Because this requires updating the site configuration for how extendedconfirmed is granted, I have posted a proposal at Wikipedia talk:Protection policy § Modifying extended confirmed permission grants. I have a short list of edit filters I would want us to use for this, but that is best discussed in private on the mailing list. Daniel Quinlan (talk) 21:55, 20 September 2025 (UTC)[reply]

I've posted a revised proposal at Wikipedia talk:Protection policy § Revised proposal to improve extended confirmed grants to address the partial oppose from EggRoll97. Daniel Quinlan (talk) 20:54, 22 September 2025 (UTC)[reply]

Add the abusefilter-modify-restricted right to EFM

This right allows for editing filters with restricted actions. With the current wiki configuration, the only restricted action is blocking autoconfirmed granting, and revoking if one already is autoconfirmed. It is worth noting that all EFMs can already restore autoconfirmed if it is revoked by a filter. I don't see any reason in which a filter should be uneditable by non-admin EFMs, considering anyone with the right has gone through a discussion/request to attain it, (or gone through RfA to gauge general competence, and has assessed themselves as competent enough to edit filters), and has proven their technical competence in filter editing, and it seems a good idea to simply grant the right to the main EFM group. EggRoll97 ^(talk) 18:18, 21 September 2025 (UTC)[reply]

I thought existing policy was that we don't write any edit filters here that blocks autoconfirmed? In that case there's no point to add that right. dbeef [talk] 02:06, 22 September 2025 (UTC)[reply]

Activating filters with blockautopromote is now being discussed at WT:PP and in the section above this, and nothing is necessarily written into policy to prevent it, though I had thought the same thing on us not writing these filters. EggRoll97 ^(talk) 02:48, 22 September 2025 (UTC)[reply]

My impression is that it's not used because it's not terribly helpful on its own for various reasons. I'm proposing on WT:PP that we use that functionality to make it more difficult to game extendedconfirmed. Daniel Quinlan (talk) 05:42, 22 September 2025 (UTC)[reply]

In that case such that a potential proposal is being considered, Support this proposal.

EFMs are already highly trusted. they can easily craft a filter that prevents someone from editing. Potential for abuse is very low. dbeef [talk] 14:44, 22 September 2025 (UTC)[reply]

@Dbeef: I've posted a revised proposal at Wikipedia talk:Protection policy § Revised proposal to improve extended confirmed grants which should address this issue independently of the above proposal. Daniel Quinlan (talk) 20:52, 22 September 2025 (UTC)[reply]

Also support this. Non-admin EFMs are already high trusted and we already can disallow edits. I see no problem with us having the ability to block autopromotion. – PharyngealImplosive7 (talk) 03:16, 23 September 2025 (UTC)[reply]

RFC discussion at Wikipedia talk:Protection policy § Revised proposal to improve extended confirmed grants

 You are invited to join the discussion at Wikipedia talk:Protection policy § Revised proposal to improve extended confirmed grants. Daniel Quinlan (talk) 21:10, 22 September 2025 (UTC)[reply]

Question

Does anyone know why Special:Diff/1313911692 seems to have triggered Filter 631, "Extraneous Toolbar Markup"? This filter usually catches test edits in main space, and when I saw the hit I reverted initially as an editing test, but then I noticed that it was actually a substantial addition of content, causing me to revert my previous revert. Why did an edit that in actuality was anything but a test edit trigger a filter used for catching test edits? Taking Out The Trash (talk) 19:49, 28 September 2025 (UTC)[reply]

See Special:Diff/1313914099, which is what triggered the filter. -- zzuuzz ^(talk) 19:52, 28 September 2025 (UTC)[reply]

Taking Out The Trash, 631 (hist · log) catches exact toolbar markup in articles (using rlike), but only if there is an addition or removal of content. On the other hand, 1300 (hist · log) is similar, but warns non-autoconfirmed users who only add exact toolbar markup and nothing else. Based on this, it seems that filter 631 is working as intended. Codename Noreste (talk) 02:46, 29 September 2025 (UTC)[reply]