* Much more easier to find it in the User class than in Preferences and it's general enough to be in that class.
* Rewrote the function for better readbility
* It now always return a Status object so that it's easier to interpret its result.
* Update the only caller in core (in Special:ChangeEmail) and moved the PrefsEmailAdit hook there
Change-Id: I55939bb5295e73594c3fdf7287dddbc16a233ce4
- MWCryptRand: A new api for generating cryptographic randomness for security tokens. Uses whatever cryptographic source is available and if not falls back to using random state and clock drift.
- wfRandomString - A simple non-cryptographic pesudo-random string generation function to replace wfGenerateToken which was written pretending to be secure when it's really not.
- Core updates to use MWCryptRand in various places:
-- user_token generation (to do this we stop generating user_token implicitly and only generate it when needed to avoid depleting the system's entropy pool by reading random data we'll never use)
-- email confirmation token generation
-- password salt generation
-- temporary password generation
-- Generation of the automatic watchlist token
-- login and create user tokens
-- session ids when php's entropy sources are not set
-- the installer when generating wgSecretKey and the upgrade key
* Reduces the overly long code in r107002, and reduces code for {{#language:}}
* Fixes the language list in Special:Translate which contained languages that gave "invalid code" when selecting
email address is removed
In Preferences::trySetUserEmail no point trying to reset the users email if it's the same
Same for User::setEmail
After setting the email though, invalidate email auth tokens
* Added $form parameter to Preferences::cleanSignature() and Preferences::validateSignature(), they are passed to the functions since r102879
* Use local context to get messages
This change is needed for my work on the Gadgets extension in the RL2 branch (one example is adding text on top of a preferences section using a dummy type=>'info' preference, you want that to show up on top, not after all the subsections). The targeted use case (sections that contain both subsections and form elements) does not occur for core preferences, and is very uncommon in extensions. I managed to find such uses in only 3 of them: CreateAPage (in unreachable code), Tasks and EditSimilar add preferences to core sections that also contain subsections.
* ParserOptions::getUserLang() will still return a string for compatibility, added ParserOptions::getUserLangObj() to get the object
* Added ParserOptions::newFromUserAndLang() and ParserOptions::newFromContext() to easily get a ParserOptions object when a context is available or when someone wants to force the language
* Updated OutputPage and Preferences to use newFromContext() and WikiPage to use newFromUserAndLang()
* ParserOptions::setUserLang() still accepts either a string or a Language object, but changed the calls to pass an object instead of a string
* Changed Parser::getFunctionLang() to return the Language object from ParserOptions when parsing interface messages rather than $wgLang directly and updated the documentation to say that $wgLang should not be used directly (as $wgUser, $wgTitle and $wgRequest)
* Pass the HTMLForm object to the submit callback so that it can have a context and also access to the form itself (see below). This makes Preferences::tryUISubmit() and Prefrences::tryFormSubmit() signatures incompatible. The only extension calling these is EditUser and I will fix in my next commit.
* Added two extension possibilites (for EditUser): PreferencesForm::getExtraSuccessRedirectParameters() to modify the URL parameters when redirecting after successful save and the fourthparameter to Prefrences::getFormObject() to be able to remove some items from the descriptor
* Pass the user being modified to the HTMLForm to use it to save the preferences instead of doing this unconditionally on $wgUser (to remove one hack in EditUser preferences)
* Make getVariantname fallback to the language name, and use that in Preferences. Shouldn't change the names in practice, but is a more logical implementation imho.
* (Fix a typo in Language.php)
* Parser.php: Apparently that was a much bigger bug: do not convert interface text going through the parser either.
* Preferences.php: Do not convert the user signature.
For this bug in action, see e.g. http://sr.wikipedia.org/sr-ec/Посебно:Подешавањ?uselang=en (e.g. "Username" -> "Усернаме")
