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
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
