Skip to main content

You've been toasted!

Contrary to the popular belief, the Sitecore Commerce Experience Accelerator (CXA) is much more than just a set of the commerce-related SXA elements with a reference storefront. Even if your newly created Sitecore Commerce 9 storefront is not going to be SXA-compatible, it makes sense to re-use parts of the CXA features and foundation, as they conveniently encapsulate complexity of the raw Commerce Connect. Since CXA was initially created with the default storefront experience in mind, it still has quite a few quirks that one would not expect to see in a true production-ready framework.

One of the most notorious "features" is the default toaster image. Even if you are using a completely custom catalog, while extending the Sitecore.Commerce.XA.Feature.Catalog feature, product images default to a toaster image. Moreover, if the Commerce Connect chokes while generating catalog templates, and "forgets" to create the Images attribute (the infamous "first product without image" problem of 9.0.1), you would still get toasters. A quick look at the Sitecore.Commerce.XA.Feature.Catalog.Models.CatalogItemRenderingModel reveals why:

protected virtual void SetImages()
{
if (this.Images != null)
return;
this.Images = new List<MediaItem>();
MultilistField field = (MultilistField) this.CatalogItem.Fields["Images"];
if (field != null)
{
foreach (ID targetId in field.TargetIDs)
this.Images.Add((MediaItem) this.CatalogItem.Database.GetItem(targetId));
}
else
this.Images.Add((MediaItem) this.CatalogItem.Database.GetItem(ID.Parse("{8B33A7DC-8680-46AC-A199-1419AF50C330}")));
}
Right, it has a hard-coded image item ID. This is true for the latest Sitecore Commerce 9 Update 3 with SXA 1.8 based features. If your storefront uses Sitecore.Commerce.XA.Feature.Catalog don't forget to override the default image, or you'll get toasted!

Comments

Popular posts from this blog

SharePoint 2013 and "search scopes"

While SharePoint 2013 introduced some undeniably handy features in the content discovery department, some of the old functionality has changed so much that you'll have to forget many of the design tricks that worked in 2007 and 2010.  One of such pain points is deprecating search scopes in SharePoint 2013. The requirement Let's start with a trivial situation. You have a requirement that states: "A user should be able to perform different types of search from any page/sub site on the portal by selecting a type of search and specifying keyword(s)". This would be considered an out-of-box functionality in 2007/2010: you just enable search scopes dropdown (considering the search box control is already in the master page), and define scopes. Piece of cake! Well, not so much in 2013.   The problem The thing is - there's no search scopes in SharePoint 2013. OK, to be exact - there's no user-definable search scopes, as we still have a couple of built-in ...

Navigation Settings in SharePoint 2013 Site Definitions

Who likes creating SharePoint site definitions from scratch? Well, it's not my favorite part of the SharePoint development either. An initially good idea of setting up your whole site through an XML file, received implementation and support far from being perfect. That quickly lead developers to look for alternative ways of defining and provisioning sites, primarily through the SharePoint API. A simple ONET.XML with beefy code-packed features became de-facto standard. What was supposed to be a template became compiled code. I was hoping SharePoint 2013 would at least attempt to do something about it… Tasked with creating a few publishing portal site definitions, I was unpleasantly surprised to find out that any attempt to use my new site definition to provision a site collection root results in both Global and Current Navigation switched to "Managed Navigation" mode, while I needed it to stay in the good old "Structural Navigation" one. This mode is new to Sh...

Catalog versioning in Sitecore Commerce Engine

Since the release of Sitecore Experience Commerce 9.0 Update-2 entity versioning is enabled by default for all catalog-related commerce entities: Catalogs , Categories and SellableItems . While certainly being a desirable feature, versioning can have a negative effect in certain use cases. Here are a couple of examples: One of the clients decided to use the BizFx business tools as a Product Information Management system. While one can argue on effectiveness of such decision, the real pain came up after the 9.0.2 upgrade when a quick 2-step process of updating the product description suddenly became an unintuitive and clumsy struggle through a dozen of steps. The client absolutely hated that experience and did not really care about versioning. Another client was using an external PIM that we were integrating with by synchronizing the deltas with SXC Catalog system. In 9.0.2 that resulted in creating a new version for every entity update. Not only these versions were useless (sin...