We have a number of parameters that are pretty much the same between
these different search api's. Lets make them actually the same by
sharing the definitions, and then letting individual classes tweak them
as needed by removing the offset, or adjusting the max limits as
necessary.
Change-Id: I6f987db8ecb63dc943b4d2518bfe3703c677448e
This was throwing exceptions, probably for many months now, when
requesting and finding interwiki search results. Probably this went
unnoticed due to interwiki search only being enabled on itwiki, and
the requirement to pass a special parameter to turn it on.
Change-Id: I68ec35bb072b5ad62dd66789936bc2ae47d5256f
This code was rather hard to follow due to reusing the same variable
multiple times. Lets give them unique names.
Change-Id: I8f134b6314d593a3e40b19765c7b71496b8e524d
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
Status::getWikiText is used for internal logging, api error messages and
maintenance scripts. All this places are usually in english, so pass an
english language to getWikiText.
Change-Id: I3010fca8eb5740a3a851c55a8b12e171714c78f7
This allows generator implementations to define how generator data
about a redirect gets merged into the redirect destination. This
does not change any defaults, only modules that explicitly set a
merge policy will have a change in their results.
This functionality is initially used for the search api modules to
retain search positions within the final result set.
Bug: T92796
Change-Id: If2f49e0fc3176288c95e870240754ee320a6bf91
Special:Search recently gained query rewriting behavior when the
original query returned no results. We want to expose this query
rewriting behavior to both api and web requests. Additionally we
want to be able to test different configurations of the query
suggestions. This patch allows for both by moving the rewriting
from core into the search backend.
This defaults to enabled for Special:Search, and disabled for
ApiQuerySearch. Internal code that talks to the search backend
needs to specifically enable this feature.
Bug: T106888
Change-Id: I0a8f75759f9148f53358707369b8a7128215de86
Use message-per-value for message
apihelp-query+search-param-prop to allow smaller strings
for translation.
Each prop in a message also will show up a new parameter on the help
page without the adjust of the translation (but than in english instead
of fully skip it).
Change-Id: Id2088213f4577c8cb88e479e8fca0e6bd3d619f4
The 'nearmatch' feature of the api is the same as the 'go' feature of on-wiki
search. This makes the nearmatch api feature return the same results as the user
would have gotten in 'go', bringing more parity between api and browser based
searching. Without this change asking for a nearmatch within a namespace fails.
Bug: T37719
Change-Id: I715326242b63c558572ce9bf69b70bd650c2bc95
The on wiki search indicates more information than is currently
available by api. Adds two more props to improve parity:
* categorysnippet: similar to the other snippets, about the category
that triggered the match
* isfilematch: indicates if the match was part of file content
Additionally when 'suggestion' is included as part of the searchinfo,
'suggestionsnippet' is now also returned.
Change-Id: Ibf18905775a79caed213aca1bdebcffe3644c23b
ApiResult was a mess: some methods could only be used with an array
reference instead of manipulating the stored data, methods that had both
array-ref and internal-data versions had names that didn't at all
correspond, some methods that worked on an array reference were
annoyingly non-static, and then the whole mess with setIndexedTagName.
ApiFormatXml is also entirely annoying to deal with, as it liked to
throw exceptions if certain metadata wasn't provided that no other
formatter required. Its legacy also means we have this silly convention
of using empty-string rather than boolean true, annoying restrictions on
keys (leading to things that should be hashes being arrays of key-value
object instead), '*' used as a key all over the place, and so on.
So, changes here:
* ApiResult is no longer an ApiBase or a ContextSource.
* Wherever sensible, ApiResult provides a static method working on an
arrayref and a non-static method working on internal data.
* Metadata is now always added to ApiResult's internal data structure.
Formatters are responsible for stripping it if necessary. "raw mode"
is deprecated.
* New metadata to replace the '*' key, solve the array() => '[]' vs '{}'
question, and so on.
* New class for formatting warnings and errors using i18n messages, and
support for multiple errors and a more machine-readable format for
warnings. For the moment, though, the actual output will not be changing
yet (see T47843 for future plans).
* New formatversion parameter for format=json and format=php, to select
between BC mode and the modern output.
* In BC mode, booleans will be converted to empty-string presence style;
modules currently returning booleans will need to use
ApiResult::META_BC_BOOLS to preserve their current output.
Actual changes to the API modules' output (e.g. actually returning
booleans for the new formatversion) beyond the use of
ApiResult::setContentValue() are left for a future change.
Bug: T76728
Bug: T57371
Bug: T33629
Change-Id: I7b37295e8862b188d1f3b0cd07f66ac34629678f
The intention here is to return the title as a text string, not to dump
all the internal fields of Title.
Bug: T88397
Change-Id: I43ad3c98bc1fc056a13f57e2e95a122108049334
Actually on second thought, having the parameter disappear is
a better option than keeping it around with only one possible
value.
This reverts commit 7a79b017a0.
Change-Id: Ia67fa1425e0aa1ee95e0a1733f89d29f94f1eeee
Originally this was designed to only show up when there was
more than one backend. That's more likely to break for clients
though if you want to go back to only having one backend again.
Change-Id: I9009f2599f5bc6fa8f9c49370fd0ffb714e31755
- 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
It has long been requested that list=search and list=prefixsearch be
able to indicate the search result ordering when used as generators.
This change introduces a generic mechanism to allow for generators to
specify additional page data.
Bug: T16859
Bug: T75623
Change-Id: I115338d2bd890ccc109a79c65f92099c0d41fc2d
Generators should generally just generate titles without adding
additional stuff to the result.
OTOH, there's no reason a generator can't generate interwiki titles.
Bug: 73321
Change-Id: I55d1d35c9d8bedbc68a201fab9d455bc011cc4d8
This also adds some new ApiBase::PARAM_* constants to generate more
helpful help, and a method to override the default description message
for the use of ApiDisabled and ApiQueryDisabled.
Bug: 71638
Change-Id: Ic0c3d232e0498d58a043037e2e0c6f0b1c3edad3
According to I5aae8caf, the parameter is gone now. Found while
tracking down a strict warning in MWSearch.
Change-Id: I571e015814ea756771c66c243cb8db86448db463
Poorly documented and never used anywhere properly.
- No core search backend supports it.
- MWSearch implements it but we've never turned it on.
- SolrStore copies MWSearch but it doesn't even work.
- CirrusSearch doesn't bother because it's silly.
Change-Id: I8b052e8e772030fba6c361fdb2775b10a7f7a15a
http://phpdoc.org/docs/latest/references/phpdoc/types.html
If IDEs have many warnings, we don't look at them.
Let's minimize the number of warnings, and make them useful again.
* Some function docs fixes
* Removed unused $iwprefixes var in ApiQuerySearch.php
* declared private $blockStatusByUid in SpecialActiveusers
* declared private $repo in UploadFromChunks
Change-Id: Ifd20f78b168b9a913fdb8d89dc26a76a173b1c29
The format for 'props' was never specified and the list for 'errors' is
impossible to keep updated when considering that many errors come from
MediaWiki backend code and extension hook functions. And since there
doesn't seem to be any real use case for either of these, let's just
kill both of them instead of wasting effort on trying to fix them.
Note that neither getResultProperties nor getPossibleErrors are called
from any extensions in gerrit, and none of the other deprecated methods
are called outside of the implementations of those two methods. Removing
the obsolete methods is left to the maintainers of the extensions, as
keeping them hurts nothing and is needed to maintain compatibility with
earlier versions of MediaWiki.
Change-Id: Ie11a401d60c834059fbf1b5625ca8ea093b3337c
Scores are an internal metric that should not be exposed to
users, plus most backends fail to even support it.
Removes PostgresSearch*-specific result classes as they're not
needed anymore.
Change-Id: I00acaabad0565b9a5b3524c992feea366eb74bcc
Which type is used depends on the ApiModuleManager responsible for
the API module. There are two managers, one in ApiMain and one in
ApiQuery. Both contain a list of API modules they instantiate.
Both use $this as the first parameter in the constructors of the
individual modules. There is no other regular way to instantiate the
modules, so we know the type must either be ApiMain or ApiQuery.
The lists don't intersect.
I would have prefered the naming scheme $mainModule for ApiMain
modules and $queryModule for ApiQuery modules but since this
doesn't add much I left the shorter variable names untouched.
Change-Id: Ie6bf19150f1c9b619655a06a8e051412665e54db
These files have all had treatment before, and these occurrences have either
been missed or have been introduced after.
Change-Id: I06cdab4616b5bff47c85152df28f18c861730a23
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.
Also added some missing @param.
Change-Id: I758fa4ad80ac95e2ddd3770bcb9b7d2e57ec34ea
Always include redirects. Search results are worse without them
and MWSearch has never respected this option anyway.
Change-Id: I0ebe321a3b14e7960aa98e3225dc5a19ba916e7d
This is useful when you're doing testing of multiple search
engines and you want to compare results.
Note that it doesn't do anything for the prefix search which is ok!
Change-Id: I96a08c64ac84e93b0bec2e8b08d8943b775e68d1
This is a followup to I54ab5207, which allowed search backends
to return status objects. We handled it in Special:Search, but
the API was overlooked.
Bug: 47353
Change-Id: Ib7abe8d5bc19d27c472053602c0e43cb1301b078
API was using SVN's version keyword which GIT does not support.
All related methods were either removed, or for those that
could have been used from extensions, emptied out.
api.php?version now shows unrecognized param warning.
Change-Id: I910ca1448ed2ed697ac19b17c486d130aa1d7e03
Doxygen choke on text enclosed by '<' and '>' since it tries to
interpret them as HTML or XML elements. This patch adds double quotes
in includes/api/*.php files around the two following strings:
<Firstname>.<Lastname>@gmail.com
<Firstname><Lastname>@gmail.com
Which becomes:
"<Firstname>.<Lastname>@gmail.com"
"<Firstname><Lastname>@gmail.com"
Tested locally, it prevents doxygen 1.8.0 related warnings.
Change-Id: I36d82eb3fd4989ee3ffc65b0b527b83711d1ba69