search

A popular feature request for sites that deal with a lot of content, is to see for each page what other pages are linking back to it. This can be helpful when doing some SEO or cleaning up and rewriting old content.

In Drupal 7 this is easily done. It exists where you wouldn't immediately expect it though: the core search module. Kind of mimicking how search bots like Google's indexer works, Drupal 7's search module now takes the amount of nodes linking back to another node to calculate the score for some result.

Here's a quick tip for people using the (simply awesome) Apache Solr Search Integration module.

The Apache Solr module depends on Drupal's core Search module. This means the Search module will be enabled too when the Solr module is installed. As soon as the core Search module is enabled it starts to index all your nodes and stuff too. This not only takes time to run, but also fills up your database (search_dataset, search_index, ... tables).

Most of the time when you are installing the Apache Solr Search module, you don't need Drupal's core search form and replace the search form with the Apache Solr one using the Apache Solr module setting "Make Apache Solr Search the default:". You have now disabled the core Search module's form, but you have not disabled the indexing. To disable the indexing and save some CPU cycles and database space, just go to your site's search settings page (admin/settings/search) and set the "Number of items to index per cron run" to 0.

A few weeks ago I posted a tip on this blog for improving search results when working with node references in Drupal. While browsing the CCK interface a bit more I stumbled upon an easier (no programming!) solution to solve this problem. Seems I had looked over an option under "Display options" to configure how the field should be indexed.

Drupal's Search Lucene API module is a nice alternative to Drupal's core search if you need more power and features (like facets, ...) but don't want to maintain a Solr installation. The Search Lucene API module comes with facet support out of the box.

One facet you will probably provide most of the time is the "Node type" facet. This allows your visitor to filter search results by content type. When you are using Panel nodes (provided with the Panels module), one of the options for your facet is "Panel". Unless all your visitors are Drupal people, they have no idea what a panel is (in this context). Most of the time, panel nodes can be considered as "pages". So conceptually, they are on the same level as "Page" nodes.

Using the hooks provided by Search Lucene API module we can add an extra field to our Lucene index, called "Clean type" and provide a facet for this field. This way we can add one filter option, called "Pages" which actually returns "page" and "panel" search results.

What follows is a snippet you can use in your own module.

In some cases we want to use Drupal's node reference module to normalize our data. This has certain implications though as information is split up in different nodes. This will influence our search results because our search indexer will only look at each node individually. To explain this problem better we'll start with an example and provide a solution to 3 problems that occur with when spreading information over different nodes (connected via node references).