- Added HTMLFormField::msg() to check whether $this->mParent->msg()
can be called and otherwise use wfMessage()
- Made Licenses::msg() inline to prevent conflict with HTMLFormField::msg()
Change-Id: I7fa95e1d61ac4128d1d4d5f091c39bcbc8ecc651
The message is fetched using Message::escaped() but is
later passed to Xml::element() (from Xml::fieldset() call
HTMLForm::wrapForm()) which means it is double escaped.
Change-Id: I7154b3b26cc46759c184bdf9059d82470e2ab836
Add 'list' (new in HTML5 as part of datalist) to the allowed input attributes in HTMLForm.
Also move maxlength into the general foreach.
Change-Id: I2ba61b0cc1b9f8b3db6c419efb5cbadfde594699
array( 'required' => false ) will now result in the field not being required rather then the unexpected opossite.
And this is now possible (without doing some extra if)
array( 'required' => getSomeBoolean() )
Change-Id: I1fc22b16ab1fa17111c48aa664aaf47de5f7075a
This make HTMLForm mutator to return $this for easy method chaining such
as:
form = new HTMLForm( $someFields );
$form->setMethod( 'get' )
->setWrapperLegendMsg( 'message-key' )
->suppressReset()
->prepareForm()
->displayForm();
prepareForm()->displayForm(); should be at the very end apparently
though it is not enforced by the object.
Change-Id: Iebaa83a1da3c89e5ab729a889e54844535619d54
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.
