== What ==
This method was "Copied from OOUI\Tag", which no longer does this
since last year (I42c7a7b4d, 6e4e1a1796). Apply the same change here.
== Why now ==
Triggering E_USER_ERROR is deprecated in PHP 8.4+.
Bug: T381341
Bug: T379445
Change-Id: I1bac121caf746c30996dccd7fb95c4c240742951
(cherry picked from commit 751eca89fe473cc4a649e47dd54e9ab38f7c1957)
* This change introduces two new optional parameters to the 'allusers'
API call named 'excludenamed' and 'excludetemp' that allows filtering
accounts based on whether they're named accounts or temporary
accounts. This is tested by using the temporary matchPattern
configured with $wgAutoCreateTempUser.
* User widgets that call 'allusers' have been updated so that
'excludenamed' and 'excludetemp' can be optionally set so that named
or temporary accounts may not returned with user suggestions.
Bug: T332030
Change-Id: I6563ae610017fd1cd35c36ba65906041f7f68c4b
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
In PHP 8, but not in PHP 7.4, every class with a __toString() function
implicitly implements the Stringable interface. Therefore, the
behavior of checks like "instanceof Stringable" differs between these
PHP versions when such classes are involved. Make every such class
implement the interface so that the behavior will be consistent.
The PHP 7.4 fallback for the Stringable interface is provided by
symfony/polyfill-php80.
Change-Id: I3f0330c2555c7d3bf99b654ed3c0b0303e257ea1
This patch refactors various widget classes in the includes/widget
directory to use cleaner namespacing. The patches remove redundant backslash
prefixes in class extending statements and add use statements for OOUI classes
and other MediaWiki-specific classes. This patch improves readability and
maintainability of the code by following the MediaWiki coding conventions and
leverages the benefits of PHP's namespacing system.
List of affected classes:
- CheckMatrixWidget
- DateInputWidget
- DateTimeInputWidget
- NamespaceInputWidget
- SearchInputWidget
- SelectWithInputWidget
- SizeFilterWidget
- SpinnerWidget
- TagMultiselectWidget
- TitleInputWidget
- UserInputWidget
Additionally, the code now correctly documents exceptions thrown by
constructors where missing, enforcing clearer developer expectations.
Change-Id: I0fdaf68a412a1c3b7049a79222f4dbeaa95a6bbc
This patch refactors the ComplexNamespaceInputWidget class to use
fully qualified class names for OOUI components. It removes the manual
specification of the OOUI namespace within the class and instead relies
on the `use` declarations at the top of the PHP file. Additionally,
it adds the Exception class to the list of used namespaced classes,
preparing for explicit exception handling.
Change-Id: I3fe255f491979b63b5361da69a87c32b4fa65b5f
This is the more native way of doing things, which avoids syncing
different states between the toggle and the hidden widget.
The DOM structure is also better and don't confuse screen readers.
Bug: T333496
Bug: T334705
Bug: T336107
Change-Id: I47de69459b96f172153065094eb4113584bb435a
Capitals are meaningful on some wikis, and they call it out with
$wgCapitalLinks. Match the autocapitalization behaviour with this.
This is mimicing the same functionality as applied to the skin
autocomplete, found in SkinComponentSearch.
Bug: T335551
Change-Id: I98c39061cd7a3d601f5380edd9730bf61f8339fd
TitlesMultiselectWidget and NamespacesMultiselectWidget both default
to false, meaning click-to-edit on the tags is disabled. Allow this
to be overridden from the corresponding PHP form fields.
This helps to provide a workaround for the related bug: T334711
Change-Id: I4014c5ba7fea0647da6ec6c420342a41ac90518b
This is required for HTMLDateTimeField to be compatible it:
HTMLDateTimeField filters out mustBeAfter/mustBeBefore, while
DateInputWidget didn’t understand min/max until now. Since moment.js
(used by the JavaScript side of the widget) seems to better like the
mustBeAfter/mustBeBefore semantics (strictly larger/smaller than) than
the min/max one (larger/smaller than or equal to), I decided to
internally keep mustBeAfter/mustBeBefore.
Bug: T219633
Change-Id: I487363e40d1e4f74780ed7146c8a6770bfc61fae
Implements HTMLTagMultiselectField, a form field that instantiates
TagMultiselectWidget, the PHP representation of the OOUI's js-based
widget of the same name with the implemented parameters:
* allowArbitrary
* allowedValues
Bug: T278317
Change-Id: I3a6a30506d493be4185f917c577b3837fffd8ae1
Expecting people to magically know that MediaWiki\Widget\SearchInputWidget is
generic and for use on random pages, but MediaWiki\Widget\SearchResultWidget
is super-specialised, based on bespoke technologies, and only for use on
Special:Search, is not great.
None of these are used outside the MediaWiki core codebase and so this change
whilst it would otherwise be technically breaking is fine.
Change-Id: I16d21dd5e1ac3aa9893863df272d1bbb4788066f
Done:
* Replace LanguageConverter::newConverter by LanguageConverterFactory::getLanguageConverter
* Remove LanguageConverter::newConverter from all subclasses
* Add LanguageConverterFactory integration tests which covers all languages by their code.
* Caching of LanguageConverters in factory
* Make all tests running (hope that's would be enough)
* Uncomment the deprecated functions.
* Rename FakeConverter to TrivialLanguageConverter
* Create ILanguageConverter to have shared ancestor
* Make the LanguageConverter class abstract.
* Create table with mapping between lang code and converter instead of using name convention
* ILanguageConverter @internal
* Clean up code
Change-Id: I0e4d77de0f44e18c19956a1ffd69d30e63cf51bf
Bug: T226833, T243332
Passing around strings that are expected to be safe html and are
known to be based on user input is a fairly unsafe operation. Make
it harder to do the wrong thing by requiring HtmlArmor to be returned
from the ResultSet snippets. This does not address the snippets on
individual result objects as the api surface is larger and requires
more bc handling.
Change-Id: I76231d6fc53c4982eb4cd174d2e6a75eb2740497
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
Repeating the variable name doesn't do anything. Documentation
generators don't need it. It's more stuff to read that doesn't add new
information. And it can become outdated.
Note there are two types of @var docs. When used inline (and not on a
class property) the variable name is needed.
Change-Id: If5a520405efacd8cefd90b878c999b842b91ac61
Pass through config options from HTMLUserTextField that allow the
field to accept an IP address and/or range, and specify the maximum
allowed range size.
Bug: T238277
Change-Id: I0e0f6b6fd6801d5cd561def28917e81a81b3f7d4
These were all checked with codesearch to ensure nothing is overriding
these methods.
For the most part, I've updated the signature to use nullable types; for
two Pager's, I've just made all parameters non-optional, because you're
already forced to pass them with a required parameter at the end.
Bug: T231636
Change-Id: Ie047891f55fcd322039194cfa9a8549e4f1f6f14
Explicitly declare all dynamic properties. Add docblocks for several
props. Remove the defaults when they're already set in the constructor.
Make TagMultiselectWidget use ?? like other widgets.
Change-Id: I889bf6f9e1bbe381f5bffb8ce1370c9e2e863520
Alters the SelectWithInput to allow a required config to be passed from a
parent widget. Also handles the required state dynamically. If the widget is
an OR widget, then only the select dropdown is required. The text input will
be required when the other option is selected. If the widget is an AND widget
then both the select dropdown and the text input will be required.
Bug: T220533
Change-Id: I8479743126756f2b1bd7bcd53b100a0134f34d07
And start indicating that hooks relying on this data might become
unreliable as this data is only populated by SearchDatabase search
engines.
This information was only populated by SearchDatabase implementations
and due to bad initial design of SearchResult[Set] (now fixed) it forced
users of these classes to carry this information for the sole purpose of
highlighting.
Because SearchEngine can now own their SearchResult[Set] implementations
nothing that is engine specific should be exposed outside of these
specific implementations.
If there are some logic that still requires access to such list of terms
they should be made engine specific by guarding their code against
instanceof SqlSearchResult.
Change-Id: I38b82c5e4c35309ee447edc3ded60ca6a18b247a
Depends-On: I53fe37c65c7940f696c1e184125e01e592a976e4
These global functions were deprecated in 1.34 and services made
available to replace them. See services below;
* wfFindFile() - MediaWikiServices::getInstance()->getRepoGroup()->findFile()
* wfLocalFind() - MediaWikiServices::getInstance()->getRepoGroup()->getLocalRepo()->newFile()
NOTES:
* wfFindFile() and wfLocalFind() usages in tests have been ignored
in this change per @Timo's comments about state of objects.
* includes/upload/UploadBase.php also maintained for now as it causes
some failures I don't fully understand, will investigate and handle
it in a follow up patch.
* Also, includes/MovePage.php
Change-Id: I9437494de003f40fbe591321da7b42d16bb732d6
T208768 introduced the PermissionManager service that can now be used
for page specific permission checks. This change replaces remaining calls
to Title::userCan() with the new service in MediaWiki core.
Bug: T220191
Change-Id: Ie45e0cb6aa49a8c66147b470946161fc18160fc1
