Page MenuHomePhabricator

Make new Vector search use wbsearchentities on Wikidata
Closed, ResolvedPublic13 Estimated Story Points

Description

The new Vector 2022 skin is now using the new Codex Typeahead search. However, by default it uses the MediaWiki search API. Whereas on Wikidata, we need it to use wbsearchentities in order to actually search through Items, Properties, and Lexemes. Currently, the new Vector skin still contains some code to maintain backwards compatibility with the Wikidata hack.

To make the new Vecor search use wbsearchentities, we need to create a custom search client and store it at wgVectorSearchClient in order to override the default implementation. The basic feasibility is outlined by this Proof of Concept.

Aceptance Criteria:

  • The new vector search uses wbsearchentities
  • The placeholder for the article images are not shown (that might need some config change or something)
  • Selecting results with the Keyboard works as expected

Notes:

Related Objects

Event Timeline

With the proof of concept patch, when I click on a search result or select it with the arrow keys and press Enter, the result is as if I’d searched for that item’s label: I get sent to the search results page, or even to a local wiki page with the same title if it exists. I can only get to the item when I middle-click or Ctrl+click a search result. I assume we want to fix that; is it part of this task?

With the proof of concept patch, when I click on a search result or select it with the arrow keys and press Enter, the result is as if I’d searched for that item’s label: I get sent to the search results page, or even to a local wiki page with the same title if it exists. I can only get to the item when I middle-click or Ctrl+click a search result. I assume we want to fix that; is it part of this task?

I noticed that as well. I think, I've probably introduce a bug somehwere in my PoC, but didn't want to spend time searching for it, because that was really only intended as trying out and showing that it works in principle.

I noticed that as well. I think, I've probably introduce a bug somehwere in my PoC, but didn't want to spend time searching for it, because that was really only intended as trying out and showing that it works in principle.

I think it’s a limitation of the Codex or Vector code – it looks like the search form just sets up a literal HTML form something like this:

<form action="/w/index.php"> <!-- plus other attributes -->
  <!-- lots of markup ... -->
    <input name="search"> <!-- plus other attributes -->
  <!-- more markup -->
  <input type="hidden" name="title" value="Special:Search">
  <input type="hidden" name="wprov" value="acrw1">
</form>

And when you press Enter, the browser navigates to /w/index.php?search=searchInputValue&title=Special:Search&wprov=acrw1 because you’ve submitted the form. The only reason that on Wikipedia you end up on regular article pages is that Special:Search redirects to the page with a matching title – you can see that happen in the network monitor:

image.png (77×755 px, 14 KB)

But that’s not going to work for Wikidata, I think.

Here’s a very hacky Vector patch to suppress the default navigation to Special:Search and instead navigate to the search result’s URL:

diff --git a/resources/skins.vector.search/App.vue b/resources/skins.vector.search/App.vue
index 3bffb5c52e..f946cf0078 100644
--- a/resources/skins.vector.search/App.vue
+++ b/resources/skins.vector.search/App.vue
@@ -189,6 +189,8 @@ module.exports = exports = defineComponent( {
 			this.wprov = instrumentation.getWprovFromResultIndex( event.index );
 
 			instrumentation.listeners.onSubmit( event );
+
+			window.location = event.searchResult.url;
 		},
 
 		onFocus() {
@@ -200,6 +202,8 @@ module.exports = exports = defineComponent( {
 		}
 	},
 	mounted() {
+		this.$el.querySelector( 'form' ).addEventListener( 'submit', ( e ) => e.preventDefault() );
+
 		if ( this.autofocusInput ) {
 			this.$refs.searchForm.focus();
 			nextTick( () => {

But I assume we can’t do it like that, this wprov stuff is probably there for a reason…

karapayneWMDE set the point value for this task to 5.Oct 4 2022, 10:33 AM
karapayneWMDE changed the point value for this task from 5 to 13.Oct 18 2022, 9:37 AM

Change 848292 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/skins/Vector@master] [DNM]: how to make use of load-more event in typeahead search

https://gerrit.wikimedia.org/r/848292

Change 848310 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/extensions/Wikibase@master] Add vector search client for use in new skin version

https://gerrit.wikimedia.org/r/848310

Change 848421 had a related patch set uploaded (by Michael Große; author: Michael Große):

[operations/mediawiki-config@master] Wikidata: don't show Vector search thumbnails

https://gerrit.wikimedia.org/r/848421

Change 848310 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Add vector search client for use in new skin version

https://gerrit.wikimedia.org/r/848310

Meh, our patch here caused T324148. Fix there is waiting for review

Change 863368 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/skins/Vector@master] search: Adapt to Wikibase instead of hard-coding wikidatawiki

https://gerrit.wikimedia.org/r/863368

Change 863368 merged by jenkins-bot:

[mediawiki/skins/Vector@master] search: Adapt to Wikibase instead of hard-coding wikidatawiki

https://gerrit.wikimedia.org/r/863368

Change 848421 merged by jenkins-bot:

[operations/mediawiki-config@master] Wikidata: don't show Vector search thumbnails

https://gerrit.wikimedia.org/r/848421

Mentioned in SAL (#wikimedia-operations) [2022-12-12T14:17:44Z] <lucaswerkmeister-wmde@deploy1002> Started scap: Backport for [[gerrit:848421|Wikidata: don't show Vector search thumbnails (T316093)]]

Mentioned in SAL (#wikimedia-operations) [2022-12-12T14:19:22Z] <lucaswerkmeister-wmde@deploy1002> lucaswerkmeister-wmde and migr: Backport for [[gerrit:848421|Wikidata: don't show Vector search thumbnails (T316093)]] synced to the testservers: mwdebug2001.codfw.wmnet, mwdebug1001.eqiad.wmnet, mwdebug2002.codfw.wmnet, mwdebug1002.eqiad.wmnet

Mentioned in SAL (#wikimedia-operations) [2022-12-12T14:27:31Z] <lucaswerkmeister-wmde@deploy1002> Finished scap: Backport for [[gerrit:848421|Wikidata: don't show Vector search thumbnails (T316093)]] (duration: 09m 47s)

Change 875810 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/extensions/Wikibase@master] Enable the new Codex-based search with the Vector-2022 skin on Wikidata

https://gerrit.wikimedia.org/r/875810

Change 875810 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Enable the new Codex-based search with the Vector-2022 skin on Wikidata

https://gerrit.wikimedia.org/r/875810

Change 875878 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/skins/Vector@master] Remove code to disable new search on Wikidata

https://gerrit.wikimedia.org/r/875878

Lucas_Werkmeister_WMDE changed the task status from Open to Stalled.Jan 6 2023, 2:13 PM

The last cleanup patch on this task is stalled at least until the new search has rolled out to wikidatawiki with next week’s train (so users have some time to give feedback).

Lucas_Werkmeister_WMDE changed the task status from Stalled to Open.Jan 17 2023, 4:04 PM

Unstalling and moving back into peer review, since this has been rolled out since last week and we haven’t seen any complaints yet (see also T326633); now that the next branch cut is also done, I think we can merge the Vector cleanup patch.

moving back into peer review

(idk what i was doing on tuesday. moving properly now)

Change 875878 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Remove code to disable new search on Wikidata

https://gerrit.wikimedia.org/r/875878

As far as I can tell, this is completed. T327510: Vector Search: Adjust bolding pattern of suggestions in Wikidata is related, but separate and should probably get its own process.

To me, that means that our work for T275251 and T281318 is also done, as we don't "own" these tasks (though I might misunderstand things here. Politics is not my strong suit). I think we could just remove the Wikidata Dev Team tag from T275251, or maybe move it to some appropriate column somewhere. (Though this is product territory.)

T279639 is not really related either, I think. And in any case, it already existed before this.

Arian_Bozorg subscribed.

This looks all good on my end.

But I can't check if it's actually using the API it should, so just moving this to Tech Verification :)