Wikipedia:Edit filter noticeboard

Jump to navigation Jump to search
Welcome to the edit filter noticeboard
Filter 1069 (deleted) — Actions: none; Flags: disabled
Last changed at 22:36, 1 July 2020 (UTC)

Filter 1063 — Flags: disabled

Last changed at 22:14, 1 July 2020 (UTC)

Filter 1072 (new) — Actions: none; Flags: enabled,private; Pattern modified

Last changed at 22:08, 1 July 2020 (UTC)

Filter 1071 (new) — Actions: tag; Flags: public; Pattern modified

Last changed at 15:19, 1 July 2020 (UTC)

Filter 891 — Pattern modified

Last changed at 18:58, 27 June 2020 (UTC)

Filter 1062 (deleted) — Flags: disabled

Last changed at 19:38, 27 June 2020 (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, 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.

Click here to start a new discussion thread

Disallow empty edit requests[edit]

Moved from WP:EFR: ~ ToBeFree (talk) 04:04, 1 June 2020 (UTC)
  • Task: Warn or disallow unregistered and new users from dropping an empty edit request on a talk page.
  • Reason: From a repeated WP:RFPP request to semiprotect Talk:TikTok where a pattern of various IPs with no pattern have been leaving multiple edit requests, leading to the talk page having been protected several times for up to a month, however I've observed similar behaviour on many pages over time. A user saving an edit with the content of Template:Submit an edit request/preload unmodified should trigger the filter, if it's possible to code a filter to do that. Preventing this specific edit would be more useful than whack-a-mole protections. Ivanvector (Talk/Edits) 17:09, 31 May 2020 (UTC)
  • It should be able to do that. We'd probably want a custom message displayed rather than the generic "your edit was unconstructive" for good faith edits of that sort. CrowCaw 18:23, 31 May 2020 (UTC)
This is a recurrent time-wasting problem at many other pages too. To avoid people just typing a random letter to circumvent this, maybe there should also be a minimal number of characters in the edit request – I don't know the exact number, a minimal valid request would be something like "Fix the typo in [word]" (16 + [word]); maybe like 20 or if we want to be even more lenient 10. Cheers. RandomCanadian (talk / contribs) 18:38, 31 May 2020 (UTC)
I don't think this activity is malicious, I think it's just not following instructions, possibly by non-English editors. I'd like to see how much of it goes away if just saving the default unmodified template is flagged or disallowed, before we talk about expanding the criteria. Ivanvector (Talk/Edits) 18:47, 31 May 2020 (UTC)
It's definitely not malicious. It's just like we regularly get non-native speakers posting their CVs at (ironically, but not accidentally) WP:AUTOBIO -- there's something about the instructions that people misunderstand. EEng 06:19, 1 June 2020 (UTC)
Altering {{Protected page text}} to offer a nice big green inviting button to take the user back to the parent page might reduce the occurrence of this error.
Altering "Cancel" across the wiki so it's a white-on-red button of equal prominence to "Publish changes" rather than a redlink may also help, not only for this problem, but in maintaining the consistent meaning of redlinks.
If this is the route by which editors are hitting this problem then, I'd say editors clicking on View source to take a look under the bonnet are at the more technically curious end of the spectrum and would be better served by an edit-filter rejection rather than a talk page message memorialising their mistake. Just my 2¢, Cabayi (talk) 07:54, 1 June 2020 (UTC)
@Cabayi: I'd be in favour of the change to {{Protected page text}}, and also in favour of disallowing empty edit requests through the edit filter. It's silly to make actual users review them, and just a waste of time overall - but of course, many people will, as you rightly point out, not be making them deliberately. This seems like a good approach to tackle the issue. Naypta ☺ | ✉ talk page | 14:30, 8 June 2020 (UTC)
  • Just a quick note that because this filter would be disallowing good faith edits in other areas of the encyclopedia, it would require community consensus before implementation per WP:EF. Sam Walton (talk) 10:31, 1 June 2020 (UTC)
  • Looks like we may need to disallow empty edit filter requests while we're at it [1]. EEng 19:02, 2 June 2020 (UTC)

This still happens. The IP here seems to have added a bunch of whitespace to evade the edit filter, while still typing a perfectly empty edit request... RandomCanadian (talk / contribs) 03:43, 8 June 2020 (UTC) Missed a few . RandomCanadian (talk / contribs) 03:45, 8 June 2020 (UTC)

@RandomCanadian: Nope - Special:AbuseLog/26948207 shows that the edit filter was tripped. Filing the BRFA now DannyS712 (talk) 03:46, 8 June 2020 (UTC)
@DannyS712:: oh, my bad, I thought it had already been enabled... trout Self-trout RandomCanadian (talk / contribs) 03:47, 8 June 2020 (UTC)

BRFA filed[edit]

Please see Wikipedia:Bots/Requests for approval/DannyS712 bot 71, where I request approval to revert the empty edit requests with an informative summary --DannyS712 (talk) 03:53, 8 June 2020 (UTC)

I'm putting the above on hold until the original discussion decides what to do - if the consensus is to just not allow blank edit requests in the first place, this bot is rather pointless. Primefac (talk) 14:09, 8 June 2020 (UTC)
Could we have the filter changed to disallow, as promised? This, or any of the other recent hits, doesn't look like a false positive to me... RandomCanadian (talk / contribs) 12:40, 17 June 2020 (UTC)
Disallow would be better than revert, also remember the disallow message can be changed to something custom. One of the reasons for these empty requests may be that people think "edit request" means requesting the ability to edit the page, so it can be clarified to "request someone else make the edit you want". Naleksuh (talk) 16:55, 23 June 2020 (UTC)

Gaining EFH[edit]


I am interested in potentially gaining the Edit Filter Helper right, because I would find the private filters useful for uprooting sockpuppets of long-term abusers and identifying automated spam, which I already have some experience with and enjoy doing. I am not making a formal request yet because I doubt I'd succeed; can anybody look through my contributions and tell me what I need to do next if I want to gain this right?

Thank you,

Passengerpigeon (talk) 03:04, 13 June 2020 (UTC)

  • There really isn't a list of steps one takes to warrant the permission; the official criteria is Having a Need, which is somewhat (and purposefully?) vague. EFH isn't like Rollback or NPP, where it is given unless there's reason not to, but rather it is not given unless you really need it. The criteria I use is: when NOT having EFH is hindering your (or EFM's) work. Again that's a bit vague and hard to specifically define, but as Justice Stewart said, "I know it when I see it". CrowCaw 16:12, 13 June 2020 (UTC)

"Hide details of this filter from public view" checked by default[edit]

Several people (including myself) on itwiki said that they would prefer the "Hide details of this filter from public view" option checked by default on Special:AbuseFilter/new. That's because it's quite easy to forget hiding a filter, which in turn could be potentially risky. I'd like to make this the default in the AbuseFilter code. However, I first want to hear some additional opinions about this. Would you be OK with this change? Is there a specific reason for keeping the option unchecked by default? Thanks, --Daimona Eaytoy (Talk) 11:55, 16 June 2020 (UTC)

It's a yes from me. -- zzuuzz (talk) 12:43, 16 June 2020 (UTC)
@Daimona Eaytoy: on enwiki, I don't think it will be an issue one way or other, however on small projects it might be a bad idea - they may have very little admins that touch EF's, and they may not be very active on the project. This could lead them to making private filters that don't really need to be private and making it harder for the rest of those communities to figure out what it going on in what is effectively a block. — xaosflux Talk 13:55, 16 June 2020 (UTC)
There is that. Maybe it could go in a $wgAbuseFilter variable, with the WMF default set to public (except enwiki, itwiki, and whichever others). After all there's nothing to stop them making all filters private anyway. I also suspect some non-WMF wikis might prefer filters to be private. -- zzuuzz (talk) 14:02, 16 June 2020 (UTC)
@Xaosflux: Thanks for bringing this up. I'd like to wait for more opinions, but now I see that there might be drawbacks in making the option checked by default. Of note, @Zzuuzz:, I don't really want to add a config variable for that -- it seems a bit of an overkill (although I don't feel strongly about that). The alternative would be to create a JS gadget (hidden+enabled) like this. --Daimona Eaytoy (Talk) 14:36, 16 June 2020 (UTC)

Is there a filter already for common vandal terms?[edit]

Such as references to human excrements or common insults? I wouldn't want to file a request for such an edit filter if it (surely?) already exists. RandomCanadian (talk / contribs) 19:37, 16 June 2020 (UTC)

Actually we have a dedicated 'poop' filter 46 (hist · log). Filter 39 deals with some common vandalism to university articles. We also have a few for common vandalism (maybe 260 and 384). The thing I would say is that it's not generally possible to predict every typo or variation, nor to do so without false positives, and rare cases are often not worth coding for. -- zzuuzz (talk) 03:52, 17 June 2020 (UTC)
@Zzuuzz: The fact is neither of those are typos; the first one has an explicit "poop" (along with vandalism/removal of a few lines from the infobox, which deserves a filter if it doesn't already have one) and the other one has "stupid" too... Maybe presence or absence of whitespace before or after the vandal words should be ignored if it isn't already? RandomCanadian (talk / contribs) 12:44, 17 June 2020 (UTC)
RandomCanadian, there is a poop filter linked above 46. But it didn't catch that edit you linked, because the filter uses a word boundary (the 'poop' in your example wasn't a separate word, but was combined into the existing one - "Bathurpoop"). ProcrastinatingReader (talk) 13:26, 17 June 2020 (UTC)
So then maybe the word boundary should be removed, as I suggested (i.e. 'presence or absence of whitespace...'). RandomCanadian (talk / contribs) 13:30, 17 June 2020 (UTC)
RandomCanadian, filter 46 is a block, so there's an aversion to causing false positives. Removing the word boundary would cause things like Special:Diff/712389476 and Special:Diff/615223933 to be blocked, not to mention changes to articles like Tales from the Poop Deck, Flush!: The Scoop on Poop Throughout the Ages, Perl Object-Oriented Persistence, Honaunau-Napoopoo, Hawaii (or references to said articles). ProcrastinatingReader (talk) 13:52, 17 June 2020 (UTC)
Wasn't there an exemption that if "poop" is already in the old wikitext it should be allowed/whitelisted (at least that's what I get from reading the comments)? In any case, what I'm pointing at is that if the current filter doesn't deal well with word boundaries, then those should at least be tagged via a filter leaving a description such as the "possible vandalism" or the like (with of course exemptions for autoconfirmed users, which looks like it is already coded in). RandomCanadian (talk / contribs) 19:11, 17 June 2020 (UTC)
To add to what zzuuzz said, there is also 189 which catches a lot to do with BLPs. ProcrastinatingReader (talk) 13:17, 17 June 2020 (UTC)
Is there a specific reason why those filters are limited to only a subset of articles? I understand that you might want to have dedicated filters for BLPs, but adding 'poop' is vandalism in 99% of cases, in any kind of mainspace article. RandomCanadian (talk / contribs) 13:25, 17 June 2020 (UTC)
RandomCanadian, just to clarify, 189 isn't for poop, it's for other vandal terms. The filter that deals with poop is 46, and that one applies to all pages in the article namespace. ProcrastinatingReader (talk) 13:29, 17 June 2020 (UTC)

Deferred Changes[edit]

I've created a section on Wikipedia:Village pump (technical) regarding deferred changes - a method to allow edit filters (and bots and ORES) to put edits into a queue for manual review.

Would appreciate your thoughts: Deferred Changes

Thanks, ProcrastinatingReader (talk) 19:30, 17 June 2020 (UTC)

Filter 1067[edit]

Hey folks, I've created 1067 (hist · log) (private because LTA filter), designed to catch a particular recurring LTA. It was successful during private filter testing, 0 false positives and caught a number of the LTA's accounts, so I'm wondering what to do next:

  • Is it worth setting to disallow? This particular LTA doesn't seem particularly creative, but I know that disallowing usually just causes an LTA to change their pattern.
  • If not disallow, should I tag? The edit filter isn't terribly helpful when private unless non-EFHs/EFMs can't see the output.
  • Since this LTA is posting what appears to be somebody's personal information, their contributions usually get oversighted. Do we have any procedures for a filter to have its hits cleared out by an oversighter on a recurring basis? (that's also why you can't see any hits in my test filter; they all got the OS treatment)

GeneralNotability (talk) 19:38, 17 June 2020 (UTC)

Probably worth adding to this list to have DatBot report hits to AIV. If you really don't want the LTA to know about it, you could potentially leave it at that. Hopefully the admin who catches it at AIV would recognise the need to report it to the oversight team. HJ Mitchell | Penny for your thoughts? 19:44, 17 June 2020 (UTC)
Neat, forgot about DatBot. Added to the list. GeneralNotability (talk) 20:08, 17 June 2020 (UTC)
  • Perhaps User:DatGuy could add a condition to DatBot for this kind of thing, so the AIV report includes a request to revdel immediately, and notify oversight to suppress it entirely? CrowCaw 13:19, 18 June 2020 (UTC)
I'll try to overhaul the /filters subpage soon. Any suggestions other than adding notes? Regarding "notify oversight," do you mean through Special:EmailUser/Oversight? Dat GuyTalkContribs 21:35, 18 June 2020 (UTC)

Unreliable ancestry sites[edit]

These two sites have been agreed to be unreliable for a long time, but are still being added. I propose to build a filter thus:

equals_to_any(page_namespace, 0, 118) &
    deprecated := "\b((freepages|lists|mailinglists|wc)\.rootsweb\.com|ancestry\.com/(family\-tree|boards)|genealogy\.euweb\.cz)";
    added_lines irlike deprecated &
    !("bot" in user_groups) &
    !(removed_lines irlike deprecated) &
    !(summary irlike "^(Revert|rv|Undid)")

The eventual intent is to:

  1. initially warn and check logs, then
  2. enforce blocking of addition to mainspace, but
  3. allow addition to other spaces (both sites may themselves cite reliable sources so may be appropriate for discussion)

I would exclude the article on

Thoughts? Guy (help!) 13:36, 19 June 2020 (UTC) hosts numerous vital records and other valuable primary sources which can benefit articles as references or external links in some cases. It's not exactly accurate to say that the "site" is unreliable. I would not want to see a filter that automatically blocks everything on I would support blocking any user generated content though, which I believe is the intent here? The other sites are less of a concern (to me). - MrX 🖋 18:51, 19 June 2020 (UTC)

Unprivate filter 34 (New or unregistered user blanking someone else's user or user talk page)?[edit]

Should edit filter 34 be public? I don't see a reason why this filter is meant to be private. I doubt it is specifically for any LTA accounts, and it is not that much different than filters 3, 30 and 33 in terms of blanking pages (all three filters are public). The only real difference is that it deals with user/user talk pages. Train of Knowledge (Talk) 07:06, 21 June 2020 (UTC)

There was a prior discussion about this in May. That filter still has a few details that appear to be targetting past vandalism and I argue that it's worth keeping Filter 34 private. More details in the prior thread. EdJohnston (talk) 13:51, 21 June 2020 (UTC)

1069 to disallow[edit]

1069 (hist · log)

Ongoing BLP concerns. Opting for a filter over semi-protection as we're probably gonna get some other updates to the article soon, in light of ongoing events. I'm not super-attached to that, though, so everyone should feel free to semi if they think it's necessary. (Log-only at the moment, will set it to disallow soon.) Enterprisey (talk!) 07:49, 24 June 2020 (UTC)

@Enterprisey For those unfamiliar with the article, would you be willing to explain the context in the notes? DannyS712 (talk) 07:57, 24 June 2020 (UTC)
Absolutely. Should have done that in the first place, thanks for the reminder. Enterprisey (talk!) 07:59, 24 June 2020 (UTC)


User:Sandbox's page ID has changed. (talk) 21:39, 25 June 2020 (UTC)

Nice catch. Yes, it was deleted by @HickoryOughtShirt?4 and then recreated, resulting in a new page id. Its now <code>63640560</code> - can an EFM please update line 9 of the filter? DannyS712 (talk) 22:42, 25 June 2020 (UTC)
Sorry, what did I do? HickoryOughtShirt?4 (talk) 22:47, 25 June 2020 (UTC)
@HickoryOughtShirt?4 you deleted User:Sandbox - see Special:Redirect/logid/107226677 DannyS712 (talk) 22:59, 25 June 2020 (UTC)
Done. GeneralNotability (talk) 23:10, 25 June 2020 (UTC)

Proposing we set 1071 to disallow[edit]

1071 (hist · log) Changed link from 1069 to 1071. {{reply to|Can I Log In}}'s talk page! 05:46, 2 July 2020 (UTC)

Not seeing any false positives lately, and the edits just keep coming... Pinging Zzuuzz, who made it. Enterprisey (talk!) 22:37, 1 July 2020 (UTC)

Did you mean 1071? :) I agree there's no real false positives. However, the vast majority of this vandalism is not and cannot be detected by this filter, so disallowing will have a negligible effect. It is more of a canary in a coal mine. In some senses, as long as this vandalism is in 'raid mode', it is best to let a page get plastered with vandalism so it can be sooner semi-protected. IMO. However the pace of vandalism is changing, and I'm on a wikibreak, so I'll leave the decision to disallow to others. -- zzuuzz (talk) 22:48, 1 July 2020 (UTC)
  • ZERO false positives! It's very infrequent so I wouldn't imagine a swarm of false positive reports if it's set to disallow; since it's trolling vandalism, not every vandal fighter is going to RBI. Now public or private? It's possible you may have to switch it to private. {{reply to|Can I Log In}}'s talk page! 05:46, 2 July 2020 (UTC)