Add doc-typehints to class properties found by the PropertyDocumentation
sniff to improve the documentation.
Once the sniff is enabled it avoids that new code is missing type
declarations. This is focused on documentation and does not change code.
Change-Id: I1f306a3925d6768209a06e70082598b2f70cd319
This new key name should better signal to developers that this key
will be used as-is without escaping
Bug: T356971
Change-Id: I98849b2e45cc4555eca7674875b9bed89f128310
get_debug_type() does the same thing but better (spelling type names
in the same way as in type declarations, and including names of
object classes and resource types). It was added in PHP 8, but the
symfony/polyfill-php80 package provides it while we still support 7.4.
Also remove uses of get_class() and get_resource_type() where the new
method already provides the same information.
For reference:
https://www.php.net/manual/en/function.get-debug-type.phphttps://www.php.net/manual/en/function.gettype.php
To keep this safe and simple to review, I'm only changing cases where
the type is immediately used in an exception message.
Change-Id: I325efcddcb58be63b1592b9c20ac0845393c15e2
In change I625a48a6ecd3fad5c2ed76b23343a0fef91e1b83 I am planning to
make Wikimedia\Message\MessageValue use it, and we try to pretend that
it is a library separate from MediaWiki, so it makes sense to move
MessageSpecifier to the same namespace under Wikimedia\.
Bug: T353458
Change-Id: I9ff4ff7beb098b60c92f564591937c7d789c6684
The code works with StatusValue, not just Status, so update the docblock
accordingly, especially considering the fact that more modern code
should prefer the former.
Also mention what the expected signature is by linking directly to the
callback property, so that developers don't have to scan the whole body
of `validate()` to figure it out.
Change-Id: I9d5f155d1d797e3fa8ab4a0f10cc19b21d933c8a
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: Ia35b2d3105880631dd26ec974068b000ac7f4b6b
This patch introduces a namespace declaration for the
MediaWiki\Json to FormatJson and establishes a class
alias marked as deprecated since version 1.43.
Bug: T353458
Change-Id: I5e1311e4eb7a878a7db319b725ae262f40671c32
Why:
* When using a HTMLFormField that has accepts the options-messages
parameter, the message keys are the key and the value is either
an array of options or the name of the value.
* However, when converting the message key to the translated text
it is possible for two or more message keys to have the same
translation (for example T19746 and T347314). This causes only
one of the duplicate items to be displayed in the options list.
* As such, an logstash error should be raised when this happens
so that, when debugging a missing option, the error can be found
and lead to the issue being found quickly. For example, in
T347314 it took several months for the issue to be found and
solved.
What:
* In HTMLFormField::lookupOptionsKeys, add code to check if the
translated text for the message key already exists in the array
of translated text to option value. If it does, then create a
logstash error and skip adding the item to the array (as it
will override the already added item).
* Also do this in LogEventsList and UsersPager, where the code
passes the options using the 'options' key and uses the
HTMLSelectFieldand. This means that HTMLFormField
::lookupOptionsKeys will not be called and as such need the
same code to handle the duplicate values.
Bug: T360326
Change-Id: Ifdeb917f7034967feed7a3b86aabec3c4d49bcc6
Mixing different binary boolean operators within an expression
without using parentheses to clarify precedence is not allowed (T358966)
Change-Id: I24ca752d5dac7c948fdbcabf721f6f0aef8a466f
Besides expanding getCodex() to build the Field component and its
constituent parts, this required adding parameters to pass the
cdx-message--inline class to the error box generation code, and passing
the error status to getCodexHtml() so that field subclasses can add
status CSS classes to the components they generate.
Bug: T359021
Change-Id: Iab3f3c81f4de034a3a04b54caf269de6fde4a7f2
It's a dropdown, not a drop down, therefore rename:
* Html::listDropDownOptions → Html::listDropdownOptions
* Xml::listDropDownOptions → Xml::listDropdownOptions
* Html::listDropDownOptionsOoui → Html::listDropdownOptionsOoui
* Xml::listDropDownOptionsOoui → Xml::listDropdownOptionsOoui
* Xml::listDropDown → Xml::listDropdown
In PHP, method names are case-insensitive, therefore we can do this
without a breaking change or deprecation.
This also matches the naming convention in OOUI.
Change-Id: Ifda13ba9dee316709c424636ec3b285de8d0e9b1
Treat Codex the same as OOUI, which also has separate getOOUI() and
getInputOOUI() methods. With this, we can refactor the HTMLFormField
subclasses that already have Codex support to override getInputCodex()
instead of checking for $this->mParent instanceof CodexHTMLForm.
The getCodex() method is mostly a copy of getDiv() for now. The next
commit reworks this to use the correct field wrappers that correspond
to Codex's Field component.
Bug: T359013
Change-Id: Iccd6fec003b6ca119b13c01a43dda9e8b2aca3e2
The main benefit is that IDEs, static analyzers and such are now
able to understand that this refers to code from the
HTMLFormFieldCloner class. This was completely hidden before.
Also fix a mistake in the documentation for getNearestField. This
was accidentally copying the getNearestFieldValue documentation,
which does return mixed.
Change-Id: Ie4204bc967013825d9d73d30f264b07ff0c9e846
This class is used heavily basically everywhere, moving it to Utils
wouldn't make much sense. Also with this change, we can move
StatusValue to MediaWiki\Status as well.
Bug: T321882
Depends-On: I5f89ecf27ce1471a74f31c6018806461781213c3
Change-Id: I04c1dcf5129df437589149f0f3e284974d7c98fa
Convert this in HTMLFormField::validate to prevent callers from
receiving unexpected Status instances that will be identified as
an error result, even if the Status is good.
Bug: T338677
Change-Id: If2208cca92c5c496eef73f25363221bc490d9c88
Some of these classes are really huge, up to 2000 lines and more. I
hope this makes the source code a little more readable.
Change-Id: I3d4b2a042a34c14e6ea0ea30ea31ca53448d8d59
While this is not really a bottleneck, I found this does quite a lot
of unnecessary things that are not used in this particular context.
All we want to know is if one or more help messages exist. We don't
need the actual, parsed help messages in this context.
Note this patch changes the code in a way that is not 100% the same as
before. Let's say there is only 1 message, and it's disabled. Since
the possibly expensive exists() check is delayed shouldInfuseOOUI()
might return true in rare edge-case situations where it returned
false before. I would like to argue this is worth it. We just trade
one performance optimization for another.
Change-Id: Ib4550e954853355f361249b13ec877478de9c789
Currently it is documented that mParent in HTMLFormField may be null.
This can happen if the form element is constructed manually via
new, instead of the normal way via HTMLForm methods.
As it stands, much of the code assumes that mParent is always set
despite the documentation. Lets mark creating form fields without
parent set as deprecated. The current situation seems like a
recipe for bugs, and after the deprecation period this would allow
us to simplify some of the HTMLFormField code.
Bug: T326456
Change-Id: Ica0740049f0a3e8ec764903c5b71825e4d628a3f
Depends-On: I15a39605e3eec8a5c265c4a331039fa906eda036
When a form identifier is set, HTMLForm::prepareForm() initializes
mFieldData as an empty array. When resolving hide-if conditions based on
other fields, HTMLFormField looks up that field's value in the parent
form's mFieldData and expects its key to be set, but it isn't because
mFieldData is deliberately empty. That causes an E_NOTICE for an
undefined index.
Resolve this by having HTMLFormField::getNearestFieldValue() fall back
to the field's default value when the field's actual value isn't found
in mFieldData.
Change-Id: I3a12f6aec1e8a6da3cd3a29195d37c12ebf08b16
null is the “default default” in getDefault() (if the method has neither
been overridden nor $this->mDefault been set), so it can appear in the
field data. Don’t pass it to the validator (which may not expect a null
value) if the param is supposed to be required.
Bug: T319219
Change-Id: Ib6bb119b841ffcbb5e7fb30014355dc90ba9b46e
Callbacks for validation-callback definitions are given the submitted
field value, which was documented as being string or array, but
actually can include int, null, etc.
This fixes the docblock, and also updates
DefaultPreferencesFactory::validateSignature() which was assuming
a string and not expecting null. (This didn't matter before PHP 8.1.)
Bug: T318307
Change-Id: Ia9096d610bf377334bbeab9021a8ade9be62edd5
Various variables are left from ealier refactor are now unused
and can be removed to make the code easier to read
Change-Id: Id51770af1f08e85c7e7a02234a2cd2ab5b47ee7a
* 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
