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
Add the widget in both PHP and JS for OOUI, and into HTMLForm
definitions.
In JS, the widget uses the engine from mw.widgets.TitleWidget
with the async support from OO.ui.mixin.RequestManager.
The PHP version provides a textarea, like UsersMultiselectWidget.php
which is then infused if JS is available.
Also, add highlightSearchQuery option for TitleWidget to allow for
not highlighting the partial search query the user typed in, if the
UI requires it. This option (highlighting partial result) is already
optional in the TitleOptionWidget, so this config exposes that
optionality in the TitleWidget widget for its menu children.
Notes:
HTMLTitlesMultiselectField is a duplication of HTMLUsersMultiselectField
except for:
- The configuration variable changed to 'titles' (from 'users')
- OOUI modules were adjusted for the TitlesMultiselectWidget
- The PHP version instantiates a MediaWiki\Widget\TitlesMultiselectWidget
TitlesMultiselectWidget is a duplication of UsersMultiselectWidget
except for:
- $usersArray was renamed to $titlesArray
- getJavascriptClassName returns the correct js class for
mw.widgets.TitlesMultiselectWidget for infusion.
Bug: T197109
Depends-On: I675316dddf272fd0d6172ecad3882160752bf780
Change-Id: Ie96947a35f70b76731e16ae5b85de815dfa4a8ce
No longer used anywhere(?); we'd rather not have to explain the temporary
variable in the MediaWiki 1.32.0 release notes if we can instead just not ship
it.
Bug: T192620
Change-Id: Icfb82f228512ed45f1a27ce3e565fbc5fc09f39c
