Wikipedia:Edit filter noticeboard

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

Welcome to the edit filter noticeboard

WATCH

Recent filter changes ():

Filter 614 — Pattern modified

Last changed at 09:51, 5 March 2025 (UTC)

Filter 1348 (new) — Actions: tag; Flags: enabled,public; Pattern modified

Last changed at 06:11, 5 March 2025 (UTC)

Filter 1347 (new) — Actions: tag; Flags: enabled,public; Pattern modified

Last changed at 23:38, 4 March 2025 (UTC)

Filter 1325 — Pattern modified

Last changed at 16:31, 2 March 2025 (UTC)

Filter 1345 (new) — Actions: showcaptcha,throttle; Flags: enabled; Pattern modified

Last changed at 09:10, 2 March 2025 (UTC)

Filter 1346 (new) — Actions: none; Flags: enabled,public; Pattern modified

Last changed at 21:59, 1 March 2025 (UTC)

Filter 869 — Pattern modified

Last changed at 18:50, 1 March 2025 (UTC)

Filter 947 — Flags: enabled

Last changed at 16:03, 1 March 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 348 enabled filters and 48 stale filters with no hits in the past 30 days. Filter condition use is ~1108, out of a maximum of 2000. (). See also the profiling data and edit filter graphs.

Click here to start a new discussion

Concern about Filter 614

I've noticed filter 614 (which disallows disruptive edits related to Internet slang etc.) doesn't seem to be working at all since it was last modified. This once-active filter's log completely dried up after this modification, and vandalism I would expect it to block has started going live. (For example, this rubbish should have been stopped by the filter for containing the word 'gyatt'.) Could the issue please be investigated? Entranced98 (talk) 01:15, 15 February 2025 (UTC)

Entranced98, the problem was that (?!\skong) was left behind after EggRoll97 removed the Diddy meme regex from the filter, but they forgot to remove that negative lookahead. Because of this, the filter is stealth disabled, meaning that it doesn't disallow meme/slang vandalism on articles. Codename Noreste (talk) 03:53, 15 February 2025 (UTC)

I'm fixing it. I'm cleaning up the filter so it'll take me more than a moment. Daniel Quinlan (talk) 05:37, 15 February 2025 (UTC)

Thanks for that. Looks far better with it separated by line in the string. EggRoll97 ^(talk) 15:43, 15 February 2025 (UTC)

@Entranced98: It should be working again. Thanks for the report. Daniel Quinlan (talk) 06:29, 15 February 2025 (UTC)

Thanks for sorting it out, much appreciated! Entranced98 (talk) 07:15, 15 February 2025 (UTC)

The new split-up pattern looks much better, I appreciate it. Codename Noreste (talk) 14:01, 15 February 2025 (UTC)

Would it be possible to add the term "goofy ahh brainrot" as well to prevent edits like these: [1]? Ca ^{talk to me!} 22:58, 17 February 2025 (UTC)

Filter 614 only triggers for users who are not autoconfirmed. – 2804:F1...D4:2EE1 (::/32) (talk) 01:43, 18 February 2025 (UTC)

@Ca: An expression for "brain rot" looks like a solid addition so it's been added. I am also testing out matching on more users with a low edit count (e.g., under 50 edits), but we want to be careful about keeping the false positive rate low. Daniel Quinlan (talk) 20:56, 23 February 2025 (UTC)

Set filter 1163 to warn and tag?

• 1163 (hist · log)

Looking at the filter's hits, they are mostly vandalism and other unconstructive edits, so we can use the default warning message for that. Any thoughts or suggestions? Codename Noreste (talk) 04:38, 18 February 2025 (UTC)

I agree, looking at the filter hits the majority of them are clear vandalism. There are a few edits that add quite a lot of text (where repeats are more likely to occur) and aren't clearly vandalism, but are probably unconstructive, for example Special:AbuseLog/40017576. If we want to be sure that this doesn't affect large constructive edits, could we perhaps add a condition to the filter to check that no (or very little) ref tags are added in the edit? I think that'd be a clear distinction between large unconstructive edits and large constructive edits and vandals are unlikely to add refs. FozzieHey (talk) 23:30, 18 February 2025 (UTC)

I hesitantly support warn and tag. I suppose I don't see anything wrong with doing so, but I'm also under the impression many of the problematic edits it catches would be caught by another filter. EggRoll97 ^(talk) 05:15, 21 February 2025 (UTC)

I've gone through a few of the filter logs, and while most users do trigger other filters, there are a few which only trigger this one. I'm sure the tag does help counter vandalism, and if we're not seeing much false positives then enabling warning is a benefit. Even if other filters match the same edits, those filters might not necessarily have tagging or warning enabled, so I don't really see much of a downside to turning it on here. FozzieHey (talk) 17:51, 22 February 2025 (UTC)

Also support warn and tag per everyone above. – PharyngealImplosive7 (talk) 04:40, 24 February 2025 (UTC)

Minor Change to 614

@Daniel Quinlan: You recently changed 614 (hist · log) so that it filters edits made by accounts with fewer than 50 edits or less than one week of age. I think it makes sense to also change the exception to the filter to reflect this change (though this is a minor, low-priority change):

−

/* exceptions for autoconfirmed users */ !("autoconfirmed" in user_groups & ( rcount("\{\{[Cc]ite\b", added_lines) > rcount("\{\{[Cc]ite\b", removed_lines) ) )

+

/* exceptions for users with fewer than 50 edits or less than one week of age */ !( (user_editcount < 50 | user_age < 604800) & ( rcount("\{\{[Cc]ite\b", added_lines) > rcount("\{\{[Cc]ite\b", removed_lines) ) )

– PharyngealImplosive7 (talk) 18:12, 24 February 2025 (UTC)

I also think that \broblox\b might be causing too many false positives, and we should remove some Hawk Tuah regex from private filter 1094, as it's already added to 614. Codename Noreste (talk) 18:38, 24 February 2025 (UTC)

I'll look at 1094. I'm monitoring "Roblox" hits with 614, but I think we'll need a bit more log data from after that was added before it's worth refining that part of the rule. Also, it would be appreciated if you could default to avoiding bringing up private filters in public, given the previous discussions about this. Daniel Quinlan (talk) 19:50, 24 February 2025 (UTC)

I haven't taken a deep look into 614, but most of the "roblox" related edits reported to EFFPR that I've seen are either vandalism, or unconstructive edits that I would have reverted myself (like adding non notable entries to lists). If it does turn out to be a problem, then I think it'd be worth splitting it out into a separate filter to take any false positive patterns into account, as I do find it useful for filtering out problematic edits. FozzieHey (talk) 17:56, 25 February 2025 (UTC)

I have noticed slightly more FP reports relating to this sort of vandalism, and some are good faith edits, by most are unsourced anyways, so I think that this should stay for now. I second the idea of creating a new filter to make the regex more sophisticated though. – PharyngealImplosive7 (talk) 21:57, 25 February 2025 (UTC)

Every edit that reaches that point of the logic meets the (user_editcount < 50 | user_age < 604800) condition. This means that condition will always be true so it doesn't make sense to repeat it.

Regardless, I looked at a version of the exception without the autoconfirmed requirement, but it would cause a loss of some true positives. There are some vandals that will add an (often silly or irrelevant) citation to their edit, but they tend to be non-autoconfirmed users. I added the exception because historical data showed it would address a small number of false positives due to the broadened scope of the filter.

Anyhow, if we see a false positive that would have been avoided with a slightly broader exception for citation additions such as (user_editcount >= 25 & user_age >= 432000), we can consider updating it. Daniel Quinlan (talk) 18:45, 24 February 2025 (UTC)

Ok, sounds good to me. – PharyngealImplosive7 (talk) 16:47, 25 February 2025 (UTC)

Viewing filter logs by IP range

Is there a way to check filter logs by IP range? For example, when an IPv6 user reports a false positive like here and nothing shows up in the filter log, I assume that they've triggered the filter on a different IP within the same range. So I tried to look up the /48 for that announced prefix, but nothing showed up, and the "filter log" button doesn't appear on the IP range's contributions page. Other than checking the global filter log manually for the prefix (I couldn't find anything there either, so we might just have to skip this specific report), is there a way to do this? FozzieHey (talk) 18:13, 25 February 2025 (UTC)

There is T256823 for this (with a patch set attached, so we hopefully shouldn't have to wait too long!), just wondering if anyone has a workaround with a script or similar in the meantime as I imagine it's an issue others have come across. FozzieHey (talk) 18:30, 25 February 2025 (UTC)

Deprecate Wen Wei Po

Please add wenweipo.com to Special:AbuseFilter/869 per with clear consensus|this RfC. Thanks. Aaron Liu (talk) 23:07, 25 February 2025 (UTC)

Sample regex: wenweipo\.com. – PharyngealImplosive7 (talk) 00:05, 26 February 2025 (UTC)

 Done charlotte ^👸♥ 00:40, 1 March 2025 (UTC)

@Queen of Hearts: I think you accidentally added this before the ?, meaning that genealogy.eu no longer matches in the regex. It also seems like there's a stray ) earlier in the regex as well (after eadaily\.com) from when @EggRoll97 edited the filter last. I think the last section of the regex should be changed to:

|eadaily\.com|geni\.com|genealogy\.eu(?:web\.cz)?|wenweipo\.com) FozzieHey (talk) 12:00, 1 March 2025 (UTC)

Derp, fixed. charlotte ^👸♥ 18:21, 1 March 2025 (UTC)

Trying to maintain that long of an pattern on a single line is just asking for trouble. I did the standard clean up since it's reached that point. Daniel Quinlan (talk) 18:54, 1 March 2025 (UTC)

Filter 54 edit request

Per WP:EF/TP, !('override-antispoof' in user_rights) in 54 (hist · log) should be replaced with !(contains_any(user_groups, "sysop", "bureaucrat", "accountcreator")). JJP_Master (she/they) 04:50, 26 February 2025 (UTC)

Noting here that there was a previous discussion that the 'user_rights' variable was and is currently not available at the moment. Codename Noreste (talk) 05:02, 26 February 2025 (UTC)

I thought that discussion concluded that we did still have access to user_rights, but as it's lazy loaded, you wouldn't see it unless that filter actually used the variable? FozzieHey (talk) 09:49, 26 February 2025 (UTC)

Special:AbuseFilter/1345

Noting that if continued testing of this filter over the next hour or so continues to produce no false positives, I plan to set this filter to Disallow. Sam Walton (talk) 09:25, 27 February 2025 (UTC)

They've evolved. ScottishFinnishRadish (talk) 18:06, 27 February 2025 (UTC)

At this point, we should stop and then continue on the edit filter mailing list. Codename Noreste (talk) 14:17, 28 February 2025 (UTC)

Since I made this filter, I guess now is an appropriate time to ask this question – how do I get on the mailing list? charlotte ^👸♥ 00:35, 1 March 2025 (UTC)

WP:EFMAILING. Daniel Quinlan (talk) 11:50, 1 March 2025 (UTC)

Inactive EFM (user:Someguy1221)

Per Wikipedia:Bureaucrats' noticeboard#Inactive admins for March 2025, edit filter manager Someguy1221 has been desysopped for inactivity and it was suggested that their EFM right (self-granted in 2009) should be reviewed on the same grounds. WP:EFM implicitly defines inactivity as 12 months with no edits or logged actions, Someguy1221 has made three edits in the last 12 months (one each in September, October and November 2024) so they do not qualify for automatic removal. Their last edit regarding edit filters seems to have been December 2022 and their last logged action regarding edit filters seems to have been August 2019. Thryduulf (talk) 12:51, 1 March 2025 (UTC)

While the policy doesn't specifically address this situation, it's clear they are inactive with respect to edit filters. I have no objection to removing EFM. If they become active again, they can request reinstatement of EFM as allowed by the policy.

It might make sense to add or from any desysopped administrator who has not logged edits or actions regarding edit filters for a similar period or perhaps for two years to the policy if there is consensus to do so. Daniel Quinlan (talk) 18:21, 1 March 2025 (UTC)

I don't object to amending the policy, but I'm not sure it's needed for something that doesn't occur particularly frequently? Thryduulf (talk) 19:02, 1 March 2025 (UTC)

I'm fine with leaving it unchanged unless we see it happening often enough to justify a change. WP:IAR is more than enough to handle this case. Daniel Quinlan (talk) 19:11, 1 March 2025 (UTC)

IAR doesn't come into it. WP:EFM explicitly states that a discussion about revocation of the right can be held at this noticeboard if discussion doesn't resolve concerns. I skipped the discussion (given that they haven't edited at all in several months, including not responding to notices about the pending change to their admin status, I don't think that would be worthwhile) but aside from that this is following the rules not ignoring them. Thryduulf (talk) 19:56, 1 March 2025 (UTC)

If I'm looking at the same passage, that provision is for misuse rather than inactivity. Daniel Quinlan (talk) 19:59, 1 March 2025 (UTC)

I don't think this is a particularly rare case. The majority of EFMs are admins, and some of those will eventually become inactive. I've just been through the list of non-admin EFMs and found two other cases of users being desysoped due to inactivity, but keeping EFM - Jarry1250 and NaomiAmethyst (I haven't checked too deeply into their edit filter contributions, this is just an example). It would be good to take this into account at the time of desysopping, whether or not that needs an extra line added to WP:EFM or somewhere else I'm not too sure. FozzieHey (talk) 20:36, 1 March 2025 (UTC)

I was granted EFM prior to my sysop, and as such it should remain after the inactivity desysop. — Naomi Amethyst 06:25, 2 March 2025 (UTC)

Hi NaomiAmethyst. Looking at the edit filter history, you made one filter change in 2017 and the previous change before that one was in 2009. Could you clarify why you still need the EFM right? Thanks. Daniel Quinlan (talk) 06:40, 2 March 2025 (UTC)

As one of the authors of ClueBot NG, I find read access to the hidden edit filters to be useful -- though perhaps Editfilter Helper is a sufficient group for that. I do also occasionally find things that are more properly handled at the edit filter rather than in an antivandalism bot. — Naomi Amethyst 06:57, 2 March 2025 (UTC)

Makes sense, thanks. EFH should be sufficient if you're not modifying filters these days. I don't think anyone is planning on doing anything right now, but it sounds like we might be headed towards doing some maintenance on EFM user rights for inactive users. Daniel Quinlan (talk) 08:01, 2 March 2025 (UTC)

I'm pretty sure this can be revoked unilaterally – east718 had EFM removed after he was criteria 2 desysopped, even though he was not inactive for a full year – but yes, I support revocation. charlotte ^👸♥ 19:08, 1 March 2025 (UTC)

I support, though perhaps we should have it in policy that EFM be revoked from anyone who is desysopped automatically unless they gained EFM through a consensus discussion. Basically, if they self-granted as an admin, I feel it should be revoked if they are no longer an admin for reasons that are not their resignation. EggRoll97 ^(talk) 21:15, 1 March 2025 (UTC)

I agree with this - if an admin self-grants EFM, then losing admin should result in losing EFM, unless otherwise specified. Sam Walton (talk) 22:05, 1 March 2025 (UTC)

That seems like a reasonable policy adjustment. Adding something like and former administrators desysopped due to inactivity if they self-granted the user right to WP:EFM would be very simple to evaluate. I don't think there's any reason to make a change broader than that, though. Daniel Quinlan (talk) 22:44, 1 March 2025 (UTC)

I think what would be clearest would be splitting the "Criteria for revocation" section into something similar to the following:

• Misuse: If an edit filter manager is misusing the user right, the concern should first be raised with them directly. If discussion does not resolve the issue, a request for discussion or removal of the user right may be made at the edit filter noticeboard.

• Inactivity: Any administrator may revoke the right in either of the following circumstances:

  • The edit filter manager has made no edits or logged actions for 12 consecutive months
  • The edit filter manager is a former administrator desysopped due to inactivity and their EFM right was self-granted. This does not apply if they explicitly request to retain the right at the edit filter noticeboard.

Other circumstances: A request for discussion or removal of the user right may be made at the edit filter noticeboard if discussion with the edit filter manager has not or would not resolve the issue. The edit filter manager must be informed of the discussion on their talk page.

The first bullet is unchanged, other than the addition of the bullet and "Misuse:"; the first bullet of inactivity just makes it explicit what total inactivity means without changing the meaning at all. The second bullet of inactivity is based on this discussion, the final bullet just makes it clear what should happen in a situation that doesn't fit any of the bullets. Thryduulf (talk) 00:00, 2 March 2025 (UTC)

That is easier to read. I'd suggest changing the last bullet to:

• Noticeboard requests: A request for discussion about revoking the user right may be made at the edit filter noticeboard for conduct or edit filter misuse issues that cannot be handled through direct discussion. The edit filter manager must be informed of the discussion on their talk page.

That would allow the first bullet to be dropped and it covers general conduct issues that rise to the point where someone is concerned about a user's EFM rights. Daniel Quinlan (talk) 00:53, 2 March 2025 (UTC)

I like the idea of combining the first and third bullets, but I'd title it "other circumstances" rather than "noticeboard requests" ("other" being in contrast to inactivity) . It also shouldn't be limited to conduct or misuse (e.g. it could be someone who is minimally active but not contributing in relation to edit filters)

• Other circumstances: A request for discussion about revoking the user right may be made at the edit filter noticeboard for issues, e.g. relating to conduct or edit filter misuse, that cannot be handled through direct discussion. The edit filter manager must be informed of the discussion on their talk page.. Thryduulf (talk) 01:21, 2 March 2025 (UTC)

Makes sense. Slightly reworded for flow:

• Other circumstances: A request for discussion about revoking the user right may be made at the edit filter noticeboard for issues such as misconduct or edit filter misuse, but direct discussion should be tried first in most cases. The edit filter manager must be informed of the discussion on their talk page. Daniel Quinlan (talk) 03:45, 2 March 2025 (UTC)

That's generally good but I don't like "such as" because it could be read as limiting to issues similar to those listed (which effective but not total inactivity is not). I can't immediately think of anything better though. What first comes to mind is using "including" rather than "such as", but then I want to add commas which takes us back to the flow issues of my previous suggestion. Thryduulf (talk) 03:54, 2 March 2025 (UTC)

Perhaps we could add a bullet to inactivity if that's the main concern you have? It's better to use a crisp definition for inactivity.

• The edit filter manager has no activity related to edit filters for 24 consecutive months and is not an administrator or former administrator.

If someone has done nothing related to edit filters for that long of a period, EFH would be more appropriate if they have a valid reason for needing read access. I added "former administrator" due to administrators being resysopped often enough. Daniel Quinlan (talk) 04:30, 2 March 2025 (UTC)

I think you've misunderstood what I was trying to say - I was just using that situation as an example. My concern is that there will be situations where it is desirable to review someone's EFM right for reasons not specifically listed (and we should not attempt to list every conceivable reason) and the policy should be clear about what to do when such a situation arises. Basically I think there should be two bullets, the first about inactivity, the second for all other matters including but not limited to abuse and misuse. Thryduulf (talk) 04:50, 2 March 2025 (UTC)

Roger. I think "such as" isn't limiting if that helps. Daniel Quinlan (talk) 04:53, 2 March 2025 (UTC)

Is this really necessary? We have admins who haven't used their EFM bit in 15+ years, why start treating former admins different then current ones? Nobody (talk) 07:39, 3 March 2025 (UTC)

Current administrators can self-grant the right so there's no point in removing it. But removing it from administrators desysopped due to inactivity is good security practice. Daniel Quinlan (talk) 14:24, 3 March 2025 (UTC)

Don't get me wrong I think it's a great idea to deal with inactive EFMs, it just seems like barking up a small tree, when instead we could just say in general Any administrator may revoke the right if the edit filter manager has no activity related to edit filters for 5 consecutive years. That might affect more admins then you'd like, but thats what I'd consider good security practice. Nobody (talk) 14:39, 3 March 2025 (UTC)

Removing it from current administrators doesn't significantly improve security. It takes 10 seconds to self-grant the right. Daniel Quinlan (talk) 16:51, 3 March 2025 (UTC)

Asking the question is reasonable; we rarely grant EFM to non-admins (only 17 non-admins have it), so asking if the admin still requires the perm isn't necessarily a waste of time. Primefac (talk) 17:21, 3 March 2025 (UTC)

For quite a while I've held the belief that the EFM perm for admins should frankly be fairly easily removed, given they can just add it right on back if they still need it. I also would wager a guess that most of the 148 EFMs are probably not involved in edit filters, and assigned it to themselves for a one-off occasion. Hell, This, that and the other was assigned the EFM right without a consensus discussion to troubleshoot a bug (which has long since been resolved), and has been inactive in edit filters generally speaking since 2016. EggRoll97 ^(talk) 19:41, 4 March 2025 (UTC)

Perhaps we should state that the EFM permission will be removed from everybody who has not made at least one edit and/or logged action related to edit filters in the last 12 months. Admins whose permission is removed in this manner can re-grant it to themselves if they have a need. Non-admins can request it again here subject to the usual requirements. Thryduulf (talk) 19:59, 4 March 2025 (UTC)

I see no problems with this. WP:EFM already allows for re-granting the right upon the request of a former edit filter manager who has had the right removed on their own request or for inactivity and the right was removed under uncontroversial circumstances. Seems like it would be fairly trivial to grant back on request (it'd operate fairly similarly to resysopping), and we can clean out the EFM right from some who haven't used it in ages. If nothing else, the benefit here would be having said admin or non-admin EFM re-confirm that they still have a need for the right and that they still have a good enough working understanding of filters not to break things. EggRoll97 ^(talk) 21:11, 4 March 2025 (UTC)

I don't think the change is necessary or beneficial.

• Removing EFM from sysops wouldn't meaningfully improve security because they can self-grant the right in seconds.
• It would incentivize inactive administrators to make trivial edits to filters.
• Adding unnecessary friction and discussions for every future removal would be an inefficient use of time.
• Many other Wikipedias, including Spanish and German, grant the abusefilter-modify permission to sysops by default because it's a routine part of administrative work.

A more practical approach is to review EFM when an administrator is desysopped due to inactivity because there is actually a significant security benefit and it's less frequent. I have no objections to suggesting that administrators not using the EFM right consider self-revoking it, though. Daniel Quinlan (talk) 22:03, 4 March 2025 (UTC)

I don't see how it would incentivize trivial edits to filters. Administrators nearing the threshold for inactivity can easily just make any edit at all to any edit filter related page, for example, responding to a false positive report, or commenting on anything on this very noticeboard. Even if the right is removed, they can simply add it back, meaning it becomes a trivial matter to simply re-grant it to themselves. EggRoll97 ^(talk) 02:58, 5 March 2025 (UTC)

EF1199

We are seeing a surge of rapid edit vandalism by IPs to articles. These are being logged by EF1199. Would it be possible for the EF to report IPs to AIV? — Malcolmxl5 (talk) 14:42, 1 March 2025 (UTC)

Good idea. It looks like CFA has already done this. Daniel Quinlan (talk) 18:23, 1 March 2025 (UTC)