While we were working on one of our upcoming projects, a new website for Stichting tegen Kanker, we had to integrate the Apache Solr module. We needed Solr for its faceted search capabilities. In combination with the FacetAPI module, which allows you to easily configure a block or a pane with facet links, we created a page displaying search results containing contact type content and a facets block on the left hand side to narrow down those results.

One of the struggles with FacetAPI are the URLs of the individual facets. While Drupal turns the ugly GET 'q' parameter into a clean URLs, FacetAPI just concatenates any extra query parameters which leads to Real Ugly Paths. The FacetAPI Pretty Paths module tries to change that by rewriting those into human friendly URLs.

Our challenge involved altering the paths generated by the facets, but with a slight twist.

Due to the projects architecture, we were forced to replace the full view mode of a node of the bundle type "contact" with a single search result based on the nid of the visited node. This was a cheap way to avoid duplicating functionality and wasting precious time. We used the CTools custom page manager to take over the node/% page and added a variant which is triggered by a selection rule based on the bundle type. The variant itself doesn't use the panels renderer but redirects the visitor to the Solr page passing the nid as an extra argument with the URL. This resulted in a path like this: /contacts?contact=1234.

With this snippet, the contact query parameter is passed to Solr which yields the exact result we need.

1. /**
2.  * Implements hook_apachesolr_query_alter().
3.  */
4. function myproject_apachesolr_query_alter($query) {
5. if (!empty($_GET['contact'])) {
6. $query->addFilter('entity_id', $_GET['contact']);
7. }
8. }

The result page with our single search result still contains facets in a sidebar. Moreover, the URLs of those facets looked like this: /contacts?contact=1234&f[0]=im_field_myfield..... Now we faced a new problem. The ?contact=1234 part was conflicting with the rest of the search query. This resulted in an empty result page, whenever our single search result, node 1234, didn't match with the rest of the search query! So, we had to alter the paths of the individual facets, to make them look like this: /contacts?f[0]=im_field_myfield.

This is how I approached the problem.

If you look carefully in the API documentation, you won't find any hooks that allow you to directly alter the URLs of the facets. Gutting the FacetAPI module is quite daunting. I started looking for undocumented hooks, but quickly abandoned that approach. Then, I realized that FacetAPI Pretty Paths actually does what we wanted: alter the paths of the facets to make them look, well, pretty! I just had to figure out how it worked and emulate its behaviour in our own module.

Turns out that most of the facet generating functionality is contained in a set of adaptable, loosely coupled, extensible classes registered as CTools plugin handlers. Great! This means that I just had to find the relevant class and override those methods with our custom logic while extending.

Facet URLs are generated by classes extending the abstract FacetapiUrlProcessor class. The FacetapiUrlProcessorStandard extends and implements the base class and already does all of the heavy lifting, so I decided to take it from there. I just had to create a new class, implement the right methods and register it as a plugin. In the folder of my custom module, I created a new folder plugins/facetapi containing a new file called url_processor_myproject.inc. This is my class:

1. <?php
2.  
3. /**
4.  * @file
5.  * A custom URL processor for cancer.
6.  */
7.  
8. /**
9.  * Extension of FacetapiUrlProcessor.
10.  */
11. class FacetapiUrlProcessorMyProject extends FacetapiUrlProcessorStandard {
12.  
13. /**
14.   * Overrides FacetapiUrlProcessorStandard::normalizeParams().
15.   *
16.   * Strips the "q" and "page" variables from the params array.
17.   * Custom: Strips the 'contact' variable from the params array too
18.   */
19. public function normalizeParams(array $params, $filter_key = 'f') {
20. return drupal_get_query_parameters($params, array('q', 'page', 'contact'));
21. }
22.  
23. }

I registered my new URL Processor by implementing hook_facetapi_url_processors in the myproject.module file.

1. /**
2.  * Implements hook_facetapi_url_processors().
3.  */
4. function myproject_facetapi_url_processors() {
5. return array(
6. 'myproject' => array(
7. 'handler' => array(
8. 'label' => t('MyProject'),
9. 'class' => 'FacetapiUrlProcessorMyProject',
10. ),
11. ),
12. );
13. }

I also included the .inc file in the myproject.info file:

1. files[] = plugins/facetapi/url_processor_myproject.inc

Now I had a new registered URL Processor handler. But I still needed to hook it up with the correct Solr searcher on which the FacetAPI relies to generate facets. hook_facetapi_searcher_info_alter allows you to override the searcher definition and tell the searcher to use your new custom URL processor rather than the standard URL processor. This is the implementation in myproject.module:

1. /**
2.  * Implements hook_facetapi_search_info().
3.  */
4. function myproject_facetapi_searcher_info_alter(array &$searcher_info) {
5. foreach ($searcher_info as &$info) {
6. $info['url processor'] = 'myproject';
7. }
8. }

After clearing the cache, the correct path was generated per facet. Great! Of course, the paths still don't look pretty and contain those way too visible and way too ugly query parameters. We could enable the FacetAPI Pretty Path module, but by implementing our own URL processor, FacetAPI Pretty Paths will cause a conflict since the searcher uses either one or the other class. Not both. One way to solve this problem would be to extend the FacetapiUrlProcessorPrettyPaths class, since it is derived from the same FacetapiUrlProcessorStandard base class, and override its normalizeParams() method.

But that's another story.