When the purge action fails with error "ratelimited", the linkpurge
would fail with "Precondition failed: The PermissionStatus passed as
$status parameter must still be good"
Bug: T369455
Change-Id: Ifb19cc195a51f5521f8365ab26b3cdb56429e0fb
Use of Authority::authorizeWrite includes permission checks for the
title against the edit rights, which was not the case using
User::pingLimiter before 26456e5b / 07a9c87b
Bug: T354460
Follow-Up: I9fee34f5b44e947a00f1aaf2d28202d009e2caec
Follow-Up: If85e2af107dd901d98e9553d7d38144f1bac62af
Change-Id: Ic03714e849bf3bd550f64e194797b45823b42c08
Failure related to page permissions (like $wgNamespaceProtection or
.js/.css-pages) should not stop further linkpurges.
Also stop further recursive linkpurges when ratelimited,
as that only repeats the api warning message.
Bug: T354461
Change-Id: I153f7d8e472dd17cc26e329bee40005e1ed914fd
Allows to trigger RefreshSecondaryDataUpdate jobs with a timestamp to
ensure a link update was done after that timestamp.
Since e5655255 it is possible that RefreshSecondaryDataUpdate gets
queued for api action=purge, but RefreshSecondaryDataUpdate only checks
that the links update is done after the last edit, so when jobs get
queued by action=purge, the jobs does nothing.
Ensure that page_links_updated gets updated via action=purge when the
timestamp is before the new freshness timestamp (checked in
RefreshLinksJob::isAlreadyRefreshed).
Bug: T351729
Change-Id: I85aed4c40d430ba6c30c763141f4b821c36e6eaf
Changes to the use statements done automatically via script
Addition of missing use statements and changes to docs done manually
Change-Id: I443aada1c18c8628b02671aa9fd6f441961e5c2e
Previously, all kinds of permission errors were reported as "rate limit
exceeded".
Follow-Up-To: I9fee34f5b44e947a00f1aaf2d28202d009e2caec
Change-Id: Idec70e754bff265c4293aee37c600e54ed1aed40
Remove hardcoded "Main Page" and use whatever the main page of
the wiki is. Many wikis have their main page in a different
title than the default or even in a different namespace entirely.
With the hardcoded title this produces broken/redlink for the doc
examples and makes it overall less useful.
Most typical examples; Mediawiki.org itself, Wikidata.org, etc.
Bug: T235207
Change-Id: Ia9eee76544cad153166dd5a2eb8e8c1bf3a38b74
Mostly used find-and-replace:
Find:
/\*[\*\s]+@var (I?[A-Z](\w+)(?:Interface)?)[\s\*]+/\s*(private|protected|public) (\$[a-z]\w+;\n)((?=\s*/\*[\*\s]+@var (I?[A-Z](\w+)(?:Interface)?))\n|)
Replace with:
\3 \1 \4
Followed by some manual review to make sure I'm not changing too much,
omitting some changes that looked too complicated and anything that
caused test failures, and some whitespace fixes.
Change-Id: I6ec7587607df4f1a4f448a096c3e44c4e5270b70
Replaces Content::getSecondaryDataUpdates with
WikiPage::getSecondaryDataUpdates so that aggregation of
data updates from multiple page slots can be handled without
the caller having to care about it.
Also adds a WikiPage::updateParserCache method for convenience.
This is a temporary measure until DerivedPageDataUpdater
(or its replacement) can be exposed directly, at which point
the WikiPage methods will be deprecated.
Also fixes a parameter handling bug in DerivedPageDataUpdater.
Bug: T194043
Change-Id: Idbe7d582b49fcb7c90aea813773b7610ad44b1a8
Links generated by the API are now aware of the user's preferred
language and will show documents in that language if available.
To test, log in to mediawiki.org and set your language preference to 'es',
then on an MediaWiki installation with this patch view the generated
expanded API help at `api.php?action=help&recursivesubmodules=1&modules=main`.
Each link to documentation on mediawiki.org should take you to its
translated /es subpage, if one exists.
Bug: T104518
Change-Id: I339a1f3ae1bce9d759cf251899d57c32b1def91e
This reverts most of commit c84ba4d864.
The changes made there are no longer needed, and nothing in Gerrit seems
to have started using them since they were added.
The added constants in WikiPage, WikiPage::getLastPurgeTimestamp(), and
Article::getLastPurgeTimestamp() are deprecated, useless, and unused,
but not removed yet since they snuck into 1.28 so we can't revert them
without a deprecation period. Sigh.
Bug: T145649
Change-Id: I526fd4e004bee84c831a4cee71e44e92ee73480b
API warnings and error messages are currently hard-coded English
strings. This patch changes that.
With a few exceptions, this patch should be compatible with non-updated
extensions:
* The change to ApiBase::$messageMap will blow up anything trying to
mess with it.
* The changes to the 'ApiCheckCanExecute' hook will cause a wrong
(probably unparsed) error message to be emitted for extensions not
already using an ApiMessage. Unless they're currently broken like
Wikibase.
Bug: T37074
Bug: T47843
Depends-On: Ia2b66b57cd4eaddc30b3ffdd7b97d6ca3e02d898
Depends-On: I2e1bb975bb0045476c03ebe6cdec00259bae22ec
Depends-On: I53987bf87c48f6c00deec17a8e957d24fcc3eaa6
Depends-On: Ibf93a459eb62d30f7c70d20e91ec9faeb80d10ed
Depends-On: I3cf889811f44a15935e454dd42f081164d4a098c
Depends-On: Ieae527de86735ddcba34724730e8730fb277b99b
Depends-On: I535344c29d51521147c2a26c341dae38cec3e931
Change-Id: Iae0e2ce3bd42dd4776a9779664086119ac188412
This is a revert of 84ffa5d124. At that point we've been implementing
page-properties-change event for the EventBus extension and thought
adding this call would be a good idea. However, it was discovered
afterwards that there's much more extensions that don't set the
triggering user. Since that call is deprecated and plans are to
remove it - revert the change.
Change-Id: I9891da628f968970247edc37cccd4a666950273b
Even if the API call was done anonymously, we still have the IP
address to set as a triggering user. This is needed in the EventBus
since the LinksUpdate job triggers a page-properties-change event
and we need information about the performer for each page-related
event.
Bug: T147516
Bug: T147977
Change-Id: Idc6efc894698606ba528f4bd67658267ed250862
This emits a warning and logs feature usage, and also pretends that POST
is required in the help and paraminfo output.
Bug: T145649
Change-Id: Ied8d47a947662158fddab383c764bf70c5ab0112
This will still clear the local DC parser cache and the CDN cache
in all DCs. Therefore, the next page views served by the local
DC will reflect the refreshed content, as will further GET/HEAD
requests by the client that issued the purge using GET/HEAD.
If the problem was imply a stale CDN cache entry, then all
DCs will be up-to-date. If the problem is stale parser cache,
then a proper POST purge request is required to refresh all DCs.
Bug: T92357
Change-Id: I9af12ca8cfff73298f404fd3e2dd4f546621c546
* Also make ErrorPageError exceptions display themselves
in PRESEND mode. Before they were always suppressed.
* Make DataUpdate::runUpdates() simply wrap
DeferredUpdates::execute().
* Remove unused installDBListener() method, which was
basically moved to Maintenance.
* Enable DBO_TRX for DeferredUpdates::execute() in CLI mode
* Also perform sub-DeferrableUpdate jobs right after their
parent for better transaction locality.
* Made rollbackMasterChangesAndLog() clear all master
transactions/rounds, even if there are no changes yet.
This keeps the state cleaner for continuing.
* For sanity, avoid calling acquirePageLock() in link updates
unless the transaction ticket is set. These locks are
already redundant and weaker in range than the locks the
Job classes that run them get. This helps guard against
DBTransactionError.
* Renamed $type to $stage to be more clear about the order.
Change-Id: I1e90b56cc80041d70fb9158ac4f027285ad0f2c9
Some pages seems to have page_latest = 0, and therefore no content to
linkupdate. To not get a BadMethodCallException (see T140514) there is a
null checked needed.
Change-Id: I1ebfcf131ad3f59f38ec2583650eba5b43bac999
Nothing in this patch should result in changed output for format=json or
format=php except as noted in RELEASE-NOTES-1.25, and changed output for
format=xml should be similar or cosmetic. However, other code accessing
the result data directly may need to be updated.
Bug: T87053
Bug: T12887
Change-Id: I3500708965cb8869b5aed1543381aad208dadd13
ApiResult was a mess: some methods could only be used with an array
reference instead of manipulating the stored data, methods that had both
array-ref and internal-data versions had names that didn't at all
correspond, some methods that worked on an array reference were
annoyingly non-static, and then the whole mess with setIndexedTagName.
ApiFormatXml is also entirely annoying to deal with, as it liked to
throw exceptions if certain metadata wasn't provided that no other
formatter required. Its legacy also means we have this silly convention
of using empty-string rather than boolean true, annoying restrictions on
keys (leading to things that should be hashes being arrays of key-value
object instead), '*' used as a key all over the place, and so on.
So, changes here:
* ApiResult is no longer an ApiBase or a ContextSource.
* Wherever sensible, ApiResult provides a static method working on an
arrayref and a non-static method working on internal data.
* Metadata is now always added to ApiResult's internal data structure.
Formatters are responsible for stripping it if necessary. "raw mode"
is deprecated.
* New metadata to replace the '*' key, solve the array() => '[]' vs '{}'
question, and so on.
* New class for formatting warnings and errors using i18n messages, and
support for multiple errors and a more machine-readable format for
warnings. For the moment, though, the actual output will not be changing
yet (see T47843 for future plans).
* New formatversion parameter for format=json and format=php, to select
between BC mode and the modern output.
* In BC mode, booleans will be converted to empty-string presence style;
modules currently returning booleans will need to use
ApiResult::META_BC_BOOLS to preserve their current output.
Actual changes to the API modules' output (e.g. actually returning
booleans for the new formatversion) beyond the use of
ApiResult::setContentValue() are left for a future change.
Bug: T76728
Bug: T57371
Bug: T33629
Change-Id: I7b37295e8862b188d1f3b0cd07f66ac34629678f
This also adds some new ApiBase::PARAM_* constants to generate more
helpful help, and a method to override the default description message
for the use of ApiDisabled and ApiQueryDisabled.
Bug: 71638
Change-Id: Ic0c3d232e0498d58a043037e2e0c6f0b1c3edad3
The format for 'props' was never specified and the list for 'errors' is
impossible to keep updated when considering that many errors come from
MediaWiki backend code and extension hook functions. And since there
doesn't seem to be any real use case for either of these, let's just
kill both of them instead of wasting effort on trying to fix them.
Note that neither getResultProperties nor getPossibleErrors are called
from any extensions in gerrit, and none of the other deprecated methods
are called outside of the implementations of those two methods. Removing
the obsolete methods is left to the maintainers of the extensions, as
keeping them hurts nothing and is needed to maintain compatibility with
earlier versions of MediaWiki.
Change-Id: Ie11a401d60c834059fbf1b5625ca8ea093b3337c
While generator support was added to various actions, the continuation
parameters from the generators weren't being returned to the client.
This patch refactors the code for handling continuation out of ApiQuery
and into ApiResult, and then uses it in the other actions that need it.
Bug: 60734
Change-Id: I1a6e51cdc964ddcdd69aaa2f735223371233e8af
Add support for ApiPageSet capabilities in ApiWatch to support batch
operation on titles, pageids etc. The old 'title' parameter (for a
single page) is still supported to keep backwards compatibility.
Moved a function from ApiPurge to ApiPageSet: getInvalidTitlesAndRevisions() gathers
warnings about invalid/missing titles/ids in the requested page set.
Split from If993f6e8.
Change-Id: I820dcb64d469616b10741df013911197cc5bde29
Bug 50785: don't queue refreshLinks jobs on null edit or API
action=purge forcelinkupdate=1, since these actions are commonly
performed in order to clear the cache of a single page, and queueing
millions of jobs is not the response the user usually expects.
Change-Id: I2dbb5d21fa6b876adefd6bcfc93a83c5904d8d13
