I am a Permanent Member (or Community Ambassador) of the Drupal Association.For the last six months, Scott Reynolds has been keeping a big juicy secret. As the maintainer of the Apache Solr Views module, he knows just how cool the future of Drupal Search is going to be. His module, based on an idea and code from Thomas Seidl, lets you make custom searches against the Solr index the same way you currently make views against the MySQL database. Want to build a search that just includes videos and MP3s, and renders the results as a playlist? Or how about a search that is limited to the current user's images, displayed in a slideshow? How about a block that shows the latest results that contain the phrase "badgers are the new pony"? Well, even if you didn't want a block like that, with Views 3 and Apache Solr Views, you can have it.
Thomas Siedl's brilliant idea was that Views should be able to build "queries" against any data source, not just databases. Earl Miles agreed, and inagurated the Views 3 branch by commiting the patch by Thomas (with great help from Jeff Miccolis and others). With Views 3 I predict you'll be able to build Views using data from Flickr, or from RDF databases using SPARQL, or from the local file system, or from any other data source that has an API.
To test it all out I used the Acquia Drupal Stack to create a new site (I just love the stack's multisite functionality!). I then signed up for a trial Acquia Network subscription because I wanted to get my hands on 30 days of free Acquia Search (it's easier than setting up Solr myself). I then downloaded Views 3 and Apache Solr (DRUPAL-6--2, just for fun. DRUPAL-6--1 works, too). I had to get the Apache Solr Views module from CVS (Scott, make a devel release!). I put these in sites/all/modules so that they'd override the versions in the Acquia Drupal Stack.
The CVS command for getting Apache Solr Views
$ cvs -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib \ co -d apachesolr_views contributions/modules/apachesolr_views
I installed Apache Solr manually which means I also needed to get the SolrPhpClient library. Since I have Drush, and since Apache Solr DRUPAL-6--2 has Drush integration, I did it like this:
$ drush solr phpclient
I <3 Drush!
I then used FeedAPI to grab all sorts of content from Planet Drupal. I could have just as well used Drush and the Devel module to generate some content, but lorem ipsum gets mighty boring. Finally I used Drush to run cron and even did a search (from the command line!) to check that the content was in the index.
$ drush cron $ # wait a few minutes for the search index to commit the changes... $ drush solr search drupal node/175 by admin (user/1) title: Agile and Scrum Videos This is likely to become a pretty big collection of videos about Scrum and other other Agile based managements processes. (Drupal 5, Drupal 6, Drupal 7, Drupal Planet, Drupal Video) ... node/1 by admin (user/1) title: Welcome to your new Acquia Drupal website! If you are new to Drupal, follow these steps to set up your web site in minutes: Step 1 ... , forums, polls, tags, comments, ratings, and more. Acquia Drupal comes with many modules to power social publishing capabilities on your site. Hundreds of additional Drupal 6.x compatible modules ...
Now for the good stuff. When you make a new view in Views 3 you get asked what data source to use. Here you can see that I use the Apache Solr search index as a data source.
Then I added some fields. These are not the same fields that are available to node based views. They are specific to the underlying data source.
I also added a sort so that the results would be displayed according to the search score (keyword relevance).
In order to make this view seem like a "search" screen, it needs a search box, right? You get that by adding a search filter and exposing it. I could add more filters, too, like a filter to limit it to just one content type.
This shouldn't just be a copy of the normal search screen. The results should look different. To that end I told Views to render the results in a table.
Since we want this to be a page view it needs a path, and I went ahead and stuck it in the menu as well.
Finally, I want to be able to use Apache Solr's facet blocks along with the view. This is a three-step process.
It tastes great! Feast your eyes on this marvelous search screen.
The keyword search and the facet block interact seamlessly.
An interesting point to note is that there are no database queries used in retrieving the data or displaying it. No complex views query with lots of joins, and no node_load() calls for displaying the results. This method of querying Solr is just as efficient as using the normal Apache Solr search module.
To my mind, Views 3 and Apache Solr Views are the future of Solr search for Drupal. Even though they are both in heavy development, you can try them out and enjoy the great control you have over your search experience. There are many more handlers that need writing, too, so jump into the Apache Solr Views issue queue and help out. Since it all works with Acquia Drupal and Acquia Search, you can easily get up and running using an Acquia subscription. Enjoy!
In this article I will show you how you can write a tiny bit of code that will reveal new fields and facets for searching with the ApacheSolr module and Acquia Search. Using Acquia Drupal we’ll write an example module that takes the file type from CCK file and image fields and makes them into their own search fields. This results in us being able to filter our search results based on file type. This code fulfils the situation where you want, for example, to find a specific post that has a JPEG image, or all of the posts with PDFs that match a particular keyword.
1. refactor search node\_rank with hook\_node\_rank scoring factors: Node module's content search allows four different runtime scoring factors, including keyword relevance, recency and number of comments. This patch replaces the hardcoded scoring factors with a hook that lets any module inject similar scoring factors.
2. Path module should add URL alias to update index in nodapi.: Currently, the URL alias of nodes doesn't play any role in the keyword relevancy of Drupal search. This might be the #1 reason Google still beats us at searching Drupal.org.
3. Add spelling suggestions to the "no search results found" page.: When no search results are found, this patch looks at the query, looks at the words in its index, and uses the Levenshtein algorithm to make a spelling suggestion that might be what you intended to search for.
4. Patch To Add User Profile Search: User search is useless in its current form. Being able to search user profiles would be a huge step forward in making search/user into something special.
5. search_index hardcodes boosts to html elements. Should be configurable.: <h1> gets 25 points, <a> gets 10, and <em> tags get 3; wouldn't it be nice if this were configurable?
6. Exclude node types from search index: Sometimes you don't want certain content types to be indexed. This adds an administration configuration for that case.
7. Optional Exclusion of Taxonomy Vocabulary from Advanced Search: For those of you with HUGE taxonomy vocabularies, this will make the advanced search form usable again.
8. Indexing options for taxonomy: Administrator gains the ability to say how strongly taxonomy terms should weigh in the indexing process. Synonym support included.
9. Add scoring factor controls to advanced search form
The administrator can adjust runtime scoring factors on the site configuration -> search page. Why not let the end user decide how important each scoring factor should be by using the advanced search form?
10. Fix search index link handling for non-existent nodes
Esoteric bug with an RTBC patch (waiting for just one more review) that fixes the case when someone links to a not-yet-created node.
11. Showing result count and result range in search results: This is really a feature request for the pager. Why don't we have something like "Showing 10-20 from 500 results" on our search pages?
12. Replace "blue smurf" in no search results message: The quintessential bike shed argument. What two words should replace "blue smurf"?
Please help review and refine these patches. All of them need SimpleTest cases written as well.