* Move the reset preferences link from the bottom of the preferences
form to the "basic information" section.
* Change the link from "destructive" red to default styling, since the
action requires confirmation so there is no reason to make the user be
afraid of clicking it by accident.
* Add a checkbox to the /reset form, for triple confirmation.
* Add a cancel button to the /reset form, to take the user back to
safety.
* Allow checkboxes to be "required" by fixing a detail in
HTMLFormField::validate(). The UI is not pretty, but it works.
Bug: T226325
Change-Id: I116d5275ba1a5beaaa44b32b8eff5824e94b437a
It gets wrapped into a Widget in ::getOOUI
Found by phan strict checks (used by tagfilter and cloner)
Change-Id: Ie1fd15fc2a66fcb39fa2e2f63761d9683029e395
This reverts commit a745a87216.
Reason for revert: logspam on use cases out side the scope of HTMLForm
Bug: T302512
Change-Id: Idcf1c7db89b4456308d57915ffd0dcc41ee577ad
The functions returning null or the class property is set explict null
Found by phan strict checks
Change-Id: I4a271093fb6526564d8083a08249c64cb21f2453
After its logic is refactored, we have more faith to use isDisabled() in these cases, which matches the original semantics of isHidden().
Change-Id: I1aece7c691307ac8bb3770e6dc4b8e2877e4d65c
This is a follow-up of change Ic414e7bb7933c8c5c58a277ac1c5c3aaf8c36119.
I noticed that HTMLForm would add a hidden field of edit token for forms
that require to be posted...
And I also noticed that there is a crazy use case (9ca8394943/includes/specials/SpecialTags.php (320))
that would break with the loose check (I'm also going to fix it by I5050311c37030a64daaa25d05e2223485ed86108).
So that change should be undone, but keep the POST check here to avoid
arbitrary token in a GET form.
Add more comments since there are some preconditions in another file and
avoid future regression.
(And I hope this is the last time I fix this test...)
Change-Id: Ib02cd6b4a45e3820c4378fe5b0c7fc61fe1251e7
This can help check fields default to true or have 'invert' enabled to
load correct data, because the 'false' values of checkboxes can never
be included in the request of normal use cases. Also better to other
use cases in HTMLCheckMatrix and HTMLMultiSelectField.
This partially reverted I5589ba7383587afdd9307c79e88849dacee02706.
I get trapped by the test case... The default value does need an invert
to check for hide-if and disable-if, like what
HTMLCheckField::getInputOOUI() do for display.
Depends-On: Icfa062eada75c50cd2c8bc5db2930602d80e9ae7
Change-Id: Ic414e7bb7933c8c5c58a277ac1c5c3aaf8c36119
Old codes relied on some assumptions, so:
* When a "key in form descriptor" is provided, the 'name' param can't be set otherwise the js wouldn't be able to find it.
* When a "name for submission" (with 'wp' prefix or same as the 'name' param) is provided, it works on the client-side but something might be broken on the server-side.
Since the documented usage is to use "key in form descriptor" and most use case is fine, the use of "name for submission" is explicitly disallowed here.
Use cases simply with the 'wp' prefix would still keep working on both sides though.
Depends-On: I27fd8fa9643d611b37e3f47e77b698245814d539
Change-Id: I9a42417a6161f42181badd8cdbec81ba85dc62f6
Don't catch and discard exceptions from the RequestTimeout library,
except when the exception is properly handled and the code seems to be
trying to wrap things up.
In most cases the exception is rethrown. Ideally it should instead be
done by narrowing the catch, and this was feasible in a few cases. But
sometimes the exception being caught is an instance of the base class
(notably DateTime::__construct()). Often Exception is the root of the
hierarchy of exceptions being thrown and so is the obvious catch-all.
Notes on specific callers:
* In the case of ResourceLoader::respond(), exceptions were caught for API
correctness, but processing continued. I added an outer try block for
timeout handling so that termination would be more prompt.
* In LCStoreCDB the Exception being caught was Cdb\Exception not
\Exception. I added an alias to avoid confusion.
* In ImageGallery I added a special exception class.
* In Message::__toString() the rationale for catching disappears
in PHP 7.4.0+, so I added a PHP version check.
* In PoolCounterRedis, let the shutdown function do its thing, but
rethrow the exception for logging.
Change-Id: I4c3770b9efc76a1ce42ed9f59329c36de04d657c
Values loaded from the default wouldn't be inverted, there is no need to copy the conditions to here, we can just simply bypass them.
Fortunately, nothing can be affected in a normal use case, since all value of fields would be set to server.
Thanks to the newly added tests, which helped me to realize this problem.
Change-Id: I5589ba7383587afdd9307c79e88849dacee02706
Follow-up changes will use cond-state params in other functions, split this out to make sure it's validated.
Change-Id: Icf358794b11a8f986fbd02c8f1b15ea9d1ef4d15
I believe there is a mistake, since DefaultPreferencesFactory::cleanSignature() uses it as field data, which is the only filter applied in the core.
Change-Id: Ic7aa509a3e5fd3a3c717259d83d5bf0a26d3556a
Data of disabled fields wouldn't be sent to the server, which needs to load data from default.
Bug: T298614
Bug: T298819
Change-Id: I58f9df384df8ecc5ebae8cac68ec2251351bc984
There is only one use case of cond-state classes passed to the client-side, and it can be done more natively.
Change-Id: Ib6835bb334bd65c6176f0a5c3881b20265901af9
Array addition in PHP does not renumber keys, so it can't be used to get
the union of two lists.
Bug: T297975
Change-Id: Ic9932b23e32c704b14fc9fe234c35a48b59767c5
The restrictions were introduced in r53480 (724411c7ca, 2009),
which makes it clear that this was just about HTML correctness,
and in HTML5 there are fewer requirements.
This code was last touched in commit fd6e9ef2d4 (2017), where it was
suggested in code review that it "can probably be removed":
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/362326/comment/6e71af52_900abad4/
Bug: T126962
Change-Id: I54c1f28ec9112cd4a161a79e76c2224f91f134b9
Rename to 'mw-htmlform-autoinfuse'. This avoids the 'mw-htmlform-field-'
prefix normally only used by HTMLFormField subclasses, and matches the
'mw-htmlform-autoinfuse-lazy' class used in related code.
Bug: T278036
Change-Id: I4a73ec6d5993a7e4f10ef8523eef594a70c9abcc
… including PHPDoc tags like `@return <type> $variableName`.
A return value doesn't have a variable name. I can see that
some people do this intentionally, repeating the variable
name that was used in the final `return $var;` at the end
of a method. This can indeed be helpful. I leave a lot of
these untouched and removed them only when it's obviously
wrong, or does not provide any additional information in
addition to what the code already says.
Change-Id: Ia18cd9f25ef658b08ad25b97a744897e2a8deffc
The message keys by 'options-messages' are evaluated with
Message::plain(), but some situation needs Message::parse() to support
templates and HTML formatting in this values.
Bug: T58633
Change-Id: I8f52f21ae2641ddcad1aa85ce6bf14de1a09ab4b
Continuing the work for 441e12f2d9,
which did this for the main HTMLForm errors (grouped at the top of
the form). This handles errors for individual fields.
This fixes the display of error/warning messages on Special:CreateAccount,
and should not break anything else too badly (it helps that most forms
are using OOUI these days).
Bug: T246894
Change-Id: If1ccdff10bebe0c2eeca4c15d82271c9de1af164
Scalar casts are still allowed (for now), because there's a huge amount
of false positives. Ditto for invalid array offsets.
Thoughts about the rest: luckily, many false positives with array offsets
have gone. Moreover, since *Internal issues are suppressed in the base
config, we can remove inline suppressions.
Unfortunately, there are a couple of new issues about array additions
with only false positives, because apparently they don't take
branches into account.
Change-Id: I5a3913c6e762f77bfdae55051a395fae95d1f841
The return type of HTMLFormField::loadDataFromRequest to mixed
Some sub classes returning arrays or bools, not everytime strings
HTMLCheckField is working with arrays, so also allow array on getTableRow
Change-Id: I076feea76d8e296f27c8a9fb4cbd9368584ba187
Mocking variadic arguments does not work in hhvm
Follow-Up: I066ec95a7beb7c0665146195a08e7cce1222c788
Change-Id: Ic3b689d003a4659abdc4c9344ffd83f24f448912
HHVM does not support variadic arguments with type hints. This is
mostly not a big problem, because we can just drop the type hint, but
for some reason PHPUnit adds a type hint of "array" when it creates
mocks, so a class with a variadic method can't be mocked (at least in
some cases). As such, I left alone all the classes that seem like
someone might like to mock them, like Title and User. If anyone wants
to mock them in the future, they'll have to switch back to
func_get_args(). Some of the changes are definitely safe, like
functions and test classes.
In most cases, func_get_args() (and/or func_get_arg(), func_num_args() )
were only present because the code was written before we required PHP
5.6, and writing them as variadic functions is strictly superior. In
some cases I left them alone, aside from HHVM compatibility:
* Forwarding all arguments to another function. It's useful to keep
func_get_args() here where we want to keep the list of expected
arguments and their meanings in the function signature line for
documentation purposes, but don't want to copy-paste a long line of
argument names.
* Handling deprecated calling conventions.
* One or two miscellaneous cases where we're basically using the
arguments individually but want to use them as an array as well for
some reason.
Change-Id: I066ec95a7beb7c0665146195a08e7cce1222c788
array_shift manipulates the original array. This is surprisingly
expensive, because it iterates *all* elements in the array and
decrements numeric keys. The code touched in this patch does not need
this restructured new array, but only the individual elements.
Change-Id: Iee28377b2c9930f6de821e041381a1d7564f7633
