Though getOutput() is what first came to mind, I do not particularly
like the name, partly because it is used in many, many places as a
method that returns an OutputPage object.
* Renamed the method to __toString(). This is appropriate because
each instance, at any given time, corresponds to a single string
value (and exceptions cannot occur during this conversion).
* Removed unnecessary variables from ApiQuery and ExportTest. In
these and most other cases, it should no longer be necessary to
call getOutput() explicitly.
Change-Id: Icf202743d1f332f8981338f42eb6e3e5a04abdf1
Specifically, it is not necessary to use output buffering functions
to capture XML generated by the export code because it is already
possible to set the "output sink" object to be used.
* Created a DumpStringOutput class, which appends all output to a
string property rather than printing output immediately.
* Used that class, instead of ob_start() and ob_get_clean(), in
ApiQuery and ExportTest.
Change-Id: I238f5d5ec7fd442c845b25cb59ef81ac3285099f
* Set API response metadata on the AuthenticationRequest metadata so it
is output as an assoc generally.
* Remove the 'image' field in AuthenticationRequest::getFieldInfo()'s
response, since we ended up not using it anywhere.
* Make it so meta=authmanagerinfo can be used on private wikis without
logging in, so action=clientlogin can be used to log in.
** This generalizes the exception for meta=tokens that was added in
I83dafb030.
* ApiAuthManagerInfo needs the "messageformat" parameter.
* ApiAuthManagerInfo shouldn't be publically cached, since the responses
vary depending on session state.
Change-Id: Iea5ddb4ef9febed18f16a7ae8314968026f39148
Changes here are:
* action=login is deprecated for use other than bot passwords
* list=users will indicate if a missing user name is creatable.
* Added action=query&meta=authmanagerinfo
* Added action=clientlogin is to be used to log into the main account
* action=createaccount is changed in a non-BC manner
* Added action=linkaccount
* Added action=unlinkaccount
* Added action=changeauthenticationdata
* Added action=removeauthenticationdata
* Added action=resetpassword
Bug: T110276
Bug: T110747
Bug: T110751
Bug: T32788
Bug: T67857
Bug: T28597
Bug: T76103
Change-Id: I244fa9b1e0623247d6d9fa30990411c6df94a496
The problem is that ApiQuery requires the 'read' right even though
ApiQueryTokens doesn't.
So, we introduce an exception: if action=query gets only meta=tokens
(and optionally rawcontinue and indexpageids, since they don't affect
anything), no other modules and nothing in the ApiPageSet,
ApiQuery::isReadMode() will return false.
Bug: T130112
Change-Id: I83dafb0305ff0cb1fc3bac668b88b5d2022e5880
No more uses found in core or Gerrit extensions for the following methods:
* ApiQuery::getGenerators() was removed (deprecated since 1.21).
* ApiQuery::getModuleType() was removed (deprecated since 1.21).
* ApiQuery::setGeneratorContinue() was removed (deprecated since 1.24).
Change-Id: I1d46adc9ecad598c7d7726a2243bba4f7a04531a
Only works for the currently logged-in user (I'm not sure how that works
with bots, if OAuth will do that correctly or whatever) but will help us
do some neat stuff with tools that use the stash - including resuming
uploads.
Bug: T85561
Change-Id: I215ac6936185563f4c7b42a4bced65e4b096fd15
Re-adds I6f807adc9cbf71c5d7b83c7eec43965dce1d2a16 and
Ic04daf475b936b942833362c7a979dde671b3ef4 (reverted in
35ccd9c2fe) with 1:1000 sampling
to avoid swamping the statsd hosts.
Also fixes query module logging.
Bug: T102079
Bug: T106450
Change-Id: I8b9366407c0d1713790d08e69aaa518130f01977
The new format is much easier to use correctly, and should therefore be
the default. The old format is maintained for clients that need the
additional flexibility.
Bug: T96858
Change-Id: I984e63581f4ef23ccada916b6d45131d1fb5e001
While we could fix the issue at hand by moving the setArrayType() call,
it's more robust to explicitly remove *all* metadata.
Bug: T96942
Change-Id: I313b19339474ea34880ebef31851eefdf14a7a07
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
It's excessively difficult to determine if the logs of people hitting
this warning are really going to be affected by the change or if they're
making queries where it won't actually matter.
Since 1.26 is coming soon, and with it the decision as to whether to
pull the switch on I984e6358, let's retarget the warnings to those cases
where it's possible it would actually break someone's code.
Change-Id: I91f170fd7d4c791ca8f5d3592c888700f4d5aa97
The profileIn/profileOut pair should be covered by the Xhprof profiling
of the method calls it was wrapping.
The profileDBIn/profileDBOut pair are covered by profiling done by the
Database class.
Nothing in extensions in Gerrit is calling anything besides the
profileIn/profileOut pair (and likely those are only to avoid core
formerly throwing exceptions from internal profileDBIn/profileDBOut
calls), and nothing in core or extensions-in-Gerrit is using the methods
for fetching profiling data.
The methods are left as stubs for now to allow for backwards
compatibility in extensions.
Change-Id: I05ba4e2762dc86d5e2bafc183dce701239b43f5c
Needed to conditionally register API modules. The previous way, messing with globals
from extension functions, is getting problematic because Config class will make this
impossible.
Change-Id: I86b40aeec555dd6b3cd82cab31d96e85fdf0a665
It has long been requested that list=search and list=prefixsearch be
able to indicate the search result ordering when used as generators.
This change introduces a generic mechanism to allow for generators to
specify additional page data.
Bug: T16859
Bug: T75623
Change-Id: I115338d2bd890ccc109a79c65f92099c0d41fc2d
list=deletedrevs has always been an odd one: it pretends to be a prop
module sometimes in taking titles from ApiPageSet, but when the pageset
supplies no titles it acts like a list module. This causes problems
such as bug 71389, and makes the whole thing unnecessarily confusing.
The solution is to split the "prop" and "list" aspects into separate
modules: prop=deletedrevisions when input should come from ApiPageSet
and list=alldeletedrevisions when not.
At the same time, let's take advantage of the situation to clear up some
other bugs. And let's share the revision-formatting code with
ApiQueryRevisions instead of partially reimplementing it.
Bug: 23489
Bug: 27193
Bug: 44190
Bug: 71396
Bug: 71389
Change-Id: I3e960d5c655bc57885d6d4ee227e67104808add7
The default behavior for continuation for action=query will be changing.
Warn clients that they will need to update.
Change-Id: I52d048040e898a0c9630e2aed071b339ec12de42
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 existing API help, formatted as basically a plain-text document
embedded in XML and with a little bolding and a few links
syntax-highlighted in after the fact, works ok for experienced programmers
but isn't at all newbie-friendly. Further, all the help is hard-coded in
English, which isn't very friendly to non-English speakers.
So let's rewrite it. The help text is now obtained from i18n messages
and output in HTML, with the default display consisting of help for a
single module with links to help for other modules. This, of course,
necessitates deprecating many of the existing help-related methods and
hooks and replacing them with new ones, but backwards compatibility is
maintained for almost everything.
At the same time, action=paraminfo also needs to support the
'description' and other help-related fields being output in wikitext or
HTML, and I11cb063d (to access all modules via the 'modules' parameter
instead of having 'modules', 'formatmodules', 'querymodules', and so on)
is folded in.
And we also add Special:ApiHelp. When directly accessed, it simply
redirects to api.php with appropriate parameters. But it's also
transcludable to allow up-to-date API help text to be included within
the on-wiki documentation.
Note this patch doesn't actually add i18n messages for any API modules
besides ApiMain and ApiHelp. That will come in a followup patch, but for
the moment the backwards-compatibility code handles them nicely.
While we're messing with the documentation, we may as well add the
"internal" flag requested in bug 62905 (although the 'includeinternal'
parameter it also requests doesn't make much sense anymore) and a
"deprecated" flag that's needed by several modules now.
Bug: 30936
Bug: 38126
Bug: 42343
Bug: 45641
Bug: 62905
Bug: 63211
Change-Id: Ib14c00df06d85c2f6364d83b2b10ce34c7f513cc
With the success of prop=redirects, let's create prop=linkshere,
prop=transcludedin, and prop=fileusage.
Let's also add a miser-mode-sensitive 'namespace' parameter to
prop=redirects, since the other three have a 'namespace' parameter using
the new *_from_namespace fields.
Change-Id: Ib650db9988a553771582eed0c183d0cae4b71252
Soon the simplified continuation will become the default for
action=query. This parameter will then serve select the return of the
raw continuation data. To allow for clients to transition without
"unrecognized parameter" warnings, I'd like to add the parameter now
before even adding deprecation warnings.
Change-Id: I5f6895b6a94c53a231a50707ee9463f91295da8f
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
This allows action=paraminfo to indicate when a parameter is specifying
a submodule (so clients can detect what the submodule names are). This
will also allow the future action=help HTMLization to easily auto-link
to submodule docs, and will allow ApiSandbox to handle submodules more
generically.
For BC, rather than directly specifying "type": "submodule", it lists
the names of all the submodules as the type and adds an additional
"submodules" indicator on the param info object.
Change-Id: Id31babdc81d970ac781ec11daa3cdafef18ecd5d
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
If someone sets $wgAPIMaxResultSize crazily small and then queries a
large number of pages, it can cause ApiQuery to fail to populate the
'pages' node. Then submodules might add data to the node, leading to
errors from the XML formatter (or bogus output from other formatters).
While that particular failure mode is probably going away soon, it's
still good to catch the error situation.
Bug: 68989
Change-Id: If0b2eda421fd86dd7acc4fe48cec47741e214221
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: I7b65fe04db431342cc58b469dc48f41a50c4e891
This way we no longer need to disable size checking just for one operation
(enable|disable)SizeCheck functions were depricated.
Overall, this is a much better practice than disabling than re-enabling
the flag, as it might lead to accidentally forgetting to re-enable it,
just like the issue with the dangling file handlers, etc.
Example:
disable, do some complex logic, re-enable. And later, by accident,
the complex logic is changed to return a value half-way, or throws
an exception that gets handled as part of normal operations. This
results in the unsafe disabled state of the result object,
which is not good (tm).
Change-Id: I389a334d35f52f23a1847aca4aef5e96b262f589
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
Which type is used depends on the ApiModuleManager responsible for
the API module. There are two managers, one in ApiMain and one in
ApiQuery. Both contain a list of API modules they instantiate.
Both use $this as the first parameter in the constructors of the
individual modules. There is no other regular way to instantiate the
modules, so we know the type must either be ApiMain or ApiQuery.
The lists don't intersect.
I would have prefered the naming scheme $mainModule for ApiMain
modules and $queryModule for ApiQuery modules but since this
doesn't add much I left the shorter variable names untouched.
Change-Id: Ie6bf19150f1c9b619655a06a8e051412665e54db
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Also added some missing @param.
Change-Id: I758fa4ad80ac95e2ddd3770bcb9b7d2e57ec34ea
It's pretty much like action=opensearch but can be used as a generator
which can be handy when you need to retrieve both the list of pages and
some information about them.
Change-Id: Iaffe30a0f7402e1316c4885a805692a34bbe1a6a
While redirects can be sort-of queried using list=backlinks with
blfilterredir=redirects, we can get more accurate results with a module
dedicated to this purpose. We can also get the fragment of the redirect
without having to load the content of the redirect page and parse it.
I'm a bit surprised I was able to put together a query for this that
will work as a prop module. Or did I overlook something?
And then we may as well add the corresponding list=allredirects, to work
like alllinks, allfileusages, and alltransclusions.
Bug: 57057
Change-Id: I81082aa9e4e3a3b2c66cc4f9970a97eed83a6a4f
Certain applications, such as the generation of PDFs, could use a list
of all non-anonymous contributors to the page (as well as a count of
anonymous contributors) without crawling the output of prop=revisions.
This patch adds a prop module to retrieve this information.
Including the IP addresses of anonymous contributors is not realistically
possible without further schema changes, so that is not done here.
Additionally, revisions with DELETED_USER will be skipped entirely.
Change-Id: Iaff50dfb09016154901a5197aa14eb9f8febcbc5
- Removed double spaces
- Added space after if/switch/foreach
- Removed space on elseif
- Added space around parentheses
- Added newline at end of file
- Removed space before semicolon at end of line
Change-Id: Id40b87e04786c6111e6686d7f7eea1e588bdf37d
This allows the client to enumerate through entries of the imagelinks
table.
This can be useful to find images from foreign repos used on the own
wiki.
Change-Id: I2ad0579e3521868d39f7d495ea9c83a2cd9731d6
