* Make UserrightsForm::doSaveUserGroups(), addLogEntry() and helpers non-static again so CentralAuth can override them; remove the short-lived UserRightsLogEntry hook
* Let UserrightsForm::fetchUser() return a WikiErrorMsg on failure
* In ApiUserrights, use an instance of the UserrightsPage class rather than calling its methods statically. This also enables interwiki userrights in this module
* Add some messages to ApiBase::$messageMap
* Add ustoken=userrights to list=users
* Move the non-UI part of UserrightsPage::saveUserGroups() to the static and more generic doSaveUserGroups()
* Add a $reason parameter to UserrightsPage::addLogEntry() and make it and its helpers static
* Move UserrightsPage::changeableGroups() and changeableByGroup() to the User class and make the latter static
* In doSaveUserGroups(), drop groups that the user doesn't have from $remove (and those that they do have from $add), and return array($add, $remove)
* Fix up a comment in ApiQueryRecentChanges
* Move export/exportnowrap handling code out of the if(count($pages)) branch
* Add an error fallback to ApiFormatRaw (exportnowrap uses the XML formatter for errors), since Raw doesn't know how to format errors
* 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
* Add $wgAPIMaxUncachedDiffs (default 1) which controls how many non-cached diffs will be served per request
* Tweak DifferenceEngine.php a bit to make cache status accessible, and remove a useless 'parseinline' which broke diff generation in the API
* Aggressively intval() numeric things; addresses the concerns raised on bug 11633
* Use ApiQueryBase::addTitleInfo() everywhere
* Remove a drug-induced-looking line from ApiQueryWatchlist.php
* To fix this, make the prop=revisions query slightly less performance-zealous and allow WHERE rev_timestamp <= 'foo' when sorting and rangescanning by rev_id
* Make adding ORDER BY in ApiQueryBase::addWhereRange() optional
* Move a RELEASE-NOTES entry to the right section
* Use + instead of array_merge(), the latter messes up keys
* Fix a fatal error ($result not an object)
* Fix an interesting mistake when calling addTables(): addTables('foo', 'bar') doesn't add both tables, but adds foo AS bar
* Fix warning about $row->pt_namespace not being set
Commit message for r47214:
API: Refactor ApiQueryInfo
* Move result generating code from execute() to extractPageInfo()
** Merge code for existing and missing titles
* Don't loop over existing and missing titles separately, but on both in one go
* Move protection query code from execute() to getProtectionInfo()
** Merge code for existing and missing titles here as well
* Move subjectid/talkid query code from execute() to getTSIDs()
* Document some functions
Previous commit message didn't mention changing ApiQueryInfo to sort $titles by page ID and to add info about missing pages in one go (the latter upon Brad Jorsch's suggestion)
* Added Title::moveSubpages() as a backend function
** Didn't update SpecialMovepage to use this; left to braver souls
* Fix handling of errors on talk page move (will backport)
* put the tables in the right order
* JOIN on user_text as well for better index usage
* Force the index on the recentchanges table as well
* Don't ORDER BY rev_user_text if it's constant
* This means queries could possibly return fewer results than the limit and still set a query-continue
* Add iicontinue, rvcontinue, cicontinue, incontinue, amfrom to faciliate query-continue for these modules
* Implemented by blocking additions to the ApiResult object if they would make it too large
** Important things like query-continue values and warnings are exempt from this check
** RSS feeds and exported XML are also exempted (size-checking them would be too messy)
** Result size is checked against $wgAPIMaxResultSize, which defaults to 8 MB
For those who really care, per-file details follow:
ApiResult.php:
* Introduced ApiResult::$mSize which keeps track of the result size.
* Introduced ApiResult::size() which calculates an array's size
(which is the sum of the strlen()s of its elements).
* ApiResult::addValue() now checks that the result size stays below
$wgAPIMaxResultSize. If the item won't fit, it won't be added and addValue()
will return false. Callers should check the return value and set a
query-continue if it's false.
* Closed the back door that is ApiResult::getData(): callers can't manipulate
the data array directly anymore so they can't bypass the result size limit.
* Added ApiResult::setIndexedTagName_internal() which will call
setIndexedTagName() on an array already in the result. This is needed for the
'new' order of adding results, which means addValue()ing one result at a time
until you hit the limit or run out, then calling this function to set the tag
name.
* Added ApiResult::disableSizeCheck() and enableSizeCheck() which disable and
enable size checking in addValue(). This is used for stuff like query-continue
elements and warnings which shouldn't count towards the result size.
* Added ApiResult::unsetValue() which removes an element from the result and
decreases $mSize.
ApiBase.php:
* Like ApiResult::getData(), ApiBase::getResultData() no longer returns a
reference.
* Use ApiResult::disableSizeCheck() in ApiBase::setWarning()
ApiQueryBase.php:
* Added ApiQueryBase::addPageSubItem(), which adds page subitems one item
at a time.
* addPageSubItem() and addPageSubItems() now return whether the subitem
fit in the result.
* Use ApiResult::disableSizeCheck() in setContinueEnumParameter()
ApiMain.php:
* Use ApiResult::disableSizeCheck() in ApiMain::substituteResultWithError()
* Use getParameter() rather than $mRequest to obtain requestid
DefaultSettings.php:
* Added $wgAPIMaxResultSize, with a default value of 8 MB
ApiQuery*.php:
* Added results one at a time, and set a query-continue if the result is full.
ApiQueryLangLinks.php and friends:
* Migrated from addPageSubItems() to addPageSubItem(). This eliminates the
need for $lastId.
ApiQueryAllLinks.php, ApiQueryWatchlist.php, ApiQueryAllimages.php, ApiQuerySearch.php:
* Renamed $data to something more appropriate ($pageids, $ids or $titles)
ApiQuerySiteinfo.php:
* Abuse siprop as a query-continue parameter and set it to all props that
couldn't be processed.
ApiQueryRandom.php:
* Doesn't do continuations, because the result is supposed to be random.
* Be smart enough to not run the second query if the results of the first
didn't fit.
ApiQueryImageInfo.php, ApiQueryRevisions.php, ApiQueryCategoryInfo.php, ApiQueryInfo.php:
* Added continue parameter which basically skips the first so many items
ApiQueryBacklinks.php:
* Throw the result in a big array first and addValue() that one element at a time if necessary
** This is necessary because the results aren't retrieved in order
* Introduced $this->pageMap to map namespace and title to page ID
* Rewritten extractRowInfo() and extractRedirRowInfo() a little
* Declared all private member variables explicitly
ApiQueryDeletedrevs.php:
* Use a pagemap just like in Backlinks
* Introduce fake page IDs and keep track of them so we know where to add what
** This doesn't change the output format, because the fake page IDs start at 0 and are consecutive
ApiQueryAllmessages.php:
* Add amfrom to facilitate query-continue
ApiQueryUsers.php:
* Rewrite: put the getOtherUsersInfo() code in execute()
* Accessed through the export and exportnowrap parameters added to action=query
* To facilitate &exportnowrap, add ApiFormatRaw, a formatter that just spits out its input without any formatting (not accessible through &format= of course)
* Fix up the action=query description message to reflect the deprecation of query.php
Mysteriously there's no way to get a boolean parameter to default to true, which leads to an incompatibility in the sensible behavior of the more detailed responses in the XML output -- eg you get a whole buttload of "#REDIRECT Blabla" in your results, which is absolutely hideous. This is very much not desireable. :)
If we could change the default, and allow it to be set on or off for specific requests if some person for some reason is doing highly customized suggestion searches and wants it configured differently (no idea why), that might be doable. But as written this doesn't make any sense.
* Move undo text generation from EditPage::getContent() to Article::getUndoText()
* Add some more examples for action=edit
* ApiEditPage.php: don't mix !is_null() and isset(), be consistent
