It can wind up logging deprecations twice if extractRequestParams() is
called with different values for 'parseLimit', for example.
Change-Id: I921777089fb8cfb4339af6fd08ee3475ed31b7f6
Two bugs here:
* If the error array contains an entry using a Message object instead of
a string as the key, it'll blow up trying to do
`self::$blockMsgMap[$error[0]]`.
* If the error array contains a Message object not wrapped in an array,
it'll blow up trying to do `...(array)$error`.
Bug: T217382
Change-Id: I2a08e02bca0fb194416b3f2e6a1d6192d5c13cb2
The code in EditPage and SpecialMovepage does this primarily in web UI
code paths that aren't called by the API. EditPage also has a check in
the internal code path used by the API, but ApiEditPage runs its own
permissions check first and won't reach that code path.
Bug: T216245
Change-Id: I6263c8b60a24f3195dba583463f1ce4b004f82f5
When using ApiBase::errorArrayToStatus(), block info was added to
'blocked' errors. But when using dieStatus() with a Status object
returned by core MediaWiki code, block info was not being added.
Change-Id: I14887b6dd76d665055283945b956b2e26c521ed5
Depends-On: Ie3addf53ab5fabf1c24e1033b58e63927f4e21bf
If a deprecated parameter has a default value, or a deprecated value is
part of the default value for a parameter, don't give the client a
deprecation warning about it.
Bug: T215548
Change-Id: I980763e3d44fb1b7459c64b175fcaddf5fd44a13
When batched deletions via the job queue were added in Ie800fb5a, the
way this was reported caused ApiDelete to report an error. Instead it
should report success with appropriate signaling to the client.
Bug: T212356
Change-Id: I1ef66277e988572c6720cf3e3cb36b18530746b4
People apparently have a tendency to typo the IDs somehow, and if you
hand MySQL a stringified integer in a list that is out of range it
decides it can't use sensible indexes.
Bug: T140302
Change-Id: Ic1975220e55cb9daa16127ec0540e7ad16aad44e
Monitoring block errors is behind $wgEnableBlockNoticeStats
and it is disabled by default.
The reason behind this metric is to get an idea on how
frequently blocked users attempt to edit a page. Similar tracking
is being added to MobileFrontend and VisualEditor.
Depends-On: I6bd1c95548616677e1f72ba6bcfc6f2b551c1ca6
Bug: T201717
Change-Id: I18bdb5ce61509ba3c2cea9aa6247656b9bd388e0
Non-breaking change. Remaining uses are public interfaces (a constant, two
globals, a config sub-parameter, SQL queries, storage function names), one i18n
message key, and a whole lot of maintenance scripts with calls to the deprecated
function wfWaitForSlaves().
Change-Id: I6ee5ca92ccf6a80c08f53d9efe38ebb4b05064d7
The following deprecated methods, intended for overriding by extensions,
are no longer called and are hard deprecated.
* ApiBase::getDescription() (deprecated in 1.25)
* ApiBase::getParamDescription() (deprecated in 1.25)
* ApiBase::getExamples() (deprecated in 1.25)
* ApiBase::getDescriptionMessage() (deprecated in 1.30)
Also, the 'APIGetDescription' and 'APIGetParamDescription' hooks have
been removed, as their only use was to allow extensions to override
values returned by getDescription() and getParamDescription(),
respectively.
Change-Id: I486c4ccab4eca6a85cb17c30dbb2439876123ba1
Enforce partial blocks and display a slightly different block
notice depending on if the block is sitewide or not
Bug: T197117
Depends-On: I675316dddf272fd0d6172ecad3882160752bf780
Change-Id: I8a3635a4a04a33912eb139b7b13c4bd874183d31
Uses new PHP 5.6 syntax like ...parameter unpacking and
calling anything looking like a callback to make the code more readable.
There are much more occurrences but this commit is intentionally limited
to an easily reviewable size.
Change-Id: Idcec077ef3fdf029b632cceafd0150851ad723e3
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
Since 2008 the API has truncated with a warning when too many values are
passed to a multi-valued parameter. It's long past time to make this an
error.
Bug: T41936
Change-Id: I0f9efbdf9230373fa0c175a7fcacbca68225cf40
This is a bit more interoperable than trying to roll our own by using
Title::makeTitleSafe().
We still need to handle IP addresses separately, of course.
Bug: T194916
Change-Id: Ie3900d768cbe15aef079b97d91f7fd23dc7c3e26
With MCR coming up, ApiEditPage is going to need to be able to take
"text" and "contentmodel" parameters for each slot-role, and enumerating
such parameters for every possible slot would probably get rather
confusing as to what is required when, or at least long-winded in
repeating the exact same thing for every possible role.
So let's abstract it: we'll have an "editroles" parameter to specify which
slots are being edited, and ApiEditPage will just declare that
"text-{role}" and "contentmodel-{role}" parameters should exist for each
value of "editroles" in the submission.
Note this patch doesn't introduce anything that uses templated
parameters, just the functionality itself. For testing purposes you
might cherry pick I2d658e9a.
Bug: T174032
Change-Id: Ia19a1617b73067bfb1f0f16ccc57d471778b7361
One bug fixed: if ApiCheckCanExecute returned false but didn't set
$message, we would try to output a message of false, which would throw
an exception.
Change-Id: Ib06970e280d750ff57d81672f1b365167b93aa3e
One bug fixed: a timestamp of '00' or similar would get interpreted as
'now' by mistake instead of Unix timestamp 0, without throwing the
warning for using 0 instead of 'now'. This is because it called
wfTimestamp() once to parse the input date, got a Unix timestamp of 0
back, and then tried passing that 0 back to wfTimestamp again to
reformat as a wiki date, but it got reinterpreted as 'now'.
Also fixed parameters with type "user" to validate usernames more
correctly. This might be risky, though, if I missed any valid
usernames, or if API clients were for some reason relying on passing in
invalid usernames. If we don't actually want to do this, we should add
a comment explaining why we're allowing any title without a fragment
rather than validating properly.
Still lots more work to do here.
Change-Id: I56b4290263df8698efdbddda71a7eabd9e303abc
SPDX released version 3 of their license list (<https://spdx.org/licenses/>),
which changed the FSF licenses to explicitly end in -only or -or-later
instead of relying on an easy to miss + symbol.
Bug: T183858
Change-Id: I4cbb98ea2bbacf46a57401dbba2bdb076fca1d3a
This allows to response with an invalidreason instead silently ignore
the parameter.
Example request: api.php?format=json&action=query&titles=%20
Response before this change:
{
"batchcomplete": ""
}
Response with this change:
{
"batchcomplete": "",
"query": {
"pages": {
"-1": {
"title": " ",
"invalidreason": "The requested page title is empty or contains only the name of a namespace.",
"invalid": ""
}
}
}
}
Bug: T185846
Change-Id: I6fdaf32792a0e6e37b08176f975c10607093351b
It is the job of git and svn to provide this information/metadata.
The form was different, some with short, some with long month name
some with leading zero at the day, some without.
The year is also present in the Copyright clause
Change-Id: If006907b82b9e45f13cfa2e45d41107a95570e1a
Per-value documentation is only generated if this option is specified,
even if it is only set to an empty array (i. e., when using the default
key for all values). Attempt to make this more clear.
Change-Id: I844df226271aadb1f06b3cc00ba32cc6c06ec76a
These comments do not add anything. I argue they are worse than having
no comments, because I have to read them first to understand they
actually don't explain anything. Removing them makes room for actual
improvements in the future (if needed).
Change-Id: Iee70aad681b3385e9af282d5581c10addbb91ac4
Adds two new ApiBase::getAllowedParams() keys:
PARAM_MAX_BYTES and PARAM_MAX_CHARS, to set a length
limit for a (string-like) parameter.
This makes it easy to document and enforce database
field length limits (where relying on the database
would either result in unfriendly error messages or
silent truncation, depending on DB settings) and
also exposes them in structured form so API clients
can verify the length without doing roundtrips.
Change-Id: I2e784972d7e11cad79fdef887bbcde297dbd9ce0
The fix for T125177 from F4932228 was incorrectly rebased when it was
applied to master as 4d38a489, causing the bug to not actually be fixed.
Bug: T180488
Change-Id: Ie6b87ef2373369987c112c19903c99afb789c1ff
Adds two new parameter settings, ApiBase::PARAM_ISMULTI_LIMIT1
and PARAM_ISMULTI_LIMIT2 for configuring the maximum number of values
that can be contained in a multivalue field (for unprivileged and
apihighlimits users, respectively). When present, these replace the
default 50/500.
Change-Id: Ic1b1bcc7ff556b7762c8d2375d910cc4fcb43087
For some varargs a variable name is added with suffix ,... as seen for
many other varargs
Some @param are swapped, because there are in the wrong order
Enable Sniff MediaWiki.Commenting.FunctionComment.ParamNameNoMatch
Change-Id: I60fec6025bce824d5c67563ab7b65ad6cd628ad8
