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.
* Made HTMLFormField pass the HTMLForm object to the validation and filter callbacks (so that they can get a context)
* Added new parameter to SpecialBlock::checkUnblockSelf() to pass the user doing the request
* SpecialBlock::processForm() and SpecialUnblock::processUnblock() now require a context as second parameter; added SpecialBlock::processUIForm() and SpecialUnblock::processUIUnblock() as adaptators from HTMLForm as second parameter to context
* Internalise $mAddress/$mUser, $mBy/$mByName, $mEnableAutoblock, $mId as getTarget(), getBlockers(), isAutoblocking(), getId().
* This required editing AbuseFilter and CheckUser backwards-incompatibly, so push the rest of the changes out to those extensions.
* Attack the evil 14-parameter constructor and gratuitously-confusing newFromDB( $notVeryImportantParameter, $moreImportantParameter)
* Reimplement the hack for bug 13611 in a slightly less fragile fashion; could still do with further cleanup, but then again the login frontend is its own can of worms... :S
* Remove transitionary getTargetAndType() and newFromTargetAndType() methods
* Some optimisation in parseTarget()
* Fix the broken phpunit test mentioned in r84251
* Move to SpecialBlock.php, and rename class appropriately
* Complete refactor
* Use HTMLForm in block form. This changes most of the ids and field names on the form, but allows proper validation, nicer formatting, clears up several fixmes, and is generally Better(TM).
* Spin various parts out into static functions, several of which properly belong in the backend (but Block.php is a worse mess still)
* Invert some of the block options so that every checkbox makes the block more severe (so "check to disable email" is fine, but "check to allow usertalk edit" (default true) is inverted to "check to disable usertalk edit" (default false).
* revert r40359 (move doMassUserBlock() to core). No one seems to be using this function, which has nothing to do with the frontend UI in SpecialBlock (it might perhaps belong in Block.php); it is pretty bespoke for CheckUser, doesn't seem to have very much utility elsewhere.
Added option request parameter to User::editToken() and User::matchEditToken() and use them where possible from the api.
Also removed $_SESSION usage since it's no longer needed
Move token requringness check to the ApiMain
Adding an exception if we're using "gettoken" (block/unblock)
Remove array( 'missingparam', 'token' ), from the getPossibleErrors of modules that set requireToken method to true
"I wouldn't object to stylizing the API code to bring it in line with
the rest of MW on principle, but I'm not gonna bother myself." --Roan
<http://www.mediawiki.org/wiki/Special:Code/MediaWiki/60657#c5108>
If you're seeing this commit in blames, tell your blame tool to ignore
whitespace, e.g., git blame -w or svn blame -x -w.
* Instead of hiding read-restricted modules, throw an error when a user without read rights tries to use them
* Do the same for write modules when $wgEnableWriteAPI is false
* Indicate whether a module needs read or write rights in action=help and action=paraminfo
* BREAKING CHANGE: action=purge now requires write rights and, for anonymous users, a POST request
* Aggressively intval() numeric things; addresses the concerns raised on bug 11633
* Use ApiQueryBase::addTitleInfo() everywhere
* Remove a drug-induced-looking line from ApiQueryWatchlist.php
Doxygen documentation update:
* Changed alls @addtogroup to @ingroup. @addtogroup adds the comment to the group description, but doesn't add the file, class, function, ... to the group like @ingroup does. See for example http://svn.wikimedia.org/doc/group__SpecialPage.html where it's impossible to see related files, classes, ... that should belong to that group.
* Added @file to file description, it seems that it should be explicitely decalred for file descriptions, otherwise doxygen will think that the comment document the first class, variabled, function, ... that is in that file.
* Removed some empty comments
* Removed some ?>
Added following groups:
* ExternalStorage
* JobQueue
* MaintenanceLanguage
One more thing: there are still a lot of warnings when generating the doc.
