- Add @param annotation for $params variable for __construct() method
in the HTMLExpiryField class.
- Add @throws annotation for getOptionsOOUI() method that throws a
MWException and remove "@return array" as this method only throw an
exception now.
Change-Id: I292f6ae04b840f6f6f74b7c92f834f056659fbe2
Pass through 'limit' and 'showMissing' configs.
Also set 'showMissing' to false for partial blocks.
Bug: T208626
Bug: T208627
Change-Id: Ifa75e2d390bf349226ad69d68adcdcaf742ab560
Use OutputPage::parseAsInterface() to tidy the output and make the
selection of user interface language explicit.
Follow-up to Ifeb1ca6eb8b5c743421b8f9e329f1e3658050e47.
Bug: T198214
Change-Id: Ia4b63715380d97ccb3133bf39a260834c20b4f5a
Add the widget in both PHP and JS for OOUI, and into HTMLForm
definitions.
In JS, the widget uses the engine from mw.widgets.TitleWidget
with the async support from OO.ui.mixin.RequestManager.
The PHP version provides a textarea, like UsersMultiselectWidget.php
which is then infused if JS is available.
Also, add highlightSearchQuery option for TitleWidget to allow for
not highlighting the partial search query the user typed in, if the
UI requires it. This option (highlighting partial result) is already
optional in the TitleOptionWidget, so this config exposes that
optionality in the TitleWidget widget for its menu children.
Notes:
HTMLTitlesMultiselectField is a duplication of HTMLUsersMultiselectField
except for:
- The configuration variable changed to 'titles' (from 'users')
- OOUI modules were adjusted for the TitlesMultiselectWidget
- The PHP version instantiates a MediaWiki\Widget\TitlesMultiselectWidget
TitlesMultiselectWidget is a duplication of UsersMultiselectWidget
except for:
- $usersArray was renamed to $titlesArray
- getJavascriptClassName returns the correct js class for
mw.widgets.TitlesMultiselectWidget for infusion.
Bug: T197109
Depends-On: I675316dddf272fd0d6172ecad3882160752bf780
Change-Id: Ie96947a35f70b76731e16ae5b85de815dfa4a8ce
Should be "string" not "String" and "array" not "Array" in
@param, @return and @var use cases. Also, minor typo fixes.
Change-Id: I9d5ebc5b741c6560907b95f7c0c4039da2861f4a
The JavaScript for the cloner fields has been updated to function
when using OOUI Cloners.
The buttons are packed quite tight together, but there does not
seem to be any CSS that enforced the spacing that I could find.
Bug: T171666
Change-Id: Iba6eed9d6cee922d56855bbe2e836956bfd90f42
Some additional parameters that are passed through as attributes in
HTML mode were not being passed through as config options in OOUI mode:
* 'min'
* 'max'
* 'step'
* 'title'
Some have no equivalent in OOUI:
* 'pattern'
* 'list'
* 'multiple'
Also note that we support some OOUI config options that have no
equivalent in HTML:
* 'autosize'
* 'flags'
* 'indicator'
I originally noticed the problem with the 'min' and 'max' params,
which are clearly missing in OOUI preferences for RC and watchlist.
I don't know if anything anywhere actually uses the other ones.
Bug: T181844
Change-Id: I2d22ef3b08b7f0b4283b644d80bd74906177d089
The PHP variant of this widget was introduced in 0.27.0.
Using NumberInputWidget has the advantage that HTMLFloatField and
HTMLIntField can now be infused as a JavaScript NumberInputWidget.
Bug: T203656
Change-Id: I5d6a913de38d12a21c9bfb1ce9790574d98a5a1b
Parent getLegend() returns a plain string, and this method should
do the same.
Form section legends are escaped by the wrapFieldSetSection() method.
Change-Id: I2059b9182fba7362f3d6226252bdc3e032a06c57
We were incorrectly escaping them. They are supposed to be already
correctly escaped HTML.
Also improve documentation and really allow 'tooltips' to be optional.
Bug: T203325
Change-Id: I1f92479bf1989e1529b18b8b206b61db1257eb87
To be compatible with OOUIHTMLForm, 'default' must be a FieldLayout
(or a subclass of FieldLayout) when using 'rawrow'.
(Technically, it works when it's a string, but that's only by chance.)
Bug: T203202
Change-Id: I571c619c32a806016b649562f5efe52ad45ef036
This is to make sure that the design is similar, but also so
that the widget can be read in JS where needed and that we
can toggle the disabled state on/off through the whole widget,
that is made from a series of checkbox widgets.
Bug: T199946
Change-Id: I9943b0aa1746fdfb60c7d4c88d6d4d7ac0589a2c
These occur when buttonlabel-message is set. HTMLButtonField
parses the message in its constructor, but at that point the
context (provided by the form field by HTMLForm::$mParent) is
not yet available. The constructor of HTMLForm assigns $mParent,
but that constructor is only called after the button label
message is parsed.
Bug: T201497
Change-Id: I021c9ecf3bc934f2cf55ec100e799c1c12e7bc01
…also HTMLSelectAndOtherField and HTMLSelectOrOtherField now
pass the 'disabled' field when creating the input widget.
The OOUI versions of these HTMLFormFields would get enabled
right after infusion even they were disabled in PHP. This
makes sure that they remain disabled.
Change-Id: Iddd8ad81731dba7bdcb599d6fe104cb259b11733
Now it behaves more like HTMLCheckField: if there is clearly a value
submitted, it will load it.
Setting wpFormIdentifier is still needed for forms with default-on
checkboxes (without form identifier, it is impossible to distinguish a
page view without form submission, and form submission with default-on
checkbox unchecked).
In particular, this fixes the 'Show additional logs' checkboxes on
Special:Log: they no longer get unchecked after form submission.
Change-Id: Ief74a7e424b37ccd44759133b3cb8665275314a6
Otherwise HTMLTitleTextField sends null to Title::newFromTextThrow(),
which causes an exception when trying to look it up in a cache.
Similar issue is present in HTMLUserTextField, although that one
hasn't caused problems in practice yet.
Follows-up on I93ad51ffe7bee597d2d127f4c5d6b2929ffc8f7e and
I0de4194a37b6ef260d35feb1e6730985775d5351.
Bug: T199763
Change-Id: I29ecd94cdf9e3064e6e9e7f4e65a50f267b5282d
UsersMultiselectWidget class extends OOUI's MenuTagMultiselectWidget,
not CapsuleMultiselectWidget any more.
Change-Id: Iea7450a371720bed392dfedb1032bc8c63c89fc4
Currently there is no way to access the preText outside of an HTMLForm. Adding
a getPreText method to HTMLForm so the preText is accessible.
Bug: T199115
Change-Id: I937028e7025b4a7b5d333e9bf5a25920f6a88316
