Migrating Aurora to Elasticsearch

Elasticsearch is a full-text search engine geared toward flexible and highly scalable indexing of full text content. This service is fully supported by Aurora and allows the search features of Aurora to operate.

This article details the changes you should be aware of when migrating from other search platforms (e.g. Sphinx) to Elasticsearch.

Suggest Edits

🚧
This article is only intended for those moving an existing instance of Aurora over to Elasticsearch. If you have never had Aurora using any other search engine, then you probably don't need to read this article.
You should only need to implement these changes once, either after or during a migration to Elasticsearch.

Introduction

This article details the changes you should be aware of when migrating from other search platforms (e.g. Sphinx) to Elasticsearch. You will find a section for each template that is impacted by the migration, containing all the changes that you should be aware of to ensure your Front-end continues to work as expected.

Front-end Templates

Product Listing/Category Pages

Filter/Sidebar Navigation

Affected Template: example.com/_includes/navigation_dynamic_new.tpl.html

The 'clear filter' button

On the product listing pages, in the sidebar filters, you have a button that will enable the customer to clear a filter that has values set. See the example screenshot from Aurora Demo below showing this button as an "X".

This button was previously displayed based on the following code:

{if $filter_status != 'selected'}

This was checking if the filter
a) had values selected, and
b) was not the currently 'active filter'.
If both of these things were true, then the filter status would be "selected" and so the 'clear filter' button would be shown.

With the addition of Alphabetical URLs that has come with Elasticsearch, the concept of an 'active filter' no longer exists and so this no longer works.

To account for this, you should change this code to the following under Smarty 3.

This code now simply checks if the filter has been used in the current request and shows the 'clear filter' button if so.

Smarty 2

Change...

{foreach from=$showFilters item="filter_status" key="filter_clean_name"}

To...

{foreach from=$showFilters item="filter_status" key="filter_clean_name"}
  {assign var="current_meta_info" value=$filter_meta_info[$filter_clean_name]}

And change...

{if $filter_status != 'selected'}

To...

{if !isset($header_filters[$current_meta_info.abbr])}

Smarty 3

Change...

{if $filter_status != 'selected'}

To...

{if !isset($header_filters[$filter_meta_info[$filter_clean_name].abbr])}

The '$showFilters' array

The following is not strictly speaking a new behaviour, however due to changes in the way this data is generated, it has come to light that some Clients may need to apply the following correction to their Template to avoid displaying 'empty' filter blocks:

Please find the following loop:

{foreach from=$showFilters item="filter_status" key="filter_clean_name"}

    ...

{/foreach}

And add within this loop the following condition:

{foreach from=$showFilters item="filter_status" key="filter_clean_name"}
  {if $filter_status == 'show'}

    ...

  {/if}
{/foreach}

This prevents 'empty' filter blocks being displayed where currently some Client Templates are displaying them.

Removing current_filter_nav

Your old AJAX calls to /ajax/Ajax_Products/search main contain some legacy code that is no longer needed and will prevent the Aurora cache being as effective as possible. An example of this can be seen here

ajax/Ajax_Products/search?page_number=1&order_by=11&current_nav_item=wco&path=mens%2Fclothing

This could be changed to

ajax/Ajax_Products/search?page_number=1&order_by=11&path=mens%2Fclothing

Price Filters/Sliders

This next section refers to the use of any freeform values in URL's such as the following link, which filters the "Clothes" category by products priced from £11 to £42:

https://demo.auroracommerce.com/clothes/p:11-42/

Previously, the section "p:11-42" was totally freeform for all categories, regardless of your configuration in Aurora. This meant that the following URL's would ALL return results:

This results in a very significant number of indexable URLs full of products that you may not actually want to be made available.

This has now changed and after the migration to ElasticSearch, you will find that this freeform format is only supported where you explicitly configure the "p" (Price) filter to be a slider in the Aurora Back-end, under Merchandising > Facets, as documented under Editing Filters and Saving Custom Filters

👍
You will still be able to use the ranges defined in your Price Bands

🚧
This behaviour is 'new', but was previously something that the Price filter was exempt from, i.e. all other filters can be sliders, but were only treated as such if they were configured to be so, as described above. However the Price slider was an exception that was always so.
The difference is that the Price filter must now be configured to be used as a slider to enable the freeform range values, just like any other filter.

If you require the prices slider to remain a totally freeform range filter, then please see the User Guide above to help you configure this for your Store.

❗️
It's important to note, that this refers to being able to enter any values into the "p:X-Y" part of the URL instead of only the pre-defined selection of price range defined in your Price Bands.

Settings and Configuration

You should not need to make any changes to your Aurora configuration in order to take full advantage of the new ES integration, as this will all be dealt for you during the initial migration.

This being said, we have included a few notes below on a some topics that you may wish to be aware of as a result of the migration.

Search Settings

Replacements

Replacements used to be applied to your search terms by Aurora when performing searches of products on the Product Listing/Category pages, e.g. replace "kids" with "children".

Replacements have been removed as part of this development as they have been deemed redundant in the face of ES's synonym support and so all existing replacements will automatically be copied over into your synonyms to ensure that the behaviour of your search continues to work as expected (e.g. returning results for "children" when searching for "kids" because it has a synonym to "children").

Updated over 2 years ago