A confusing warning message was displayed when filters
have af_throttled = true. That message was replaced with a
new one reflecting the behavior that is actually ocurring and
how to solve it
Bug: T54525
Change-Id: I5c6e434249d5c9649eb2d7c5b16b9ecb1f530c8a
Metrics per edit:
- Execution time of all filters
- Number of filters executed
- Number of conditions executed
Due to the current structure of abuse filter there was not
a clean way to include filter actions and abuselog creation
as part of the runtime metrics.
Bug: T161059
Change-Id: I6208b620453863133c6623aa419775f63c7d3eb1
It should have been deleted in I02ba4ce31b6aca5b7324114093f8ece143abc295
but accidentally survived.
Change-Id: Icdbe8fb0154513d643905f7f8bd6391780cd44a7
- Use rc_source with values that we know we support. In
particular, this drops categorization changes.
- Filter on rc_log_type and rc_log_action (which itself
may be shared across types).
- Use the same query on both Special:AbuseFilter/test
and Special:AbuseFilter/examine.
Bug: T170574
Change-Id: I79b903b4424d3c15095a1e0491d35f6e005db0b8
Cleaned ccnorm method to use AntiSpoof::normalizeString instead going
after AntiSpoof extension files and doing a manual implementation of it.
Also removed composer requirement for AntiSpoof extension.
Bug: T172766
Depends-On: I731733671b650b6bb2f480c41c4f6f2d2f5c62e8
Change-Id: Ib38ba0b06918e81e8af03032eef95e3942773bc1
After I544cdfa75c7472f2d98b2561bc6f6f9c2d2ad639 (dieWithError
and checkUserRightsAny), this is the oldest MediaWiki version
AbuseFilter can be run on.
AbortMove was removed from MediaWiki in 1.25, UploadVerifyFile
is only relevant for 1.27 and older.
(Replaces I1e962217c3b20d901a5742cf76339a3f488a6e97.)
Change-Id: Iec237b2887f72b115fdcef78d2d7a944ba82c784
As described in the task, anyone can view the page but do nothing
with it. It doesn't make sense, it should either work or be disabled.
I chose the latter.
Bug: T124096
Change-Id: I7271cd5a0d00d5fdba28ce3974c50ea5dfd0ad9b
The following sniffs are failing and were disabled:
* MediaWiki.Commenting.FunctionComment.MissingDocumentationProtected
* MediaWiki.Commenting.FunctionComment.MissingDocumentationPublic
* MediaWiki.Commenting.FunctionComment.MissingParamComment
* MediaWiki.Commenting.FunctionComment.MissingParamName
* MediaWiki.Commenting.FunctionComment.MissingParamTag
* MediaWiki.Commenting.FunctionComment.MissingReturn
* MediaWiki.Commenting.FunctionComment.ParamNameNoMatch
* MediaWiki.Commenting.FunctionComment.WrongStyle
The following sniffs now pass and were enabled:
* MediaWiki.Commenting.FunctionComment
Change-Id: I0874c547ef2bc8a7c3fa4ca72738aa3320f2bdbe
It seems that move actions have rc_this_oldid set. rc_log_type
should have higher priority.
Bug: T170586
Change-Id: I9bb4ea599f12ef01fad823ac3232330966b0d281
Also move --ignore to phpcs.xml for use by phpcbf
Short array syntax will be used in follow ups
to keep this patch set small
Change-Id: Ib91f3768cc7cdccdc26a4d5200178ceb8e61e098
The return value from the method is only suitable for passing to
$db->insert(). To get the inserted ID, you need to call $db->insertId()
even if $db->nextSequenceValue() returned non-null.
Change-Id: Id5a0df17c77445e9f29564a55fb850c3ecad2630
We add FORCE INDEX to revision because probably we have hit a MariaDB
bug that can potentially create an outage on pages with thousands of
revisions due to extreme resource usage by this query when using the
wrong index page_user_timestamp, instead of page_timestamp.
This is considered to be a hack, and once we are in the clear, I promise
to review this an try to get a saner execution path (both in MySQL and
in PHP.
Bug: T116557
Change-Id: I41853da5c0e1a15efad5594eff0cee62be1ad9a4
Follows-up e4ac1ef. A lot of this class gets its own cache object
in key-generation methods because of legacy compat with public
methods and because of how wfMemcKey used to be.
However where possible, we should encourage passing $cache
so that makeKey() can be used on the same instance that uses
the key.
This is a no-op since it's exactly the same object.
Change-Id: Ib3c31110176659a9175679eb716369e7f0a1d3b2