When the existing search results don't contain an exact match
(see previous patch), perform an additional search for the
title. This uses OpenSearch. This is recommended in multiple
places and also used in the quick search field at the top of
MediaWiki.
Again, I came to the conclusion that an isolated unit test
would be complicated and not test much anyway. Better test
on-wiki.
Bug: T274903
Change-Id: Ib575248e089ff66814400202d224deff6369c772
This code detects a few edge-cases:
1. When some search results are exact matches, make sure they
are always at the very top.
2. When the prefixsearch API is used, e.g. as a fallback,
redirects show up as a separate metadata structure outside of
the pages array. Consider these and stop if there is already
an exact match.
3. CirrusSearch returns redirects as part of the pages array.
When there is an exact match, make these redirects separate
options and add them to the top.
All of this is case-insensitive, on purpose. In case two
templates with different capitalization exist, we rely on
the backend to return both. The code introduced here is fine
with this.
Notes:
* This doesn't guarantee an exact match is always there. This
requires an additional HTTP request and is done in the next
patch.
* I tried to write unit tests for this, but gave up. The setup
is complicated. An isolated unit test would not test much
anyway. Better test this on-wiki.
Bug: T274903
Change-Id: I64e1b5633e7b878a4d0d23d66229ca87e69d0045
These are the most minimal (and therefor most stable,
hopefully) hacks I could come up with so far.
Bug: T274903
Change-Id: I28ba414dd34aad756e29400eb656f0942291a923
Template names sometimes show up twice when searching for a
template in the "Add a template" dialog.
This is a bit hard to test. The code responsible for this
is not in a single place. The feature is in the upstream
TitleWidget class. It's not broken. It makes sense to
provide e.g. "foo" and "Foo" as two separate options when
the user typed "foo", but the page is named "Foo". Both are
valid, and the feature allows the user to pick either.
But the VE widget does it's own normalization. Both entries
are normalized to "Foo". Both do the same. The additional
one is pointless.
You can try this on the actual enwiki: Open VE, insert a
template, search for "Template:nHLE".
Change-Id: I65e706c4d131a2f8c605d7979a02ea56f831bf03
The "redirects" part in a prefixsearch query is always an
array, no matter if formatversion 1 or 2 is used.
The "pages" part is an object with formatversion 1, and an
array with formatversion 2.
As of now this always uses formatversion 1. This is
hard-coded in the upstream TitleWidget class.
Change-Id: I8cde8e104f8a288015da745db41016f6639b453b
Discussed in T274903#7077957. Note this might not be the
"perfect" solution. We are still experimenting, and this is
all hidden behind a feature flag. This is the change with the
most minimal impact. Actively trimming the input is another
solution, but with a bigger impact we might want to discuss
first.
Bug: T274903
Change-Id: I2ed06c04bb96c7b61bd7e87ad001e639ea6d06a2
This parameter name was deprecated and replaced in 1.31. See also
Ie5fe2097cda45968bb080643d3afcac0b2868a6c
Change-Id: Ie9d6c70d3dfe3954504d3d698c122dceede7603d
As configured on-wiki via MediaWiki:templatedata-doc-subpage; this will
probably have a few false positives, but that's worth it.
Bug: T54448
Change-Id: Id91f95b5865e151f8007a2421428aeb82b11b3fd
This only comes back in results from certain modules, so I'm not entirely
sure whether we want to do this in here or mw.widgets.TitleInputWidget.
Bug: T111598
Change-Id: If2916706db359d520c41c2dec7ded44e0d3a56a9
All link input/title input functionality has been moved to core, so
we can replace the link widget, redirect widget and template search
widget with it.
Depends on Ib463e60cad96 in MediaWiki core.
Change-Id: I452f3b86ead403307072cf904f0553c9771f4300
For each template result, ask for the templatedata description. If
that description exists, show it under the template result.
Bug: T53436
Change-Id: If28d1eb082edca6f50c6c15c933a0b7d014eaeaf
