Open main menu
Welcome to the edit filter noticeboard
Filter 891 — Pattern modified
Last changed at 12:58, 16 October 2019 (UTC)

Filter 995 — Actions: none

Last changed at 21:03, 11 October 2019 (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.

New edit filter warning for filter 365Edit

Implemented as below. This NB is a fine venue for this type of request (simply changing the message on a multi-purpose filter). EFR would have been fine too. — xaosflux Talk 12:51, 18 September 2019 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I think the edit filter warning for filter 365 (hist · log), Unusual changes to featured or good content, should have a custom edit filter warning since it's catching good faith edits. My suggestion is something like , but would like some input from experienced edit filter users. --Trialpears (talk) 17:12, 7 September 2019 (UTC)
Any thoughts? Is this how you make edit requests to abuse filters? Could someone implement this? --Trialpears (talk) 08:28, 18 September 2019 (UTC)
Here is probably as good as anywhere, even if WP:EFR might be a more traditional place for requests. Edit filter people can sometimes be a bit slow unless poked. As the filter's primary author I don't really see any problem with this custom warning. I suppose the wording could be tweaked a bit about what to do next. I'd be curious about any examples of false positives. The filter usually picks up so much crap it's very difficult to spot them. -- zzuuzz (talk) 08:56, 18 September 2019 (UTC)
I've implemented the change, seeing as it was proposed in a reasonable place for 11 days with no opposition. Jo-Jo Eumerus (talk, contributions) 09:05, 18 September 2019 (UTC)
There was a good faith edit reported to WP:EFFP and that's why I wanted this change, and I wouldn't be suprised if a percent or two are good faith, could check if you really want me to. --Trialpears (talk) 12:39, 18 September 2019 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Fake/Deceptive journal journalofm.orgEdit

Please someone blacklist/EF this website per [1]. Headbomb {t · c · p · b} 13:02, 27 September 2019 (UTC)

I'm not sure I see any real problem here, but I might be missing something. EggRoll97 (talk) 04:51, 28 September 2019 (UTC)
This isn't a journal, it's Wikipedia articles reformatted in a fake journal format, so that students can link to a fake paywall site that looks legit. Read the Forbes story linked above. Headbomb {t · c · p · b} 18:25, 1 October 2019 (UTC)
  Added to the Spam blacklist. — JJMC89(T·C) 01:35, 2 October 2019 (UTC)

Unseemingly broken filtersEdit

Hello all! Due to a recent update in the AbuseFilter parser, you may be able to save a filter even though it has invalid syntax (T234339). In particular, this is affecting enwiki's filter 874; the error is pretty easy to spot, as it was introduced with this change. Could someone please fix it? Thanks, --Daimona Eaytoy (Talk) 17:43, 1 October 2019 (UTC)

@Daimona Eaytoy: for Special:AbuseFilter/874 the pattern in the description for phab:T234339 does not appear to be present. If the change is on a non-private component, would you please specify what you would like changed below? Optionally, you can drop me an email with the requested change here: Special:EmailUser/Xaosflux. — xaosflux Talk 17:55, 1 October 2019 (UTC)
@Xaosflux: Yeah, the example on phab is simplified. The filter is private, so I'm not gonna say too much. However, if you look at the edit linked above, you'll see that there's an extra + in the regexp. Hence, the regex is invalid overall. I think that you can simply remove the plus. --Daimona Eaytoy (Talk) 18:01, 1 October 2019 (UTC)
@Daimona Eaytoy: thanks for the note, think I got what you were talking about resolve here: Special:AbuseFilter/history/874/item/22371 - if not please drop me an email. — xaosflux Talk 18:09, 1 October 2019 (UTC)
@Xaosflux: Your edit is totally fine, thanks! --Daimona Eaytoy (Talk) 18:23, 1 October 2019 (UTC)

Filter 384 (Addition of bad words or other vandalism) false positivesEdit

We currently have a long standing problem of many false positives coming from filter 384 (Addition of bad words or other vandalism), mostly in song names. To combat this I suggest adding

!(added_lines rlike "\[\[[^\]]{0,10}"+bad_word+"[^\[]{0,10}\]\]")

to check if it's inside a wikilink. If some edit filter manager could add this to the test filter (filter 1) that would be appreciated. I will monitor it to see if it works like I expect it to. --Trialpears (talk) 18:50, 5 October 2019 (UTC)

Filter 380 exception for "Ass'n" as abbreviation of AssociationEdit

Could there be an exception added to Filter 380 regarding the usage of Ass'n as an abbreviation for Association? (See Wikipedia:Edit_filter/False_positives/Reports# EggRoll97 (talk) 20:25, 5 October 2019 (UTC)

Unprivate edit filter 31 (ASCII art)Edit

Should edit filter 31 (ASCII art) be public? I don't see any reason why an ASCII art filter should be private, but could be wrong since I can't actually see the filter and don't know the history behind it. --Trialpears (talk) 09:16, 7 October 2019 (UTC)

The filter does contain some elements of long term abuse, but these are probably not so relevant these days (and could be filtered in other ways). A lot of entries are just memes which have had their day, and people won't be looking to circumvent. I think I'm in favour of making it public, but would want to hear from others. -- zzuuzz (talk) 10:48, 7 October 2019 (UTC)
@Zzuuzz: I think it shouldn't be public, given the exceptions on line 60 --DannyS712 (talk) 17:56, 7 October 2019 (UTC)
OK, noted, so I won't rush into anything before hearing more opinions. But if I understand your objection correctly, you are saying that a determined vandal could fiendishly devise some ASCII art which evades the filter? I refer to my original comments and would probably disagree with your objection. -- zzuuzz (talk) 18:58, 7 October 2019 (UTC)
I think it can be made public. Most ASCII-spamming vandals aren't going to bother trying to evade the edit filter. Reaper Eternal (talk) 19:32, 7 October 2019 (UTC)

Special:AbuseFilter/891 (ResearchGate)Edit

Someone added ResearchGate doi's to the edit filter. That's rather overkill to lump those in the 'predatory journal' edit filter, especially without explanation.

If those are warranted in an edit filter, the warning it throws should at least warn that papers with ResearchGate dois are possibly (likely?) not peer-reviewed and might not be suitable as a reference. Headbomb {t · c · p · b} 19:50, 31 August 2019 (UTC)

Or rather, it should be split into a new filter, for "potential unreliable sources" with a priority lowered to "tag", rather than warn. Headbomb {t · c · p · b} 15:24, 1 September 2019 (UTC)
@Crow:, could you remove 10.13140 from this one. It's already in Special:AbuseFilter/1003. Likewise for removing frontiers\.in which pretty much does nothing since there's no such website. Also acacdemicjournals should be academicjournals. Headbomb {t · c · p · b} 21:50, 9 September 2019 (UTC)

De-archived as unresolved. Headbomb {t · c · p · b} 19:03, 7 October 2019 (UTC)

  1. Remove 10.13140 since RG isn't predatory, and should be/is handled by Special:AbuseFilter/1003 instead
      Done Guy (help!) 11:43, 16 October 2019 (UTC)
  2. Remove frontiers\.in since that's not a domain in use for anything, and the likely intended target Frontiers Media is way too borderline to be covered by such a filter.
  Done#Fix acacdemicjournals to academicjournals
Headbomb {t · c · p · b} 19:13, 7 October 2019 (UTC)
@Xaosflux: could you take a look at this, since Crow seems to be on a break? Headbomb {t · c · p · b} 04:55, 16 October 2019 (UTC)
  • 3 done. — xaosflux Talk 11:08, 16 October 2019 (UTC)
  • Ping to @JzG: regarding other changes. — xaosflux Talk 11:09, 16 October 2019 (UTC)

Add exception to edit filter 890 for account creatorsEdit

Frood recently reported the following false positive at WP:EFFP/R and I'm moving it here to attract more attention for edit filter managers. The following is a direct copy of their second report after the first one got archived:

Previous post was archived before anything actually happened with the filter. Attempting to create an account for WP:ACC (request #261368) and filter 890 is preventing me from doing so. I'm in the accountcreator group and have chosen to override both spoofing and title blacklist checks. The username, while seemingly random, does appear to be legitimate based on some researching I've done prior to trying to make the account. The filter looks like it has an exemption for users with override-antispoof, but only for automatically-created accounts (which isn't the case for ACC).
I'm not super familiar with how the EF syntax works, but I think it'd have to turn into something like:
   (action == 'createaccount' | action == 'autocreateaccount') &
   !('override-antispoof' in user_rights)
) &
lcase(accountname) rlike "[bcdfghjklmnpqrstvwxz]{9}"

--Trialpears (talk) 15:12, 9 October 2019 (UTC)

Log of denial is here. — xaosflux Talk 15:31, 9 October 2019 (UTC)
Ping for @MusikAnimal:.[2] I don't really understand why this change would have been done. -- zzuuzz (talk) 15:46, 9 October 2019 (UTC)
@Zzuuzz: phab:T230256. Basically user_rights doesn't exist for the 'createaccount' action anymore. This means that check would fail because the variable is undefined. But I realize now that is only true when creating your own account for the first time, when you do not have any user rights. Using Special:CreateAccount while logged in would mean that user_rights is defined. I suppose we need to somehow check that user_rights is defined before running comparisons on it, regardless of the action? This may be a bug with AbuseFilter. Pinging Daimona Eaytoy for input. MusikAnimal talk 05:15, 10 October 2019 (UTC)
Exactly. There's some rationale on phab about that. Basically, until a few weeks ago, all unset variables were just null. This means that you can create shorter filters, but sometimes they'll be unpredictable (a recycled example: edit_delta < -50000 would match *all* actions !== edit). Hence, I had changed the AF parser to assign unset variables a "special" value; such value consistently makes any expression containing those variables return false, hence some filters stopped working. I then realized that way too many filters were relying on this kind of shorthands; hence, I decided to switch back to the old behaviour (i.e. use NULL). The patch for that is still under review, though. --Daimona Eaytoy (Talk) 12:41, 10 October 2019 (UTC)

───────────────────────── This seems to work, and should continue to work once the change is reverted:

action == "createaccount" & /* Or action contains "createaccount" if we really want to stop autocreations... */
    user_rights ?
        !('override-antispoof' in user_rights) :
) &
lcase(accountname) rlike "[bcdfghjklmnpqrstvwxz]{9}"

Daimona Eaytoy, is this the "right" way to check if a variable is defined before using it? Seems strange that !foo | ("bar" in foo) doesn't work, but foo ? ("bar" in foo) : true does, when they seem logically equivalent. Even weirder, !foo ? true : ("bar" in foo) doesn't work either. Suffusion of Yellow (talk) 20:12, 14 October 2019 (UTC)

There's no "right" way, but usually it should be enough to check action. However, sometimes (like in this case) it's not enough. That's why I wanted to add an is_set(varname) function, but that's under review as well. The behaviour is weird due to the very special way that unset variables are treated. As an alternative you could use var === var; if the variable is unset, it will return false. --Daimona Eaytoy (Talk) 12:19, 15 October 2019 (UTC)

RfC proposing a new filterEdit

Would an uninvolved edit filter manager please assess the discussion at Wikipedia:Village pump (proposals)/Archive 161#RFC: Block edits that contain a VisualEditor bug and determine if a new filter should be created to disallow the specified edits? A close was requested at Wikipedia:Administrators' noticeboard/Requests for closure#Wikipedia:Village pump (proposals)/Archive 161#RFC: Block edits that contain a VisualEditor bug but since the result may require editing a filter, it should be closed by someone with the ability to do so, so cross-posting here for more visibility. Thanks, --DannyS712 (talk) 01:34, 15 October 2019 (UTC)

@GreenC: as you opened that. There is general support to prevent these bad edits, though part of the discussion suggests that it was due to a bug that has since been resolved. Is this issue still occurring? Can you provide a recent example of the bad edit? — xaosflux Talk 02:46, 15 October 2019 (UTC)
@ESanders (WMF): says the bug is probably fixed. Determining has proven difficult because it requires knowledge of what actions editors took and when I ask them (admittedly I only asked two) they don't respond or don't remember. And it's been difficult to show unambiguously the text was caused by the bug and not old data/sessions that contained copies. If the bug has truly been fixed it doesn't make sense to add the filter. But edits like this by an editor who has only ever made a single edit to Wikipedia are spooky, it suggests the bug still occasionally occurs, in which case the edit filter would make sense. What do you think ESanders? -- GreenC 03:58, 15 October 2019 (UTC)
Suggest that this is a "log and warn" only filter at least for a while, but the warning would need to be useful to the editor. — xaosflux Talk 11:48, 15 October 2019 (UTC)
@Xaosflux: Not sure how filters work but can it point to Template:Warning VisualEditor bug? -- GreenC 02:40, 16 October 2019 (UTC)
@GreenC: yes, they can use templates, and they can use custom markup as well; we generally have a few standard layouts - and then any custom verbiage, each filter can have its own message, it should be whatever will be most useful to the person making the edit. An example of one can be seen here: MediaWiki:Abusefilter-warning-ref-group-blanking. — xaosflux Talk 02:46, 16 October 2019 (UTC)