Issues with spacing (T107311), probably shouldn't have
been merged right before the branch cut.
This reverts commit 9508c5bd57.
Change-Id: Ibf2ca5a33b8ab0f7381c720c6c92fbfd7a7c819d
Just skip validation if it is a GET form and the current input is an
empty string. Callers will need to check that it is not the empty string
though.
Also make sure HTMLForm::mMethod is always lowercase.
Change-Id: I605f32048fe97eebd7e04b6ffd799759aeb7f31e
Currently, every submit button generated by HTMLForm itself (not via
the descriptor) doesn't have the primary flag and there is no (easy) way
to add it, although this generated submit button is most likely the primary
one.
Add a new function HTMLForm::setSubmitPrimary() to allow a form to set
add the primary flag to this submit button.
Change-Id: I3ce363f995389a87764edb586b4b64ab2b77b0db
To use OOUI for forms with user name autocomplete, the new widget
UserInputWidget interacts like the jQuery pendant (working with css
class "mw-autocomplete-user").
It is also available in HTMLForm as "user".
Example usage: Iaeff912e6437d6ebef0d5b1919ce8cf53a7fd5f1
Change-Id: I9501c85f4288c255bbe3a5284e99b57b6169916f
Changed FormSpecialPage not to call setWrapperLegend() for OOUI
forms to preserve current default behavior.
Bonus:
* Correct documentation of setWrapperLegend() to state that it
HTML-escapes legend text.
* Remove hard-coded class="visualClear" in getFormAttributes().
* Allow setWrapperLegend( true ) to display the wrapper without
legend text.
* Rejigger things so that we can put the legend and "header HTML"
into correct order.
Bug: T103026
Change-Id: I847c5e18ae5469aa3a68cc9fa37b2a6614476ca2
HTMLTitleTextField will automatically validate title input, can
optionally ensure the title is in a specific namespace, is creatable, or
already exists.
The field currently doesn't support GET requests since validation on
empty strings fails.
Bug: T104420
Change-Id: I45718462570d0a523a148c3830b1116b634df050
Rejigger some HTMLForm internals to remove the hardcoded assumption of
using 'mw-ui' classes.
Bug: T98903
Change-Id: Icc20453c999c761b87e19a71ccd43d93b9c1bfa7
* Transform all input fields to use HtmlForm as preparation for enabling
MediaWiki UI eveywhere.
* Remove protected whitespace for HTMLCheckField (adds empty line to div-layout)
* Add a new HTMLForm input field "Text with Button" and "Namespaceselector with Button"
Bug: T73434
Change-Id: I53cc019c3ca94cec8f3c05500d0c604c1af7f688
* Convert Special:LinkSearch to use HTMLForm for preparation of MediaWiki
UI everywhere
* Add support for dir= tag in HTMLTextField
Bug: T73439
Change-Id: I8503c391a40f1654f8570578a9de9015d86c9845
* Prepare the usage of MediaWiki UI.
* Add new HTMLForm output mode "inline" (very close to "raw")
Bug: 71436
Change-Id: I12240aaf624dff5219b344648b20373594b5ec46
…and in general, work with the existing HTMLForm design for defining
display formats, rather than against it.
Breaking changes:
* HTMLForm::isVForm() is now deprecated.
* You can no longer do this:
$form = new HTMLForm( … );
$form->setDisplayFormat( 'vform' ); // throws exception
Instead, do this:
$form = HTMLForm::factory( 'vform', … );
When using FormSpecialPage, override the new getDisplayFormat() method
instead of calling $form->setDisplayFormat() in the alterForm() method.
(Other display formats are not affected, only 'vform'.)
Bug fixes:
* Correctly suppress empty labels for VForm fields
* Correctly disable <fieldset/> wrappers for VForms
Other benefits:
* Reduce code duplication related to $getFieldHtmlMethod
* Introduce HTMLForm::factory() method for constructing HTMLForms
Related cleanup:
* Correctly style 'reset' buttons in MediaWiki UI mode
* Label $wgHTMLFormAllowTableFormat as a mobile-specific hack
* Display checkboxes normally in MediaWiki UI mode (removed weird
override that only broke things). Also, always render checkboxes
in VForms as .mw-ui-checkbox.
* self:: → static::
Bug: T85285
Change-Id: I086a84f1c8cc6a16710709b7806c7f5f96462b32
One call in core already called it non-static
Avoid:
[GlobalTitleFail] MessageCache::parse called by
Message::toString/Message::parseText/MessageCache::parse with no title
set
Change-Id: Ic91e715177c0a4578825640a31ec68ecba3176e0
Pass the HTMLForm parent instance in the constructor so context
is available when parsing a message.
Change-Id: I532c0d95698cbcc57294b9bd2725f33838f393a9
Use HTMLForm instead of self-built table structure, to be
prepared for use with MediaWiki UI.
Bug: 71446
Change-Id: I5c03dc543b910aab27a26a5a223341be50893cf3
Although the classes (e.g. mw-ui-input) are still there,
the style module was not being loaded.
This affects forms that deliberately use VForm even without
wgUseMediaWikiUIEverywhere (since they pre-date it).
This applies at least to PasswordReset, which was added in
d32891d99f (last October).
Bug: 71448
Change-Id: Ieca36c0036d4c93244c533237eddd678564dd3c0
* Apply mw-ui-destructive to Special:Preferences/Reset
when $wgUseMediaWikiUIEverywhere is enabled
Introduces HTMLForm->setSubmitDestructive()
Bug: 65317
Change-Id: I1d6691dce3e7dab662bda9a718e16c5caee6c041
Check for isVForm() and apply styling matching the default submit button
when generating alternate form submit buttons.
Change-Id: Ia3313087248af1537ac4740694846b6ff1187b1a
- Added space after reserved words: function, foreach, if
- Combined 'else if' into elseif
- Added braces to one-line statements
- Added spaces after comma, before parentheses
Change-Id: Ie5bbf680d6fbe0f0872dab2700c16b1394906a72
This is much like the one OAuth has in
Special:OAuthConsumerRegistration/propose, except it stores the
autocompletion options in a data property rather than a global and uses
jquery.suggestions rather than jquery.ui.autocomplete.
Change-Id: I42473cea75f3706cc0125167f9191275ca6cb3b0
This provides better mobile experiences on various pages
and a more consistent UI across both mobile and desktop.
It does this in two ways.
1) Forces HTMLForms to not use table based layouts so as
not to interfere with responsive nature of mediawiki ui elements
2) Applies MediaWiki.UI classes to most pages
If a page is created via Xml or Html classes it will use mediawiki ui
Where possible I've added classes unconditionally, but for cases of buttons
this is behind the $wgUseMediaWikiUIEverywhere global since button styling is
enabled on pages by default and for checkboxes since it is changes HTML markup.
3) Adds all MediaWiki.UI styles to pages which can use it
When enabled:
* Apply these styles to all pages which use HTMLForms
* Apply to EditPage
* Apply to anything that uses certain elements outputted by the
Xml or HTML helper classes
* Apply to History page
* Apply to protection page
* Apply to move page
* Apply to deletion page
Currently kept behind a global to allow us time to finetune
existing elements. After further testing we will look to kill the
globals and make mediawiki.ui the default
See: I430c0fbb79d2a33bb828b2427bda0ee01115d73f
Change-Id: I47db5eab4569514d039261d11b6dedb0eeae17b5
Hidden fields are supposed to be ignored during validation; more
completely ensure this by checking in HTMLForm::trySubmit before calling
validate.
Also, more properly handle HTMLCheckFields in the isHidden check by
casting their booleans to strings.
Bug: 68132
Change-Id: I84f8239c299727b773015643048eed4684417733
When a message needs plural support, it should be possible to parse a
message object with the params set.
Change-Id: Ifb67952b589a1821cde452b2be3f327f24e6b534
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: I41a84e8e1dec39170aa655250325ffc485eaeaef
There is now a new option named csshelpclass that can be passed in form
descriptors for HTMLForm objects. This option accepts a css class and
applies it to the help text that is provided with the help option in the
form descriptor.
Bug: 65087
Change-Id: If1bd1d12a9159895f45c9cf0fbb7992e4c7e3526
The possibilities for the submission callback return value were
documented in three different places, and none were entirely correct.
Related documentation could also use a cleanup.
Change-Id: Ib3621a0d5ba24c481f3117b547bca70d4ca50ba2
There are so many slightly different understandings of what a
"section" is or can be. I'm aware the documentation was improved
just a few weeks ago. I still find it incomplete and confusing.
1. I renamed it to $sectionId to make it more clear what it
really is.
2. Sections are usually numbers. 0, 1 and so on. There is no
reason to disallow the use of ints or even floats (this works
because the string representation of 0.0 is "0"). The code never
disallowed numbers.
3. 'T1' never was supported, as far as I can tell. 'T-1' is
supported. See Parser::extractSections().
4. null and false and '' all mean "the whole page" in
WikiPage::replaceSectionAtRev() but for some reason this meaning got
lost in WikitextContent::replaceSection(). I made it the same again.
Change-Id: Icc3997722d2ed742bf7703cd7c06d09199225720
SecurePoll is going to need the ability to have a form for stuff like
"one or more admin usernames" and "one or more poll questions, each with
one or more options".
This change implements a generic field container that simply displays as
a <ul> followed by an "add more" button, with each <li> containing
various fields including a "remove" button.
Since this is only going to show up in SecurePoll to people creating a
poll (not to general users), the current design is functional but not
necessarily beautiful. Those interested in beauty are welcome to do so
in a followup change.
Change-Id: I46fad3971739ddc961259fe32eb6e1cd265a1c06
These files have all had treatment before, and these occurrences have either
been missed or have been introduced after.
Change-Id: I06cdab4616b5bff47c85152df28f18c861730a23
