I have a website that uses the apachesolr module with a completely external, read-only index.
What I have done is:
- Indexing happens outside of Drupal.
- I have added all my index fields to the solr schema.xml file.
- I implement hook_facetapi_facet_info() for the fields I want to use facets with. Note that this isn't needed for basic search to work.
and this works fine.
In the report I get legit stats for number of items in the index and it shows my fields. I don't get distinct term counts though because I have more than 20000 items in the index.
I do not see "NOT INDEXED" anywhere.
I also have some customisations to facet blocks and a custom sort block but that is just for my specific use case, it isn't a requirement.
The other part to my setup is my search pages are all custom pages in a custom module that manually run queries using apachesolr_drupal_query() and apachesolr_do_query().
I'm not sure how feasible it is to use the out of the box search page with an external index.
The apachesolr_search module is a useful example of search functionality. You might find there are chunks of that module you can copy and paste and modify to suit your needs.
To implement a custom search page you need a hook_menu() callback for your page, for which there are many examples around the internet.
There are a lot of ways you could implement it based on your requirements and preference but the way I have it is my menu item points to a search results page that by default shows x number of results, not filtered in any way.
If there is a url segment after the search url that is taken as the search keys (entry into search box), just like the default drupal search and apachesolr_search work.
Then I have the normal drupal search box, which has been form altered to add a custom submit handler that redirects (via $form_state['redirect']) to my search page with any keys appended.
I then use facetapi facet blocks as usual. The facet blocks should link to whatever the current search is and they pass facets in as query string params (from memory I think that's how it works).
So for those to work the custom search page also checks for any facet query strings to pass into its query.
As mentioned before I have a custom search block, which also passes search options via the query string.
This is heavily based on the apachesolr_search module sort block.
So your custom page really assembles search keys and query string params for facets and sort into a query, runs it, then returns the results.
You can return the results in any format you choose.
As per hook_menu() usage you will return a render array or a string of HTML.
I would recommend using custom theme functions to output your results.
So you get the results from your query and pass them as variables into your template, which returns the markup.
See hook_theme() for more information on creating theme templates.
So that brings you to the main part, the solr query.
For this you can use apachesolr_search_search_results() as an example and take from that the parts you find relevant to your usage.
The main parts are:
apachesolr_get_solr() to load the search environment you want to use to search on.
apachesolr_search_run() to run the actual search.
I found that apachesolr_search_run() was not suitable for my needs because it did some things I didn't want, like processing the response in a way that doesn't suit your my data.
So I took the parts from there that I needed instead, which are:
apachesolr_drupal_query() to load a query object.
apachesolr_do_query() to run the query.
apachesolr_has_searched() to tell the system that a search has been run.
This is used for things like facet blocks later in the page load.
So in the end the basis of the search is:
Now your use case may mean you want to utilise some other parts of the apachesolr module but if you start from apachesolr_search_search_results() and follow it through you can see how it works and take the parts you want.
I'm sure given more time I could improve my solution but it currently gives the results I require.
I'm not sure how complex your searching is but be aware that there is a fair bit of caching that goes on when running these searches. It is used for things like facets, so that they know what the current page's search was to show you its facets.
If you are doing multiple searches on a single page load you will run into issues, but that's probably outside the scope of this specific question, which is just to get basic searching running.
It's worth noting that my search index structure was very different from a normal drupal content one and my search requirements were very custom, so there may be simpler ways to do this for a simpler setup, but this is definitely one option that works.