Better Searching in Drupal 7 (and the roadblocks along the way)

Published: 12/9/2016

As many do, I started out using the core search module for my site, but it was lacking the features that I thought made a powerful and useful search tool. I installed Search API (opens in new tab) and used it in conjunction with the Fuzzy Search module, which was sufficient for a while, but eventually I wanted more: autocomplete, highlighted search term results, and facets. Also, at the time of this post, Fuzzy search appeared to be an abandoned project, without any updates in nearly two years.

I found a great article that summarized the available search options for D7 and helped me to choose the right solution: https://swsblog.stanford.edu/blog/better-search-drupal (opens in new tab)

I decided on a combination of Search API – which I was already using – and the Search API Database Search (opens in new tab) module. Along with Search API Autocomplete (opens in new tab) and Facet API (opens in new tab) and their module dependencies, I had exactly what I needed.

Although I was already familiar with the Search API setup, this article (opens in new tab) helped with the integration of the Search API Database Search module and setting up the search results view. I won’t duplicate its content here, but rather I’ll explain some of the challenges I had completing this setup and beyond.

Some of the necessary configuration was already in place, because Search API was installed and working. However, I ran into a snag with the search results view when an option that should have been there, well… it just wasn’t there.

When creating the search results view, I should have been able to choose the name of my search index in the Show setting. In my case, “Default Node Index” was my index, but that option wasn’t available. I found another article that directed me to clear the cache in admin/config/development/performance, and once I did that, my index was available to select. This stumped me for quite a while, and the resolution was somewhat illusive. In fact, I later tried to locate the article that provided the cache-clearing suggestion, and I couldn’t find it. So, clear your cache!

Since one of my requirements was an autocomplete in the search box, I installed the Search API Autocomplete module. I ran into two issues with this configuration. One – out of the box, it didn’t work. Even after configuring the Autocomplete tab settings of my search index, I could type all day long in my search box, but no suggestions appeared.

It seems non-intuitive to me, but the Search API Autocomplete module has a permission setting in admin/people/permissions that allows you to specify which roles can use autocomplete. Once I granted it to Anonymous and Authenticated users, it worked for everyone. In fairness to the developer, the README file does tell you about the permission setting. But there’s an order in which you must configure this module’s settings and permissions. The permission setting doesn’t even appear until after you configure the Autocomplete tab of your index here: admin/config/search/search_api/index/{index name here}/autocomplete. Once you’ve enabled your server and saved your settings, the permission becomes available for you to set.

The second issue with Search API Autocomplete was the default styling of the drop-down suggestions box. The background of the box was transparent, which made suggestions hard to read when the drop-down displayed over top of things like images and other text. The suggestion hover color was set to white. On a white page background, this caused the term to be invisible when moused-over. What made this more challenging was my struggle to isolate the right divs, spans, and classes using my standard browser tools. I typically use Chrome’s Developer tools to select/inspect a page element to figure out where it’s being styled, and then override, if needed. But there was no easy way to select the drop-down. The drop-down – and the suggestions themselves – only appeared in the HTML when I was actively typing in the search box. When I clicked my Chrome Select tool to select the drop-down, it disappeared. After choosing the Select tool, I could no longer type in the search box to make the drop-down appear again. It was a vicious loop. Eventually, I found that I could choose my Select tool and then TAB to the search box, and I could then identify the elements that needed styling. Here is the CSS I added to my search suggestions:

#autocomplete {position: absolute; background-color:white; color:#746c6c; box-shadow: 3px 4px 13px rgba(0, 0, 0, 0.28); -moz-box-shadow: 3px 4px 13px rgba(0, 0, 0, 0.28); -webkit-box-shadow: 3px 4px 13px rgba(0, 0, 0, 0.28);}

.search-api-autocomplete-suggestion:hover {background-color:#00678f; cursor:pointer;}

With autocomplete working, I focused on the search results themselves. I’d created the search results view quickly and had only added the fields node title and meta description. This was OK, except that sometimes the search term existed in the node body but not the title or description. This made the search results seem less relevant. What I wanted to do was show the section of text where the term existed, without (obviously) displaying the entire node body. This and other configuration options were available on the Filters tab of the index config: admin/config/search/search_api/index/{index name here}/workflow. Under Processor settings, I selected the option to Create an excerpt and set a length of 256 characters. Then in my search results view, I removed the meta description field and added the Search Excerpt field.

Next I wanted my search term to be highlighted in my results page. Also on the Filters tab, under Processors settings, I checked the option for Highlighting. I tested my search, and everything worked great. However, I didn’t like the way it looked. Back on Filter Tab/Processor settings, I customized the Highlighting prefix and suffix. The default was and . I wanted to take advantage of a class in my custom CSS file, so I adjusted it to and and re-indexed. While I was testing again, I noticed that the highlighting worked in my excerpt but not in my title. I checked the Filters again, and I had accidentally excluded the Title field from the excerpt (sometimes I get a little click-happy). For some sites, excluding certain fields from highlighting might be desirable, so it’s worth noting that you can choose – or not choose – from any of the fields that you index. After allowing the Title field, my highlighting worked as expected.

But what didn’t seem to work was relevance. Regardless of the search term, the results page seemed to display the things I didn’t care about first. I found this article (opens in new tab) that explains how relevance/ranking works, and it helped me identify my mistake. When I created the search results view, it seemed obvious that I should sort the search relevance in ASCENDING order. But since relevance is based on counting the number of times a term appears in the indexed fields, I needed to sort by DESCENDING instead, so that the highest counts appeared first.

With those items working as needed, there was one more feature I wanted, and that was Facets. Fortunately, setting up Facets was the easiest part of this configuration. Search API came boxed with a Search Facets module; it just required the Facets API module. Enabling both of these modules allowed me to access the settings on the Facets tab of index config admin/config/search/search_api/index/{index name here}/facets. There are multiple facets you can use to categorize your search results. For me, categorizing by Content Type was what I needed, and I stuck with the default settings for the facet.

This automatically created a block for Facet API which I configured to display on my search page, and it worked perfectly without any other configuration.

After a few stylistic tweaks to my search results view, I was done. And although it was a bit of work to set up, I’m very pleased with the combination of Search API, Search API Database, Search API Autocomplete, and Search Facets for my Drupal 7 website searching.