This allows the URL to the other wiki's rest.php to be configured
exactly, rather than assuming that it has the same wgScriptPath as the
current wiki. This is necessary to make this feature work on PatchDemo,
where wgScriptPath looks like '/123abc456/w'.
$wgVectorSearchHost is removed, since nothing uses it except PatchDemo
(where it's broken) and development setups.
Bug: T319494
Change-Id: Ife042f4f683d366a31a642723746d4aa80774c03
Change I765d3bbf89 pushes the module over the configured maximum allowed
size (3 KiB, see bundlesize.config.json); shave off some bytes elsewhere
to bring it below the limit again. IMHO all of these changes should be
acceptable:
* arrow functions are already used elsewhere in this module;
* using the mw.config.get() fallback argument is normal (it slightly
changes behavior, but I don’t think explicitly setting the search
client or URL generator to a falsy value and expecting to get the
default behavior should be considered supported);
* not quoting [name="search"] matches [name=title] immediately above;
* using forEach() with a function reference is still readable (initApp()
is now called with extra arguments, but that doesn’t matter).
Change-Id: I45dda26cb59279d91804b0c2bbf12174fa78ee12
This class is no longer needed in Codex and will be removed.
This patch adds a similar dynamic class to the Vector search
app, to be used for showing/hiding the search button on
focus/blur or hover/leave.
Bug: T316893
Change-Id: I738c0f24dcd06ddeb9179cfedc85ed73a6504f1e
This doesn't change any behavior, it just suppresses a compatibility
warning and ensures that future changes to this file won't introduce
code that relies on Vue 2 compatibility features.
Change-Id: Id15af7d5d5035f59dc8f402f00d8f7f0d73a77f7
[Visual changes]
This should result in 9 visual regression failures relating to
increased height of search results and loading bar
[More details about change]
- Migrate search app from Vue 2 to Vue 3; update tests
accordingly
- Remove dependence on WVUI and use Codex instead, via the special
`@wikimedia/codex-search` package
- Update search app to use CdxTypeaheadSearch, which no longer
takes in props related to the search client or fetch start/end
instrumentation. Instead, directly use the restSearchClient
and call fetch start/end events in the search app.
- Handle hideDirection in the search app/API response formatting
code, not within the TypeaheadSearch component
- Handle showing/hiding the search button in the app
- Move the WVUI URL generator into Vector
- Update server-rendered search box styles to match design updates
included with CdxTypeaheadSearch
- Replace references to WVUI with references to Codex
- Update values of various LESS variables to match Codex, and update
searchBox styling to prevent jankiness when the searchBox is replaced
with the Codex TypeaheadSearch component
The VectorWvuiSearchOptions config variable has been maintained and
will be updated to a code-agnostic name in a future patch.
Bug: T300573
Bug: T302137
Bug: T303558
Bug: T309722
Bug: T310525
Co-Authored-By: Anne Tomasevich <atomasevich@wikimedia.org>
Change-Id: I59fa3a006d988b14ebd8020cbd58e8d7bedbfe01
Rather than test for fetch, limit the code to ES6 browsers.
Depends-On: I96a03796628a74ace93579d45a582711400c09c1
Change-Id: I4ca10182491118e61e155f99c713d4cb1b4fc7f0
Vector's tsc version is currently reporting errors that the latest
typescript version doesn't report and vice versa. Upgrade to the latest
version to avoid these discrepancies.
Additionally:
Fix tsc errors that are now reported by updated version
Bug: T297614
Change-Id: I0eb67bcc1a5ce214fcf2d6f6433a5de3a845b6a6
In preparation for I30c670e3f195f77a27715c6b494a3088b7a55712, refactor
the search component expand behavior so that it can accomodate the new
changes in WVUI while maintaining backwards compatibility with the
status quo.
Additionally, pass/enable the `auto-expand-width` prop to the main
header's search. This will be inert until the new changes in WVUI have
landed.
Bug: T297531
Change-Id: Id8d3bd4aa74113b91ecaf66cb58cf5625db8a302
Follow up to 5dee570cb2.
It seems the mount works slightly different in that it creates a div,
appends by the App element to the element you give it, after
clearing all it's child nodes.
The previous behaviour was that the old element was /replaced/
by the App element.
Bug: T296889
Change-Id: Iee7493c032f4de5389207bba288a1a70e4cd14f3
- Create new 'vector-searchsuggest-containing' translation for WVUI search footer text
- Use 'search-footer-text' slot in WVUI typeahead search
- Remove instances of old 'footerSearchText' prop
Bug: T290392
Depends-on: I8fb7761e60be330e58cd017872318fe3675c0be1
Change-Id: I9c946f85c3e4a603c362c3ea4b8016c585cdd212
Port the initialization code for the Vue search to use Vue.createMwApp()
instead of new Vue( ... ). The former mimicks Vue 3's API for mounting
components.
Without this change, this code breaks in Vue 3 (even in compatibility
mode) because the compat support for new Vue(...) is imperfect. By the
time renderFn is called, the searchForm container has already been
emptied by Vue's internal mounting code.
Instead, inspect searchForm and generate the prop list before mounting,
then pass the props to createMwApp() and mount the component.
Bug: T294476
Depends-On: I1fcdcf7bf87f5af2deb9763a231f2c360ea45b23
Change-Id: I5b6e66051d97e75f8f03b8258894daba22525797
- Create new 'vector-searchsuggest-containing' translation for WVUI search footer text
- Use 'search-footer-text' slot in WVUI typeahead search
- Remove instances of old 'footerSearchText' prop
Bug: T290392
Depends-on: Ic92721d5aaf6b833c882a26e9a60b42ab91546fa
Change-Id: I34a184cc8f10172a7ebf67981731c3694d008446
Styling should not depend on IDs to allow us to have multiple
searches in the page.
Precursor for wiring up search in the sticky header.
This also tweaks performance metrics to track separate metrics
for the sticky header search
Change-Id: I5b4192a8f5a9f95af26c1faf904f7cc994323518
Per T289724#7342741, server renders an anchor tag pointing to #p-search
into the "button-start" bucket of the sticky header.
In the future after T289718, this anchor will then acts as a button when
the search module is loaded and searchToggle executes.
* skins.vector.search was modified to accomodate instantiating multiple
search components (one in the main header and one in the sticky
header).
* searchToggle.js was modified to accept a searchToggle element as a
param which the caller can then instantiate when ideal. For the sticky
header toggle, this needs to happen *after* the search module loads.
Before then, the toggle will act as a link.
* Drops one jQuery usage from searchToggle so that it can be jQuery
free. Because the native .closest method is used, IE11 support is also
dropped. However, the script feature detects and returns early if the
API isn't available.
* Makes App.vue accept an `id` prop so that multiple instances of it can
be created.
Bug: T289724
Change-Id: I1c5e6eee75918a0d06562d07c31fdcbd5a4ed6d5
... for the WVUI search autocomplete widget.
The VectorWvuiSearchOptions object is sent to the client whole and
already used as the base props for the app component constructed in the
skins.vector.search RL module. We also define the highlightQuery prop on
that component so that its value can be passed to the WVUI
typeahead-search component.
Bug: T281797
Depends-On: I142810c177b850ecd7015f835bb6630bae00a6ea
Depends-On: Ia5e14fb9d0073a5126a0918f7a94213c671e773a
Change-Id: I551414b111226e690f6a2bc69dabf5edc6fb0a96
Eslint is throwing compat warnings on every commit in Vector. This
commit silences those warnings.
Change-Id: I0e914c6179745415e916fadd382d86baa72e3e63
The parameters passed to the typeahead-search Vue component don't need
to be escaped, they're already escaped by the Vue implementation. Use
.text() instead of .escaped() for the i18n messages passed to this
component, to prevent them from being escaped twice.
Change-Id: I5dcf442f6af181a99123bf7426743af01b097729
The #p-search element is present in at least the Vector, Vector V2,
Timeless, and Monobook skins. This is because the HTML for the element
is generated in MediaWiki Core. At the very least, the
SearchSatisfaction instrument relies on the element always being
present.
Update the skins.vector.search module to simplify the App component
template so that it doesn't render a div#p-search element and mount that
component on the #searchform element instead.
Bug: T274869
Change-Id: Ifde679b62484fda7661fded2d978b78adac9f5da
```
mw.config.set('wgVectorSearchClient', {
fetchByTitle: function( query, domain, limit ) {
var xhr = fetch('http://' + domain + '/w/rest.php/v1/search/title?q=banana')
.then(function (resp) {
return resp.json();
}).then(function (json) {
return {
results: json.pages
}
});
return {
fetch: xhr,
abort: function() {}
}
}
})
```
This should be the absolute minimum to allow API clients to configure
the search. This should be considered an interim solution to buy us time to work out a more
elegant way to do this e.g. do this in the API itself…
Bug: T262566
Change-Id: Iac6f2551bed911980064dcb023193f800df0934f
This is almost identical to the instrumentation currently used in
production for mediawiki.searchSuggest -- the only differences being in
the nomenclature of variables, etc.
As part of comparing Vue search with legacy search, we need to track how
long it takes a keypress to load and render search results for Vue
search. This will only be used only in synthetic testing at this time
(Real user monitoring (RUM) is not in scope for this ticket).
To test locally, first enter characters in input. Then to see the
metrics recorded:
```
// View all marks
performance.getEntriesByType('mark');
// View all measures
performance.getEntriesByType('measure');
```
This commit adds the following metrics which will only be used in our
synthetic tests. We are not collecting RUM metrics at this time.
Measures:
* mwVectorVueSearchLoadStartToFirstRender: Measures the time it takes
from the start of loading the search module to the first render of results.
* mwVectorVueSearchQueryToRender: Measures the time it takes from
the start of the fetch to the render of search results.
Bug: T251544
Change-Id: I39200648a3a0a4079a132134d142ad8997c8962a
Add event listeners and associated helpers to emit SearchSatisfaction
events via the `mediawiki.searchSuggest` protocol.
Bug: T257698
Change-Id: Ica040cd18d6c4bf8a1b1f607bb4647c7e8eb7108
By default the API uses location.host as the host, however during
development it is useful to test against production wikis
For example to test against English Wikipedia:
$wgVectorSearchHost = 'en.wikipedia.org';
Note: Links when clicked will not take the user to the target page, and
instead will take the user to the search results page with a link to
create the page.
The following config can be used to workaround that page:
$wgDisableTextSearch = true;
$wgSearchForwardUrl = "/w/index.php?title=$1";
Change-Id: I5fbac7f54844d7a9d6976007bc0d0ff9938b9f2b
Uses ResourceLoader's virtual config feature to get the config and pass
it down to Wvui's typeahead search component.
Disclaimer: I'm a typescript noob and am not sure if the
config.json.d.ts is correct although it seems to make tsc happy.
Bug: T260167
Change-Id: I2eced14c7df3b795b4de0e5149c2ca9fd598c7be
Creates a new skins.vector.search module that
replaces the searchSuggest module from MediaWiki core.
This module creates a new Vue app using the WVUI
search widget for the new search experience.
The legacy search input form is still retains on pageload,
and the new search kicks on search input focus.
In order to manage that transition, the legacy search
input is styled to resemble the new WVUI input, and the
new input is manually focused after the component mounts.
Vue is also added as a dev-dependency to help with
type-checking.
Other changes:
* the entry in skin.json is reordered alphabetically after
skins.vector.js
Bug: T264355
Change-Id: Ibb9561a77a14734297cb4d0ddcd415fc0750b45d
Roan Kattouw
Lucas Werkmeister
Anne Tomasevich
bwang
Ed Sanders
Jon Robson
Jdlrobson
Nicholas Ray
jenkins-bot
Sam Smith
Volker E
Jan Drewniak