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.