Drupal Planet

One of the most commonly used features in Drupal is path aliases; that is, the ability to define a custom, clean URL that accurately represents the content contained in that page.  A basic example is creating a mysite.com/about-us URL for an About Us page.  This can also be done in Apache Solr with search result pages.  It's a bit more work than setting up an alias with the Pathauto module, but the end result is a page of customized search results listed at a custom URL.  In this post, I'm going to take the URL of mysite.com/search/apachesolr_search/?filters=type%3Avisualization and create an alias of mysite.com/visualizations.

Before continuing reading, you need to familiarize yourself with this post from James McKinney on creating custom search paths with keywords.  However, what I'm going to show is different, in that instead of using keys (i.e. search terms entered in the search box), I'm going to apply a custom filter, or facet in Solr-speak.

To start, we first define our custom paths in hook_menu():

/**
* Implementation of hook_menu().
*/
function mymodule_solr_menu() {
  $items = array();
  $items['partners'] = array(
    'page callback' => 'mymodule_solr_custom_search',
    'access arguments' => array('search content'),
    'type' => MENU_CALLBACK,
  );
  $items['visualizations'] = array(
    'page callback' => 'mymodule_solr_custom_search',
    'access arguments' => array('search content'),
    'type' => MENU_CALLBACK,
  );
  return $items;
}

These menu items are defined in mymodule_solr_menu(), which is part of a custom module mymodule_solr.module.  It defines two URLs, mysite.com/visualizations and mysite.com/partners, that both use mymodule_solr_custom_search() as a page callback.  mymodule_solr_custom_search() is a modified copy of apachesolr_search_view() from apachesolr_search.module.

/**
* Create a custom search path.  This is a slightly modified copy of
* apachesolr_search_view from apachesolr_search.module
*/
function mymodule_solr_custom_search($type = 'apachesolr_search') {
  // Search form submits with POST but redirects to GET.
  $results = '';
  if (!isset($_POST['form_id'])) {
    if (empty($type)) {
      // Note: search/X can not be a default tab because it would take on the
      // path of its parent (search). It would prevent remembering keywords when
      // switching tabs. This is why we drupal_goto to it from the parent instead.
      drupal_goto('search/apachesolr_search');
    }
    $keys = trim(mymodule_solr_get_keys());
    $filters = '';
    if ($type == 'apachesolr_search' && isset($_GET['filters'])) {
      $filters = trim($_GET['filters']);
    }
    // Collect the search results.
    //  In this custom function we are searching regardless of whether or not there are $keys
    // which there won't be whenever this function is used
    $results = search_data($keys, 'mymodule_solr');

    if ($results) {
      $results = theme('box', t('Search results'), $results);
    }
    else {
      $results = theme('box', t('Your search yielded no results'), variable_get('apachesolr_search_noresults', apachesolr_search_noresults()));
    }

  }
  // Construct the search form.
  return drupal_get_form('search_form', NULL, $keys, $type) . $results;
}

If you compare this module to apachesolr_search_view(), you'll see there are a few differences.

    Replaced the call to search_get_keys() with a call to mymodule_solr_get_keys().  This is a custom version of search_get_keys() that gets the value from the URL (covered in detail below). 
    Remove the conditions that only call apachesolr_search_execute() if there are values for $keys or $filters, since we don't want to use keywords for this search and we can't apply filters at this point in the process (they are applied later in hook_apachesolr_prepare_query()).
    Replaced the second parameter of $type in the call to search_data() with 'mymodule_solr'.  This will call our custom function mymodule_solr_search() (detailed below), which is an implementation of hook_search().

The next function is mymodule_solr_get_keys(). 

function mymodule_solr_get_keys() {
  static $return;
  if (!isset($return)) {
    $parts = explode('/', $_GET['q']);
    if (count($parts) == 1) {
      $return = array_pop($parts);
    }
    else {
      $return = empty($_REQUEST['keys']) ? '' : $_REQUEST['keys'];
    }
  }
  return $return;
}

The purpose of search_get_keys() is to get the search terms from the URL, which is normally assumed to be /search/apachesolr_search/$keys.  These terms are then passed to solr via search_data() and eventually apachesolr_search_execute().  However, in this case, we are hijacking this function to get the URL, but instead of using the value as a key, we will be using it to apply a filter.  Since this will only get called for specific paths which only have one value in addition to the base path, we get that value and return it to mymodule_solr_search_view().

Our third custom function is mymodule_solr_search().

/**
* Implementation of hook_search().
* Copy of apachesolr_search_search with slight modification
*/
function seedge_solr_search($op = 'search', $keys = NULL) {
  // We're using the $keys variable to store the base path that is passed to apachesolr_search_execute
  // so we need to blank it out since it's not needed as $keys any more
  $custom_path = $keys;
  $keys = '';

  switch ($op) {
    case 'name':
      return t('Search');

    case 'reset':
      apachesolr_clear_last_index('apachesolr_search');
      return;

    case 'status':
      return apachesolr_index_status('apachesolr_search');

    case 'search':
      $filters = isset($_GET['filters']) ? $_GET['filters'] : '';
      $solrsort = isset($_GET['solrsort']) ? $_GET['solrsort'] : '';
      $page = isset($_GET['page']) ? $_GET['page'] : 0;
      try {
        $results = apachesolr_search_execute($keys, $filters, $solrsort, $custom_path, $page);
        return $results;
      }
      catch (Exception $e) {
        watchdog('Apache Solr', nl2br(check_plain($e->getMessage())), NULL, WATCHDOG_ERROR);
        apachesolr_failure(t('Solr search'), $keys);
      }
      break;
  } // switch
}

As I mentioned above, I'm using the $keys variable to pass my filter value from mymodule_solr_search_view() onward, and here is where we take it out of $keys.  Since the $keys variable is actually passed on to apachesolr_search_execute(), we store the value in $custom_path and set $keys to an empty string.  Next, we alter the call to apachesolr_search_execute() from

$results = apachesolr_search_execute($keys, $filters, $solrsort, 'search/' . arg(1), $page);

to

$results = apachesolr_search_execute($keys, $filters, $solrsort, $custom_path, $page);

The final function is an implementation of hook_apachesolr_prepare_query():

/**
* Implementation of hook_apachesolr_prepare_query
*/
function mymodule_solr_apachesolr_prepare_query(&$query, &$params) {
  // Get the $base_path value, since that will tell us what type of content type
  // the filter needs to use
  $base_path = trim($query->get_path(''), "/"); 
  // Add filter for data_sets
  switch ($base_path) {
    case 'visualizations':
      $type = 'visualization';
      break;
    case 'partners':
      $type = 'knowledge_partners';
      break;   
  } 
  if ($type) {
    $query->add_filter('type', $type);
  } 
}

The value stored in $query->base_path is the $custom_path value that was passed to apachesolr_search_execute() in mymodule_solr_search_search() above.  We pass an empty string to get_path so that  only the base path value is returned (see the get_path() function in Solr_Base_Query.php to see why).  Once we have that value, we use the $query->add_filter() method to the $query object.  The first parameter is the type of filter ('type' is the node type), and the second parameter is the value of the filter.

One point that is worth making is the difference between hook_apachesolr_prepare_query() and hook_apachesolr_modify_query().  As I mentioned in my previous post, which one you use is determined by whether or not you want the user to see the change.  Anything modified in prepare_query will be visible to your users, and anything modified in modify_query will not be visible to your users.  Here is the code from apachesolr.module that calls the two hooks to help illustrate why:

// Allow modules to alter the query prior to statically caching it.
  // This can e.g. be used to add available sorts.
  foreach (module_implements('apachesolr_prepare_query') as $module) {
    $function_name = $module . '_apachesolr_prepare_query';
    $function_name($query, $params, $caller);
  }

  // Cache the built query. Since all the built queries go through
  // this process, all the hook_invocations will happen later
  $current_query = apachesolr_current_query($query);

  // This hook allows modules to modify the query and params objects.
  apachesolr_modify_query($query, $params, $caller);
  $params['start'] = $page * $params['rows'];

The only line between the calls to the two hooks is the caching of the query.

This is illustrated in this case by the display of the Apache Solr Search: Current search block; when the code to add the filter with $query->add_filter() is placed in modify_query, the block is not displayed, but when it is placed in prepare_query, it is displayed on the search results page (assuming you have it enabled in your Blocks admin, of course).  I won't go into detail on all the ways I tried to get that block to display, including directly modifying $_GET['q'] before I finally remembered that distinction...

And that's it.  Now, when you navigate to mysite.com/visualizations, you get a page of Solr results with only the content type filter of the visualizations content type applied.  It's a bit of a hack in that I'm using the functionality for passing keywords to pass filter values, but it shows the customization possibilities that are possible with Solr.

I attended Drupalcon for the first time this year in San Francisco, and of all the sessions I attended, one that really stood out for me was Apache Solr Search Mastery, put on by Robert Douglass and Peter Wolanin of Acquia and James McKinney of Evolving Web.  It was like the first time I read "Pro Drupal Development", in that it really opened my eyes as to what is possible with the Solr module.  On top of that, I was almost immediately able to take what I learned back to a project I was working on and start using it.

One of the first use cases I had was the need to add a custom sort to the search results.  Out of the box, the module has the following five sorts available:

•     Relevancy
•     Title
•     Type
•     Author
•     Date

However, the client also wanted to add a search by the number of times a node had been viewed, as provided by the core Statistics module.  In order to make this data available in Solr as a sortable field, we have to follow a two step process:

1.     Add the field to the Solr index
2.     Tell Solr that the field is sortable

Adding the field to the index

The apachesolr module has multiple available hooks that can be used to alter the search data.  In this case, the one that we want is hook_apachesolr_update_index.  This hook is run for each node, and is passed the $document object by reference.  $document is the XML document that is passed to Solr for indexing.  The source for our data is the totalcount field in the node_counter table.

function mymodule_apachesolr_update_index(&amp;$document, $node) {<br />
        &nbsp; // Get count from node_counter table<br />
        &nbsp; $count = db_result(db_query(&quot;SELECT totalcount FROM {node_counter} WHERE nid = %d&quot;, $node-&gt;nid));<br />
        <br />
        &nbsp; // Add field to index<br />
        &nbsp; if ($count !== FALSE) {<br />
        &nbsp;&nbsp;&nbsp; $document-&gt;tis_hit_count = (int) $count;<br />
        &nbsp; }<br />
        }}

So all we do is run a query to get our count value, and add it to the Solr index in the tis_hit_count field, but only if the query returns a value.  If you try to add an empty value, such as the case where there is no record in node_counter for a node yet, Solr will throw an error.

One important thing to notice is the field name.  The 'tis_' at the beginning of the name tells Solr what kind of data is stored in the field.  If you look in the schema.xml file that comes with the module (and that you use to replace the default Solr file when installing the module), there is a section that lists all of the dynamic field naming patterns.

&lt;!-- Dynamic field definitions.&nbsp; If a field name is not found, dynamicFields<br />
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; will be used if the name matches any of the patterns.<br />
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RESTRICTION: the glob-like pattern in the name attribute must have<br />
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a &quot;*&quot; only at the start or the end.<br />
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; EXAMPLE:&nbsp; name=&quot;*_i&quot; will match any field ending in _i (like myid_i, z_i)<br />
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Longer patterns will be matched first.&nbsp; if equal size patterns<br />
        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; both match, the first appearing in the schema will be used.&nbsp; --&gt;<br />
        <br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;is_*&quot;&nbsp; type=&quot;integer&quot; indexed=&quot;true&quot;&nbsp; stored=&quot;true&quot; multiValued=&quot;false&quot;/&gt;<br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;im_*&quot;&nbsp; type=&quot;integer&quot; indexed=&quot;true&quot;&nbsp; stored=&quot;true&quot; multiValued=&quot;true&quot;/&gt;<br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;sis_*&quot; type=&quot;sint&quot;&nbsp;&nbsp;&nbsp; indexed=&quot;true&quot;&nbsp; stored=&quot;true&quot; multiValued=&quot;false&quot;/&gt;<br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;sim_*&quot; type=&quot;sint&quot;&nbsp;&nbsp;&nbsp; indexed=&quot;true&quot;&nbsp; stored=&quot;true&quot; multiValued=&quot;true&quot;/&gt;<br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;sm_*&quot;&nbsp; type=&quot;string&quot;&nbsp;&nbsp;&nbsp; indexed=&quot;true&quot;&nbsp; stored=&quot;true&quot; multiValued=&quot;true&quot;/&gt;<br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;tm_*&quot;&nbsp; type=&quot;text&quot;&nbsp;&nbsp;&nbsp; indexed=&quot;true&quot;&nbsp; stored=&quot;true&quot; multiValued=&quot;true&quot; termVectors=&quot;true&quot;/&gt;<br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;ss_*&quot;&nbsp; type=&quot;string&quot;&nbsp;&nbsp;&nbsp; indexed=&quot;true&quot;&nbsp; stored=&quot;true&quot; multiValued=&quot;false&quot;/&gt;<br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;ts_*&quot;&nbsp; type=&quot;text&quot;&nbsp;&nbsp;&nbsp; indexed=&quot;true&quot;&nbsp; stored=&quot;true&quot; multiValued=&quot;false&quot; termVectors=&quot;true&quot;/&gt;<br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;tsen2k_*&quot; type=&quot;edge_n2_kw_text&quot; indexed=&quot;true&quot; stored=&quot;true&quot; multiValued=&quot;false&quot; omitNorms=&quot;true&quot; omitTermFreqAndPositions=&quot;true&quot; /&gt;<br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;ds_*&quot; type=&quot;date&quot;&nbsp;&nbsp;&nbsp; indexed=&quot;true&quot;&nbsp; stored=&quot;true&quot; multiValued=&quot;false&quot;/&gt;<br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;dm_*&quot; type=&quot;date&quot;&nbsp;&nbsp;&nbsp; indexed=&quot;true&quot;&nbsp; stored=&quot;true&quot; multiValued=&quot;true&quot;/&gt;<br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;tds_*&quot; type=&quot;tdate&quot;&nbsp;&nbsp;&nbsp; indexed=&quot;true&quot;&nbsp; stored=&quot;true&quot; multiValued=&quot;false&quot;/&gt;<br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;tdm_*&quot; type=&quot;tdate&quot;&nbsp;&nbsp;&nbsp; indexed=&quot;true&quot;&nbsp; stored=&quot;true&quot; multiValued=&quot;true&quot;/&gt;<br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;bm_*&quot;&nbsp; type=&quot;boolean&quot; indexed=&quot;true&quot;&nbsp; stored=&quot;true&quot; multiValued=&quot;true&quot;/&gt;<br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;bs_*&quot;&nbsp; type=&quot;boolean&quot; indexed=&quot;true&quot;&nbsp; stored=&quot;true&quot; multiValued=&quot;false&quot;/&gt;<br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;fs_*&quot;&nbsp; type=&quot;sfloat&quot;&nbsp; indexed=&quot;true&quot;&nbsp; stored=&quot;true&quot; multiValued=&quot;false&quot;/&gt;<br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;fm_*&quot;&nbsp; type=&quot;sfloat&quot;&nbsp; indexed=&quot;true&quot;&nbsp; stored=&quot;true&quot; multiValued=&quot;true&quot;/&gt;<br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;ps_*&quot;&nbsp; type=&quot;sdouble&quot; indexed=&quot;true&quot;&nbsp; stored=&quot;true&quot; multiValued=&quot;false&quot;/&gt;<br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;pm_*&quot;&nbsp; type=&quot;sdouble&quot; indexed=&quot;true&quot;&nbsp; stored=&quot;true&quot; multiValued=&quot;true&quot;/&gt;<br />
        <br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;tis_*&quot;&nbsp; type=&quot;tint&quot;&nbsp; indexed=&quot;true&quot;&nbsp; stored=&quot;true&quot; multiValued=&quot;false&quot;/&gt;<br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;tim_*&quot;&nbsp; type=&quot;tint&quot;&nbsp; indexed=&quot;true&quot;&nbsp; stored=&quot;true&quot; multiValued=&quot;true&quot;/&gt;<br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;tls_*&quot;&nbsp; type=&quot;tlong&quot; indexed=&quot;true&quot;&nbsp; stored=&quot;true&quot; multiValued=&quot;false&quot;/&gt;<br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;tlm_*&quot;&nbsp; type=&quot;tlong&quot; indexed=&quot;true&quot;&nbsp; stored=&quot;true&quot; multiValued=&quot;true&quot;/&gt;<br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;tfs_*&quot;&nbsp; type=&quot;tfloat&quot;&nbsp; indexed=&quot;true&quot;&nbsp; stored=&quot;true&quot; multiValued=&quot;false&quot;/&gt;<br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;tfm_*&quot;&nbsp; type=&quot;tfloat&quot;&nbsp; indexed=&quot;true&quot;&nbsp; stored=&quot;true&quot; multiValued=&quot;true&quot;/&gt;<br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;tps_*&quot;&nbsp; type=&quot;tdouble&quot; indexed=&quot;true&quot;&nbsp; stored=&quot;true&quot; multiValued=&quot;false&quot;/&gt;<br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;tpm_*&quot;&nbsp; type=&quot;tdouble&quot; indexed=&quot;true&quot;&nbsp; stored=&quot;true&quot; multiValued=&quot;true&quot;/&gt;<br />
        &nbsp;&nbsp; &lt;!-- Sortable version of the dynamic string field --&gt;<br />
        &nbsp;&nbsp; &lt;dynamicField name=&quot;sort_ss_*&quot; type=&quot;sortString&quot; indexed=&quot;true&quot; stored=&quot;false&quot;/&gt;<br />
        &nbsp;&nbsp; &lt;copyField source=&quot;ss_*&quot; dest=&quot;sort_ss_*&quot;/&gt;

In this case, the 'tint' field type is most appropriate for this data.  For more information on naming fields you can read the schema.xml document, or watch the video from the Drupalcon session (Peter talks about dynamic fields starting at 15:50 into the video).

Once this has been saved, you will need to re-index the content at admin/settings/apachesolr/index.  You can then go to admin/reports/apachesolr and verify that your field has been indexed.
Telling Solr that the field is sortable

Now that the data has been added to the index, we need to tell Solr that the field is sortable.  To do this, we use another hook, hook_apachesolr_prepare_query().  This hook is run after the query has been generated by Solr, and it allows you to make any modifications before it is run.

function mymodule_apachesolr_prepare_query(&amp;$query, &amp;$params) {<br />
        &nbsp; $query-&gt;set_available_sort(&#39;tis_hit_count&#39;, array(<br />
        &nbsp;&nbsp;&nbsp; &#39;title&#39; =&gt; t(&#39;Number of Views&#39;),<br />
        &nbsp;&nbsp;&nbsp; &#39;default&#39; =&gt; &#39;asc&#39;,<br />
        &nbsp; ));<br />
        <br />
        }

As you can see in the code above, the $query object is passed by reference, and we use the set_available_sort method to add this as a sort field that will be displayed in the Apache Solr Sorting: Core block.  The first parameter is the field name that was defined in hook_apachesolr_update_index(), and the second is an array that contains the string that will be displayed in the Sorting block, and the type of sort (ascending or descending).  In addition, if you do not want to use any of the default sorts, they can be removed at the same time with the remove_available_sort method. passing the field name:

$query->remove_available_sort('solr_field_name');

And voila!  You should now have a Number of Views link in your Sort block.

One additional thing to note is that there are actually two different hooks for modifying the $query object: hook_apachesolr_prepare_query and hook_apachesolr_modify_query.  The one you want to use is determined by whether or not you want the user to see the change.  Anything modified in prepare_query will be visible to your users, and anything modified in modify_query will not be visible to your users (a more detailed explanation is given by James McKinney in the DCSF session video from 37:20-39:15).  In this case, since we want the change to be visible to our users, we use hook_apachesolr_prepare_query.

There are many more customizations that can be done in Solr with the available hooks.  In subsequent posts, I will show how to add a field so that it is displayed with the search results, and a more complicated use case of creating a custom search path that automatically applies a filter to the results.