This works thanks to the new "deletetalk" parameter (the name is
consistent with "movetalk" to ApiMove). The API will return with a
warning if the page is already a talk page, or if the talk page
doesn't exist.
Note that the API response doesn't expose information about the talk
page deletion. This would likely be a breaking change to the module, and
is also not too easy to implement until FileDeleteForm is refactored as
well.
Bug: T263209
Change-Id: I30f2da190433a3ef9c0ac375f23b68acd3d6f190
In retrospect, I rushed the previous patch: we really need a way to tell
which deletion an ID belong to (and whether it was scheduled). So make
both result getters return an array with known keys that can be used
programmatically. Right now the class can only delete a single page, and
thus there's a single constant and this change is effectively a noop.
The deletionWasScheduled() method, introduced in 1.37, was
hard-deprecated out of an abundance of caution. There are no known uses
on codesearch, so it can probably just be removed in the next release.
Also reorder constructor params to DeletePage -- BacklinkCacheFactory is
a service injected by the factory, hence it shouldn't be grouped
together with value objects injected by the caller.
Change-Id: I32679b7cacc638ec3e9dc5b8dfe9bcc794b22ecf
- Use DeletePage in FileDeleteForm instead of
WikiPage::doDeleteArticleReal
- Properly handle scheduled deletions in FileDeleteForm: previously, a
null status value could indicate a missing page OR a scheduled
deletion, but the code always assumed the first, and it would generate
a duplicated log entry. The API response would also not contain the
"delete-scheduled" message. This has been broken since the introduction
of scheduled deletion.
- In ApiDelete, for file deletions, check whether the status is OK not
good. The two might be equivalent, but this way it's more consistent.
- Add some documentation for the Status objects returned by file-related
methods. This is still incomplete, as there are many methods using
Status and none of them says what the status could be. In particular,
this means that for now we keep checking whether the status is OK
instead of good, even though it's unclear what could produce a
non-fatal error.
- In LocalFileDeleteBatch, avoid using a class property for the returned
status, as that's hard to follow. Instead, use a local variable and
pass it around when needed.
Bug: T288758
Change-Id: I22d60c05bdd4a3ea531e63dbb9e49efc36935137
Unused except for DeleteAction, which now uses a custom query (similar
to the one in ContentHandler::getAutoDeleteReason). Passing the
parameter is hence hard-deprecated, and it will be removed in 1.39.
Also escalate the exception logging from wfDebug to error, since we want
to know what exceptions are being caught.
Bug: T288282
Change-Id: I91ed9574da68bc7ff36e968f016da390b6d295ed
Instead of putting logID/false in the status' value, add getters that
can be used to retrieve this information. Also, make it return an array
of log IDs, which is easier to expand later on to account for deletion
of related pages (e.g. associated talk page).
Note: this change will be backported to 1.37.
Bug: T288758
Change-Id: I7ef64242ae0cb7018a4b1e8eb004a5563925b9a4
Allow specifying the title used for rendering error messages in
ApiErrorFormatter.
Then, specify one in ApiEditPage (and a few similar modules that deal
with single pages) once we've figured out which page is being edited.
Bug: T247661
Change-Id: Ic3d70efc23744ef6e90abc445f3babebf45c4697
This trait is not needed in ApiBase and its presence here is
proving to be problematic. See I795db12.
In this patch, the trait usage (more precisely the 'use statement')
has been removed from ApiBase and accordingly the signatures of
ApiWatchlistTrait::getWatchlistValue() and ::setWatch() have been
altered to now require User object.
With these changes, the abstract getUser() method in the trait is no
longer needed, so it has been removed also.
All core usages of the affected functions are fixed in this patch.
The trait is used in only one extension according to codesearch tool,
the extension will be fixed in Ic22e163.
Bug: T262175
Bug: T248512
Follow-up: Ia18627b9824dca81f44f0571e8420d89b7626cf6
Change-Id: Idabcea71edfca9e7ed42000a258c99ff407873d4
This introduces an ApiWatchlistTrait that refactors out common code
across APIs that allow you to watch pages. Some methods have been
migrated from ApiBase and changed completely, but codesearch suggests
they aren't being used outside the API modules in this patch.
Bug: T248512
Bug: T248514
Change-Id: Ia18627b9824dca81f44f0571e8420d89b7626cf6
No classes extend ApiDelete, and this is essentially a breaking change
(previously accepted WikiPage or Article)
Update calls to WikiPage::doDeleteArticleReal to use the new signature
Bug: T247869
Bug: T247870
Change-Id: I48d9d8a2e1df92b81d8e477434c15e8ab3e90f3c
When batched deletions via the job queue were added in Ie800fb5a, the
way this was reported caused ApiDelete to report an error. Instead it
should report success with appropriate signaling to the client.
Bug: T212356
Change-Id: I1ef66277e988572c6720cf3e3cb36b18530746b4
Still missing a test for file deletion, because I didn't figure out a
simple way to create a file page that I can test on.
Change-Id: I276e84b4f7777e5dd5be5520e572b9b9bb0c0633
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
PHP 7.2 broke existing functionality in making count( null ) raise a
warning. So add tests for null all over the place, or change tests where
we know the value is null or an array (but not false, empty-string, or
0) to just cast to boolean.
Bug: T182004
Change-Id: Idfe23a07daa9f60eee72f2daf04304be87057a29
Such a deletion doesn't currently produce a log entry, but that's a
different bug that also occurs via the web UI.
Bug: T167693
Change-Id: If6e751aa28960243db49ac9b81fe518edba11bd5
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
Since the recent change save of logged actions is now deferred, we need
to move tagging of API deletions to the RC save, like other API actions
do already. Otherwise, only the log gets tagged, not the RC.
Bug: T108564
Change-Id: I4e6e18e7f8fb7a6b0932e7579bafddcc1b0a9758
Some were being logged, and some weren't. Let's log them all
automatically when PARAM_DEPRECATED is processed, instead of requiring
each module to manually log them.
Bug: T117569
Change-Id: Ia38aeeccd0b9857b12b28914f509284483fbcca8
ApiDelete::delete() and ApiDelete::deleteFile() are altered from public
to protected visibility. This is not believed to affect any extensions.
Also get rid of the token variables, as they are not doing anything useful.
Bug: T108564
Change-Id: I6143043dafa6425a0df4baefe970620cbe69466c
* Potentially long running POST requests often use multiple transactions,
talk to multiple services, or defer updates. Try to make sure they have
a chance to complete all of the work. WMF already sets ignore_user_abort()
across the board in config, but this applies it to key spots for all
installs, in addition to bumping the time limit.
* Eventually this can lower the need for high overall time limits.
Bug: T102890
Change-Id: I893ddd773064dcd63b5b24c84c6391974f4b5aee
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
- 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
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
WikiPage was no longer valid given the current type hint. Added
types and documentation where missing.
Change-Id: Ie0a3a8fff3ad496b723958133867df48a695d3b7
