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
This for example will allow to display descriptions by setting:
$wgSpecialSearchFormOptions['showDescriptions'] = true;
Bug: T55652
Change-Id: Ifdbca4c508314cb950f2835ee65caea18e0af5b1
This means that the rememberme checkbox will not result in DB
writes on HTTP GET. If JS is enabled, it becomes GET initially.
Bug: T151903
Change-Id: If700ba9d6d1fe582d3d7c5660fcefd6d2639e4ee
Use the showPendingRequest config option instead of setting
a prototype method to false.
Bug: T222329
Change-Id: I0e3176141c63ed9a849326c2f9a5a26ffc2b273f
According to the coding standards we even enforce with a custom PHPCS sniff.
It currently does not pick these mistakes up because of the curly brackets.
I'm not sure if this is worth an update of the PHPCS sniff. I wanted to
suggest this fix anyway.
Change-Id: I9041ea7a00baf7f55e0ff0e56879a89fb74bb479
The check `if ( $config['disabled'] == true )` is the same as the
check `if ( $config['disabled'] )`. Was this intentional or was it
supposed to be a test for equality and type (===)? If not, then I
think this patch removes the irrelevancy.
Clearly, if the $config['disabled'] is set to false, the isset()
check will return true but the second check will fail even with
this patch as it does the same thing.
Change-Id: Ibbe5b4949590f8ac954f613236056dd2e6dd18ba
This might hint at an edge-case in the PHP CodeSniffer sniff that should
detect if methods are separated by a single empty line. Feel free to
investigate. I, personally, can't invest more time in this than
suggesting this quick fix.
Change-Id: Ib3c60eac76f255b4fe929f7933de256222716576
This change ensures that the toggle buttons are already present while
loading.
Depends-On: I41225ccdf8a95a7c501fb6eea99abbd08353f4ea
Change-Id: I3292cf48214b842542ba97730ad91a1e95d127fe
TitlesMultiselectWidget and UsersMultiselectWidget share
a lot of functionality, so implement a common base class.
This also adds some things to UsersMultiselectWidget:
* shows a pending element to users with JavaScript
* makes the input configurable
Change-Id: Ie6649b476c64e795254f457e3863fa7f14aa05ac
Create a PendingTextInputWidget and use it in
TitlesMultiSelectWidget instead of the multiline
text area for users who have JavaScript.
Bug: T210080
Change-Id: I824fea6a3df580d342e6087ab901fec025f0e70b
Pass through 'limit' and 'showMissing' configs.
Also set 'showMissing' to false for partial blocks.
Bug: T208626
Bug: T208627
Change-Id: Ifa75e2d390bf349226ad69d68adcdcaf742ab560
