This mimics how full text works by silenty dropping results returned from
search that no longer exist. This could be because the search index is slightly
out of sync with reality, or the search engine could simply be broken.
Only silent from the users perspective. We maintain a count in statsd of
the number of titles dropped. This can be monitored over time to
recognize any increases.
Bug: T115756
Change-Id: I2f29d73e258cd448a14d35a2b4902a4fb6f61c68
Various code using the search engine shouldn't need to implement it's
own methods, such as over-fetching, to determine if there are more
results available. This should be knowledge internal to search that is
exposed by a boolean.
Change-Id: Ica094428700637dfdedb723b03f6aeadfe12b9f4
The plan is to convert these methods into final, considering
it a removal under the deprecation policy. By making entry
points into the search engine final we provide a guaranteed
point where generic handling can be applied to all search engines.
The first use case for this generic handling is pushing pagination
via overfetch into the SearchEngine class instead of re-implementing
an overfetch in individual parts of the code that perform searches.
Change-Id: I3426d6a2f32d8b368b044b154e1cb70dac007c62
In phpcs.xml rename renamed sniffs and add the failing sniffs,
because now the whole sniff is no longer excluded.
Change-Id: If5b0bd16028761abc2c47ace9e97d37ad14bb36f
- mostly auto fixes
- some too long lines fixed
- ignore amp space in one case passing by reference
Change-Id: I6472f83bc3cbf4bd629d83050cc3319b19ec465c
Partially revert I61dc536 that broke phrase search support.
Fix phrase search by making explicit that there are two
kind of legalSearchChars() usecases :
- the chars allowed to be part of the search query (including special
syntax chars such as " and *). Used by SearchDatabase::filter() to
cleanup the whole query string (the default).
- the chars allowed to be part of a search term (excluding special
syntax chars) Used by search engine implementaions when parsing with
a regex.
For future reference:
Originally this distinction was made "explicit" by calling directly
SearchEngine::legalSearchChars() during the parsing stage. This was
broken by Iaabc10c by enabling inheritance.
This patch adds a new optional param to legalSearchChars to make this
more explicit.
Also remove the function I introduced in I61dc536 (I wrongly assumed
that the disctinction made between legalSearchChars usecases was due
to a difference in behavior between indexing and searching).
Added more tests to prevent this from happening in the future.
Bug: T167798
Change-Id: Ibdc796bb2881a2ed8194099d8c9f491980010f0f
The used phpcs has a bug, so the version 0.9.0 could not be enforced at the moment.
Will be fixed in next version, see T167168
Changed:
- Remove duplicate newline at end of file
- Add space between function and ( for closures
- and -> &&, or -> ||
Change-Id: I4172fb08861729bccd55aecbd07e029e2638d311
I think the bug was introduced during a cleanup in Iaabc10c.
I don't think that " should be part of the legalSearchChars at query
time, it seems to break the regex.
The strategy here is to distinguish legalSearchChars used query time vs
the ones used at index time by introducing:
SearchEngine::legalSearchCharsForUpdate()
Bug: T167798
Change-Id: I61dc53665e26d3c6c48caed78dd3bbde9a33def7
Allows search engine to suggest deleted titles for undelete search.
Note that the titles are still verified against the archive table,
to ensure search engine is not out-of-date.
Bug: T109561
Change-Id: Id6099fe9fbf18481068a6f0a329bbde0d218135f
Useful in case the client wants to re-evaluate what was set
here, or if the SearchEngine implementation wants to expose
some of its states.
In our case it allows CirrusSearch to inform SpecialSearch
that we prefer to display search results with a new experimental
layout.
Bug: T156299
Change-Id: I7f661c852ef70ea7bc9ae2959f7d6e48776a9877
When scrolling results on prefix search api the exact Title
match is always at pos 0 even if we want to scroll the results
by setting offset to > 0.
Change-Id: Ib02c9d3e479d739e6fe79014d962db50b6fd9de8
Useful for search engines that allow users to customize search profiles.
Depends-On: Icd577c8ebc6e162befe30bde4fe276e633d2e434
Change-Id: I471cd090730d2a25cb70d622ec3bebbe9583118c
Useful for some search engines that have a keyword that wants
to reuse this logic without building a new SearchEngine object.
Change-Id: Iee5bfd1da70b8339a98555ba062bd33b21f0b761
This patch introduces a way for SearchEngine implementations to expose
specific search profiles useful to fine-tune the various behaviors related to
search.
A SearchEngine can expose a list of profiles by overriding
SearchEngine::getProfiles( $profileType ), profileType stands for the type of
profile being customized. Two types are added in this patch:
- completion: exposed by ApiQueryPrefixSearch and ApiOpenSearch to control
the behavior of the algorithm behind "search as you type" suggestions.
- fulltext query independent profiles: exposed by ApiQuerySearch to customize
query indpendent ranking profiles (e.g. boost by templates/incoming
links/popularity/...)
This patch allows api consumers that might have been confused by fuzzy
suggestions to switch to stricter profiles and to officialize the behavior
behind the hidden param cirrusUseCompletionSuggester. Or to control the
fulltext ranking behaviors like cirrusBoostLinks=(yes|no).
The list of profiles can be discovered by using ApiSandbox/ApiHelp and is totally
controlled by search engine implementations.
Bug: T132477
Change-Id: I66be724d8975976c98c91badbf421f237e014f89
Unfortunately some backends (like Cirrus) are not able to do proper crossnamespace
lookup. If the backend returns no result we should still try an exact title match.
Bug:T129575
Change-Id: Ic08ec0aac0fd8a289f21753d74ae62ba509de841
By default it still uses PrefixSearch and supports PrefixSearchBackend
but it can be deprecated and phased out and SearchEngine extensions used
instead.
New APIs:
- SearchEngine
public function defaultPrefixSearch( $search );
public function completionSearch( $search );
public function completionSearchWithVariants( $search );
Search engines should override:
protected function completionSearchBackend( $search );
Bug: T121430
Change-Id: Ie78649591dff94d21b72fad8e4e5eab010a461df
This variable is set to null in the replacePrefixes method, document
it as such to prevent errors in consuming code.
Bug: T98082
Change-Id: I78880ffe590ed7193b8482c0ae41c8c69e495878
SearchEngine grows a method to list valid sort orders one to set the
sort for the next search, and one to read it. The default implemenation
only supports 'relevance' and the documenation strongly urges that all
other implemenations leave that as the default. Other implementations
can support other orders. Cirrus already supports title_asc and title_desc.
Change-Id: Ie946150c6796139201221dfa6f7750c210e97166
There's really no reason for the extension to exist separately from
core, and merging it reduces the risks of bitrot in both the extension
(lots of deprecated functions there) and core (missing integration with
PageImages and TextExtracts, for example).
Change-Id: Ie0ab90902ede9499879402290006466efba479e9
This hook is poorly thought out. The only extension that uses it
can't possibly think it works how they're expecting.
Change-Id: I853a01afc8e922f22e949321a2f2343d264632a6
- Move filter() function and make it protected, nothing uses it
outside database-backed searching
- Use per-backend legal search characters rather than assuming the
static implementation is right
Change-Id: Ic2b830b56137b2dfe68b9b9c3de012151e716952
Only worked for Postgres, and only worked halfway at that. Result
sets could be false for many reasons. No results, bad query, database
went to Mars. We shouldn't assume they're always "too many results."
Leave it up to the normal query error logging and move on.
Change-Id: Ieddd163e440ae54b152541d727c1afdbc4ab4fbd
* Checkbox on own row below power search checkboxes per MatmaRex;
avoiding a mw-search-ns* id leaves it untouched by All/None JS.
* The option searcheverything is removed: a "shortcut" which is no
longer necessary now that options can be (un)selected at once
with All/None buttons on search page itself.
* Require a token for saving: no accidental preferences changes.
* Keep the searchoptions/advancedsearchoptions prefs section in case
something is using it (no known extension does though); options
are converted to "api" type so it's empty and hidden by default.
* Add minimal documentation for saveSettings() and friends
(@todo since 155ddf6de, 2009!).
Bug: 52817
Change-Id: I514cee835988600cc013658049e88a10b670e64a