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
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
Doxygen expects parameter types to come before the
parameter name in @param tags. Used a quick regex
to switch everything around where possible. This
only fixes cases where a primitve variable (or a
primitive followed by other types) is the variable
type. Other cases will need to be fixed manually.
Change-Id: Ic59fd20856eb0489d70f3469a56ebce0efb3db13
* 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
On Tim's request, this change moved getParserOutput() and getSecondaryDataUpdates()
from the ContentHandler to the Content interface.
Change-Id: Ia654aa8710a242ba5fe7a4eb528e6a6449035f59
Added information about the properties of the results of API calls
to action=paraminfo, including information about "property groups":
what should the prop parameter be set to to get that property.
Uses the same format for types as parameters already do.
The output format of some modules doesn't fit this, so the result
properties for them weren't added, or only partially.
Partially implemented modules:
* expandtemplates:
parsetree is in its own tag
* protect, allusers, backlinks, deletedrevs, info, imageinfo,
logevents, querypage, recentchanges, revisions, searchinfo,
usercontribs, userinfo, users, watchlist, upload:
response with partially complex structure
Not implemented modules:
* feedcontributions, feedwatchlist, opensearch, rds:
non-standard reponse
* help:
error is normal response; not very useful for automated tools anyway
* paraminfo, parse, pageprops, siteinfo, userrights:
response with complex structure
Change-Id: Iff2a9bef79f994e73eef3062b4dd5461bff968ab
action=purge with forcelinkupdate crashes when the rate limit is
reached, because the module passes an array rather than a string to
setWarning. The appropriate string is in the 'info' key of the array, so
just use that.
Change-Id: Ia0215290197e115e7272f945ab1bc5b81aeec80a
This supercedes I6d03bf2a, using better names for the new classes and
incorporating the changes requested by Aaron.
This change introduces the base class SecondaryDataUpdate to be used for any
updates that need to be applied when a page is changed or deleted. Until now,
this was done by the LinksUpdate class for updates and WikiPage::doDeletionUpdates
upon deletion. This patch uses a list of SecondaryDataUpdates in both cases.
This allows extensions (e.g. via the ContentHandler facility, once that is in) to
easily specify what needs to be done when a page is updated or deleted in order to
keep any secondary data stores (such as link tables) in sync.
Note that limited transactional logic is also introduced, so SecondaryDataUpdate
can be implemented to only commit their changes if all updates were performed
sucessfully.
Patch Set 2: fixing some coding style issues mentioned by Nikerabbit.
Patch Set 4: some stuff I kept from the old LinksUpdate class needs cleanup,
but might break extensions when changed. Marking as todo for now.
Patch Set 5: fixed misnamed member in LinksDeletionUpdate (thanks Aaron).
Change-Id: Ibe3e88fadd8c1d4063cf13bb6972f2a23569a73f
* {{REVISIONID}} and related variables are no longer blank after doing a null edit
* {{REVISIONID}} and related variables are no longer blank after calling action=purge&forcelinkupdate
ApiPageSet isn't really designed for non query usage, but a little hacking and it can be made to work in the ApiPageSet mould. Allows us to use titles, pageids and revids, without the work of validating them and such ourselves
Same caveat that you can't use a mix of them in one request - tough!
