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
Rely on the mass-rollback logic in MWExceptionHandler instead.
This results in a better chance of atomicity.
Change-Id: I2eb5661d4acc105a1323d69c5463268c234bd745
Use rollbackMasterChanges() instead so that all DBs get reverted.
Otherwise, external DB updates may get committed while related local
DB changes are rolled back.
Change-Id: I74de77f4b12dc15c0473c272d090caeeb97d6983
* They no longer commit the update, but just make sure
it is part of a transaction. The BEGIN/COMMIT will
happen at request start/end given DBO_TRX or in this
method otherwise (like when in CLI mode). This avoids
premature committing of other transactions.
* FileDeleteForm was the only caller using $commit=false
for WikiPage::doDeleteArticleReal() and its proxies
WikiPage::doDeleteArticle() and Article::doDeleteArticle().
The ugly $commit flag is now removed.
* No caller was using $id for WikiPage::doDeleteArticleReal()
and its proxies WikiPage::doDeleteArticle() and
Article::doDeleteArticle(). It is now removed and we can
be sure the lock() and CAS logic always hit in the method.
The rollback() calls are not needed given the page row lock
and having them there could break outer transactions.
* Updated FileDeleteForm to use startAtomic()/endAtomic() so
the article and file delete are still wrapped in a
transaction. Note that LocalFile::delete() does reference
counting and trxLevel() checks so it will not try to begin()
and break FileDeleteForm's transaction via startAtomic().
* Moved less important 'page-recent-delete' key update down
for sanity in case it blows up.
Change-Id: Idb98510506c0edd02236c30badaec97d86e07696
WikiPage::doDeleteArticleReal returns the log id as the value of the
returned Status object, and ApiDelete depends on this. ApiDelete is also
expecting FileDeleteForm::doDelete to do the same, so let's make it
happen.
Bug: T114893
Change-Id: Ia887d88f16378134924d122dad6c17c8a981f0e6
The doDeleteArticleReal() call does BEGIN but not COMMIT
and the LocalFile::delete() does no trx commands because
trxLevel() > 0, so the COMMIT here is needed as things are.
This reverts commit 985a8f7214.
Change-Id: I72529965ae9fe41641f22af12a40ec13ff65a2c1
The title used for Linker::link in all places are mediawiki pages, which
are known to be exists (and blue), because there are definied in en.json
Change-Id: Ib3b6e4f4f6cef059a502aaabfcfc17730b4445a6
Some special pages or actions have a link for users with editinterface
rights to edit the message used in scroll down menu.
When the message is parsed for the scroll down menu the config
$wgForceUIMsgAsContentMsg is used, but that was not used for the edit
link.
Add a new function Message::getTitle and use it in all places in core.
Most benefit will have the edit link for MediaWiki:Licenses on
Special:Upload, because commons.wikimedia.org has that message in
$wgForceUIMsgAsContentMsg.
Change-Id: Ib800b9adcc9ae88ef53228b66838bf61d2065f0f
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: I7f605aa9e117b5fd80d9b1440864fe526d2b14a5
Also 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.
Change-Id: Ic36c8c7820a6c2d603f1138130670c6bf6a1ca59
These are needed for OAuth grants.
Note that, even if 'editmywatchlist' is not granted, various actions
will still allow for adding but not removing of pages.
Change-Id: Ie33446a228dd6ed0114730935c1bf65667f5ce01
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
The LogPage::logName method has been deprecated in 1.19,
warnings being planned in 1.21.
This change removes any call in the MediaWiki core to this
deprecated method.
Removing extra whitespaces/tabs in includes/ProtectionForm.php.
Change-Id: I1907f17341ecb6448967a5283e3c913778dcb1a9
* For consistency with WikiPage::doDeleteArticleReal().
* Also log suppressed deletions in suppression log instead of normal log.
Change-Id: Ie63bac5ebd77d0269ba2075d66cf3ba31668e595
* The problem is that Title::userIsWatching() relies on $wgUser,
which is not suitable on every case. Instead User::isWatched()
requires both an User and a Title object.
* Replaced all core calls from the former to the latter
* Added a cache in User for the WatchedItem instances so we do not
need to do a database request every time something want to know
whether a page is watched or not, which can happen several times
per request.
Change-Id: Ifa9c55b7ffb487ce6893c74df233eedc7654dc5e
This entails some refactoring to actually surface the log_id all the way
up:
* Made doDeleteArticleReal() return a Status object rather than a
constant, and put the log_id in $status->value. This Status object is
also passed to the ArticleDelete hook.
* Kept doDeleteArticle() the same for extension compatibility.
* Switched all core callers of doDeleteArticle() to
doDeleteArticleReal() and surfaced the error message from the Status
if appropriate, rather than hardcoding 'cannotdelete' all over the
place.
* Exposed the log_id in ApiDelete
* Add 'delete-hook-aborted' message for when a hook aborts the deletion
but does not provide an error message. Previously this just caused the
'cannotdelete' message to appear.
Change-Id: Ia6415b390d5d4172ce96667f46ccdba2be02461f
* Moved $wgUploadMaintenance check after permissions and read only, so that the user doesn't think the error is temporary if he both doesn't have the permission and $wgUploadMaintenance is true
* Show normal error page when $wgUploadMaintenance and added a message for the error title
* Moved watchlist updating to FileDeletForm::execute(), it has nothing to do in doDelete() (would also be executed for api requests, etc.)
* Added $user parameter to FileDeletForm::doDelete() to pass the user doing the action
* Use WikiPage instead of Article
* Make OutputPage::setSubtitle(), OutputPage::addSubtitle() and OutputPage::appendSubtitle() accept a Message object in addition to a string
* Added new method OutputPage::addSubtitle() to replace appendSubtitle() and marked it as deprecated
* Clear the subtitles when showing an error page
* Always show the subtitle from Article::viewRedirect() when showing a page; left the parameter for use in EditPage
* Make Article::setOldSubtitle() add two subtitles and has to set "display:inline;" for the three possible divs to avoid too many spacing
* Removed the six different backlink subtitles and added one new message 'backlinksubtitle' to replace them and added OutputPage::addBacklinkSubtitle() to factorise common code
* Changed EditPage's view source to show "View source for <Page>" with the same backlink in subtitle for consistency with other back links and page titles
* Use the new 'cannotdelete-title' message for the title on error instead of "internal error"
* Don't use OutputPage::showFatalError() but add the content by "normal" methods (related to the item above)
* Don't use the $DeleteReason and $DeleteReasonList member variables in Article and FileDeleteForm but local variables since they are not used anywhere else
* Moved down some variable definitions near where they are used so that they are only set when they will actually be used
* Same for the setPageTitle() call with 'delete-confirm' message in Article::delete() that is now in Article::confirmDelete()
* Added missing "true" as fourth parameter of WikiPage::doDeleteArticle() call that was missing
* Factorised getTitle() and getUser() calls
* Salt token with array( 'delete', 'page title' )
* PermissionsError now calls OutputPage::showPermissionsErrorPage() to display the error (this is needed to make the item above work correctly)
* Removed the override of the HTML title in OutputPage::showPermissionsErrorPage() so that it shows "Permission errors - Sitename" instead of simply "Permission errors" for consistency with the other things
* Pass the error array returned by Title::getUserPermissionsErrors() to PermissionsError where available
* Converted direct calls to OutputPage::showPermissionsErrorPage() to throw an PermissionsError error instead
* Added 'action-rollback' message that will be displayed when accessing action=rollback without sufficient rights
* Changed getRestriction() in subclasses of Action to return null when they previously returned 'read' so that user rights can be check with Title::getUserPermissionsErrors()
* Reordered checks to do first user rights, then block (if needed) and finally read only (also if needed) so that users don't think the error is temporary when they both don't have right and the database is locked
