SXA Search with Multiple Checklist Filters

One of the requirements of our Sitecore site is to improve the searchability of our pages. Before the refresh of the site, Search was only linear, meaning users can only select one filter value on a dropdown. However, in the new mockup that I designed, proposed and eventually got approved, a user can now search with multiple checklist filters.

Suppose we are going to build a tech-related website that has a feature to search for a keyword and select multiple filters say, Content Type, Topic and Threats and that returns filtered results. It also comes with a “Load more” button, a results count with some filter pills to deselect a specific filter/s. It would look something like this:

Search with Multiple Filters
Search with Multiple Filters
Filtered Search Filtered

Search Architecture

In order to achieve that mock up and functionality, we will utilize SXA out-of-the-box (OOTB) components. SXA framework really did a great job at organizing components, datasources and settings that make up a rather complex feature such as this simpler. Below is a map I created on how the elements of the Search are interconnected:

SXA Search Architecture
SXA Search Architecture

How It Works:

1. Site Search Components

To build this kind of Site Search, the five SXA OOTB components (those with uppercased titles) are:

  • Search Box
  • Filter (Checklist)
  • Results Count
  • Search Results
  • Load More

Place all these components in a page. Remember to bind them all together by a single unique identifier called a signature. Ensure that the properties of each component will have the same signature.

Edit Component Properties

2. Search Box

Sitecore provides more information on how to configure a Search Box here. Under Search Box component properties > datasource, you can set the text values related to display. Auto-suggest is enabled by default which means that when the user types in 5 characters, a Search Results dropdown would pop-up, adding to a better user experience.

3. Search Scope

Both Search Box and Search Results require a Scope to be set in their components properties. These scopes are found under /sitecore/content/<Tenant>/<Site>/Settings/Scopes/ where you can create one to basically define the limits of the search in the site. For example, you can specify there an item path for which sitecore would start searching at and/or specify which kinds of items via templates are allowed to appear in the Search Results.

4. Search Results

Datasource for this component is only used for displaying UI labels, but other component properties such as Page Size, Default Sort Order and Rendering Variants are useful too. If you want a 4-column search results, create a Rendering Variant under /sitecore/content/<Tenant>/<Site>/Presentation/Rendering Variants/Search Results to control the styling.

5. Page Template

Items that appear in the Search Result are based on which templates are selected in the Build Query of the set Search Scope. In our case, these are the templates in our site that we wanted visitors to be able to search for: Blog Post, Resource Document, Site Page, Announcement, etc. The key strategy here is to make sure that all these templates have fields that will be used for tagging. This is achieved by creating a partial template called Taxonomy, which means a system of classification, that will be inherited by the mentioned templates. The following fields should have Tag Treelist as their field type:

  • ContentTypes
  • Topics
  • Threats
Taxonomy Partial Template

6. Tags

All these fields should point to a Tags list datasource defined under /sitecore/content/<Tenant>/<Site>/Data/Tags. Relevant pages in the site would need to have values selected for Taxonomy. Powershell scripting is a great way to automate the population of these pages.

Example of a Page with selected Tags in the Taxonomy Section

7. Filter (Checklist)

To set up the Filter Checklist, first tick in the component properties the property called Multiple Selection, because we want users to be able to filter out multiple tickboxes in each checklist. The other important thing to set up correctly is the Datasource found or can be created under /sitecore/content/<Tenant>/<Site>/Data/Search/Checklist Filter. A Datasource for the Filter (Checklist) for Content Type should point to the Facet for Content Type too.

8. Facets

Facets are created under /sitecore/content/<Tenant>/<Site>/Settings/Facets. Create facets each for Content Type, Topics and Threats. The key field here is the Field Name.

Content Type Facet Field Name

The value of this field should be the field name set in the Taxonomy partial template in lowercase. It’s especially important to follow this step because it will be basis for the field to be defined in the Solr Index configuration.

9. Solr Index Configuration

The SXA Solr Search config file called Sitecore.XA.Foundation.Search.Solr.config is found under App_Config/Modules/SXA/z.Foundation.Overrides. Add index fields for the contenttypes, topics and threats and set its returnType to stringCollection.

<indexConfigurations>
	<defaultSolrIndexConfiguration type="Sitecore.ContentSearch.SolrProvider.SolrIndexConfiguration, Sitecore.ContentSearch.SolrProvider" >
		<fieldMap type="Sitecore.ContentSearch.SolrProvider.SolrFieldMap, Sitecore.ContentSearch.SolrProvider">
			<fieldTypes hint="raw:AddFieldByFieldTypeName">
				<fieldType fieldTypeName="tag treelist" returnType="stringCollection"/>
				<fieldType fieldTypeName="multiroot treelist" returnType="stringCollection"/>
			</fieldTypes>
			<fieldNames hint="raw:AddFieldByFieldName">
				<field fieldName="tags" returnType="stringCollection" />
				<field fieldName="contact.tags" returnType="stringCollection" />
				<field fieldName="contenttypes" returnType="stringCollection" />
				<field fieldName="topics" returnType="stringCollection" />
				<field fieldName="threats" returnType="stringCollection" />
			</fieldNames>
		</fieldMap>
		<fieldReaders type="Sitecore.ContentSearch.FieldReaders.FieldReaderMap, Sitecore.ContentSearch">
			<mapFieldByTypeName hint="raw:AddFieldReaderByFieldTypeName">
				<fieldReader fieldTypeName="tag treelist" fieldReaderType="Sitecore.XA.Foundation.Search.FieldReaders.NameLookupListFieldReader, Sitecore.XA.Foundation.Search"/>
				<fieldReader fieldTypeName="multiroot treelist" fieldNameFormat="{0}" fieldReaderType="Sitecore.ContentSearch.FieldReaders.MultiListFieldReader, Sitecore.ContentSearch" />
			</mapFieldByTypeName>
		</fieldReaders>
	</defaultSolrIndexConfiguration>
</indexConfigurations>

After deploying a patch for this in your project, the Sitecore CM instance will restart. When the CMS is ready, open the Control Panel and Populate the Solr Managed Schema. Once that’s done, rebuild your indexes via Index Manager.

Control Panel Indexing Section

After rebuilding the Indexes, follow the steps below to verify if the documents were populated with the newly added index fields:

  1. Access your Solr Admin Panel via url (usually https://localhost:8983/solr)
  2. In the Core Selector, select either the <name>_master_index or <name>_sxa_master_index
  3. Click the Schema. In the field dropdown, search for the index field that has been defined.
  4. Once verified, go to Query and search for the any Page under a specific item path that has contenttypes values.
Content Type Index Field has registered

Solr Query:

_fullpath:{starting item path}/* 
AND _templatename:Page
AND contenttypes_sm:[* TO *]

10. Filter Pills

Since Filter Pills are not inherent to SXA we will create this in the frontend. Here’s the approach:

  • All Search interactions of the Search Box, Search Results or Filter (Checklist) are being controlled via URL query strings. Therefore, we can have full control over the behavior of SXA Search.
SXA Search Query String
  • The default elements of these SXA OOTB components will be hidden, like the Search Box “Search” button and the Search Filter “Filter” button so as to prevent their default Submit behavior.
  • Each tickbox selected in every Filter Checklist will silently register an entry via javascript object to later be assembled for submission.
  • When the user is done with inputting the search term and selecting the checklists’ tickboxes, the user will click on the “Search” custom button to proceed with the search, thus triggering the assembly of the URL and query string based on the javascript object.
  • The page will load with the successful results of the Search. And because we already know the structure of the URL, we can parse the selected tickboxes and create the filter pills on the fly. Every further interaction will be controlled by the frontend.

So, there you go! SXA is awesome. Happy Searching!

Leave a Reply