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
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
This patch introduces a new namespace declaration,
MediaWiki\Xml and adds Xml and XmlSelect to it
and establishes class aliases marked as deprecated
since version 1.43.
Bug: T353458
Change-Id: I45cccd540b6e15f267d3ab588a064fbeb719d921
Nowhere it has ever been activated for many years.
Nobody has been missing it.
Nobody wants it.
Bug: T361032
Depends-On: I2761d634b2c351d755c664778ee0a4796d67c37b
Depends-On: I419cba60e43e10a0a3003f911bd125573b3b7cd7
Change-Id: I067866abc9cc6acdcf05b6048416cfa6caad66d6
Described as "Evil hack for mobile :(", this config variable had been
overridden in the MobileFrontend extension for some time, but this has
been removed last year in Icb1711a0cef828dda0d99b8a7c7963bc409816c9.
Since it was introduced, most HTMLForms using the 'table' format have
been reworked to use 'ooui' (or 'codex', these days), so the hack is
no longer needed.
We recently removed $wgUseMediaWikiUIEverywhere for similar reasons
in aa7eeeeef9 / be135c0fc0.
Change-Id: Id507c0dc5a1c1cfb9737073bae97b14badc30a54
- Override HTMLForm::wrapFieldSetSection() to apply the right
markup and classes for a fieldset and its legend
- Override HTMLForm::formatSection() to include the
.cdx-field__control class
- Add a setter for section info to HTMLForm (that only
works when the display format is 'codex')
- Add an optional flag message
- Override HTMLForm::getLegend() to include CSS classes
and additional sub-elements of the legend, including an
"optional" flag and a description.
Implementation notes:
- CodexHTMLForm::getLegend() returns HTML, while the parent
method returns plain text. This was necessary to include
the "optional" flag and description within the legend
element, which is critical for users of assistive tech.
- setSections() was added to HTMLForm instead of CodexHTMLForm
to support use cases like FormSpecialPage, which expect the
form to be an HTMLForm
Bug: T359020
Bug: T359016
Change-Id: I7b637331e171c46b48de085a6fa92f8ceaf16a50
Mixing different binary boolean operators within an expression
without using parentheses to clarify precedence is not allowed (T358966)
Change-Id: I24ca752d5dac7c948fdbcabf721f6f0aef8a466f
Add the 'option-descriptions', option-descriptions-messages' and
'option-descriptions-messages-parse' settings to HTMLRadioField, which
allow setting descriptions for each option.
For simplicity, only support this for HTMLRadioField, and only for
Codex. See also T324268 for a previous stalled attempt to implement this
for OOUI, which ran into issues.
Bug: T359019
Change-Id: I38116bb2fa3086408d3e2b47e5fe020b30f9729a
Example at Ia0281346be:
```
$form->addButton( [
'name' => 'renew',
'value' => '1',
'label-message' => [ 'wikimediaevents-special-wikimediadebug-submit-renew',
Message::durationParam( self::DEFAULT_EXPIRY )
],
] );
```
Causes
> `PhanTypeMismatchArgument Argument 1 ($data) is array{…label-message:array{0:'wikimediaevents-special-wikimediadebug-submit-renew',1:int[]}} but \MediaWiki\HTMLForm\HTMLForm::addButton() takes array{…,label-message?:\MessageSpecifier|string|string[],…} defined at ../../includes/htmlform/HTMLForm.php:1244`
The inferred return value of Message::durationParam() and other such
Message class methods is `int[]`, not string.
Change-Id: Id0835193442e17e0f9979373c366c087ff4a7640
Removing the config variable in a separate change:
Ib9966bc6a4a94f771cb99a5aa52fb6a1dc826ca5
(just in case something depends on its existence).
Bug: T182050
Change-Id: Ic3e038df16fc540ec7f6bcb9a54d73f8d596d305
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
I've never liked how HTMLForm guesses the method names that return
each field's HTML based on the $displayFormat property, for example
`$displayFormat === 'div'` resulting in using `->getDiv()`. Recently
this mechanism resulted in CodexHTMLForm lying about its display
format to get the desired result. Instead, explicitly switch based
on the display format and call the appropriate method, and override
this in subclasses when using subclasses.
Change-Id: I91b802ac63622e3b592be589d89ea11117a616f8
This is mostly so that I can add nice type hints. (But also, this is
one of the main things that this class does, I think it deserves its
own method instead of being sandwiched in that ugly loop.)
Change-Id: I621b839a8079cee1198c4250686e378ff7006c75
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
Changes:
* Use Codex markup instead of mediawiki ui markup
* We limit what can be customized by the skin
* Current rules for touch area and snapping of
inputs is moved from Minerva into core so other skins
benefit from the styling
* A placeholder text is adding to the "real name" field.
* Introduce CodexHTMLForm
Bug: T182050
Change-Id: I834cc0e07fc1e705753df6866a5eeda2ac77fb8e
Special:Logs is prefilling fields manually by the `default` param
for compatibility with links without `wpFormIdentifier` set.
That disabled the validation built in HTMLForm, since we would
give up when the default value is invalid.
Prefilling fields and trying submit should be fine if the caller
is sure that the page only contains that GET form.
Bug: T338042
Change-Id: I047d2546d3dacc672304dab1e362c08992e68308
* Inappropriate @inheritDoc usage. Arguably all @inheritDoc is
inappropriate but these are the ones PHPStorm flags as misleading
due to the method not being inherited.
* Doc comment type does not match actual argument/return type.
* I replaced "@return void|never" with "@return void" since never means
never, it doesn't make sense for it to be conditional. If a method
can return (even if that is unlikely) then @return contains the type
that it returns. "@return never" means that there is no such type
because the method never returns.
* Incomplete/partial/broken doc tags
Change-Id: Ide86bd6d2b44387f37d234c2b059d6fbc42ec962
Use cases of HTMLForm should not supply user inputs as the default
value, espacially values that can't pass validations.
Bug: T41126
Change-Id: Ia50b06e12fbe5d47165a73245e695ba75fa4faec
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
The methods HTMLFormField::getDiv, getRaw, getInline, etc. all
accept a single string parameter, but here are being passed null.
This raises a deprecation warning in PHP 8.1 in some situations,
(because of deeper usages of substr() etc.).
Bug: T289926
Change-Id: Id965f42b9cb4fc617d89c26d4459c66c3c478090
Mainly, document some parameters as non-empty-array so that phan knows
the list of arguments won't be empty when unpacking.
In EditPage, account for hooks potentially unsetting the copyright
notice.
Also rewrite some code in LogPager, so it's hopefully easier for phan to
understand what's going on.
Change-Id: Ic0638571554424098d0743db32dd46723a08e103
