Last updated March 16, 2011.
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:
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:
- 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:
- 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
- The preprocessing needs to affect the search excerpt functionality, because right now the excerpt is generated based only on complete words
- 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).
- For diacritic matching, we're relying on the database collation to match letters with accented letters. It should be done in preprocessing instead.
- 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:
- 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.
- 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?).
- Refactor the search query extender
- Suggestions for improving the search query extender:
- 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:
- Search results for different search modules displayed together
- Multi-Site shared searching
- Advanced search more modular:
- Play better with dynamic/PHP content:
- More configuration options and other changes to node searching
- Add more search types
- User profiles -- Note that probably this means user fields should be searchable, or whatever would be visible on a user/N page?
- More configurable:
- Choose number of results per page
- Miscellaneous/small changes
- Better logging
- Add search keys to page title
- Wildcard searching:
- Spelling suggestions:
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).