Improving Episerver Search With Vulcan 2.0

A few weeks ago, I was tasked with finding a search replacement for our projects, since the default Episerver Lucene search can be difficult to set up and troubleshoot, and despite its great features, our client adoption for Episerver Find has been low. As luck would have it, I came across Dan Matthews’ Vulcan project, which already utilized Elasticsearch, so instead of starting from scratch, I had a solid base to start from.

After a fork of the project and several merge requests, Dan graciously gave me contribute access to the main project, and I’ve put together some highlights of Vulcan’s new capabilities.

New Features

UI Search providers are now included, so Vulcan can search for pages, blocks, media files, and commerce content, displaying and linking to the edit view of the items.

VulcanSearchableAttribute is available to index custom string contents for model properties, and can also be used to index ContentArea properties.

Permissions are now indexed with the content, and the IVulcanClient.SearchContent<T> method now takes an IPrinciple to filter by permissions. Passing a null instead removes the permission filter. Also, the search function now takes a IEnumerable<Type> as a type filter for fine tuning searches.

Search scope can now have many content references using an IEnumerable<ContentReference> instead of the initial single reference. This is a breaking change from the 1.x version.

MediaData contents can now be indexed with the additional NuGet package ‘TcbInternetSolutions.Vulcan.AttachmentIndexer’. By default, this package indexes files by an app setting key ‘VulcanIndexAttachmentFileExtensions’ with the default value of ‘pdf,doc,docx,xls,xlsx,ppt,pptx,txt,rtf’. The default implementation that determines if a file can be indexed can be swapped out in structure map with the ‘IVulcanAttachmentInspector’ interface.

Elastic Search connection settings can now also be swapped out using the ‘IVulcanConnectionSettings’ interface. The default implementation uses the following app setting keys:

• VulcanUrl – elastic search server URL.
• VulcanIndex – name of the Elasticsearch index.
• VulcanUsername – if the Elasticsearch client requires basic HTTP authentication.
• VulcanPassword – if the Elasticsearch client requires basic HTTP authentication.
• VulcanEnableHttpCompression – Compresses JSON requests with Elasticsearch server; false by default.

IVulcanClient now has a search extension to provide a quick site search for website front-ends. Below is a quick example of how to search text from analyzed string fields:

int maxResults = 0;
int currentPage = 0;
var searchText = context.Request["q"] ?? "";
int.TryParse(context.Request["page"], out currentPage);
int.TryParse(context.Request["pageSize"], out maxResults);
var client = ServiceLocator.Current.GetInstance().GetClient();
var siteHits = client.GetSearchHits(searchText, currentPage, maxResults);

IVulcanPocoIndexer allows for batch indexing of custom objects, which get stored in the invariant index. The indexer needs to be able to get a total count of items and a list of items, given a page and page size. This allows for objects to come from a variety of sources, such as SQL or web service calls.

Additional sample code can be found on my GitHub page.

Looking Ahead

Vulcan has come a long way with these updates, but there is still plenty of room for improvements, such as running indexing jobs in parallel, batch indexing CMS content, caching search requests, and content event enhancements to index any referenced content that has any VulcanSearchableAttribute properties such as blocks used in pages. Any feedback from the community will be greatly appreciated.

If you have any questions for us about how to implement Vulcan, or if you want to share some tips of your own, please feel free to leave a comment below. Happy searching!