Unpopular pages with short titles, e.g. [[Sop]], [[Topo]], do not appear in the top 10 opensearch suggestions, so VE thinks the pages don't exist. However, they definitely do exist.
This, along with bug 50898, suggests that the VE team might need to implement its own wrapper web API for link suggestions.
Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=54361
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Krinkle | T53013 VisualEditor: OpenSearch results aren't perfect for checking for page existence | |||
| Resolved | Krinkle | T72958 OpenSearch: If input exists as a title it should be included in the results |
This looks the same as bug 52596 which contains more details of which pages are believed to exist and which are not
Right now MediaWiki search has a bug where one searches "Foo" and a page by that name exists, it might not be included in the search results (or at least not in the first 10). Or sometimes it's in there but on #3.
While fixing the order is harder, we can easily work around the case where it is absent by running an additional api query simply checking whether a page by the title of "Foo" exists.
Action item: When using search in a way that the user input should be used as first hit if it exists[1], our code should always do an additional query for the literal input against the pageinfo API. At least until the upstream bug in MediaWiki search is fixed (do we have a report for that?).
[1] e.g. mediawiki link input widget, and transclusion dialog template name input, but not media dialog probably.