Some search engines generate the title variant from the highlighted
snippet, and thus must have the snippet requested to be able to
provide the title. This is perhaps a bit implementation specific,
but until there is a more concrete api around requesting particular
values from the search engine this should work to provide users
a reasonable output, and document more of the limitations the
future api will need.
Bug: T306477
Change-Id: Ibcd8c24e87e424acab43ce842b68ebd5896e36cd
Some SearchEngine's optimize their snippet generation to not overload
Special:Search with too many snippets, but that implementation detail
is difficult to document for a generic API and leads to confusion
about why a requested snippet may or may not be included in the
response.
Add a way for the api to hint to the SearchEngine what it expects from
the snippet generation. SearchEngine's are under no obligation to
respect this hint. Longer term this may evolve into an API that
provides a more concrete set of expectations around what types of
snippets are expected.
Bug: T306477
Related: I38d58a5af45eef7cd1798312af137a70f73c54c3
Change-Id: Ied664e3c1b7d246bca914f10c8fd2e36ff6418ec
Used in api classes where services can be injected,
no need to rely on MediaWikiServices
Will make it possible to convert ApiOpenSearchTest to
a unit test, since everything is injected, but that will be
done in a follow-up
Plus some minor cleanup to SearchApi
Change-Id: If0a3a60f1ead897947143b57d98a3a506387f6d5
array_fill_keys() was introduced in PHP 5.2.0 and works like
array_flip() except that it does only one thing (copying keys) instead
of two things (copying keys and values). That makes it faster and more
obvious.
When array_flip() calls were paired, I left them as is, because that
pattern is too cute. I couldn't kill something so cute.
Sometimes it was hard to figure out whether the values in array_flip()
result were used. That's the point of this change. If you use
array_fill_keys(), the intention is obvious.
Change-Id: If8d340a8bc816a15afec37e64f00106ae45e10ed
This is micro-optimization of closure code to avoid binding the closure
to $this where it is not needed.
Created by I25a17fb22b6b669e817317a0f45051ae9c608208
Change-Id: I0ffc6200f6c6693d78a3151cb8cea7dce7c21653
Guidelines for when generators can add additional data to the response
have been updated, in T263841, to allow generators to add that data
when explicitly requested. Update module to add the same values as
in non-generator mode, and update the allowed parameters to set
the default values to false, providing values only when explicitly
requested.
Without this information, such as the matching text snippits, it can
be hard to figure out why a search for intitle:park returned 'Capilano
Suspension Bridge' (because there is a redirect with the word park).
Bug: T270381
Change-Id: Iea48937662492445783104077666ab1f1b30da2d
Deprecating something means to say something nasty about it, or to draw
its character into question. For example, "this function is lazy and good
for nothing". Deprecatory remarks by a developer are generally taken as a
warning that violence will soon be done against the function in question.
Other developers are thus warned to avoid associating with the deprecated
function.
However, since wfDeprecated() was introduced, it has become obvious that
the targets of deprecation are not limited to functions. Developers can
deprecate literally anything: a parameter, a return value, a file
format, Mondays, the concept of being, etc. wfDeprecated() requires
every deprecatory statement to begin with "use of", leading to some
awkward sentences. For example, one might say: "Use of your mouth to
cough without it being covered by your arm is deprecated since 2020."
So, introduce wfDeprecatedMsg(), which allows deprecation messages to be
specified in plain text, with the caller description being optionally
appended. Migrate incorrect or gramatically awkward uses of wfDeprecated()
to wfDeprecatedMsg().
Change-Id: Ib3dd2fe37677d98425d0f3692db5c9e988943ae8
Passing around strings that are expected to be safe html and are
known to be based on user input is a fairly unsafe operation. Make
it harder to do the wrong thing by requiring HtmlArmor to be returned
from the ResultSet snippets. This does not address the snippets on
individual result objects as the api surface is larger and requires
more bc handling.
Change-Id: I76231d6fc53c4982eb4cd174d2e6a75eb2740497
And start indicating that hooks relying on this data might become
unreliable as this data is only populated by SearchDatabase search
engines.
This information was only populated by SearchDatabase implementations
and due to bad initial design of SearchResult[Set] (now fixed) it forced
users of these classes to carry this information for the sole purpose of
highlighting.
Because SearchEngine can now own their SearchResult[Set] implementations
nothing that is engine specific should be exposed outside of these
specific implementations.
If there are some logic that still requires access to such list of terms
they should be made engine specific by guarding their code against
instanceof SqlSearchResult.
Change-Id: I38b82c5e4c35309ee447edc3ded60ca6a18b247a
Depends-On: I53fe37c65c7940f696c1e184125e01e592a976e4
In some functions MediaWikiServices::getInstance() was called twices or
in loops. Extract the variable to reduce calls.
Change-Id: I2705db11d7a9ea73efb9b5a5c40747ab0b3ea36f
This should be handled internally by SearchEngine implementations.
Bug: T198860
Change-Id: Ifbfd0fcb81fcacf5228bd2ffcac7b80fca872b2a
Depends-On: I7d4ff9498fa1f4ea66835c634b8931f4c29993fb
This method was introduced in 4115586000
to support the prefix URI param introduced by the InputBox extension.
There are no reasons that this logic is exposed to SearchEngine users
and should be handled internally by SearchEngine implementations
that supports it.
Previously the search query was updated, now the prefix param will passed
along using SpecialSearch::$extraParams.
Bug: T198318
Change-Id: I33518d3f3ddee741ff4f3b47eb4928009bea66d1
Depends-On: I67c7f1886dd6a2d07c12015e2711c138e9f140e9
Selectable sort orders were added to search some time ago, but never
appear to have been used. Expose them in ApiQuerySearch.
There is one large problem here, but it's not easily solvable.
Specifically supported sort orders vary per search engine, but the
available api parameters are calculated with the default search
engine. This is already a problem with search profiles so it's
nothing new, just continuing the existing problem. Much like
search profiles we hide the functionality when multiple engines
are available.
Bug: T195071
Change-Id: I187a530bc973c08386d2c2126e02a85b952d9022
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 funky iteration here was at best annoying. Switch
it over to an iterator based approach with appropriate
BC code to simulate the old iteration style.
Depends-On: I19a8d6621a130811871dec9335038797627d9448
Change-Id: I9fccda15dd58a0dc35771d3b5cd7a6e8b02514a0
It is the job of git and svn to provide this information/metadata.
The form was different, some with short, some with long month name
some with leading zero at the day, some without.
The year is also present in the Copyright clause
Change-Id: If006907b82b9e45f13cfa2e45d41107a95570e1a
'pageid' is now an always-on property returned by API:Search.
Change made in ApiQuerySearch.php::getSearchResultData().
Bug: T172700
Change-Id: I9d856efdd1d72c70bf9fb72c82b1f276abef8b16
This has a number of implications:
* A deprecation warning is automatically generated if the value is used.
* action=paraminfo can list it in a machine-readable manner.
* It is automatically flagged in the help when message-per-value mode is
used.
* In values lists in the help, it's specially marked (currently
strike-through).
* ApiSandbox will mark it in the widgets (currently strike-through).
Deprecation of submodules is not automatically detected here, that's
left for a later patch.
Bug: T123931
Change-Id: Idad6377063e457f9352a99df5c7cc15b1563579e
Links generated by the API are now aware of the user's preferred
language and will show documents in that language if available.
To test, log in to mediawiki.org and set your language preference to 'es',
then on an MediaWiki installation with this patch view the generated
expanded API help at `api.php?action=help&recursivesubmodules=1&modules=main`.
Each link to documentation on mediawiki.org should take you to its
translated /es subpage, if one exists.
Bug: T104518
Change-Id: I339a1f3ae1bce9d759cf251899d57c32b1def91e
API warnings and error messages are currently hard-coded English
strings. This patch changes that.
With a few exceptions, this patch should be compatible with non-updated
extensions:
* The change to ApiBase::$messageMap will blow up anything trying to
mess with it.
* The changes to the 'ApiCheckCanExecute' hook will cause a wrong
(probably unparsed) error message to be emitted for extensions not
already using an ApiMessage. Unless they're currently broken like
Wikibase.
Bug: T37074
Bug: T47843
Depends-On: Ia2b66b57cd4eaddc30b3ffdd7b97d6ca3e02d898
Depends-On: I2e1bb975bb0045476c03ebe6cdec00259bae22ec
Depends-On: I53987bf87c48f6c00deec17a8e957d24fcc3eaa6
Depends-On: Ibf93a459eb62d30f7c70d20e91ec9faeb80d10ed
Depends-On: I3cf889811f44a15935e454dd42f081164d4a098c
Depends-On: Ieae527de86735ddcba34724730e8730fb277b99b
Depends-On: I535344c29d51521147c2a26c341dae38cec3e931
Change-Id: Iae0e2ce3bd42dd4776a9779664086119ac188412
"Inline" interwiki results are added as "additionalsearch" section to the results,
if enablerewrites are turned on.
Bug: T142795
Change-Id: I1c14179ee4fb72b6b84772074b6d231d1129ac14
Historically code that talks to the SearchEngine has been treating
anything other than a 'Good' result, such as results but with a warning
(perhaps the query timed out and only gave partial results) as a
complete failure. Adjust the handling to report results from an 'OK'
status response while attaching any warnings to the api response, or
in a notiable red box on Special:Search.
Bug: T134157
Change-Id: Ic5e0db727790f4fd189caa54ea5f01672d6a8ea4
Currently interwiki result are always computed even if the client does
not request them.
Pass the option via featureData to allow SearchEngine not to run
interwiki searches when not needed.
Bug: T147003
Change-Id: I55067bc7e5d926a3e37f4d24fb8e085bd252c376
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
