- This is needed to for I90965346 ((bug 37453) Move
$wgDisable(Lang|Title)Conversion to ParserOptions)
because that change sets an option based on the Title,
and I don't want to duplicate that to all ParserOptions
that need it.
- Refactored ApiParse to have a WikiPage object available
and changed some part to take advantage of having this
object available. Also used ApiBase::getTitleOrPageId()
to reduce code duplication.
Change-Id: Iec98e472af9c43d940f77261367a796b0d7b4b54
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
This comes from
https://translatewiki.net/wiki/Thread:Support/MediaWiki:Missing-article
that asks for a link to the deletion log in the
'missing-article' message.
Instead of simply changing that message I replaced
it with two news messages 'missing-revision' when trying
to view an old revision and 'difference-missing-revision'
when showing a difference. This removes the "lego"
construction of 'missing-article' with 'missingarticle-rev'
and 'missingarticle-diff' submessages.
I had to keep current messages since they are still
used in extensions.
Change-Id: Ibe60c84cfea922a78b3ad22cc48185a109cd617d
Two reasons:
- the page must exists to reach this part of the code
- it's useless to have special classes (redirect, stub)
since this a link to the history and not to the
content itself
Change-Id: I59af2f237e0539842cc7777ddd44ba5ac500b070
* 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
* Use context everywhere
* Fix comments, including two functions from other files it references
* Remove pointless function return value
Change-Id: I29a0a2a54432c8ef7185a210c7f2f73c64bfb71c
* Added Article::getPage() as accessor to the WikiPage object so that it can be set in the context from MediaWiki::initializeArticle()
* Use it WikiPage::main() to call doViewUpdates()
I'm doing to this now so that I can revert r105790 and use the WikiPage object before the 1.19 release
* Pass the User object to Revision::userCan() in Linker::getRevDeleteLink()
* Return the result Linker::revDeleteLinkDisabled() in Linker::getRevDeleteLink() instead of storing it in a variable that will not be used
* Moved WikiPage::estimateRevisionCount() and WikiPage::isBigDeletion() to Title and marked those WikiPage methods as deprecated (only call in extensions removed in r107385)
* Show an error message when deleting a page to move another one in Special:MovePage and the deletion fails due to permissions errors (previously the form would simply show again)
* Cache the result of Title::estimateRevisionCount() since it's called two times when showing the deletion form and the user doesn't have 'bigdelete' right (one for the permissions check and the other when showing the number of revisions)
* Removed permissions check from WikiPage::doUpdateRestrictions() and left it for callers, resolves the todo from documentation
* Inverted $expiry and $reason parameter between WikiPage::doUpdateRestrictions() and WikiPage::updateRestrictions() for more consistency; WikiPage::doUpdateRestrictions() also requires all parameters to be passed
* WikiPage::doUpdateRestrictions() returns a Status object instead of bool for the older one; only possible error at the moment is a read-only database
* Updated core calls to these functions
* Made maintenance scripts using it simply protect all actions returned by Title::getRestrictionTypes() instead of hardcoded 'edit' and 'move'
* This also means that protect.php can be used to protect a non-existing page for creation
