Make search module into a cleaner and more flexible framework

OK so the main thing which needs fleshing out I think is that fact that node module implements search module hooks, and search module implements node module hooks, and people don't seem happy with either of those at various times.

The answer I've seen (and I think a contrib module by Robert Douglass already implements this), is refactoring the core search implementations into node_search.module and node_user.module - I'm not overly keen on that because it adds a lot of cruft to the modules page, for something which only really matters at an API level.

While I didn't give it lots of thought yet, was thinking more along the lines of a hook_search_info() hook.

so node_search_info() {
return array(
'type' => 'node',
array (
'search path' => content,
'indexer' => 'node_search_index',
)
}

Then you'd be able to swap out bits and pieces of this with a hook_search_info_alter(). So for example I think user_search() currently does direct queries rather than building an index, but with fields in core, it's possible someone would want to build a search index for users using all the rendered information from fields. The other option is doing it OO style, or we might need a combination of both - but something like this at least allows us not to require an extra module for every search implementation - I think it'd be good to be able to search for taxonomy terms in core for example (at least in taxonomy administration), and adding a taxonomy_search.module starts to look really messy.

I'd give a big thumbs up to that. It would make swapping out alternate implementations much easier, and also make it easier to determine what modules are providing search pages on the site.

There are three elements in play:

1. The data provider (node, user, taxonomy, etc.)
2. The search index provider
3. The search UI

There are two hooks to define: one between the search UI and the data provider (let's call that hook_search_object_info()), and one between the search index provider and the data provider (let's call that hook_search_index_<index>()).

The problem of the current hook_search() is that it tries to do both at the same time:

• 'admin' and 'name' belong into hook_search_object_info()
• 'reset', 'search', 'status' and the whole hook_update_index() belong into hook_search_index_<index>()

EDIT: refined the repartition above.

My current vision is that we need two modules:

• search, providing the base API and defining hook_search_object_info()
• search_index, providing the core indexer, and defining hook_search_index_core

The node module will implement hook_search_object_info() like this:

function node_search_object_info() {
  return array(
    'node' => array(
      'name' => t('Content'),
    ),
  );
}

search_index will provide the core indexer, and will also provide implementations of hook_search_index_core for base core objects (node, user, but probably also taxonomy vocabulary and terms). A search implementation is very tightly coupled between the object provider and the index provider (take a peak at http://api.drupal.org/api/function/node_search/7 and get convinced... most of node_search() is useless for say... Apache Solr), so it would make little sense to move that into the node module directly.

Too busy to give enough of a review to put RTBC, but otherwise would:

1. This is obviously a much better architecture format, and disabling user search without disabling the user module, is a good thing.

2. This patch shouldn't change much because it is basically just splitting up a massive hook, easy to commit IMO if it works correctly.

As Peter mentioned on IM:

needs a little cleanup to get nice module names - there's a sucky APi

So I think a little language / format work on the new settings page and this is ready to go.

@Joshua had already marked it RTBC; just switching the status back.

Committed to CVS HEAD. Thanks.