SaaS CMS has officially launched! Learn more now.

Dan Matthews
Feb 6, 2017
  2579
(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
Optimizely SaaS CMS Concepts and Terminologies

Whether you're a new user of Optimizely CMS or a veteran who have been through the evolution of it, the SaaS CMS is bringing some new concepts and...

Patrick Lam | Jul 15, 2024

How to have a link plugin with extra link id attribute in TinyMce

Introduce Optimizely CMS Editing is using TinyMce for editing rich-text content. We need to use this control a lot in CMS site for kind of WYSWYG...

Binh Nguyen Thi | Jul 13, 2024

Create your first demo site with Optimizely SaaS/Visual Builder

Hello everyone, We are very excited about the launch of our SaaS CMS and the new Visual Builder that comes with it. Since it is the first time you'...

Patrick Lam | Jul 11, 2024

Integrate a CMP workflow step with CMS

As you might know Optimizely has an integration where you can create and edit pages in the CMS directly from the CMP. One of the benefits of this i...

Marcus Hoffmann | Jul 10, 2024