RevisionStore::getPreviousRevision() and ::getNextRevision() don't
handle being passed a RevisionArchiveRecord very well. Even if they
would, it's not clear whether the user wants to be comparing with the
next/previous deleted revision or the next/previous revision even if not
deleted. So let's just make it an error, at least for now.
Bug: T208929
Change-Id: I151019e336bda92aa4040ba4162eb2588c909652
These new classes provide a mechanism for defining the
behavior of slots, like the content models it supports.
This acts as an extension point for extensions that need
to define custom slots, like the MediaInfo extension
for the SDC project.
Bug: T194046
Change-Id: Ia20c98eee819293199e541be75b5521f6413bc2f
Prior to I700edfa76, torelative=prev on the first revision of a page
would "diff" from an empty revision, and torelative=next on the latest
revision would diff to that same latest revision. People were depending
on that behavior, so restore it.
Bug: T203433
Change-Id: Ie81b58c196998a8047322740fe1d1fa44eff8526
During development a lot of classes were placed in MediaWiki\Storage\.
The precedent set would mean that every class relating to something
stored in a database table, plus all related value classes and such,
would go into that namespace.
Let's put them into MediaWiki\Revision\ instead. Then future classes
related to the 'page' table can go into MediaWiki\Page\, future classes
related to the 'user' table can go into MediaWiki\User\, and so on.
Note I didn't move DerivedPageDataUpdater, PageUpdateException,
PageUpdater, or RevisionSlotsUpdate in this patch. If these are kept
long-term, they probably belong in MediaWiki\Page\ or MediaWiki\Edit\
instead.
Bug: T204158
Change-Id: I16bea8927566a3c73c07e4f4afb3537e05aa04a5
We can't allow the main slot to be deleted. DifferenceEngine assumes it
exits.
We also shouldn't allow parameters such as `tosection-{role}` to be used
without the corresponing `totext-{role}`. This will help prevent people
from being confused into thinking that `tosection-{role}` will do
anything in that situation (as opposed to `tosection`, which did).
Bug: T203255
Change-Id: I58573bb2c1ee68e6907ef2e88385fe36e5184076
The main external change here is that it can now return diffs per slot,
and the various parameters for providing text are deprecated in favor of
templated per-slot versions.
Also, this deprecates the 'fromsection' and 'tosection' behavior
introduced for T183823 (extracting a section's content for the diff) in
favor of the more logical behavior requested in T185723 (expanding
'fromtext-{slot}'/'totext-{slot}' as if for a section edit).
Bug: T200569
Bug: T183823
Bug: T185723
Change-Id: I700edfa766bbc320887f2e0b7507fcdb11e72cdc
Some diffs can be really huge. Since ApiComparePages is intended to
return only the diff and some small metadata, bypass $wgAPIMaxResultSize
to allow the diff to be returned even if it's insanely huge.
Really insanely huge diffs might still make PHP run out of memory, even
before it gets the chance to return the diff to the API. That is outside
the scope of this change.
Bug: T184412
Change-Id: I755417f573c3caf85031d03b262aa55bd8cf36d7
The deprecated diffing in prop=revisions and such used a 'rvsection'
parameter. To enable migration of things using that, action=compare
needs corresponding section parameters.
Bug: T183823
Change-Id: If1a0e2df614c083b37640418c69cca367ce0e895
Several classes have a "selectFields()" static method to tell callers
which fields to select from the database. With the recent comment table
change and the upcoming actor table change, this pattern has become too
simplistic as a SELECT will need to join several tables to be able to
retrieve all the needed fields.
Thus, we deprecate the selectFields() methods in favor of getQueryInfo()
methods that return tables and join conditions in addition to the
fields.
Change-Id: Idcfd15568489d9f03a7ba4460e96610d33bc4089
Support diffing deleted revisions, user-supplied text, and additional
properties about the diffed revisions such as the user and edit summary.
Bug: T20189
Bug: T30047
Bug: T164529
Change-Id: I5565d717d9c2fd19da7cae02890a15e244cc238b
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
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
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
Fixed a little documentation issue, removed a line of unreachable code
and fixed up two formatting issues in the process.
Change-Id: If29391ee1a0daf19973437f36c3216b8716debd0
See bug 44341 for action=parse, but the problem with interwiki
processing can also be happen in other modules.
This gives clearer error message on some modules
For example action=move:
Bad title "*title*"
instead of:
Unknown error: "immobile-target-namespace-iw"
Change-Id: I86524533dfd778a169b39968999918a1f531efeb
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
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
Representing content_model and content_format as integers in the
database was suggested by Asher mainly to save space.
This change entails some refactoring and renaming, but no big
change in logic.
This lets the client distinguish a legitimately blank diff (identical revisions) from one that does not exist or which they do not have permission to view.
getDiffBody doesn't tell the caller why it failed, so there may be a better way to do this.
