Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
HTMLFormField subclasses triggered false positives when phan incorrectly
thought that $this->mOptions was only a boolean.
ReplacementArray $this->data was defined as possibly being boolean, but
in reality that never happened.
Change-Id: I06bae9c9952366ff7927df37373b146d570f4a02
I have no idea where this convention came from, but we had them in
core until 265ff105aa and they still
appear widely in extensions. The non-OOUI code also has special
handling for it (a label equalling ' ' is treated as raw HTML
even when not marked as such). In OOUI-style "vertical" forms these
fake labels cause a lot of unnecessary white space to appear, so let's
just not display them.
Change-Id: I45559fa69dc1ae4b9d048445e27a24815fe93b6d
The same behavior was implemented by Xml::listDropDown(),
Article::confirmDelete() and HTMLFormField::getOptions().
A new function Xml::listDropDownOptions() is added and
all three are changed to use it.
Additionally:
* Xml::listDropDown() now uses XmlSelect internally to generate the
dropdown HTML.
* Xml::listDropDownOptionsOoui() is introduced to handle converting
the existing format to the OOUI format, which was previously
duplicated in Article::confirmDelete() and HTMLFormField::getOptionsOOUI().
* This change allows HTMLForm 'select' fields (HTMLSelectField) to
support nested options (optgroups) in OOUI mode. This is a
prerequisite for T117781.
Bug: T117781
Change-Id: I0a088f61eb32ec59677113583c7ecdcbc3fd2af0
It adds the ability to replace the current section ID escaping
schema (.C0.DE) with a HTML5-compliant escaping schema that is
displayed as Unicode in many modern browsers.
See the linked bug for discussion of various options that were
considered before the implementation. A few remarks:
* Because Sanitizer::escapeId() is used in a bunch of places without
escaping, I'm deprecating it without altering its behavior.
* The bug described in comments for Parser::guessLegacySectionNameFromWikiText()
is still there in some Edge versions that display mojibake.
Bug: T152540
Change-Id: Id304010a0342efbb7ef2d56c5b8b244f2e4fb2c5
Values returned by `Linker::tooltipAndAccesskeyAttribs()` and
`Linker::titleAttrib( ..., 'withaccess' )` include an accesskey
hint in the title text. This is unnecessary when used for OOjs UI
widgets, since after the changes from T168408 they display an
accesskey hint automatically.
Also fixed some other accesskey bugs in HTMLForm which probably
no one ever ran into.
Bug: T168408
Change-Id: I63285b5bce3341875a6d82eba059623bf105ca62
Use the cancreateerror returned from list=users&usprop=cancreate for
username validation.
Use the new action=validatepassword to validate entered passwords.
This also injects the resulting errors in the style of HTMLForm's field
validation rather than at the top of the form.
Change-Id: Ie8c1270eb605367556fe36b0b2080eb3f957dc54
Our 'hide-if' fields are fundamentally incompatible with HTML5 form
validation attributes. If you have a checkbox field A, and field B
that is required, but hidden if A is unchecked - that's impossible to
express with HTML5 form validation. The only thing you can do is
remove the validation on B (or on the entire form).
The field contents are still validated server-side, just like if the
browser did not support HTML5 forms. The validation is also re-enabled
in JavaScript, since we have extra support for 'hide-if' field that
makes them work.
Change-Id: Ia7ffa76965a7c14af9b6d2db007b6255498398d9
Most of these are simply changing annotations to reflect
reality. If a function can return false to indicate failure
the @return should indicate it.
Some are fixing preg_match calls, preg match returns 1, 0 or false,
but the functions all claim to return booleans.
This is far from all the incorrect return types in mediawiki, there
are around 250 detected by phan, but have to start somewhere.
Change-Id: I1bbdfee6190747bde460f8a7084212ccafe169ef
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
For plain HTML forms, we just put the required data in the 'data-hide-if'
attribute. For OOUI, it's not so easy - while we could just call
->setAttribute(...) on the FieldLayout, this would disappear when
infusing (since it's not part of the config), and we have no control over
when some piece of JavaScript decides to infuse the element. Even if we
managed to handle it first, infusing replaces the DOM nodes for elements
with new ones, which would "disable" our event handlers.
To solve this, I'm creating two new layouts HTMLFormFieldLayout and
HTMLFormActionFieldLayout (subclassing FieldLayout and ActionFieldLayout)
with a common trait (mixin) HTMLFormElement. This is all implemented both
in PHP and JS. Right now it only serves to carry the 'hide-if' data from
PHP to JS code, but I imagine it'll be extended in the future for other
HTMLForm features not yet present in the OOUI version (e.g. 'cloner'
fields).
The code in hide-if.js has been modified to work with jQuery objects or
with OOjs UI Widgets with minimal changes. I had to duplicate the map of
HTMLFormField classes to modules they require there (from autoinfuse.js),
which is ugly - I'm fixing this in a follow-up commit
I3da75706209cbc16b19cc3f02b355e58ca75fec9.
Bug: T141558
Change-Id: I3b06a6f75eed01d3e0bdc5dd33e1b40b7a2fc0a2
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
Calling HTMLForm::setFormIdentifier() will set an internal identifier
for this form. It will be submitted as a hidden form field, allowing
HTMLForm to determine whether the form was submitted (or just viewed).
Setting this serves two purposes:
* If you use two or more forms on one page, it allows HTMLForm to
identify which of the forms was submitted, and not attempt to
validate the other ones. (T102114)
* If you use checkbox or multiselect fields inside a form using the
GET method, it allows HTMLForm to distinguish between the initial
page view and a form submission with all checkboxes or select
options unchecked. (T29676)
Bug: T102114
Bug: T29676
Change-Id: Ib6ce3fd8941be86211cff5c6932b5e84982490fa
'notice', 'notice-message' and 'notice-messages' can be used
as a parameter to the HTMLForm field to show the notices.
Only added implementation for OOUI forms because I'm not sure
what to do for others.
Bug: T104423
Change-Id: I512f3936bc3335df1bdf76505cfc39da6be99bed
Improves Ida647973a which unified message handling for form fields
but did not make the functionality available to HTMLForm itself.
Change-Id: I2e6195ba13afbd8b993acb47409fab1be91c547e
Fix a test in If4e0dfb : in the unlikely but valid case when
some form field object returns null from loadDataFromRequest,
handle it correctly and do not replace it with the default value.
Bug: T133163
Change-Id: Id8b48cfc6288d11a79a5838e72bb80b14137a7b0
- do not return anything when the button was not clicked
- return boolean true (instead of the button text) when it was clicked
Unbreaks submit fields which currently don't return anything so there is
no easy way to tell whether they have been clicked.
Change-Id: If4e0dfb6ee6674f0dace80a01850e2d0cbbdb47a
*-message(s) settings were documented as message key strings or arrays
of message key strings, but some actually accepted [key, params...]
arrays as well. They did not accept Message objects, which would be
the cleanest and most flexible method of message passing.
The patch adds a new method to process these settings (which accepts
a messages key, a [key, params...] array or a Message object), and
makes all *-message(s) usage call that.
Change-Id: Ida647973a58bea83fdbd53335e63b5a8615c16e4
Fix the OOUI field element implementation to conditionally add
labels to the FieldLayout (only if the label isn't empty). Also
add setShowEmptyLabel( false ) to HTMLButtonField (labels usually
aren't set outside of the button, the button itself should have a label).
Bug: T129821
Change-Id: I0499bb82245273519e77c80e78bc431588875a85
Depends on I0e5c956b9358b510c8473b1cfe6465ea1b5c07ef in OOjs UI.
This mostly reverts dd04b31052 and parts
of e85bd04bcd.
In addition to cleanup, it fixes bugs in HTMLFormFieldWithButton
(which did not add some attributes in OOUI mode) and HTMLMultiSelectField
(which did not do the mapping, losing some attributes in OOUI mode).
Change-Id: I0d1a5288e9edb73a0c3a8431feca9fcc67b72b6a
Switch to OOUI HtmlForm and replace mediawiki.userSuggest with
OOUI HtmlForm type user.
Bug: T117734
Change-Id: I37d9acbdd272c0cc2f2e120aada2e9fcea215509
Hidden elements doesn't need an extra element in the DOM, but OOUIHTMLForm
would render one, wrapped into a fieldLayout div.
Fix this by adding the possibility to bypass the output, and only construct
a HTMLFormField element and run the output method.
Bug: T117768
Change-Id: I8c9d2ff862f1b14d72a9bb9e1a51e8745af6d1f4
HTMLFormField subclasses are supposed to handle error display but
some (like hidden fields) have no means of doing this. Add
a HTMLFormField::canDisplayErrors() method which can be overridden
to return false, in which case HTMLForm will take care of the
error display.
Also adds a 'rawmessage' message which can be used to wrap
arbitrary text. This can be passed to methods which expect a message
specifier array but do not allow a message object (so the RawMessage
class cannot be used), such as HTMLFormField::trySubmit().
Bug: T112635
Change-Id: I5d73536805774ff2ee0ec64b5442650c4888dc84
HTMLFormField::getAttributes() is unfortunately reused both for
generating HTML tag attributes and generating OOUI widget
configuration. For boolean ones passing '' for true (empty string)
works for HTML (where the attribute only has to be present), but not
for OOUI (where the configuration option has to be truthy).
It would be cleanest to pass true/false, which is the expected input
for OOUI widgets and which the Html class handles intuitively, but it
seems that these values often end up in the Xml class's methods
instead (somebody remind me why do we even have that?). So let's play
it safe and pass the name of the parameter instead, which is okay for
both HTML/XML (both disabled="" and disabled="disabled" work the same)
and OOUI widgets.
(Note also that the whole thing relies on the default value of these
boolean parameters/attributes being false.)
This was not spotted before because we had hacks for this problem in
all the important places. This commit reverts three such hacky
patches that missed the underlying problem:
* e25eb30ea8
* 70910cd13c
* 8a164ff9f9
Change-Id: Ic6a1f3758cba62147f7fe8127cc0a83c695b0212
Depends on Ie14a35fac70d62ff7d102caaa56654ebde11d7dd in OOUI.
Part 2 follows after some cleanup in intermediary commits
in Ifbf38878d41906184f97169b22002f788711a311.
As a bonus, HTMLFormField::getOOUI() now always produces a
OOUI\FieldLayout in OOUI mode. This will let us clean up some code
where we had to take errors HTML from HTMLForm
(I91af6efa8762e9676efea532381292e221255862).
Bug: T98894
Change-Id: I860a96858c4fcac62d63b46e35a9153f22c0a9c9
Doxygen uses a single "\" as a start sign for a command.
Anything after "OOUI" will be interpreted as a command
(and throws a warning "Unknown command" or something else) when
you create the doc. The doc itself will show the following
as the return values of the function:
Returns
OOUI|OOUI
See: https://phabricator.wikimedia.org/F214499
As a workaround you can escape the backslash with a second
backslash (OOUI\\FieldLayout) or this notation should work, too:
OOUI::Fieldlayout
Follow up: I9050c4a09cbb841ad26ca01a25f706227e35e3be
Change-Id: I0c9300e72e00e1d827c63074cbaa51a935828695
