Make the 'interwiki' option temporarily accept null as well as true/false
(and default to null instead of false) so form fields which disallow
interwiki titles can avoid deprecation warnings. This also includes
implementing the new error message.
The idea is that for the duration of the deprecation process, form fields
can be set explicitly to interwiki => false (which will eventually become
the default). It would be super annoying to have to do this for all
title fields, but this way it's only needed for fields where users actually
submit interwiki titles with some frequency.
Also improve the logic for legacy fields (which do not set the option
either way): since these (while emitting a warning) allow an interwiki
title, it does not make sense to apply namespace etc. checks to that
title.
Bug: T288155
Change-Id: Ic00f4a0f27747b5ff0893b4c01f42f68a99771ab
Some forms (namely Special:EditGrowthConfig) need to make sure
title exists if possible, but also need to support interwiki
titles.
Bug: T279886
Change-Id: I1bed0aa90dab8c872e915148923a5d78c9dee2f3
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
Previously we would always run the validation, and it would fail when
the field was empty, since empty string is not a valid title.
Respect the 'required' option (defined by HTMLFormField) and make it
default to true for compatibility with existing forms that might rely
on this.
Also add a TODO comment about a confusing special case in validation
code. I don't want to dig into that.
Change-Id: I93ad51ffe7bee597d2d127f4c5d6b2929ffc8f7e
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/HTMLTitleTextField.php (Browse further)
