The conversion of SpecialNewpages to HTMLForm seems to be half-finished.
It's not using HTMLForm to read in the request query, which means we have
to roll our own logic. Kind of defeats the purpose of using HTMLForm in
the first place.
When ProtectedPages is converted to HTMLForm (T117722), it can use this new
field type.
Bug: T12817
Change-Id: I069609fbb37b18c3df25156779ad7ac7cd5d6813
Replacing deprecated `constructive` mediawiki.UI CSS class and OOjs UI
flag with `progressive`.
Bug: T146923
Change-Id: I524b9722ee49692c55bb1f97d34d8a28068716ee
Previously, you could pass 'cssclass' => 'mw-chosen' in the form
descriptor for a 'multiselect' field, and it'd be automatically
converted to a text field with a dropdown allowing values to be
selected. This is not very intuitive (unless you know what the Chosen
library is) and was not documented anywhere except for release notes.
The new recommended and documented way to achieve this is by passing
'dropdown' => true. Old way is supported for backwards compatibility.
Also, add the 'jquery.chosen' module to the page server-side.
Change-Id: I3a025e1c3c7571e930a35e020d73d558fdc433d0
Rather than have a master list in autoinfuse.js (duplicated in
hide-if.js), we put this information in each field class and put it
in the generated HTML as a separate 'data-' attribute. This also
allows new fields defined by extensions to be correctly autoinfused.
Change-Id: I3da75706209cbc16b19cc3f02b355e58ca75fec9
This is not really what we had in mind when developing the infusion
feature and I think it's not helpful. Most of the time there is just
no benefit; a ButtonWidget generated in PHP and in JS behaves and
looks pretty much the same, and rebuilding it through infusion is a
small performance hit. If you're not adding any event handlers, it only
makes sense for various dropdowns, which have themed styling.
For the primary use case of adding JS behaviors to PHP widgets you
need to call OO.ui.infuse() anyway to get a reference to the JS
widget, and not infusing automatically should make it easier to reason
about your code. Infusion tries to be very transparent, but it can't
hide the fact that the DOM is re-built, making your references to DOM
nodes from before infusion useless and losing anything from PHP that
wasn't included in the config (e.g. custom attributes).
This commit removes automated infusion from mediawiki.page.ready
and adds some custom code in mediawiki.special.movePage and
mediawiki.htmlform. I see only two extensions using infusable OOjs UI
widgets in Gerrit (ArticlePlaceholder and ExtensionDistributor) and
neither should be affected by this change.
Change-Id: I56608c537fc57c5c54960b0603694f2612f45618
I was a bit fast with merging I18edfcb62f7b21f2c1990c73944ee6a956fd4901,
because I think, type hinting the type of the parameter would make sense,
too.
Bug: T142912
Change-Id: Id397847c6c078047f3daa84db68ccf3e629ca531
It's getting more difficult to navigate the files in includes/htmlform/
with every new field and every new helper class that is being added.
Change-Id: I92ce2356baf6151f17b2440970d5abdf86503820
