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.
start changing member variables.
Otherwise something ends up stomping on $this->mBlockedby when
things get lazy-loaded later, causing false positive block hits
due to -1 !== 0. Probably session-related... Nothing should be
overwriting mBlockedby, surely?
This was giving me blank "you are blocked" messages.... but only
when doing *section edits on SSL*, not regular edits, nor section
edits on non-SSL wikipedia. Weeeeeeird
In CentralAuth (and related changes interface changes in Newuserlog and the core):
* Moved the AutoAuthenticate hook to User::loadFromSession(), to defer processing for longer and avoid unstub loops
* Undeprecated User::setID()
* Added partial support for new user log registration and IP-based blocking of automatically created accounts. Still needs the same support implemented in Special:Userlogin.
* Fixed all inappropriate uses of the term "DB name", changing them to "wiki" or "wiki ID". Renamed the relevant database fields.
* Refactored central session and cache support
God I wish this browser would finish dying. :D
The particular situation was that the session cookie was getting eaten as "disabled", thus not sent back to the server so your session state never quite happened. Other cookies on submit seemed to come in intact, but without the session cookie you'd get a big fat error message, even if you set the long-term login cookie option.
Mac/IE seems to always *see* the HttpOnly cookies, but it sometimes marks them as "disabled". It seems to be incorrectly parsing the options after the path, sometimes seeing "/;" as the path instead of "/". Failure is more likely if there's no expiration option (as with the session cookie), or if there *is* a secure option set.
Anyway, just set up a user-agent blacklist $wgHttpOnlyBlacklist and copied the Mac/IE entry over. The HttpOnly setting now gets ignored for blacklist hits as well as for old PHP versions, the check being encapsulated into wfHttpOnlySafe().
Also added some logging for cookie settings, around the setcookie() and session_set_cookie_params() calls.
* mEmail was already cached, don't need it twice.
* mRights isn't safe to cache -- it may change due to updates to $wgGroupRights, which won't clear the cached User entries.
* Cache mRights. If a hook adds some rights, then that hook needs to be called again and again without caching (e.g. upcoming changes to CentralAuth to add global groups)
* Cache mEmail.
Recent changes to User object made User::sendConfirmationEmail() *not* save the new confirmation token to the database, which seems rather odd. As a result, you got a mail with a bogus value.
Since the function has side-effects, it pretty clearly needs to be saving its changes. Went ahead and had it do that rather than forcing all callers to fix its internal failing.
* Don't clear the token cookie when mailing a password -- this may belong to a different user entirely! If it's the same user, then no harm; the old cookie just won't have any affect. If they're making someone else's account, this will avoid clearing their own token.
* Defer load of groups data
* Introduce newFromRow()/loadFromRow() to allow bulk loading of user objects from a result set
* Hook email and email authentication save/load to allow CentralAuth to provide a global email address
* Defer save of user data after confirmEmail() and invalidateEmail(). Caller must now also call saveSettings(). This reduces the master query count in some code paths.
Elsewhere:
* Introduce UserArray class, for bulk loading of user objects. Immediately useful in email notification, potentially useful for proposed user alias feature.
* In Special:Confirmemail, remove useless handling for impossible false return from confirmEmail()/invalidateEmail().
* Add user preference to always show hidden categories
* Add all hidden categories to [[Category:Hidden categories]], localised by hidden-category-category
* Add wgVariantArticlePath and wgActionPaths to the JS variables script, needed to determine title from link href.
* Credential data in the session is destroyed, so the session is harmless. But it is still useful for abuse tracking (logout/login sequences) and similar analysis.
* Not much point in removing the username persistence feature if you can't improve the squid cache hit ratio, which was obviously your goal.
Actually, keeping a session is still bad. And trying to ensure that they don't see cached content... Well, thats wrong idea.
See, if someone is logged out, he is anonymous and deserves to see cached content as everyone else.
So, let's destroy all cookies.
* Mark private methods private using a keyword.
* Reject arrays with count == 2: these will fail when you do array_slice( ... , 1 ).
* Treat xor consistent with the other operations: if there's only one parameter the result should just evaluate that, not always return false; and any number of parameters should be allowed.
* Fail fast on bad input: throw an exception if Autopromote encounters a condition it can't understand (after asking extensions).
* Code documentation! There were five lines of comments in the original commit.
* APCONDS_INGROUPS is not used, or for that matter defined.
* Editcount should use >=, not >, for consistency with past behavior and intuitiveness.
* "autopromoteUser" sounds like it's actually promoting the user somehow. Renamed the function to getAutopromoteGroups.
* Make sure we don't return the same group more than once, when we're returning a group. Probably not going to hurt, but may as well be clean.
