Drupal 8 Search Feature Ideas

Last updated on

6 October 2020

Drupal 7 is not out yet, and Drupal 8 is just a far-away dream, but I'm thinking about what we'd like to see in the core Search module for Drupal 8 and beyond, so that we can get started on it sooner rather than having things get postponed again. So, here are thoughts from jhodgdon (and whoever else edits this page) about what would be good to see in a future Search module. With links to issues where available.

Structure/architecture of code, interfaces with other modules, etc.

In general, I think that the search module needs to be made more modular, so that various bits of it can be turned on, turned off, and replaced. A start has been made in:
http://drupal.org/project/search_api

Here are some more specific suggestions.

Make the way Search uses the form and menu system more standard

As things are now, the way Search uses the form system and the menu/tab system is non-standard, and it tends to make things rather difficult. For instance, there is no clear distinction in the URLs between search tabs/modules and search terms (e.g. path search/foo could mean you are searching for "foo" or that you are using the "foo" tab). This has led to many issues that we had to fix in Drupal 7.

I am not sure how to fix all of this, but I think it should definitely be fixed. Maybe by scrapping the idea of each search module being a tab, and instead using radio buttons, and using the standard form submit mechanisms of Drupal? It needs some thought. Here are some Drupal 8 feature request issues on the subject:
#753996: [META] Re-architect use of menus, tabs, and forms in Search module
#894486: Use the query string for search keys rather than appending them to the URL

Decouple from user and node modules

Right now, the code for search.module has a few places in it that pretty much assume that node.module searching is turned on and should be the default search. Also, both node.module and search.module have several places that support search.module. It would be better if search.module was truly independent of both user.module and node.module, and if all of the searching capabilities of node.module and user.module were in separate modules. Issues related to this:
#237748: Decouple core search module implementations from node and user module (and turn search/node and search/user to views).
#248154: Allow UI to choose which search module is default tab

Preprocessing

When both indexing and searching, there is some preprocessing that takes place. For instance, text has to be split into words, which right now has some implicit assumptions that make supporting other languages difficult (such as that a space separates words, which isn't necessarily true in Chinese and other character-based languages). Also, there is an API for third-party preprocessing that lets you install stemming modules.

There are several problems with the current approach:

All of the preprocessing should be made modular, so you can turn on and off different bits of preprocessing and probably change the order
These bits should be turned on or off based on language, so that search will work properly for multilingual sites
#511594: hook_search_preprocess needs to be language-specific
The preprocessing needs to affect the search excerpt functionality, because right now the excerpt is generated based only on complete words
#493270: search_excerpt() doesn't work well with stemming
We should add some new optional processing steps, such as n-gram searching, which is indexing/searching based on sub-words such as tri-grams (three-letter sub-words).
#103548: Partial Search in Drupal Core
For diacritic matching, we're relying on the database collation to match letters with accented letters. It should be done in preprocessing instead.
#731298: Searches for words with diacritics/accents: word not highlighted in results

Probably the best way to implement this is to have a hook_search_preprocess_info() that will let modules define their preprocessing steps. Return value could be an array with components 'languages' (define which languages this applies to), 'name' (human-readable name), 'process callback' (define which function to call to pre-process text), 'excerpt callback' (define a function to call to do excerpts, and this needs to be thought out a bit, but I have an example of how this could work in contrib project Search by Page, which is implemented in Porter Stemmer, and works).

Then the UI could let you make a sequence of preprocessing steps, turn each step on or off, etc.

Another implementation possibility would be to use a filter chain:
#257007: Convert hook_search_preprocess() into a plugin

Multiple tabs per module

Right now, search.module allows third-party modules to define search types, each one shown on a tab. But it only allows each third-party module to define one search type, which is very limiting.
#239133: Multiple Search Tabs Per Module

Pluggable index and retrieval

It would be great if the parts of search.module that actually do the indexing and retrieval were made more modular. Then you could easily replace the search module's indexing capabilities (with something like solr), or even replace it on a search tab by search tab basis (for instance, the user module already does its own thing for searching, but maybe for each tab, you could choose the indexing method?).
#282192: Pull custom search indexing into backend

Refactor the search query extender

Suggestions for improving the search query extender:
#582938: Fix up documentation and member names in SearchQuery

Ranking

Ranking seems to be somewhat more modular in Drupal 7 than it was in Drupal 6, but it could still be improved:

Other miscellaneous structure suggestions

Play better with dynamic/PHP content:
#752184: Keep running cron when bad PHP content is encountered
#286263: Make search indexing smart to handle nodes wth php redirects
#155786: Ability to keep indexing beyond cron failures
Search results for different search modules displayed together #252211: Override creation of separate tab for other modules' invocation of hook_search
Multi-Site shared searching #114233: Multisite enhancement for 'search.module'
Caching #242187: Cache search results
#721394: Allow links to non-existent URL aliases to be indexed correctly once the node with that alias is created
Advanced search more modular: #256792: Figure out how to allow advanced search operands (alongside type:, category:)

User experience and user interface

Here are some additional suggestions that are more along the lines of user interface and user experience (although some of the structural suggestions above affect UI and UX as well).

More configuration options and other changes to node searching

Add more search types

User profiles #28325: Patch To Add User Profile Search -- Note that probably this means user fields should be searchable, or whatever would be visible on a user/N page?
Taxonomy #172812: Implement SearchPlugin for taxonomy

More configurable: