Let the search engine controls if multimedia results have to be shown
in the new interwiki sidebar.
Bug: T164925
Change-Id: Ie3ccb28bf73110b136475e9527a2653bf06b8e45
Various improvements to the sister-search sidebar:
- using WM project favicons
- scoping CSS specific to sister-search sidebar
- making sister-search items more compact
Bug: T160724, T158938
Change-Id: I2794121ab83cbd4e2b8868150e4d61db376fa63b
Current way of counting returned search results (e.g. for
Event Logging) relies on counting the appropriate elements
in the search results page's DOM, up to the limit the user
requested (e.g. 20 by default). This allows us to record
the total number and the offset, useful for event logging.
For example, if we wanted to know whether the user viewed
2nd or 3rd set of search results.
Change-Id: Ic8601e9eeddac84ba8e0d7dc6f127bf360b6f90f
Causes deprecation warnings.
Most of this code is copy-pasted from OO.ui.SearchInputWidget.
Bug: T148471
Change-Id: I81d52ba938a8b90c5d2c173f1f2682d9e3300e43
These are a few minor fixes to improved the
UX of the new sister search sidebar.
- Making the link color on sister search results blue
- Fixing the order of the multimedia search results widget
- added a more explicit 'more results' message instead
of the current '(more)' message.
- aligning the top of the sidebar with the top of the regular
search results.
- fixing a typo in the multimedia widget.
Bug: T158935
Change-Id: Iaae603cc217b7847bebfa61b050b7c86bdd19f14
A hidden input 'profile' gets added within the search form widget no
matter what profile is loaded at the moment. This is done in
shortDialogHtml along with a few other hidden fields. The same hidden
field is added a second time in optionsHtml if the profile 'advanced' is
run. Remove this redundance.
Bug: T158869
Change-Id: I3be598702dbe9fa2cfe0fdd6c23fe6d88477626d
I think ideally, these would be at the end of the form, but there
are some hooks below which can produce arbitrary HTML and potentially
want to override these with their own fields, so I'm avoiding any
revolutionary changes to the field order here.
Bug: T158856
Change-Id: I377c0061a365930e11454a86c1e0926853789b55
A recent patch updated these two calls to use Message::parsed(),
but it should have used the Message::parse() message.
Change-Id: I5aba40576b89f21d2b1416ca0db0d28d2a088c39
A recent refactor of the interwiki sidebar looks to have a small
regression, in that this message used to use ->parsed() but now
uses ->escaped(). Switch back so the interiwki results on beta
render appropriately.
Bug: T149806
Change-Id: I44d0b1cd3bcc0606a0fb14e171d51bec1c310a91
Changed use of escaped() to parse() to allow wikilinks in
MediaWiki:Powersearch-ns. Use case is provided in T157204.
Bug: T157204
Change-Id: Ic2eb28aaf735c31b50f3365176966e2e48091e54
New widget and html form field, which allows selecting multiple
users using convenient single-line input (CapsuleMultiselectWidget)
Bug: T131492
Change-Id: I7b6ffe7fb47e0a7083e2a956156ab0f142444398
Add a "longDisplayFormat" config option to DateInputWidget to show
full month and day names when using the default locale-specific
display format.
Bug: T120733
Change-Id: I2db6892720abf86dfc9655291b1070aa7f7bf77b
Reasons:
* $text is vague. It's the label of the link. There is a function named
getTitleSnippet, which is what I'm reusing for the variable name.
* $page is vague. It's not the page of the search result, but the search
special page.
* $queryString is not a string but an array of strings.
I also updated https://www.mediawiki.org/wiki/Manual:Hooks/ShowSearchHitTitle
accordingly.
Change-Id: Ia18dbf5ccf7f9fcc8890ad01641d0b7ff3e6eee8
Has a pre-existing problem related to the link offset of secondary
inline results. Specifically the offset of secondary inline starts
at the provided offset, even though there may be primary results
displayed above it.
Bug: T150390
Change-Id: Id1d6b357f45a2cf615d9412cc95dd597c724e8b6
First step in refactoring the search results page. Pulls out widgets
to render our two styles of search result, Full and Simple.
Bug: T150390
Change-Id: If78cb0c29ae394f16e465c15a8e8246c1b56dcea
For consistency with how normal OOjs UI widgets behave.
Only one usage outside of HTMLForm needed updating. There
are no usages in extensions in Gerrit.
Change-Id: I9b5de86307a13ca7355b7541e8683e4d6a10431f
SearchInputWidget is similar to a TitleInputWidget, but doesn't has
a visible loading indication, doesn't highlight the first result and
uses the opensearch api endpoint for suggestions, instead of
prefixsearch.
Extra points:
* Improve documentation of mw.widgets.TitleInputWidget's configuration
option validateTitle
Bug: T118443
Change-Id: I8b8098041fe2971389fa908d007d2e77255829ec
config.validate is already given and used in OO.ui.TextInputWidget to
define a string/regex/method where a query is checked against. TitleInputWidget
would override it with a config option to enable/disable this check.
The config option "validate" uses the "validateTitle" name, now. There was
no usage so far.
Follow up: I732a2f56a2375d8c708e3b295996187ee209f1a6
Bug: T119075
Change-Id: Ibb47b20506d21213fc9681b6aa919ce45505e474
For some use cases an empty value is valid, too, or at least, it's not a reason to
mark the form input red. Special:Search, e.g.. This change implements a new config
for MediaWiki\Widgets\TitleInputWidget, validate, which allows a user of this
widget to decide, if the value of the input type should be validated (empty -> flagged
red).
Extra points:
* Fix php notice errors for previously added configuration
* Added doc for previously added configuration
Bug: T106946
Change-Id: I732a2f56a2375d8c708e3b295996187ee209f1a6
Recreated the form with OOUI widgets. This required putting together
ComplexTitleInputWidget to handle the split namespace+title field on
this page.
Bug: T86865
Change-Id: Ice69df851137e3454ae2c9f4c75494b18cf8a75a
Integrate $.byteLimit functionality into OOjs UI's value preprocessing
(#cleanUpValue), rather than just calling in on #$input, to avoid
validity state flashing back and forth when the value is limitted.
Bug: T106454
Change-Id: I3d24e4bf7427c9bd922ff2e24edc9583ee0aaecb
* Refactor NamespaceInputWidget into two widgets: NamespaceInputWidget
and ComplexNamespaceInputWidget. The former is now only the dropdown
(and inherits from DropdownInputWidget), the latter is the dropdown
plus two checkboxes.
* Change ComplexNamespaceInputWidget configuration to take nested config
for `invert`, `associated`, and `namespace`, rather than require
parameters like `invertName` and so on for every combination.
* Implement standalone JavaScript versions of both widgets (previously
mw.widgets.NamespaceInputWidget could only be created via infusion
of the PHP widget).
Bug: T99256
Bug: T106138
Bug: T109559
Change-Id: Ie2fee6d035339ceb934fca991675480db3d630d1
To use OOUI for forms with user name autocomplete, the new widget
UserInputWidget interacts like the jQuery pendant (working with css
class "mw-autocomplete-user").
It is also available in HTMLForm as "user".
Example usage: Iaeff912e6437d6ebef0d5b1919ce8cf53a7fd5f1
Change-Id: I9501c85f4288c255bbe3a5284e99b57b6169916f
