php documentation:
If the size of post data is greater than post_max_size, the $_POST and
$_FILES superglobals are empty.
When the action= and format= are not in the GET data,
the help page is returned in html, breaking the clients expected format.
Return api error with http status 413
Bug: T291754
Change-Id: I5906fb6b4412b161b198df0b51e2476e7e1079b8
Implicitly marking parameter $... as nullable is deprecated in php8.4,
the explicit nullable type must be used instead
Created with autofix from Ide15839e98a6229c22584d1c1c88c690982e1d7a
Break one long line in SpecialPage.php
Bug: T376276
Change-Id: I807257b2ba1ab2744ab74d9572c9c3d3ac2a968e
Use
$request->getRawVal( 'key' ) ?? 'default'
instead of
$request->getRawVal( 'key', 'default' )
The ?? is more flexible, avoids a wrong type detection by phan and
avoids the evaluation of the default value if not needed.
Bug: T376245
Depends-On: I3ed6b85c0d117ed7cb3a8b79f73a3eb42977891e
Change-Id: I8b02f9297b76d04e21f8cb9194f3b85631956eca
Add doc-typehints to class properties found by the PropertyDocumentation
sniff to improve the documentation.
Once the sniff is enabled it avoids that new code is missing type
declarations. This is focused on documentation and does not change code.
Change-Id: I8b33b5f4d91c1935228e7010327dbc6ce138fc00
This avoids data bloat in feature usage logging and tracking,
reducing the chance of truncation, and makes it easier to search
these records.
Note that all uses of this method are tied to deprecated API
feature use reporting.
Bug: T313731
Change-Id: Ie097ad21959fbcedc33da407145a7aad573a361e
In change I625a48a6ecd3fad5c2ed76b23343a0fef91e1b83 I am planning to
make Wikimedia\Message\MessageValue use it, and we try to pretend that
it is a library separate from MediaWiki, so it makes sense to move
MessageSpecifier to the same namespace under Wikimedia\.
Bug: T353458
Change-Id: I9ff4ff7beb098b60c92f564591937c7d789c6684
This commit replaces some of the uses of getErrorsArray(),
getWarningsArray(), getErrorsByType(), and getErrors().
In many cases the code becomes shorter and clearer.
Follow-up to Ibc4ce11594cf36ce7b2495d2636ee080d3443b04.
Change-Id: Id0ebeac26ae62231edb48458dbd2e13ddcbd0a9e
Why:
* Modules that extend ApiQueryBase are loaded using the ApiQuery
module. This defines an override to the ApiBase::isWriteMode
method that loads the modules.
* Using the mModule when $isError is true could lead to the
exception that was thrown in ::executeAction being thrown again.
* Therefore, ApiMain::sendCacheHeaders should only call the
ApiBase::isWriteMode method if the request did not fail
with an error that caused $isError to be true.
* Without this fix, ApiUsageExceptions appear in logstash as
exceptions, as described in T363133.
What:
* Only interact with $this->mModule if the $isError argument
is false. If $isError is true, assume that ::isWriteMode
would return true. Assuming this will also avoid error
responses being marked as fresh for any amount of time, as
the error may be temporary.
* Add a test that verifies that the method does not throw if
ApiBase::isWriteMode throws an ApiUsageException.
Bug: T363133
Change-Id: I41d869c257878b8a94d6c40332e2028405de8729
Instead of globally ignoring this sniff, convert the current violations
(which set the variable so can't be fixed easily yet) to use local phpcs
comments to silence the errors.
Change-Id: I490cbf4915e2705383edb4a2fc5ddc1efd55c960
Why:
* Since 1941f28f60, the
recentchangesfeed API (ApiFeedRecentChanges) has treated
temporary accounts as being anon users for the purposes of the
'hideanons' parameter.
* However, the help text does not describe that temporary accounts
are treated in this way and as such the help text needs to be
modified depending on whether temporary accounts are enabled.
What:
* Add 'apihelp-feedrecentchanges-param-hideanons-temp' as a i18n
message which duplicates the existing 'apihelp-feedrecentchanges
-param-hideanons' but includes temporary accounts.
* Update ApiFeedRecentChanges::getAllowedParams to use the new
message if TempUserConfig::isEnabled returns true.
* Add the TempUserConfig as a injected dependency for
ApiFeedRecentChanges.
* Add an integration test to verify that the correct help message
is used for the 'hideanons' parameter in ApiFeedRecentChanges.
Bug: T358249
Change-Id: I516c1a563a81777217cda998efaeda7967dd224d
* Switch out raw Exceptions, mostly for InvalidArgumentExceptions.
* Fake exceptions triggered to give Monolog a backtrace are for
some reason "traditionally" RuntimeExceptions, instead, so we
continue to use that pattern in remaining locations.
* Just entirely give up on PostgresResultWrapper's resource vs. object mess.
* Drop now-unneeded false positive hits.
Change-Id: Id183ab60994cd9c6dc80401d4ce4de0ddf2b3da0
This adds significant complexity and provides very little value.
As far as I can tell, we've never linked to those IDs. Other headings
in generated documentation don't have fallback IDs (in ApiHelp).
I'm mostly doing this because I want to deprecate and remove
Linker::makeHeadline(), which is a function with really silly
parameters that grew out of a regexp replacement callback in
Parser.php, and which – except for these usages I'm removing
– is only used there.
Change-Id: If793f5023fca744f109f5a1f0f0ad3857375db8c
The goal is to unify the high level control flow in entry points by
making them use a shared base class. Eventually, this will allow
us to test all aspects of request handling, including response
headers and output buffer handling. That will however require
us to move quite a bit of logic from ApiMain into ApiEntryPoint.
Bug: T354216
Change-Id: I4ea1cbb8b2786c24deade7d5029d95fe0c2abc57
When we format API output as HTML, that HTML may contain user secrets
and should not be cacheable, even if the API output would ordinarily be
cacheable.
Bug: T354045
Change-Id: I94fe5f7bfae580e8bda8af1971b9448db8201c22
Why:
* Before this task, when an API parameter specifies allowed user
types, temporary users and permanent users are in the same
category: 'name'.
* However, it is useful to separate them out, and sometimes
allow a permanent user but not a temporary user (e.g.
ApiResetPassword, since temporary users don't have passwords).
* We therefore re-defined the 'name' type only to refer to
permanent (named) users, and add a new 'temp' type.
* This fixes params that currently intend to allow temp users,
and that use 'name' to do so, by adding 'temp'.
What:
* Based on a search for `UserDef::PARAM_ALLOWED_USER_TYPES`,
add the 'temp' type where necessary.
* The following were not updated, because they shouldn't apply
to temporary users:
- owners for includes/api/ApiQueryWatchlist.php,
includes/api/ApiQueryWatchlistRaw.php
- users for includes/api/ApiResetPassword.php,
includes/api/ApiUserrights.php,
includes/api/ApiValidatePassword.php
Bug: T350701
Change-Id: If5ccf1d469327791acff74d013343307e411cca9
Deprecated methods are:
* WebRequest::isSafeRequest()
* WebRequest::markAsSafeRequest()
Introduced in I43f4bc06c19d823d7d1f (549af8bf) and used in
I01ae2f045726208d2af7 (ce3a25be), then later removed in I4eb10817cccb40aa255
(e34fd634) which became unused in core.
As a result, it made markAsSafeRequest useless as there is really no
consumer at this point.
No known usage (confirmation) per our code search tool today. See below:
https://codesearch.wmcloud.org/search/?q=isSafeRequest&files=&excludeFiles=&repos=
Change-Id: I39cfb04c46374153d374fe0bb88690fa48ad7250
A unique index on ar_rev_id was added in T193180 (2019), allowing
revisions of deleted pages to be reliably looked up by just their ID.
Use the improved getArchivedRevisionRecord() method in a few places
that previously had to use manual queries.
Bug: T251066
Change-Id: I9352f64952ac4b803d76e9e72f88a01be7317c56
* Add an API action=acquiretempusername
* Add a mw.config variable with the temp user name
* Add mw.user.acquireTempUserName, which checks the mw.config
variable, then fetches a name from the API
* Use mw.user.acquireTempUserName when previewing
Bug: T331397
Change-Id: Iec8a15dadd595bed0f7e54f907fbb8e192b45cf3
