Page MenuHomePhabricator

New widget for searching templates
Closed, ResolvedPublic8 Estimated Story Points

Description

Create new OOUI widget called TemplateSearchWidget for searching templates, with the same functionality as the merger of the existing template search fields in VisualEditor and TemplateWizard (i.e. CirrusSearch if available, prefix search if not). VE also handles the case of TemplateData not being installed, but as this is being implemented in TemplateData we don't have to in the new widget.

The outcome of this will be a wrapper widget for an InputWidget that's functionally equivalent to ve.ui.MWTemplateTitleInputWidget or mw.TemplateWizard.SearchField. Note that although we could be creating a single-input widget like these are, we don't want to do that because we'll be adding more functionality to the TemplateSearchWidget (such as a tab bar under the search input) that'll mean it's probably easier to have a general Widget.

This task does not include actually using this new widget anywhere. We will want to add it somewhere for testing though: T385034: Add Special:TemplateSearch page for testing purposes

The new widget will be added in two subsequent tasks:

Search logic

The new widget will follow the existing search logic of the two systems (they should be referred to for actual details), and their behaviour is the same. The general approach is as follows (in both the below cases, the search is limited to the Template namespace, ID 10; this can be changed in config but it doesn't look like it ever is):

  • Without CirrusSearch installed:
  • With CirrusSearch installed:
    • If the search term ends in an alphanumeric character, a wildcard suffix search if run; otherwise it's a normal search.
    • A prefixsearch is also run, to make sure it finds any exact prefix matches.
    • The results of these are combined.

Both are followed by a templatedata request to get the template metadata (i.e. the descriptions).

Note that TemplateWizard does combine parts of this as a generator, but we'll follow the VisualEditor approach here in order to keep the latter templatedata-fetching step simpler and separate.

Widget design

This task doesn't include any special design for the autocomplete field, it'll be a standard OOUI LookupElement displaying a title and description (and no image).

Neither search input debounces, but rather send API requests on every keystroke. TemplateWizard aborts on subsequent ones; VisualEditor doesn't.

Event Timeline

Why do we do the prefix search at all? Why not just do a namespace search in all cases? My recollection is that, back when we were building TemplateWizard, prefix search was preferred because many wikis have conventions around template names, so it makes it possible to find all cite templates by starting to type cite, or infoboxes with infobox. I feel like that might be out of date now, and that having the same search results in the template dialogs (the same as what you get at Special:Search?ns10=1) might be more expected. We have been talking a bit about using CirrusSearch if it's installed, but it looks like the only thing we're doing is the asterisk at the end of the search term, which seems to be an attempt to emulate a prefix search.

It would be simplest to just do a normal search within the template namespace, and not add an optional dependency on CirrusSearch. At least, we could start with that for the initial work, because then we can build the widget etc. and get it started, and if we need to change the search system that could come later. Does that sound okay?

The asterisk is there because otherwise a normal search only searches for whole words, which doesn't really make sense for something that's matching as you type - so if you start typing infobo without the asterisk it'll find nothing until you add the x

We should probably arrange a meeting with my WMDE-TechWish team that did this as part of our WMDE-Templates-FocusArea. We spend a lot of time fine tuning and user-testing the template search within VisualEditor to make it do what users expect it to do. There should be many Phabricator tasks where the decisions have been documented. T274903 might be a good starting point.

There also seems to be a mistake in this task's description. While TemplateWizard and VisualEditor don't share any code, we made sure the template search in the two behaves the same. They ultimately do the exact same API requests, both relying on CirrusSearch. It's just that TemplateWizard nests the two search and templatedata requests utilizing the somewhat esoteric generator feature, while VisualEditor makes separate requests.

So I think it'd probably be ok to not use prefix search, we probably need CirrusSearch-with-the-asterisk on foundation wikis or we're gonna be making the search worse

Deleting in light of @thiemowmde 's more informed comment above :)

@thiemowmde Yep, we're aiming to not change anything at all, at least initially. I was just confusing myself about the asterisk and thinking that it wasn't necessary! Oops.

We'll stick with replicating the existing search behaviours: prefixsearch by default, and search-with-asterisk if CirrusSearch is installed.

I think the reason that VE does the separate requests for templatedata is that TD mightn't be installed with VE, so it's simpler to do it in two steps. We can avoid that because we know that TD is installed, so can use the search generator with the templatedata API (better to make one API request rather than two per keystroke I think).

Oh yep, and I'll update the description with the correct detail about how TemplateWizard works (with and without CirrusSearch).

While I like the generator approach, I think it doesn't provide much benefit nowadays. While it might save one HTTP request (possibly relevant for slow clients), it doesn't make any difference from the perspective of our servers. The server ends doing the exact same, if not more. But sure, you can try it if you like.

Note there is an extra prefixsearch with a limit of 1 in addition to the Cirrus-powered search request. This is critical in rare but very relevant edge-cases, see T274903.

I've updated the task a bit, to make it less about specific API calls and hopefully more informative.

One thing I'm not sure about is how a demo of the new widget might be best setup: one idea was to create a temporary special page that could showcase the new widget for testing purposes (which would also be behind the new feature flag of course). Are there other examples of extension-provided widgets that have demos available? i.e. outside of the main OOUI Demos.

I'm assuming we don't want to add a new resourceloader module for this, because of the extra data required when loading — which I'm assuming means we'll need to define the lists of files, messages, etc. in both the ext.TemplateWizard and ext.visualEditor.mwtransclusion modules. Does that sound ok? Are there other (modern) examples of extensions sharing OOUI components like this?

(The actual work for adding to those extensions isn't part of this task, it's in T377416 and T377417, but I don't want to do anything here that's going to make things hard for those tasks.)

Change #1118493 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/TemplateData@master] [WIP] New template search widget

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

Regarding the module, it sounds like it's going to be simplest to create a new one, e.g. ext.templateData.templateDiscovery here, and then if need be its details can be merged into (multiple) other modules if that's required for performance.

Change #1118493 merged by jenkins-bot:

[mediawiki/extensions/TemplateData@master] New template search widget

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

KSiebert set the point value for this task to 8.Feb 20 2025, 10:32 AM

Change #1121795 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/TemplateData@master] Template Discovery: Add missing `redirectedfrom` message

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

I've been investigating switching to use mw.widgets.TitleSearchWidget, and it doesn't seem it'll be a super smooth switch. It looks like that widget is only used in the VE link-selection dialog (and in a Bluespice extension). We're wanting to use it within an ActionFieldLayout (i.e. an input with a button next to it). My feeling is that as we're customising the search behaviour and the display of the search results list, and we've already got a large part of it working, it's perhaps not worth switching to the core widget at this time.

Change #1121795 merged by jenkins-bot:

[mediawiki/extensions/TemplateData@master] Template Discovery: Add missing `redirectedfrom` message

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

The current work here is in getting the submit button working. Currently it uses the same event handler as the choose event of the menu, but this doesn't work because it doesn't have access to and pass the require data to that handler. Instead, it should be the same as choosing the currently-highlighted menu item — this doesn't work however, because when the button is clicked the menu closes and so there's no current selection. I'm working on a patch for this now.

Change #1123583 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/TemplateData@master] [WIP] Template search: Choose the current template when clicking the button

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

Change #1124225 had a related patch set uploaded (by Samwilson; author: Samwilson):

[mediawiki/extensions/TemplateData@master] Handle non-existing templates in search results

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

Change #1124225 merged by jenkins-bot:

[mediawiki/extensions/TemplateData@master] Handle non-existing templates in search results

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

Change #1123583 merged by jenkins-bot:

[mediawiki/extensions/TemplateData@master] Template search: Choose the current template when clicking the button

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

KSiebert changed the task status from Open to Stalled.Mar 27 2025, 10:38 AM
dom_walden subscribed.

Resolving as needing no extra, specific testing.