Changed the textarea size in AbuseFilter Notes text area
from 5 to 15 to match with the new Conditions text box.
Bug: 55365
Change-Id: I1da26166f28f31b2a18c1dca3709efc0728d45d6
When an empty parameter is passed to a function using strpos, such as when
an extra comma appears at the end of contains_any's parameter list, don't
call strpos on the empty string.
Bug: 60203
Change-Id: I6221a01ad1ec9090de7bfc1d9d6583f22ba0eb2e
The text areas for the table row had only 5 rows, which is a lot less than
the default number of rows.So now the number of rows in the testing textarea is changed to 15.
Bug: 59869
Change-Id: I9f221e7a49473ae1d473333f7ecf26235366d257
The text areas for the table row had only 5 rows initially which was
small and it needed scroll to view it completely.
Now it has been changed to 25.
Bug: 59866
Change-Id: I77a092ac956bd9a9e4b7eb38abb16876087b8560
This patch makes a diff link appear in Special:Abuselog no matter a filter
is public or private. Because there is much information to figure out which
revision a filter catches, showing a diff link will make patrollers more
convenient without leaking more information.
Bug: 59695
Change-Id: I6a4432cbb41ae78583cc87355514f252984c1005
The fix for bug #50808 resulted in the Details link being hidden from the
log page as well as the details page. This restores it to the log page.
Change-Id: I651f0f41e0d603cbd28cbf920842d6bdd879f4b1
When an invalid page name is entered in Special:AbuseFilter/test, display
a sane error message rather than throwing a PHP fatal error.
Bug: 55411
Change-Id: I5ec005180c9009f6d14244f3b03221e525cfaed3
The "description" says "publicly viewable", but the
actual visibility depends on the visibility of the
filter.
Bug: 57305
Change-Id: I04301fc9f188862b2a23d6b316d7e5eef111ade0
I'm not really sure why it exists; I assume to minimize overhead of init'ing
multiple AbuseFilterParser objects that would be exactly the same.
However, checkConditions() - which checks one specific condition - is not really
an "endpoint" you will want to call in <your-extension-that-uses-AbuseFilter>.
You're more likely to call something higher-lever (like
AbuseFilter::filterAction, which will take care of fetching all appropriate
filters, as well as run them through checkConditions, and much more). This will
trickle down to ::checkAllFilter, down to ::checkFilter, which would eventually
call ::checkConditions with the 'keepvars' argument.
Basically, unless you're re-implementing much of AbuseFilter yourself, you won't
get to pass anything other than 'keepvars' to checkFilter.
As a result, even though you may call AbuseFilter to call on multiple different
vars, it will re-use the same parser with the first vars.
I'm proposing to drop the 'keepvars' and just keep the vars around instead.
checkFilter can compare previous vars with new vars, and only init a new Parser
if the vars are different.
Change-Id: I96ccc60c77f3cdbb82c0f9f16782a1a44ffb1592
