I know there's no second parameter to WikiPage::newFromID(), but this will change soon.
This follows-up I098dd36619fff3610be6894037220d3472b809d5.
Change-Id: Ic28b7e05db51e55a5f49fed70c042ba11e4d97fe
per pageid
Move the possibles errors set by ApiBase::getTitleOrPageId to
ApiBase::getTitleOrPageIdErrorMessages and remove it from used modules
Change-Id: If037e04665d2524c1f2476bc7996d9573753a4b8
* Use WikiPage::newFromID() directly instead of Title::newFromID() (for now it does not change anything but it will soon)
* Directly load the data from the master when creating a page from its name, it avoids both having out-of-date information
when doing the existence check and a second database query from LinkCache::addLinkObj() when calling (WikiPage|Title)::exists()
* Moved the page existence check to only be executed when creating a title from its name since if we have a WikiPage from its ID it must exist.
Change-Id: Ifaff725d955ce111c46d6b7f00610191820f3ced
* 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)
* Create the WikiPage object directly in execute() and pass it to both delete() and deleteFile()
* Reordered parameters of delete() and deleteFile() to be consistent and take both on the WikiPage and User objects (instead of relying on $wgUser); no callers outside of this class
* Fixed deleteFile() to match the behaviour of FileDeleteForm with oldimage parameter
* Pass the User object to getPermissionsError()
* Factorised duplicated code
* Added missing error code to ApiBase (and also a new one)
* Added missing possible error codes (with a new one too)
It's a parctice that dates back to 2006 when the API was first written, and frankly isn't covered by the coding conventions. Same thing with the docblocks, they're all copypasted with some bits changed and don't even make sense if you look at them in the genereated code docs.
I don't feel that any of us depend on this anymore (get a better IDE), so in the inerest of consistancy it's time we said goodbye to it.
* Actions come in two flavours: the show-a-form-then-do-something-with-the-result (delete, protect, edit, etc) and the just-do-something (watch, rollback, patrol, etc). Create abstract base classes Action and FormlessAction to support these two cases. HTMLForm is an integral part of the form-based structure.
* Look mum, no globals! :D Fully context-based.
* Implement watch/unwatch, credits and delete actions in the new system as proof-of-concept. This also gives the delete frontend a much-needed overhaul.
* Stub out the newly-deprecated functions from Article.php. This already reduces its linecount by about 15%, and there are plenty more actions still to do.
* Centralising actions like this is going to render a lot of hooks type-incompatible. There's simply nowhere you can put the ArticleConfirmDelete hook, for instance, where it can be passed an OutputPage as the second parameter. On the other hand, we can implement new hooks like ActionModifyFormFields and ActionBeforeFormDisplay, which can do much prettier stuff to the forms, like adding extra fields the 'right' way. Update LiquidThreads to use these new hooks where appropriate.
Deprecate old watch/unwatch parameters
Move generic watchlist stuff to ApiBase/getWatchlistValue (maybe needs renaming better?)
Tweak some braces in ApiEditPage
