* mw.config is the new way, and global config variable lookups are deprecated
* Based on two phase3-wide quick searches:
-- of " wg": http://toolserver.org/~krinkle/wikimedia-svn-search/view.php?id=321&hash=81700bf7486e4fee3b7bc1f83eb9eba6
-- of "!wg": http://toolserver.org/~krinkle/wikimedia-svn-search/view.php?id=327&hash=47c9d54a7a1d5d58a724dd834585f40d
Related changes:
* Changed some php comments mentioning "wg" variables to include the dollar sign, and a typo when the wf function prefix was meant.
* Removed TODO comment in wikibits.js and made it use the JS equivalent of wfUrlencode, which we have now, mw.util.wikiUrlencode
* SpecialUpload.php: use OutputPage::addJsConfigVars instead of creating a new script tag through OutputPage::addScript(Skin::makeVariablesScript(..))
* Renamed wgUploadSetup in upload.js and made it local. Not used anywhere in ./trunk/phase3 and ./trunk/extensions
* Fix OutputPage::addJsConfigVars so that it can actually be called with an array instead of two arguments for key/value
* Some minor whitespace/convention stuff around the same line
* 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
On [[Special:EmailUser]], someone ought to be able to pass the checkboxes
names to overrides the default. As an example from bug 31770, the email
user page has a checkbox wpCCMe which let the user as for a copy of the
email being send. This is a user preference.
One change that checkbox state by appending ?wpCCMe=<boolean> ie:
Special:EmailUser/Hashar?wpCCMe=0
Special:EmailUser/Hashar?wpCCMe=1
The logic added in r84814 could have allowed checkboxes to be overriden
for GET form. Unfortunately, HTMLForm is mostly with the default POST.
Hence, when appending the query parameter, we would never honor it!
The fix is to still unconditionally look at the value if the form was
correctly submitted (ie has wpEditToken) and additionaly whenever
there is a checkbox name appearing in the query (wherever it is false
or true, hence the use of getVal()).
This is a regression in REL1_18. I dont think it deserves a release notes
since it is not fixing anything compared to 1.17.
Bug fixed:
==========
* (bug 31770) Allow URL parameter wpCCMe on Special:EmailUser
* (bug 30909) URL parameters for checkboxes in Special:Block no longer work
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.
* 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)
Also, if a field is marked as required, it should still be checked to see if it's empty before going to the callback. Don't like that behavior? Don't mark it as required.
Followup to r83298: makes HTMLSelectAndOtherField backwards-compatible with Xml::listDropDown as it was apparently intended to be.
Also fixed double-escaping in the options for HTMLSelectAndOtherField.
Followup to r83795: fixes regression in Special:Block by fixing HTMLSelectAndOtherField which got used in place of Xml::listDropDown, but wasn't compatible.
Note that this removes the clever thing that lets you have separate values and texts in your dropdown; since Xml::listDropDown had no such feature and actual usage includes texts containing links and other stuch where the pipe character is a legit part of the content.
