New types 'text' and 'password' for where a <textarea> or
<input type="password"> would be preferred over <input type="text">.
Some timestamp parameters get actually tagged as 'timestamp'.
'submodule' types change the 'submodules' output property from a boolean
to an object indicating the mapping from values to module paths. And
they get an indication of the submodule parameter prefix (e.g.
generator's "g"), if applicable. "generator" actually gets reported as a
submodule type, using this new mechanism.
action=paraminfo will now indicate ApiBase::PARAM_RANGE_ENFORCE status,
and return better-formatted defaults for timestamps and booleans.
Change-Id: Ic862d6f8fe13f7eb6b4298683514d33af5823e47
You can add tags at the same time as performing action=edit, as long as you
have the "applychangetags" right. Also, you can add or remove tags after
the fact from revisions and log entries using the API action=tags.
No UI is provided for either of these changes. The target audience is user
scripts, gadgets and similar tools.
Includes a new log parameter format type: "list", for a comma-separated
list of values.
Logging of change tag events is limited to those that do not accompany an
edit (i.e. those done after the fact), and is hidden from Special:Log by
default, similar to the patrol log.
Bug: T20670
Change-Id: I37275e0f73fa3127f55da0c320b892551b61ee80
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
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
There are cases where the list of values for a 'prop' parameter may be
manipulated by a subclass or by a hook function of some sort. Rather
than requiring the subclass/hook to completely replace a monolithic i18n
message, let's add the possibility of separate messages for each value
in the list.
Bug: T77930
Change-Id: I0bb061c62ebeef125062460e26306c88390f7b31
Add the user right 'editcontentmodel', which is required to change the
content model while editing a Page.
Bug: 70901
Change-Id: I54f59539f1045092ec0de76c31cb47ca19c56874
XMLHttpRequest does not allow overriding the "User-Agent" header. To
allow such clients to make effective use of the api-feature-usage log,
let's give them a different header they can use.
Change-Id: Ia1e4f52f35f8d9a8e9f5590a00854d14c11f7cc9
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
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
* Group methods in ApiBase by function
* ApiBase::validateLimit and ApiBase::validateTimestamp are now
protected; there are no callers in any extensions in Gerrit
* Group methods in ApiQueryBase by function
* Move ApiFormatFeedWrapper out of ApiFormatBase.php
* Deprecate some methods in ApiQueryBase that seem useless and are
unused in core or any extensions in Gerrit
Change-Id: I32092f13906b6826d2137401724c21ccefa6f670
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
On the advice of the Research Analyst, quote all data fields and add
slashes to escape quotes.
Change-Id: I3471475c0ae7a11398a774b1a14d023676259c04
Follows-up: Ifd640883e46f3e6c8179c63d122c704b046674ca
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
- Added since to @deprecated
- Use lowercase array on @param
- Added missing type on @param
- Swapped type and variable on @param
- Fixed spelling of @return
Change-Id: Idbbc6b4c8aadb6d98c636f53024ac513346c912b
When deleting a page, only check that the user can edit through
protection, rather than running all of the other checks. This is Tim
Starling's option 3 from bug 69380.
Bug: 69380
Bug: 69398
Change-Id: I5a7c4147bd241dc086fda6c16827f9554d78599b
This was probably overlooked in the past because usually the only users
who can delete pages also have permission to edit the relevant
protection levels.
Change-Id: Ibe28a69c9fbab00b81c53b1643df722a3f1fbf19
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
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
Add a hint to the getError function which should be called in the
getPossibleErrors() function.
Also do this for getTitleOrPageId.
Change-Id: I601feb8a5b8699ce4d81814aa3cd127552a525ac
The existing doc blocks for all three of these functions is entirely
wrong.
* ApiBase::requireOnlyOneParameter
* ApiBase::requireMaxOneParameter
* ApiBase::requireAtLeastOneParameter
Change-Id: Id0dd86be3cbfa813a43f918c7d780c7ee2afc09e
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
