Wikipedia:Edit filter noticeboard

    Welcome to the edit filter noticeboard
    Filter 636 — Actions: tag,warn
    Last changed at 18:48, 15 November 2025 (UTC)

    Filter 1346 — Pattern modified

    Last changed at 04:24, 11 November 2025 (UTC)

    Filter 614 — Pattern modified

    Last changed at 20:22, 10 November 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.



    WP:RSN Grokipedia

    [edit]

    I can see some sort of consensus emerging at Wikipedia:Reliable sources/Noticeboard#Grokipedia to filtering out grokipedia.com. I am not well versed of this, seems some thing technical like to me. may be some one from this board can join or take stalk of ongoing discussion at Wikipedia:Reliable sources/Noticeboard#Grokipedia and give inputs there if possible. Bookku (talk) 11:44, 29 October 2025 (UTC)[reply]

    Filters 869 and 1132 both now include Grokipedia. Note that they are not disallow filters. Daniel Quinlan (talk) 03:18, 31 October 2025 (UTC)[reply]
    @Daniel Quinlan, For sample I checked only few hits of 869 if any of those are cached 'Grokipedia', I did not any.
    Rather than checking hits in 1132 I found searching talk name space with Wikipedia search itself easier.
    a) is their any easier way to understand filters have cached which specific edits for Grokipedia. How many instances have happened so far of inserting grokipedia.com in the article namespace despite warnings?
    b) Whether any specific users who keep tracking most of these edits and I can get some feed back from them for discussing the details at WP:RSN and may be other places. Thanks. Bookku (talk) 08:07, 3 November 2025 (UTC)[reply]

    Implementation of closed RfC on extended confirmed grants

    [edit]

    I have closed WT:PP#Revised proposal to improve extended confirmed grants (initiated by Daniel Quinlan) as having a consensus. It will need implementation by edit filter people and changes to site settings requested on Phabricator. I'll leave that to y'all unless you would like anything else from me as the closer. ~ Jenson (SilverLocust 💬) 19:29, 30 October 2025 (UTC)[reply]

    Thank you. I'll be filing a ticket for point 1 which seems like it will require some code changes and I'll send an update on filter changes to the edit filter mailing list. Daniel Quinlan (talk) 19:37, 30 October 2025 (UTC)[reply]
    @Daniel Quinlan: Have you filed the phab ticket yet? If so, could you please link to it here? Thanks, – PharyngealImplosive7 (talk) 15:46, 6 November 2025 (UTC)[reply]

    Final updates to filters for temporary accounts

    [edit]

    I'm done working my way through the filter list to update filters using user_name to user_unnamed_ip for IP address conditions. This is discussed further at mw:Trust and Safety Product/Temporary Accounts/For developers. These updates did have the side effect of permanently changing some filters to protected status, but in several cases where the IP address conditions were no longer needed, I was able to make alternative changes. I also sent out some emails to EFMs about several of the somewhat more complex filters (Ohnoitsjamie, Ingenuity, King of Hearts, and Zzuuzz).

    A few additional things about non-hidden filters I noticed along the way:

    • Could 958 be merged into 1025 so we have a single WP:SIP filter?
    • Is 862 still needed? It's not hitting much these days.

    Also, I think we should consider throwing in the towel and updating 1201 and 1301 (the random sample filters) to include the IP reputation variables from 1363 as well as user_unnamed_ip. That will unfortunately make them protected filters, but 1201 and 1301 really need user_unnamed_ip to be useful. @Suffusion of Yellow: What do you think?

    Finally, please feel free to review my changes and reach out if you spot any issues (email is probably best since many are hidden filters). Daniel Quinlan (talk) 02:07, 4 November 2025 (UTC)[reply]

    (I changed my decision regarding the two sensitive IP/Congress filters.) As for filter 862, I'm fine with disabling that filter. Codename Noreste (discusscontribs) 02:10, 4 November 2025 (UTC)[reply]
    I'm having second thoughts about merging those filters because it would make something like https://bsky.app/profile/congressedits.bsky.social impossible if we combined the two tags. I also should have pinged TheresNoTime and MusikAnimal about whether 862 (hist · log) is still needed so doing that here. Daniel Quinlan (talk) 06:24, 4 November 2025 (UTC)[reply]
    In theory, hits from 1363 should have all the same variables as from 1201, plus the ip_reputation ones. So anyone with TAIV rights can just ignore 1201 and use 1363 instead. I wouldn't object to adding user_unnamed_ip to 1363, so long as we think that's in compliance with foundation:Policy:Wikimedia Access to Temporary Account IP Addresses Policy#Use of temporary account IP addresses. Suffusion of Yellow (talk) 21:35, 5 November 2025 (UTC)[reply]
    It looks like the variables are all there, but 1363 matches are a subset of 1201 right now so it's not as useful for general testing. I'd be easier if 1201 and 1301 just logged everything. We already log protected data for 26 enabled filters, adding two more filters shouldn't be an issue. If it turns out there's a need for a completely unprotected/unhidden random sample filter, we can always add one later. Regarding the policy, it's up to users to follow the policy for any use of temporary account IP address data. Daniel Quinlan (talk) 01:16, 6 November 2025 (UTC)[reply]

    Adding the abusefilter-access-protected-vars right to the temporary-account-viewer group

    [edit]

    Would adding the abusefilter-access-protected-vars right to the temporary-account-viewer (TAIV) group make sense? This would allow TAIV group members to view these filters and logs as long as they aren't hidden. Now that so many filters are using the user_unnamed_ip variable or the IP reputation variables, I'm concerned that we've restricted too many trusted anti-vandals from the information they need to be effective. I'm not sure whether the WMF will have concerns or additional requirements, but I wanted to start a discussion here before initiating a broader discussion anywhere. Daniel Quinlan (talk) 02:54, 4 November 2025 (UTC)[reply]

    We've had a similar discussion before, at Wikipedia:Edit filter noticeboard/Archive 15#TAIV and EFM/EFH rights. Besides that, I have no objection. Codename Noreste (discusscontribs) 03:01, 4 November 2025 (UTC)[reply]
    Perhaps we could start an RfC to see what the broader community thinks and also see if the WMF objects if the proposal gains support. – PharyngealImplosive7 (talk) 03:32, 4 November 2025 (UTC)[reply]
    That's basically the plan if there's general agreement here. RFCs are pretty heavyweight so it's usually best to not jump straight into one. Daniel Quinlan (talk) 06:19, 4 November 2025 (UTC)[reply]
    It's also worth noting that global temporary account IP viewers already have the proposed user right, so it makes sense to add to the local TAIV user group. Codename Noreste (discusscontribs) 19:56, 14 November 2025 (UTC)[reply]
    I suppose I have no objections, though I wouldn't say there's necessarily a lot of filters that would be accessible. Out of the currently enabled filters, only 5 (which are all tag or log-only) would become accessible to TAIV's if this were to pass. All other protected filters are private, and thus no change would occur. Again, no objections here, just seems like there wouldn't be a terribly big impact. EggRoll97 (talk) 05:15, 5 November 2025 (UTC)[reply]

    user_type condition changes to various filters

    [edit]

    Per this filter search and because temporary accounts were deployed today, there are some remaining filters whose user_type conditions should be changed to the following:

    • user_type == "ip" to user_type != "named", or a similar condition for the latter.

    This does not apply to private filter 53 (hist · log), in which I've notified Oshwah (as the filter maintainer) off-wiki. Thank you. Codename Noreste (discusscontribs) 16:30, 4 November 2025 (UTC)[reply]

    Done (except for two disabled filters and one private filter that should work fine as it is). Daniel Quinlan (talk) 17:42, 4 November 2025 (UTC)[reply]
    Well, there was an edit conflict (private filter) with PharyngealImplosive7. 🤷 Codename Noreste (discusscontribs) 17:54, 4 November 2025 (UTC)[reply]
    Yes, I saw that, but it wasn't a big deal. The comment needed to be updated, though. You'd think the system would warn you if you are saving starting from an older version than the current version when you hit the save button, but it does not. Daniel Quinlan (talk) 18:00, 4 November 2025 (UTC)[reply]
    This is when User:Suffusion of Yellow/filterDiff would come in handy. Codename Noreste (discusscontribs) 18:02, 4 November 2025 (UTC)[reply]
    Yeah, I generally just diff locally for anything non-trivial. I learned about that script shortly after I had created the other FilterDiff (which I wish I had named differently). Daniel Quinlan (talk) 21:42, 4 November 2025 (UTC)[reply]
    @Oshwah: Since it had stopped working for temporary accounts and is needed as a filter, I updated filter 53 as well (I've made some updates to it before so it was a straightforward change). Daniel Quinlan (talk) 17:49, 4 November 2025 (UTC)[reply]
    Daniel Quinlan - Ah, thank you! I meant to make that change today (I updated filter #53 on October 10 to use user_type in addition to user_editcount, since user_editcount would return neither 0 or null for temporary accounts), and just logged on to do so. I appreciate you for having my back! :-D ~Oshwah~(talk) (contribs) 00:03, 5 November 2025 (UTC)[reply]

    Filter blocking FP reports

    [edit]

    I noticed Special:AbuseLog/42658810 in the log today. Since I can't see the filter I don't know for sure what's going on, but we absolutely should not be disallowing edits to EFFPR except in extreme circumstances. This leaves no way for a genuine FP to be reported. Taking Out The Trash (talk) 18:36, 5 November 2025 (UTC)[reply]

    This was definitely a false positive, and the filter was fixed by Ohnoitsjamie recently. Codename Noreste (discusscontribs) 19:33, 5 November 2025 (UTC)[reply]
    That filter is intended to block a particular LTA; it just needed a small adjustment. OhNoitsJamie Talk 19:36, 5 November 2025 (UTC)[reply]
    I understand, but reiterating what I've said above, it was adjusted so that this specific false positive does not happen again… Codename Noreste (discusscontribs) 19:50, 5 November 2025 (UTC)[reply]