When inserting XML elements inline <such as this one>, doxygen chokes
about it not being known. Simply enclosing the tag in double quotes
prevents doxygen from emitting a warning.
Also enclosed a few invalid functions calls such as \. and double quoted
the HTML entities such as &foobar;
Change-Id: I4019637145e683c2bec3d17b2fd98b0c50a932f1
- $wgUsePathInfo is now only used on servers not passing REQUEST_URI to determine if PATH_INFO should be used
- WebRequest now extracts information from REQUEST_URI even when $wgUsePathInfo is false
- HTMLForm bases it's decision on whether or not to include a hidden 'title' input on whether $wgArticlePath uses a query instead of assuming that $wgUsePathInfo was used to set the article path
Change-Id: I1b461fef88b26d045f4edd7553b59255c5e595d8
* 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.
