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 1346 — Pattern modified

Last changed at 23:30, 1 August 2026 (UTC)

Filter 1343 — Flags: disabled

Last changed at 02:06, 29 July 2026 (UTC)

Filter 1401 — Pattern modified

Last changed at 21:53, 28 July 2026 (UTC)

Filter 1402 — Pattern modified

Last changed at 21:53, 28 July 2026 (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 or an edit filter helper if you have specific concerns or questions about the content of hidden filters.

---

There are currently 369 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. ().

Click here to start a new discussion

Proposing expansion of 630

Filter 630 flags new editors moving pages out of their userspace, which is a strong signal for UPE/Promo/COI issues. In recent times we have strongly encouraged new users to use draftspace instead of userspace, especially for AFC submissions. I propose expanding or duplicating this filter to cover moves from draftspace to mainspace. I see this as an uncontroversial change, but wanted to give the opportunity for concerns to be flagged. Courtesy ping to @Bobby Cohn and Jlwoodwa: with whom I discussed this. Vanamonde93 (talk) 19:31, 29 June 2026 (UTC)

One point to consider is whether the filter should apply whenever a new editor moves any page out of draftspace, or only if it's a draft that they created/submitted. jlwoodwa (talk) 19:35, 29 June 2026 (UTC)

We can only do checks against recent editors, not the creator, but I think it would need to be any user regardless because of how spam rings operate. Daniel Quinlan (talk) 19:53, 29 June 2026 (UTC)

Support the change, but I'm not familiar enough the the practices of edit filters to give advice on whether to expand or duplicate the filter. (edit conflict) I will say that as written, the filter doesn't discern the page creator, rather just the action, user and namespace. I think this is elegant in its simplicity. I have been thinking about proposing something here that tracks the removal of {{AFC submission where |u=user or the page creator are the same as remover. I think that may be a good candidate for a new filter. I think between filter 630 catching new user moving and then this one, catching the removal of AFC tags, I think the two could create a pretty comprehensive net. Bobby Cohn 🍁 (talk) 19:35, 29 June 2026 (UTC)

There's 1370 which tracks removal of declines. Tenshi! (Talk page) 19:43, 29 June 2026 (UTC)

I like that. I will say, in conversation with Vanamonde93, I know they mentioned concerns specifically about pulling the users pulling drafts out of the queue before the draft had a chance to be reviewed. Bobby Cohn 🍁 (talk) 19:58, 29 June 2026 (UTC)

I think expanding the scope is probably fine ("New users moving pages to mainspace"), but first we should do some testing. Specifically, we should check the accuracy of any changes, determine which namespaces to include, see whether there are any common good faith cases that should be excluded, etc. Daniel Quinlan (talk) 19:49, 29 June 2026 (UTC)

Well, the filter is set to tag, not disallow. The cost of flagging good faith edits is low. Even so: I'd be willing to undertake to spot-check; is that sufficient from a testing perspective? What else would you look for? And I'd suggest only adding draftspace. Anything else is weird enough not to be a common means of avoiding scrutiny. Vanamonde93 (talk) 19:57, 29 June 2026 (UTC)

I'm fetching logs now, I'll probably check the last two years of moves. I'll check all namespaces since it's not much more work. Some spot checking might be worthwhile, I'll reach out if that seems like it will be helpful. Daniel Quinlan (talk) 20:17, 29 June 2026 (UTC)

Changing moved_from_namespace == 2 &

To (moved_from_namespace == 2 | moved_from_namespace == 118) &

Looks to have additionally picked up on this move of the last 100 move log entries. As an example of what would be caught. (edit conflict) Nvm, I see that there's a better way to do testing. Bobby Cohn 🍁 (talk) 20:26, 29 June 2026 (UTC)

I think it's probably fine to run this for all namespaces based on a preliminary analysis of the logs. I focused on analyzing the proportion of moves and unique users that ended up blocked. The starting sample was the last one million moves (every move going back to 2024-08-26) which included 104,852 moves from outside of mainspace into mainspace from 17,668 unique users.

Source namespace	Total moves	Unique users	% moves by currently blocked users	% unique users currently blocked
1	98	83	19.4%	22.9%
2	21030	8360	6.8%	9.4%
3	152	105	10.5%	10.5%
4	806	685	8.2%	7.6%
5	8	6	25.0%	33.3%
7	4	4	0.0%	0.0%
9	3	3	0.0%	0.0%
10	37	29	37.8%	20.7%
11	1	1	0.0%	0.0%
12	9	9	22.2%	22.2%
14	4	3	0.0%	0.0%
15	1	1	0.0%	0.0%
100	11	9	45.5%	44.4%
101	1	1	0.0%	0.0%
118	82623	10556	9.4%	20.0%
119	42	40	31.0%	32.5%
126	5	5	20.0%	20.0%
710	2	2	50.0%	50.0%
828	2	2	0.0%	0.0%
829	2	1	0.0%	0.0%
1728	10	10	30.0%	30.0%
1729	1	1	0.0%	0.0%

It looks like every source namespace with more than 5 moves in the sample is "worse" (higher blocked percentages) than namespace 2 (which is currently in the filter) with the possible exception of namespace 4. Note that the above table did not consider edit counts.

I then reviewed a random sample of these moves by users with fewer than 200 edits (current edit counts, not simulated historical edit counts) and a reasonably high proportion of the moves are now red links, were made by a user that's now blocked, or both. If there's consensus to move forward, I'll update the filter, but if anyone else wants to help review a random sample of move log entries that would have been tagged with this change, I've built several groups of 25 random logs:

1. 182261707 166684661 170346031 173355389 166198906 169768267 170954428 164503337 172204342 165373936 167707897 165609055 172831653 178987917 179540508 172168878 170351809 179164880 181575346 180635458 170035869 169261831 173244722 179842768 178197358
2. 177693645 168562419 171089653 176521385 174516071 177131308 168643848 164732665 171810980 168592203 176883903 166678443 178285963 164382299 179063813 172861849 164408438 164523831 171553946 172091940 171108587 173206073 167432742 165313133 173264457
3. 168985556 166441652 175951555 179140379 168609238 166076969 170743269 164221468 173605639 174220077 175342135 181234946 171814461 174430982 167837410 182238627 176115517 168559732 173713855 165920054 181368688 180004293 172057876 165096869 178021687
4. 167219148 180374662 166499717 180106117 165637044 172995292 166831517 178839421 177611169 167029662 166507195 167102546 180297958 169961925 178294156 168573474 164486336 178347643 173900048 176176062 172660420 168833223 174428692 168052777 171170526

If anyone wants to review a group, I'd suggest counting the number of logs that have (a) destinations with red links, (b) were made by a user that is now blocked, or (c) both (in addition to whatever else you want to produce as results). Daniel Quinlan (talk) 21:50, 29 June 2026 (UTC)

• I checked the first 50 entries in this list. 30 of the moved articles were deleted; 8 were re-draftified; the rest remain extant, though a couple ought to be deleted. 18 of the movers were blocked (I did not check for duplicates).
  IMO this is clear-cut evidence that flagging these moves via the expanded filter will be useful to anti-abuse operations. I wonder if the RCP softwares can incorporate evidence from this flag too. Vanamonde93 (talk) 04:40, 2 July 2026 (UTC)

  Sweet, I'll take the next 50:

  1. redlinked: 13 (+2 BLARed, +2 with a COI/UPE tags or tag dispute, +1 extant with a former delete at AfD, +1 almost entirely without citations, +3 with notability tags)
  2. blocked: 2 (both sockpuppets, 1 article in WP:CT/SA)
  3. both: 12

  Yeah, this looks like it would be a useful expansion of the filter. Bobby Cohn 🍁 (talk) 22:48, 3 July 2026 (UTC)

 Done. The data looks good and there seems to be strong consensus for the change. I've updated 630 as discussed. The new tag is new user move into mainspace. Daniel Quinlan (talk) 23:24, 3 July 2026 (UTC)

Updated filter 686

@Galobtter, Zzuuzz, Samwalton9, and Rich Farmbrough: I just finished a substantial update to filter 686 (hist · log) after we received this false positive report. The hit rate is going to be substantially higher now because the table and infobox exceptions are absent (at least for now), but the changes also eliminated about 5% of the previous matches that were definitely false positives. The main change I'm having second thoughts about is whether we should exclude some changes to tables. Don't get me wrong, they are mostly unreferenced changes and additions, but that seems to be par for the course for athlete and entertainer BLPs. Perhaps it's time to raise the bar, though. Please let me know if you have any concerns or questions. Daniel Quinlan (talk) 02:05, 2 July 2026 (UTC)

For athletes updates are regular and desired. They are not without problems though, from juvenile exaggeration of idols achievements, through to simple mistakes. Exactly what is a good target for edit filters and what should rely on another mechanism is not defined. The reduction in delta size seems like a good idea to me. All the best: Rich Farmbrough 10:03, 3 July 2026 (UTC).

Disable filter 960

This should be redundant since MediaWiki automatically tags these edits now. * Pppery * _{in solidarity} 17:34, 5 July 2026 (UTC)

Disabled. The new tags are 'Edited other user's JS' and 'Edited other user's CSS', seemingly from around 7 May 2026. Courtesy ping for Xaosflux who created the filter. -- zzuuzz ^(talk) 06:16, 17 July 2026 (UTC)

Not sure a tag is as robust as a log here - but also I don't think this one is being used much for actual review so likely fine. — xaosflux ^Talk 10:07, 17 July 2026 (UTC)

Use of edit filters for LTA ranges

I've noticed this discussed briefly on WP:EFFPR, but to echo User:Taking Out The Trash, why are we using edit filters to disallow edits based on IP ranges? It seems we're getting a lot of false positives, and how does this benefit over using range blocks? Lordseriouspig 08:08, 22 July 2026 (UTC)

Courtesy ping: Ohnoitsjamie Lordseriouspig 08:09, 22 July 2026 (UTC)

@Lordseriouspig: It's not wise to comment in public on private filters (for WP:NEEDTOKNOW reasons). EggRoll97 ^(talk) 17:40, 24 July 2026 (UTC)

Well we're not discussing a specific filter... this is more of a question about principle and procedure. Why are we using edit filters to outright disallow edits solely based on IP ranges in the first place? That's what a range block is for. Hard-block if necessary. Filters should be used for, y'know, filtering actual unwanted content. Basically filters should be checking against what's in the edit, not who is making the edit or where the edit is originating from. Taking Out The Trash (talk) 13:41, 26 July 2026 (UTC)

@Taking Out The Trash: IP blocks are fairly blunt instruments, even when only partial blocks are applied. Edit filters allow us a little more leeway to target bad faith behavior. EggRoll97 ^(talk) 19:23, 27 July 2026 (UTC)

Based on some of the comments seen at WP:EFFPR by EFMs, I think the filter only targets specific topics or pages from editing on IP ranges that have been used by LTAs, not all pages. --Prothe1st (leave me a message)-- 12:50, 28 July 2026 (UTC)

LTA 1365 filter

I saw that this filter was disallowing this user's edit to WP:EFFPR. I looked at Special:AbuseLog/44722676 and it doesn't look like there was anything wrong with their edit. Maybe a change to the filter needs to be made so that WP:EFFPR is exempt from this filter. --Prothe1st (leave me a message)-- 13:56, 25 July 2026 (UTC)

 Done EggRoll97 ^(talk) 02:54, 26 July 2026 (UTC)