London Dev Meetup Rescheduled! Due to unavoidable reasons, the event has been moved to 21st May. Speakers remain the same—any changes will be communicated. Seats are limited—register here to secure your spot!

Dan Matthews
Feb 6, 2017
  2813
(1 votes)

Moving Commerce content in Vulcan

I’ve just released a minor update of Vulcan that addresses two quite significant issues.

  1. Reindexing commerce content if a product/variant is moved between categories or, more to the point, the categories change by being modified, added to or removed.
  2. Indexing all the categories of a product/variant if it belongs to multiple, rather than just the first one.

Note this has also introduced a breaking change if you created custom IVulcanIndexingModifier classes.

The first ‘bug’ occurred because although we were listening to the move of content on IContentEvents and updating the index appropriately, moving commerce content doesn’t actually fire a move event of the content itself on IContentEvents. This is correct as, technically, it’s not being moved. It’s simply changing the relations, and we weren’t picking that event up. To replicate the issue, cut-paste a variant/product to a different category and you’ll see the ‘ancestors’ in ElasticSearch don’t change for an item. I’ve updated the Vulcan Commerce package to listen for these relation changes and index appropriately.

The second ‘bug’ occurred because of a limitation of the GetAncestors extension API call for IContentLoader. It only understands one ‘parent’ but with Commerce content you can have multiple ‘parents’ as it can belong to many categories. I’ve had to rewrite a commerce-specific version of it to work nicely with variants/products. This implementation can be found in the Vulcan Commerce library codebase inside VulcanCommerceIndexingModifier for the curious. To replicate the issue, add another category to a variant/product and you’ll see the ‘ancestors’ in ElasticSearch don’t change for an item. In fixing this, I’ve taken the opportunity to create the ability for customising the ‘ancestors’ that are picked up when an item is indexed. The IVulcanIndexingModifier interface now has a GetAncestors method. In your custom indexer classes you can leave it throwing a not implemented exception, that’s OK. However, the OOTB CMS and Commerce indexers will now return ancestors as appropriate which will get indexed with the item. (This is the breaking change as your custom classes WILL need to implement the method, even if it just throws a not implemented exception.)

Side note: in the bugged version, manually firing a re-index is a workaround for issue (1) but it still only picks up the first category that something belongs to as it won’t resolve issue (2). If your products/variants only ever belong to one category then manual reindexing would be a workaround until you can update to the latest Vulcan packages.

DISCLAIMER: This project is in no way connected with or endorsed by Episerver. It is being created under the auspices of a South African company and is entirely separate to what I do as an Episerver employee.

Feb 06, 2017

Comments

Please login to comment.
Latest blogs
Routing to a page in SaaS CMS

More early findings from using a SaaS CMS instance; setting up Graph queries that works for both visitor pageviews and editor previews.

Johan Kronberg | Apr 14, 2025 |

Developer Meetup - London, 24th April 2025

Next Thursday, 24th April will be Candyspace 's first Optimizely Developer Meetup, and the first one held in London this year! We've have some...

Gavin_M | Apr 14, 2025

Successful Digitalization for SMEs: How Optimizely One can Revolutionize Your Business Processes

"Achieve digital excellence with Optimizely One: Boost efficiency, delight customers, secure growth." In today's digital world, it's crucial for...

Frank Hohmeyer | Apr 11, 2025

Personalized Optimizely CMS Website Search Experiences Azure AI Search & Personalizer

In the last blog, we discussed Integrating the Optimizely CMS website with Azure AI search. Now let’s take a bit more advanced topic to serve...

Naveed Ul-Haq | Apr 10, 2025 |