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
The vast majority of wikis have an empty help namespace and
searching project pages is mostly an advanced search feature.
Cluttering the UI with an extra tab that's (most likely) rarely
clicked isn't helping anyone.
Change-Id: I0c448bcee877e027ff95c96812aac86d89d4eb32
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Change-Id: Ifbb1da2a6278b0bde2a6f6ce2e7bd383ee3fb28a
Always include redirects. Search results are worse without them
and MWSearch has never respected this option anyway.
Change-Id: I0ebe321a3b14e7960aa98e3225dc5a19ba916e7d
None of the following extensions use these parameters:
- CirrusSearch
- MWSearch
- SolrSearch
- SphinxSearch
Change-Id: I9686ca0849f35a3a09bd9996e4c6eac4334a342a
Rather, create a hook that search implementations can override to specify
that the search contained advanced syntax and core will read it in
Special:Search and only offer the link if it is false. It'll default
false.
Change-Id: Ic4ce6361d0e602ed9a812dfbbd15ce11a762f5f8
The class default is 10/0, it doesn't make sense to set that
as 0/0 here. Nor does it make sense to really override it
here at all, as class defaults should take precedent unless
explicitly overriden by callers.
Bug: 60475
Change-Id: I4a48fd3c55908b52c8b0ab081d856874d16b876e
There's a lot in the base search implementations that is specific
to the database backed search. This starts moving some of that out
into a shared base class for those.
For starters, let's not grab a connection to the slave DB for
every single search for backends unless they need it.
Change-Id: Ib66696841eea901e04b21dd309784af889a45ab1
- Make variables protected. Only class that uses these is LuceneResult
and it's fine
- Don't bother constructing a new file object if we've already got
one in memory (we likely do)
Change-Id: I7973aff1e96297a2fea70392b765c93a8c884d52
