When 'exists' was false (the default), other validation was skipped.
Change the default 'iprangelimits' to allow any range, to avoid issues
with code that relied on the previous broken behavior.
Bug: T177329
Bug: T311948
Change-Id: I55cad7a5395da70105e20ce33e3a8e3834a4f4ad
The HTMLUsersMultiselectField and HTMLUserTextField fail validation when an
empty string is passed to a non-required form field. To prevent this, the
widget should pass the validation to the parent when the value is an empty
string.
Bug: T246958
Change-Id: I39df2b575b90a4648188ed3ef4cc0c38ac553636
This check was added in I605f32048fe97eebd7e04b6ffd799759aeb7f31e,
to fix an issue on Special:ChangeContentModel that was pointed out
in code review of I766da59e6cbf7ed8f887d1a684ea9e284e9cf67e.
This code actually does nothing in most cases, because `$value` for
unsubmitted forms comes from the getDefault() method, and it is
`null` and not `''`, unless specifically overridden. As it happens,
Special:ChangeContentModel overrides the default to `''`, so this
worked there.
However, this was a brittle hack, and another change recently broke
Special:ChangeContentModel in the exact way this was supposed to
avoid: T196514. There is a pending patch there to fix it properly.
The proper way to avoid validation errors on initial view of a GET
form is to call setFormIdentifier( … ) on the form, which allows
HTMLForm code to detect whether the form was really submitted.
Change-Id: Id6a449bfa313d470ae4c39455e58b36252dc6b43
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
It mostly already worked. HTMLForm::trySubmit() needed a little
adjustment to handle things properly.
Change-Id: Ibb17bb61ac0b2d41953249980bc2f23b8a3ae5b6
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
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
2016-08-01 07:58:56 +00:00
Renamed from includes/htmlform/HTMLUserTextField.php (Browse further)
