Move solr into a separate make file

[jyee]

A couple issues with the apachesolr stub in os_project.make:

1. It's enabled by default, but many (likely a majority) of projects don't require solr
2. Out of the last 4 projects that have used Solr, all have used the Search API implementation

This change removes the apachesolr stub and puts the standard search api, search api solr, search api attachments and facet api module set into a solr include.

[mpgeek]

On board here. I like the idea of pushing the search implementation out into its own makefile and including it... keeps the clutter minimized. I have never used solr native, so i'm a fan of standardizing on SAPI.

[jhedstrom]

I'm generally for this change. Does the search_api module have the same 'drop-in' replacement to core search ability as apachesolr? On many projects, facets are never used, but replacing the awful core search is still nice.

[nielsonm]

Sounds good. :+1: for @jhedstrom's comment on unfaceted search.

[mpgeek]

AFAIK, facets are not required, but i did have an issue with getting a global search form to work. @jyee mentioned there might be something toward that end that involved a form_alter, which is the same solution i've implemented recently.

[jyee]

Search api doesn't have a drop in replacement. The typical way to do this is to disable core search, enable exposed filters in a block and use that to replace the core search block. As @mpgeek mentioned, there's a little bit of form_altering that needs to happen because of the way the filters assume you're on a search view page.

Should we comment out facet api and attachments by default, then devs can enable those individually as necessary?

[nielsonm]

Would there be some way to build a module to replace core search using search API, I'm totally willing to devote my Code Rally to creating something that could be a drop in replacement for core search.

[jyee]

Also, maybe we should include https://drupal.org/project/search_api_page That module creates a search block for every search page it generates. It's an easier, more direct replacement for core search. The process is:

1. enable search api stuff, disable core search
2. create search page
3. place the corresponding search block wherever the core search block was.

[nielsonm]

Looks good. It'd be cool to be able to automate the creation of a basic search page in profiler, but that's probably asking for a lot. Maybe an install function in turnip would be easier. Ideally we could make the stock replacement completely automated, so as to make the switch completely brainless.

[jyee]

Search pages are exportable in features, so we could create an os_solr feature that would simplify the stock search replacement in the same way that we have os_blog, etc. Although I think core search replacement is a bit of an minority (maybe even edge) case for us. Most projects that have solr have needs beyond basic searching.

[jhedstrom]

Sadly, I think until we have a drop-in (as in ~15 minutes of dev time max) replacement to core search, apachesolr module will still occasionally be required. However, since that would appear to not be the norm, I'm fine with this patch for now--just realize that on some sites, manually adding apachesolr will be required.

[jyee]

@jhedstrom Maybe the solr include should have that as well? Should we break the file up into a search api and a apachesolr section? That would definitely make things easier for anyone who needed to use apachesolr.