We previously added the message key as .message property
(97b433286d), leaving it for the API
client to know what the parameters are and how to get them.
(Here, the parameters are the .line property and the page title.)
Let's just do this work for the client, so that it doesn't have to
know what TitleBlacklist is - it'll be able to just display the given
message with the given parameters. My specific use case is the upload
dialog in core (core shouldn't have to know about any extensions).
See also AbuseFilter change I5780eae96930211191ecd874aacf53fdacb58f89.
Change-Id: I97c1f5c6bbbdfc0b8ea9914bb075d5299c14df8f
Also use it to only log the title blacklist hit when running for real,
not when testing a username.
Change-Id: Ie9639a15d04b387be0e72754301eb6d91cd8adc2
I guess this only ever worked before because none of the other tests
depended on these globals. Now that AuthManager is enabled by default,
one does.
Change-Id: If335fcc9b844a518b2c56bfa39153159261ae314
It looks like the original implementation of this (r28307) was
incorrectly using wfEmptyMsg() so it was checking if the specified
message page had content equal to '<titleblacklist>' rather than
checking whether the message actually being loaded was empty.
Then r64178 changed wfEmptyMessage() such that it was checking if the
'titleblacklist' message was disabled in the user's language, which
caused the behavior here to be even more wrong. Then Ie78fa258 came
along to cement this in place and make this code even more
incomprehensible.
So let's go back to what it was probably originally trying to do: return
the 'localpage' message's content if it's not disabled, or empty string if
it is disabled.
This should also take care of T56193#2068536, which is being triggered
by the attempt to load the message in the user's language.
Bug: T56193
Change-Id: I8fe7f03d68e6854106cc903baf7c14ba4badb7c7
* Use only a single error code 'titleblacklist-forbidden'
to allow API users to easily identify TitleBlacklist errors.
* Return the internal code ('message') and the matching entry's text
('line') in machine-readable format, same as action=titleblacklist
(depends on I1334ba21a2862973a9d8ff5be2c9bec06a82698b in MediaWiki).
This bumps the version requirement to 1.27, as older MediaWiki
versions would ignore the error in new format entirely.
Example API output change, for action=edit:
Before:
{
"error": {
"code": "custom-message",
"info": "TitleBlacklist prevents this title from being created",
"*": "See http://localhost/w/api.php for API usage"
}
}
After:
{
"error": {
"code": "titleblacklist-forbidden",
"info": "TitleBlacklist prevents this title from being created",
"message": "custom-message",
"line": ".*test.* <errmsg=custom-message> # test rule",
"*": "See http://localhost/w/api.php for API usage"
}
}
Bug: T115258
Change-Id: I42a0c5b0ea7e61088dd609b764dd7d1396c60cd5
