Page MenuHomePhabricator

added_lines does not work in AbuseFilter, need to use to new_wikitext
Closed, DeclinedPublic


For some unknown reason The rules that I copy from wikipedia do not work in my wiki.

!("bot" in user_groups) & !("sysop" in user_groups) & action == "edit" &
(article_namespace == 0) &
(count("[[", added_lines) != count("]]", added_lines) &
count("[", added_lines) != count("]", added_lines) |
(("[[]" in added_lines) | ("[]]" in added_lines)))

this rule still working in zh ver wikipedia but not in my wiki

MediaWiki 1.20.3
PHP 5.4.9 (fpm-fcgi)
MySQL 5.5.28-debug

We have to replace added_lines to new_wikitext. Any idea about why this happen?

!("sysop" in user_groups) & action == "edit" &
(article_namespace == 0) &
(count("[[", new_wikitext) != count("]]", new_wikitext) &
count("[", new_wikitext) != count("]", new_wikitext) |
(("[[]" in new_wikitext) | ("[]]" in new_wikitext)))

Version: REL1_20-branch
Severity: trivial



Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 22 2014, 1:36 AM
bzimport added a project: AbuseFilter.
bzimport set Reference to bz46404.
bzimport added a subscriber: Unknown Object (MLST).
Zoglun created this task.Mar 21 2013, 6:15 AM

Just to make sure, you use the 1.20 branch of AbuseFilter?

yes, 1.20 latest stable version.

I think it worked for me..

I edited a page with '[abc' and the filter was hit.

(In reply to comment #3)

I think it worked for me..

I edited a page with '[abc' and the filter was hit.

So what is your PHP version?

Today I tried to disable all the extensions expect abusefilter. I tried 120 stable and newest version, none of then work in my wiki(actually none of them able to use added_lines)So I think this is not caused by extension conflict. I tried to delete


in my database and then run update.php but added_lines still not work. So what could cause this problem?

Here is a example log, looks like abusefilter can't get the "edit_diff" therefore it can't generate anything in added_links.

(In reply to comment #6)

It looks annoying that I can't view this page without logging in, but when I try to create an account, it gives me a question and I have no idea about its answer. :(

(specifically it asks me for the name of something in an image that I've never seen)

Hi Liangent,
I am sorry for bother you by the verification system. These verify are setted for both spam prevent and user selected. You can register account through our En version since they use same user data table.

By the way, there is one validation question for En version too, following page may help you:

If you still can't access the examine page, or you can't register. Please let me know, I will set up an Administrators account for you.

examine page:


Hmm it seems I've already created an account in 2012. I'm not sure why I did that.

I guess you have misconfigured your path to diff utilities, based on behaviors of other editing functionalities. Maybe you can have a look at these configuration settings:$wgDiff$wgDiff3

$wgDiff = "/usr/bin/diff";
$wgDiff3 = "/usr/bin/diff3";

I tried these two via CLI, both of then work.

(In reply to comment #10)

$wgDiff = "/usr/bin/diff";
$wgDiff3 = "/usr/bin/diff3";

I tried these two via CLI, both of then work.

I still doubt it's related to some configuration issues...

What if you set $wgDiff = false; (so it falls back to use PHP diff engine)

If everything works in this way, it must be a problem of diff instead of AbuseFilter.




$wgDiff = false;
$wgDiff3 = false;
added to localsettings.php the Abusefilter work! Although the wiki become perceptible slow, it work!

So it doesn't sound like an AbuseFilter bug... If you really want to consider it as a bug, it's just some imperfect error handling (but generally we don't try to spot improper configurations) in core.

Maybe you can try to manually execute (with maintenance/eval.php) lines at:;a=blob;f=includes/GlobalFunctions.php;h=50758c89f7afdc687f80385c4cdc7ad0dac64677;hb=375d04b02cfb9f1e4a1ecc5193f95010c76fbf0d#l2967

from line 2967 to 2992 and see what's going wrong.

Solved, allow "popen" in php.ini, and then AbuseFilter work as normal. This is a "dangerous" function, and looks like not necessary.