these tests get skipped and so should adding these pages, since it
leads to a fatal error and inability to run tests on such a wiki.
Bug: T97416
Change-Id: Icc4e325ecbc5ed069d12bbad686812f6a45b47e7
Doesn't change the semantics much since run() calls addDBData()
right before setUp(), but these belong addDBData() per the
documentation of setUp().
Change-Id: I304a0aff1fc6b2f0541b3dc3c9e3527772c8f91c
- Added/removed spaces around parenthesis
- Added newline in empty blocks
- Added space after switch/foreach/function
- Use tabs at begin of line
- Add newline at end of file
Change-Id: I244cdb2c333489e1020931bf4ac5266a87439f0d
Prefix search attempts to find exact matches to the user's query that aren't
returned by plugins. In some cases, like when the exact match is a redirect
and the target of the redirect is also in the search results, it would result
in multiple results in prefix search going the same place. This looks really
silly when the top hit is "Barack obama" (a redirect) and the next one is
"Barack Obama" (the target of the redirect).
This handles a bunch of cases to do with redirects in the matches and when
the exact match is a redirect.
Bug: 736731
Change-Id: I49fe1ccec84bd5d1f44c6b91b260abf50f2cc3a1
The default search backend implements proper prefix search and
does this naturally. But extensions providing search backends
like Lucene and CirrusSearch actually fail to implement proper
prefix searching and instead use their search engine ranking for
prefix search as well. Thus often the exact match is not on top
or is not even in the first 10 results at all.
On en.wikipedia.org:
> Example
1. "Example (musician)"
2. "Example"
3. "Example.com"
> John ive
1. "John Ives"
2. "John Ivey"
3. "John Ive"
> Foo
1. "Football (soccer)"
2. "Football League Cup"
3. "Foot (length)"
"Foo" exists but is NOT among the returned results.
Bug: 70958
Change-Id: I78d419424baf43d38beeb6dabfc347f430fa45f6
