The InputBox extension allows to pass a prefix URI param to the SpecialSearch page.
The purpose of this prefix param is to limit searches to pages whose title is starting with this prefix value. This is useful to provide ready-to-use search boxes to search archive pages for example or pages within a particular tree of subpages.
This prefix param is only supported by CirrusSearch and the deprecated lucene-search extension.
To implement this feature:
- a new URI param has been added to SpecialSearch,
- this var is then passed to SearchEngine by SpecialSearch
- SearchEngine::transformSearchTerm is called and will, in the case of CirrusSearch, append a prefix keyword to the query
- SpecialSearch then calls searchText with the modified search query
This has imo multiple drawbacks:
- Having to call SearchEngine::transformSearchTerm() prior to calling searchText() seems like an unnecessary step that is easy to miss. This should be handled internally by the SearchEngine.
- Appending and munging the user query might lead to unexpected behaviors, while this works for simple word queries there are no guarantee that the generated query will be valid as we start to support better boolean logic in cirrus search
- This changes the original query sent by the user and gives a false impression that the prefix keyword is heavily used by users.
This task is about proposing to change how this works and at the same time address some tech debt by deprecating the SearchEngine::transformSearchTerm method.
To illustrate this here is as an example using the MOS page on the english wikipedia:
Searching for bold opens the Special:Search page with the user query being suffixed with the keyword prefix:Wikipedia:Manual Of Style :
The suggested behavior is to not change the user query but add a hint in the UI (to be properly defined) to indicate that the user is searching within pages whose titles start with Wikipedia:Manual Of Style. By clicking the UI hint the user will have the possibility to reset the Special:Search state (i.e. remove the prefix filter).
Note that this UI suggestion is far from being ready, it's just for illustration purposes and was a way for me to test the new back-end code.
A few patches will be attached to this ticket to clarify the impact on the code, they should not be merged without discussing the impact of adding a new UI component to Special:Search. I'm also pinging the AdvancedSearch extension since it might have some impact there as well.
To sum up, the state of this ticket is to start to discuss about this suggestion.