The funky iteration here was at best annoying. Switch
it over to an iterator based approach with appropriate
BC code to simulate the old iteration style.
Depends-On: I19a8d6621a130811871dec9335038797627d9448
Change-Id: I9fccda15dd58a0dc35771d3b5cd7a6e8b02514a0
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
Special:Block needs a date time selector for easier selection of expiry. To
accommodate this cleanly, a new Expiry Widget is created that handles this
logic.
Bug: T132220
Change-Id: I2853a2ca0ae6ccead3978f4bb50a77c2baa3a150
Update the flag for new interwiki sidebar from unset means disabled
to unset means enabled. Deprecate the old rendering widgets to be
removed at a later date per deprecation policy.
Change-Id: I80d8375bbd3e1fabc9b2432b6875d17a96aee099
Related: I9a488438
Most notably: The documentation header repeats the file name. This
appears to be fully automatically generated, but does not add helpful
information.
Change-Id: I9edf15dd25ef6cc52fe931fffde69f0bd9042474
With some special tweaks:
* Remove weird custom overlay handling in DateInputWidget that nobody
actually used. I think if you need something special like that, you
can just write two lines of JS code to attach the dropdown elsewhere.
* Also handle the CapsuleMultiselectWidget produced by HTMLForm's
'multiselect' field in the same way.
Bug: T183069
Change-Id: I693f406194aeb826a3ab5bc78c97015b0b8a7fdb
Clean up use of @codingStandardsIgnore
- @codingStandardsIgnoreFile -> phpcs:ignoreFile
- @codingStandardsIgnoreLine -> phpcs:ignore
- @codingStandardsIgnoreStart -> phpcs:disable
- @codingStandardsIgnoreEnd -> phpcs:enable
For phpcs:disable always the necessary sniffs are provided.
Some start/end pairs are changed to line ignore
Change-Id: I92ef235849bcc349c69e53504e664a155dd162c8
I can see that "parent::__construct" literally calls the parent
constructor. I can see that stuff preceeded by the keyword "protected"
is protected. I really (really) don't need comments explaining such.
Change-Id: I7458e714976a6acd3ba6a7c93fdc27d03903df83
The code uses $size, which does not exist and never used otherwise.
The actual size HTML is stored in $desc.
Change-Id: Ida5e69c81acea6bdec75810cf7b192f9dc7cf327
This would allow extensions to define custom attributes on title link,
such as put information in "title", change attributes depending on
specific search hit, etc.
Now Wikidata does the same by overriding LinkBegin, but this applies
to all links, not specifically to search result link.
Since ShowSearchHitTitle is always used with the link, I think it makes
sense to enable this specific customization.
Change-Id: I19f64e0909d92e32ddf6271f74c014e8b65d5014
Release notes:
https://phabricator.wikimedia.org/diffusion/GOJU/browse/master/History.md;v0.23.5
Also, replace uses of `OOUI\TextInputWidget( [ 'multiline' => true ] )`
with `OOUI\MultilineTextInputWidget()` to avoid deprecation warnings
(which cause unit tests to fail).
Depends-on: I990b14982ffb72fe981040d02c7023d13f721aaa
Change-Id: If8312c60e1547a6177f5491011badb6576f54b21
But we should also have a different class name for this, as this isn't
upstream's SearchInputWidget.
Bug: T177659
Change-Id: Ie62e8678e89b2403d769694adb23fe21a047019c
- mostly auto fixes
- some too long lines fixed
- ignore amp space in one case passing by reference
Change-Id: I6472f83bc3cbf4bd629d83050cc3319b19ec465c
Makes the header on interwiki results
(results from different languages on Special:Search)
bigger.
Bug: T146655
Change-Id: I10ea6f85f97b4c8a5e585b2b1090af68054cbe2c
Typing a search query into the main box on Special:Search
causes the search to be performed for the first autocomplete
result, rather than the typed query. The first autocomplet
result should only be searched for if explicitly selected with
the mouse or arrow key.
This reverts commit 7882e3b660.
Bug: T171112
Change-Id: I1af6ba90542fafe3ed1aeca420e9d6df6612f7d0
Bonus:
* Remove puzzling code that claimed to fix a bug that I couldn't reproduce
but instead made single-character searches never display suggestions
* Clear the input after choosing a menu item
Change-Id: I44e72205880d152639ee823238dc5ab84d34402b
Mixin mw.widgets.TitleWidget instead of extending mw.widgets.TitleInputWidget.
* Remove code that reimplemented pieces of OO.ui.SearchInputWidget.
* Remove code that overrode pieces of mw.widgets.TitleInputWidget.
* Copy the code from mw.widgets.TitleInputWidget that we actually want.
This should result in no functional changes, other than losing the
TitleInputWidget API (some methods and config options) that no one
relied on, as far as I can tell.
Bug: T169194
Change-Id: Ic1482b4c7cfde7d4cf0b8900654bd3a454776010
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
