r55990 "* Totally refactor includes/specials/SpecialUserlogin.php:"
r55991 "Followup to r55990 - Remove debugging hack :("
r55994 "Followup to r55990 - rename method to avoid PHP Strict warnings"
r55997 "Follow-up to r55990, per comments:"
Continued reports of breakage with the new version...
Non-vital changes of this magnitude should probably be worked up on a branch to ensure everything's consistent before pushing them to trunk.
** Split backend stuff out into includes/Login.php
** Split account creation and login stuff up, into includes/specials/CreateAccount.php and includes/specials/Userlogin.php.
* Reimplement the special pages as subclasses of SpecialPage
* Use HTMLForm to generate the input forms
** Deprecate and delete includes/templates/Userlogin.php, which is horrible and old :D
This changes the syntax of the UserLoginForm and UserCreateForm hooks, and AuthPlugin::modifyUITemplate; they now receive the SpecialPage subclass rather than the template to work with. Update everything I could find in SVN to accommodate this.
There was a mix of uses of the reference and non-uses of the reference. :)
Reverts r53714 and fixes it from the other end by cleaning up the uses to not expect references.
* Fixed the formal parameter bloat in the file finding functions by making wfFindFile(), RepoGroup::findFile() and FileRepo::findFile() take an associative array of options instead of a rapidly growing collection of formal parameters. Maintained backwards compatibility for the $time parameter, which was the only one used in an extension.
* Took the advice of the todo comment on FileRepo::findFiles() and implemented a calling convention for specifying times (and other options)
* Removed the file object cache from Parser, redundant with the RepoGroup file cache
* Deleted clueless and non-functional LocalRepo::findFiles(). Does not respect redirects, deletion bitfields, or anything else nuanced about FileRepo::findFile(). Does not have the same calling convention as FileRepo::findFiles().
This is pure code duplication and should be done by fetching data from the respective query pages. This has as advantage that other query pages can be readily added to the API as well. See the querypage-work branch.
* Where supported by backend, list=search adds a 'searchinfo' element with
optional info: 'totalhits' count and 'suggestion' alternate query term
Snippets added to result items earlier by Roan; extended this with the other
byte size, word count, and timestamp available on the result items and exposed
through the regular UI.
Had to work out a backwards-compatible method for the search meta-information
with Roan; added a second 'searchinfo' element since adding attributes to
'search' would break compatibility for JSON output (despite being safe in XML).
'searchinfo' is present only if the backend supports the extra info and has
something available; 'totalhits' with a total hit count and 'suggestion' for
an alternate query suggestion (exposed as "Did you mean X?" link in UI).
Note that total hit counts can be enabled for MySQL backend now by setting
the experimental option $wgSearchMySQLTotalHits, but did-you-mean suggestions
are not yet supported and need to be tested with a hack or another backend.
Sample XML and JSON output with the new searchinfo items (which can be
present whether or not there are any result items):
<?xml version="1.0"?>
<api>
<query>
<searchinfo totalhits="0" suggestion="joe momma" />
<search />
</query>
</api>
{
"query": {
"searchinfo": {
"totalhits": 0,
"suggestion": "joe momma"
},
"search": [
]
}
}
The suggestion value is suitable for plugging back in as a search term,
if present.
