3e36ba655e added an option for passing a page ID to this method of
Revision, and e03787afd9 switched it to a Title and made it mandatory.
This behavior propagated to the method in RevisionStore. As far as I
can tell, the parameter does not help anything, but it can add a
database query to get the page ID if it's not cached, and impedes
conversion to LinkTarget. I can't figure out any reason to not
completely drop it. I've noted it as deprecated but still supported it
for now for compatibility -- I found one extension that does pass it.
(It's ignored, though, which theoretically would be a behavior change if
someone was passing a Title that didn't match the revision ID.)
While I was at it, I added the method to RevisionLookup, although it's
only used in later patches. Properly I should move that piece to a later
patch, but it didn't seem worth the effort.
I didn't change the Revision method, because the whole Revision class is
deprecated anyway.
Change-Id: I26ef5f2bf828f0f450633b7237d26d888e2c8773
Update rows in batches, using the same logic as is used by
removeWatchBatchForUser().
Also remove the functionality for updating all rows, and move that to
resetAllNotificationTimestampsForUser() instead. To that end, add a
timestamp parameter to that method and to the job it uses, and make
setNotificationTimestampsForUser() behave like a backwards-compatibility
wrapper around resetAllNotificationTimestampsForUser() when no list of
titles is specified.
Bug: T207941
Change-Id: I58342257395de6fcfb4c392b3945b12883ca1680
Follows-Up: I2008ff89c95fe6f66a3fd789d2cef0e8fe52bd93
Use WatchedItemStore's built-in feature for clearing the entire
watchlist when no timestamp is specified. When a timestamp is specified,
this will still use the inefficient page-by-page method, which I'll
improve in a follow-up commit.
Bug: T207941
Change-Id: I2008ff89c95fe6f66a3fd789d2cef0e8fe52bd93
MCR deprecated the Revision class in favor of the broadly similar
RevisionRecord, and more interestingly added the concept of multiple
content "slots" to revisions.
Thus, prop=revisions, prop=deletedrevisions, and so on gain a parameter
to specify which slots are wanted. When this new parameter is not
specified (and any content-related props are specified), a warning about
the legacy format will be issued.
The rest of the modules just needed to call methods or use constants on
RevisionRecord instead of Revision. ApiQueryDeletedrevs wasn't touched,
since it has been deprecated since 1.25 anyway.
This also updates a few non-query modules that don't depend on details
of editing, diffing, or viewing MCR revisions that haven't been figured
out yet.
Bug: T200568
Change-Id: I1327d1784f5cedb006cd74df834cf9a560a77a5d
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
Undo traces of a practice we carried over from past projects and
existing examples that is neither universal nor actively encouraged in
the MediaWiki codebase.
Bug: T139301
Change-Id: I5c9c89b72a45a44aa4264a5e57b003c1a86cdf6e
Co-Authored-By: Brad Jorsch <bjorsch@wikimedia.org>
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
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
For example file pages from foreign repos, MediaWiki-namespace messages
that haven't been locally customized, and titles manipulated with the
'TitleIsAlwaysKnown' hook.
This allows clients to be able to display such titles as bluelinks
rather than redlinks.
This also has ApiPageSet populate LinkCache to make later checks of
->exists() and ->isKnown() more efficient.
Bug: T141963
Change-Id: Idbdfd2896c0ce9425ededd7cb4b60eda89ba7ef5
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 current token handling is a mess. This simplifies things greatly:
* *All* tokens are obtained from action=query&meta=tokens, rather than
being spread over action=tokens, action=query&prop=info,
action=query&prop=revisions, action=query&prop=recentchanges, and
action=query&prop=users. All these old methods are deprecated.
* Similarly, there is only one hook to register new token types. All old
hooks are deprecated.
* All tokens are cacheable.
* Most token types are dropped in favor of a 'csrf' token. They already
were returning the same token anyway.
* All token-using modules will document the required token type in a
standard manner in action=help and are documented in machine-readable
fashion in action=paraminfo.
Note this will require updates to all extensions using tokens.
Change-Id: I2793a3f2dd64a4bebb0b4d065e09af1e9f63fb89
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
When newerthanrevid or torevid is used and no pages are given, do not
throw a fatal PHP error.
When no pages are given in other modes, do not return a database error.
Bug: 48071
Change-Id: I5abcdf0fa20486f1198d1cc111461b3088a311df
These are needed for OAuth grants.
Note that, even if 'editmywatchlist' is not granted, various actions
will still allow for adding but not removing of pages.
Change-Id: Ie33446a228dd6ed0114730935c1bf65667f5ce01
This allows extensions to modify the array.
This completes the serie of hooks for similar get methods in ApiBase.
Change-Id: Ib398f5815ab57f25d56356b0997c55a03fd96874
This allows extensions to modify the param description of the ApiPageSet
params at once for each module, which used the ApiPageSet.
Change-Id: I2ed6f3ad38d3d84182b8525a6b247f721be7f460
This was broken in I7a3d7b6e, when the ApiPageSet parameters stopped
being returned by getAllowedParams() and so by extractRequestParams().
Although it would be broken differently if they had been.
Change-Id: I4b6ec21fd7b7c932856546df1ccad574d996db1f
- Missed item in ApiSetNotificationTimestamp.php
- Update link to mediawiki.org in ApiEmailUser.php now that the
page was renamed
Bug: 45633
Change-Id: I2a0a41317b9671fcd5fa1f9301cd67e619926a3e
* PageSet can now be used in any action to process titles/pageids/revids
or any generator, redirects resolution, and converttitle functionality.
* action=purge proper usage of MustBePosted()
* Add supports for all pageset capabilities - generators, redirects, converttitles to
action=purge and action=setnotificationtimestamp
* BREAKING CHANGE: ApiPageSet constructor now has two params instead of three, with only the
first one keeping its meaning. ApiPageSet is now derived from ApiBase.
* BREAKING CHANGE: ApiQuery::newGenerator() and executeGeneratorModule() were deleted.
Change-Id: I7a3d7b6eb015d21ec1a9b9d9c6af9d97663f3f9a
For historical reasons, all our API class had a dummy __construct which
simply calls their parent constructor. This patch removes all such
occurences to save out some bytes.
Change-Id: I667955d7821f780fc5ce23823d74dedb1729b9fa
API was using SVN's version keyword which GIT does not support.
All related methods were either removed, or for those that
could have been used from extensions, emptied out.
api.php?version now shows unrecognized param warning.
Change-Id: I910ca1448ed2ed697ac19b17c486d130aa1d7e03
ApiBase::getDB() doesn't take a parameter indicating whether DB_SLAVE or
DB_MASTER is wanted. Use wfGetDB() instead.
Change-Id: Ic2057a1561ad31a0638eea6bae887982a4fe8d80
It should be possible to query the notificationtimestamp as a page info
property, rather than only by querying the recent changes for the
watchlist. It should also be possible to clear or adjust the
notificationtimestamp via the API.
This patch does just that.
Change-Id: I8e2c0769e93802a6a09936899a41c07f9c4c9f25
