I just tried to create a page in the mediawiki talk namespace on arwiki to explain T229888, and was prevented.
The filter: https://ar.wikipedia.org/wiki/%D8%AE%D8%A7%D8%B5:%D9%85%D8%B1%D8%B4%D8%AD_%D8%A7%D9%84%D8%A5%D8%B3%D8%A7%D8%A1%D8%A9/130
It includes (article_namespace == 3 | article_namespace == 2)
The details of my edit:
https://ar.wikipedia.org/wiki/%D8%AE%D8%A7%D8%B5:%D8%B3%D8%AC%D9%84_%D8%A7%D9%84%D8%A5%D8%B3%D8%A7%D8%A1%D8%A9/2790626
It includes page_namespace as 9
However deprecated variables are supported, this seems to have short circuited the namespace filter.
Description
Description
Related Objects
Related Objects
Event Timeline
Comment Actions
As an aside, and out of the scope of this task: @Daimona when, fi ever, will support for the deprecated variables be removed? I know that first they should be replaced with current variables, a process that even enwiki hasn't completed, but eventually they should be fully remove.
Comment Actions
While the filter shouldn't have matched, and the page namespace is a clear indicator of that, it doesn't seem to be caused by deprecated variable names. Moreover, I cannot reproduce locally, and examinating your edit on arwiki says it doesn't match. However, arwiki filter 130 is one of those affected by the DNONE issue at T214674, which we fixed a few hours ago. It could indeed have caused the filter to randomly match, although as I said I cannot reproduce locally with an old version of AF. Could you please try again, on arwiki, with an edit similar to the one you linked?
Comment Actions
I forgot to answer. I don't think we'll ever be able to remove support for deprecated variables. There are too many filters using them, also outside of WMF wikis, and dropping support would mean that those filters stop working. We could start being more aggressive, i.e. prevent filter save if it contains deprecated variables, but keep it working. Or maybe add a maintenance script to mass-edit all filters. But I don't think it's really worth it to do that, especially in the short term.
Comment Actions
Well, in the long term, this would be a great use case for https://meta.wikimedia.org/wiki/Requests_for_comment/Creating_abusefilter-manager_global_group, right? Isn't this exactly the technical kind of edit that would be in the scope of the group?
Comment Actions
Yes, and no. This kind of edit wouldn't be that urgent, so I'm unsure whether it should be included in the scope of the group. At any rate, it'd be super boring to fix all deprecated variables across all wikis :-)
Comment Actions
Aye, I managed to reproduce this locally. As expected, it was caused by the DNONE issue described in T214674, due to the fact that arwiki's 130 was one of the affected filters. And the problem was indeed fixed by https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AbuseFilter/+/527520/. But actually, the problem was first fixed in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AbuseFilter/+/526276/ (included in wmf.16). For some reason, this patch wasn't in production on Aug 5th (we've experienced this "bad sync" problem at least twice in the linked task), and thus the filter matched your edit. If I download wmf.16 and remove the revert, then I can hit the filter with an edit identical to yours, on NS 9.