In the D8 Search core conversation at Drupalcon London, we discussed the following high level actions items (listed in no particular order) that are quick wins and would hopefully improve the underlying Search framework in D8 and alleviate some of the maintenance overhead.
- Allow for multiple search pages per module
- Remove menu tab assumption
- Make the preprocess code language / type aware
- Make the highlighting code pluggable
- Make default operator to "OR", start to explore making the parser pluggable.
Like many others I have been following the WSCCI initiative and the core issue Add unified context system to core, and I'm wondering if this changes the approach for D8 Search at all. It seems like to some extent, a lot of the functionality that is abstracted in modules such as Search API, and to a lesser extent Facet API, is geared towards providing various contexts such as whether a search was executed, which search was executed, what keywords were passed, and information about the results to name a few.
Although it would in no way approach the level of abstract that Search API provides, it does seem like an opportunity to put a lot of these contexts into core using the functionality provided by WSCCI without an overwhelming amount of effort. My big question is how can we leverage WSCCI to make D8 Search more useful to the existing contribs without adding a maintenance tax to the subsystem?