Extensions are supposed to return false to break hook chains when failed, which can avoid unnecessary call of later handlers in other extensions and work around with problems caused by difference betwen multiple triggers.
On mediawiki version 1.36 and before, just returning false in this hook can't display error message by default.
Set $status->value manually still to provide backward compatibility.
Bug: T280312
Change-Id: I456a40ce676c486b4ae12f00a7024a4c070448cd
There are some usages outside of SpamBlacklist that must be fixed. After
doing that, the signature should be updated to make the user
non-optional.
Note: I've changed the signature because external callers only pass the
first two parameters. Hence, it's easier to change it now, add a
User parameter to the callers and then make it non-optional, than having
to pass $preserveLog and $mode in all callers and then swapping the
order (as that would break the world).
Change-Id: I0714eb9dbc6af3c775ab7a81cb4b59e687183f77
Tests need a way to rest BaseBlacklist::instances, so they can be sure
they operate on a clean slate. This is also needed to ensure they do not
operate on real settings, targetting a real remote host.
Bug: T262443
Change-Id: Ic320f7a72da7f26e0931ce3d393fc5a61d43d4fc
Setting 'apiHookResult' results in a "successful" response; if we want
to report an error, we need to use ApiMessage. We already were doing
this for action=upload. Now our action=edit API responses will be
consistent with MediaWiki and other extensions, and will be able to
take advantage of errorformat=html.
Additionally, remove incorrect 'message' value from action=upload
output. It was anyway redundant to the normal error information.
To avoid user interface regressions in VisualEditor, the changes
I3b9c4fef (in VE) and I106dbd3c (in MediaWiki) should be merged first.
Before:
{
"edit": {
"spamblacklist": "example.com/test|example.net/test",
"result": "Failure"
}
}
After:
{
"errors": [
{
"code": "spamblacklist",
"data": {
"spamblacklist": {
"matches": [
"example.com/test",
"example.net/test"
]
}
},
"module": "edit",
"*": "The text you wanted to save was blocked ..."
}
],
"*": "See http://localhost:3080/w/api.php for API usage. ..."
}
For comparison, a 'readonly' error:
{
"errors": [
{
"code": "readonly",
"data": {
"readonlyreason": "foo bar"
},
"module": "main",
"*": "The wiki is currently in read-only mode."
}
],
"*": "See http://localhost:3080/w/api.php for API usage. ..."
}
Bug: T229539
Depends-On: I106dbd3cbdbf7082b1d1f1c1106ece6b19c22a86
Depends-On: I3b9c4fefc0869ef7999c21cef754434febd852ec
Change-Id: Id36aa6bdb8f873fe7deb8123a7fc774103721c01
Revision::getQueryInfo() was added in MediaWiki 1.31. We already
require that or later in our extension.json, so we can safely drop it.
The deprecated methods called by this code have been recently removed
(Id35544b879af1cd708f3efd303fce8d9a1b9eb02) and calling them is
causing Phan failures.
Change-Id: I474367d00c6d3917f1416023901132c0649b3163
Compared to other extensions like AbuseFilter, SpamBlacklist's
integration with MediaWiki's error reporting was weird.
* When dealing with page editing, we returned two (or more)
separate messages, which would then be rendered in a list.
This looks weird, especially if the messages have fancy wrapper
boxes etc.
* When dealing with file upload, we returned incomplete
error message, not reporting the blacklisted link.
Now, in both cases, we return a single error message
containing all the details.
Change-Id: I4ca8e67e03726696a428093cc9fb547a6daa1492
The following sniffs now pass and were enabled:
* MediaWiki.Commenting.FunctionComment.MissingDocumentationProtected
Additional changes:
* Committed package-lock.json (T179229) too.
Change-Id: Ic5edf46789ab191b59aaae0921b3038381e704b7
The instrumentation attempted here has been implemented more correctly
by https://phabricator.wikimedia.org/T214706. This change removes
instrumentation from this extension. It should not affect much,
because emitting events was already disabled.
Bug: T162365
Change-Id: I8f02c62d41260a62b37a7738d69c039d2ce7562f
