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
Replacement with services made available in 1.28 and this extension
requires 1.31. So, the replacement is good.
Change-Id: I1960a36541c9578abc3178a3a5ddcac7c32b8292
This parameter is not used anyway. It's possible it is null, as
demonstrated in Id2caa44. Because this code does not need it anyway,
it should not do any harm to remove this type hint.
Change-Id: Id107501e6d62e567354c90e5d3aeec47dbf57298
Having a different ParserOptions for each content model isn't feasible
in an MCR world. And the only thing using this was Wikibase, which has
been fixed to do what it needs in a different way.
Bug: T194263
Change-Id: Ib8ed827012c7bd73fcdaa6c0c6edd44869c79f14
Depends-On: I01373b29ee25fa9346c6b0317155be4ccdc8c515
Introduce BaseBlacklist::getSpamBlacklist() and getEmailBlacklist()
as type-documented alternatives to getInstance( 'email/spam' ) so we
don't need to keep documentating types in a comment when using a function
that isn't included in the base class.
Change-Id: Ic8bd8f803ddbce1294707d5f1d62b701e24d8c6e
