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 1230 (deleted) — Flags: disabled

Last changed at 01:53, 2 June 2026 (UTC)

Filter 631 — Pattern modified

Last changed at 20:49, 31 May 2026 (UTC)

Filter 1300 — Pattern modified

Last changed at 21:58, 31 May 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 368 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

Filter 1393

Filter 1,393 "Publifye sourcing" was created five months ago with the goal of warning editors about citing AI-generated sources (in this case, books published by Publifye per this discussion, per consensus). During this test run, it caught a few edits, which I have fixed and warned the editors about. A slight modification might be warranted as to not warn for edits where the citation was already present in the previous edit. Other than that, I think this filter is ready to be activated. Kovcszaln6 (talk) 16:58, 20 May 2026 (UTC)

I made some updates to the filter including your suggested modification. @EggRoll97: What do you think about merging this into 894 instead of it being a separate filter? We could broaden the description to something like "Self-published or AI-generated source" and update the warning template. The main reason is because the new filter has only matched 9 times. Daniel Quinlan (talk) 22:45, 22 May 2026 (UTC)

No issues here with that approach, Daniel Quinlan. EggRoll97 ^(talk) 04:28, 23 May 2026 (UTC)

 Done. @Kovcszaln6: Publifye is part of 894 now. Daniel Quinlan (talk) 06:40, 23 May 2026 (UTC)

Thank you. Kovcszaln6 (talk) 15:22, 23 May 2026 (UTC)

@Kovcszaln6: After all of that, I decided against merging with 894 because it seemed better to use a different tag for these edits. The new filter is now at 893 and it will also tag any edits that proceed after the warning with the new "AI-generated source" tag. Daniel Quinlan (talk) 21:59, 23 May 2026 (UTC)

The user rights abusefilter-modify-restricted and abusefilter-revert

Proposed configuration

case 'enwiki':
	$wgGroupPermissions['*']['abusefilter-log-detail'] = true;
	$wgGroupPermissions['abusefilter']['abusefilter-modify'] = true;
	$wgGroupPermissions['abusefilter']['abusefilter-modify-restricted'] = true; // T405999
	$wgGroupPermissions['abusefilter']['abusefilter-revert'] = true;
	$wgGroupPermissions['abusefilter']['changetags'] = true; // T97013
	$wgGroupPermissions['abusefilter']['managechangetags'] = true; // T141847
	$wgGroupPermissions['abusefilter-helper']['abusefilter-view-private'] = true; // T175684
	$wgGroupPermissions['sysop']['abusefilter-modify'] = false;
	$wgGroupPermissions['sysop']['abusefilter-modify-restricted'] = false;
	break;

Currently, the user right abusefilter-revert is only granted to administrators, but without the edit filter manager permission, they solely have read-only access to all edit filters on this project, and I'm unsure if they need the right to revert an action from an edit filter (without the edit filter manager permission). Thus, I would like to propose moving abusefilter-revert from administrators to edit filter managers, as EFMs have the trust to access the edit filter interface.

On a side note, administrators have abusefilter-modify-restricted by default, but what is the point of them having that user right if they only have read-only access without the EFM toolkit? We might have to consider removing abusefilter-modify-restricted from administrators per my reasoning above.

Thoughts? Codename Noreste (talk • contribs) 17:09, 28 May 2026 (UTC)

All of the suggested changes make sense to me. Although, I'd imagine that removing the abusefilter-modify-restricted right from admins would require a broader discussion at the village pump. Not sure though. — 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 17:38, 28 May 2026 (UTC)

These changes also all make sense to me as well. We might also want to couple this change with another change to the configuration that allows non-admin EFMs to edit pages starting with Mediawiki:Abusefilter, but as far as I understand, that would require more substantial code changes. – PharyngealImplosive7 (talk) 01:38, 29 May 2026 (UTC)

• It's not clear to me what, in practical terms, the net impact of these proposed changes will be? What can non EFM-admins do/not do now that they will/won't be able to do if this is implemented? Thryduulf (talk) 16:09, 30 May 2026 (UTC)

  My proposal above is that non-admin EFMs will have abusefilter-revert to revert an action from an edit filter, and admins who are not edit filter managers will probably not encounter a difference, since they only have read-only access (they cannot modify edit filters by default without the EFM permission). Codename Noreste (talk • contribs) 17:57, 30 May 2026 (UTC)

Are there examples of this being an issue? Daniel Quinlan (talk) 03:16, 31 May 2026 (UTC)

I don't think the current configuration here is an issue. The AF revert function is really never used, and I don't think anyone's going to be leaping to use it even if it's assigned to non-admin EFMs. I also see no real reason to fix the redundancy in the restricted right being assigned to admins and EFMs. At the current time, why not just leave it be? It doesn't appear to be harming much. EggRoll97 ^(talk) 07:23, 31 May 2026 (UTC)

Alternatively, how about we discontinue abusefilter-revert from admins (per your reasoning above), and I'd leave abusefilter-modify-restricted as is to admins? Codename Noreste (talk • contribs) 22:25, 2 June 2026 (UTC)

Possibly relevant discussion at the village pump

See this discussion on adding abusefilter-bypass-blocked-external-domains and sboveride to the admin user group. – PharyngealImplosive7 (talk) 03:21, 30 May 2026 (UTC)

Adding a warning to filter 631

Filter 631 (hist · log) tags edits with extraneous toolbar markup like '''Bold text''' and empty reference tags. Virtually all of these edits have to be cleaned up or reverted afterwards so I'd like to add a warning to this filter. Given that ~63% of hits include empty references and ~28% of hits include '''Bold text''' or ''Italic text'', those mistakes would definitely be mentioned prominently in the warning message, but it should also cover attempted vandalism cases because a very high proportion of these edits are blatant vandalism.

As some additional context, I recently added '''Bold text''' and ''Italic text'' to 1294 (hist · log) because they are common in vandalism, but I think it might be better to try to reduce the number of these edits in 631. And I'm looking into revising that part of the 1294 regex to focus more so on "toolbar smashing" vandalism.

@MusikAnimal, Zzuuzz, and Suffusion of Yellow: Pinging you as EFMs who have worked on this filter previously. Thanks. Daniel Quinlan (talk) 20:36, 30 May 2026 (UTC)

Filter 1300 (hist · log) warns for edits which only add extraneous toolbar markup. Out of principle, I don't think we should be warning people who add stuff like <ref></ref>https://nytimes.com/a.perfectly.valid.source.html. That's the sort of the thing that can be easily fixed afterwards, and I'd rather they just click "Publish" than be scared off. Suffusion of Yellow (talk) 19:49, 31 May 2026 (UTC)

@Suffusion of Yellow: I share that general concern so I wanted to raise it here before making any changes. I'll leave it as a tagging-only filter and focus on identifying the subset of 631 matches that are blatant vandalism and handling those in 1294 or another filter.

I also updated 631 and 1300 to include namespaces 4, 10, 12, 14, and 118 (excluding sandboxes) and made some other minor improvements. I tested the changes on the entire 1201 log which also yielded a false positive case for 1300: someone adding valid ref tags in addition to empty ref tags (now fixed). I'll keep an eye on the filters over the next few days. Thanks! Daniel Quinlan (talk) 22:04, 31 May 2026 (UTC)

Allowing non-admin EFMs to edit MediaWiki pages

Tracked in Phabricator
Task T43838

I'm wondering whether it would be worth it to allow non-admin EFMs to create and edit MediaWiki pages, specifically pages beginning with MediaWiki:Abusefilter, so that they could manage edit filter warnings and disallow messages. However, I'm not sure how easy this would be to implement without requiring significant changes to the enwiki configuration. With that in mind, do you think this would be a worthwhile change to pursue, or would it require too much work to implement? – PharyngealImplosive7 (talk) 03:57, 31 May 2026 (UTC)

This thought has crossed my mind before, though I will note that the MediaWiki interface is locked to those with the editinterface right, and that confers the entirety of the MediaWiki interface. It would be useful to create custom filter warning and disallow messages, as I've had to do an edit request for at least a couple times, though I'm not sure if the broader community would support non-admin EFMs being able to edit the broader MediaWiki namespace (It does not, of course, contain access to MediaWiki:Common.css or MediaWiki:Common.js, those are locked to interface administrators). EggRoll97 ^(talk) 07:26, 31 May 2026 (UTC)