* 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
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Change-Id: Ifbb1da2a6278b0bde2a6f6ce2e7bd383ee3fb28a
SecurePoll will have a field that's a url, so we may as well use the
correct HTML5 input type for it.
Change-Id: Id3ddd8f2efdff08c8a188089d321d143ce5ef9c9
One shortcoming in HTMLForm is that fields that use the 'options'
parameter (e.g. <select>) have no easy way for the individual labels to
be localized.
This change adds a new parameter type, 'options-messages', where the
keys are message keys rather than bare strings (similar to the
difference between 'label' and 'label-message'). It also abstracts out
the fetching of the various option parameters, and changes the necessary
field classes to use it.
Change-Id: If4175332405d26c7ff2e8fbe100bcad61762ce6f
The new Agora ("beveled bottom") version deprecates mw-ui-primary.
* Use mw-ui-constructive (green) for Login, Create account, and Reset
password.
* Use mw-ui-progressive (blue) for Join <wiki> and Search.
A separate change I90954ea will implement right-aligned and quieter button layout.
Bug: 60596
Change-Id: Ia1fe557e7ebeac011c5da7297e848c1bfee7910f
All of these also use other mw.ui features (e.g. mw-ui-vform,
mw-ui-input, mw-ui-checkbox-label, etc.), so they can't only depend
on mediawiki.ui.button.
Change-Id: I6906533753185f7de42552cff38a86fb0171d1d8
$html in HTMLForm::getButtons() is vrapped in a <div></div> when in
vform mode but it contains a <span> tag without its closing
counterpart, thus making the HTML invalid.
And while I'm at it: put line breaks at better places.
Change-Id: I7ffa1bdd72d95188320c1b29d1c46a5f6f434cbe
