In the world of a big business you can find a lot of very complicated business rules but sometimes things that seems to be an easy task when it comes to reality are not. A good example of that was one of our client requirement. Basically he wanted to have a promotion that will give users that known a “special code” a gift and a free shipment. Looks like something simple and out of the box. All types of EPiServer Commerce promotions can have a coupon code that will be required for promotion to apply, so I started to create a new promotion. First of all I used “Order: Build your own discount” promotion and configured it like on following image.
Above promotion give user that entered “XMASGIFT” code a free gift. To add free shipping we need to add another promotion of type shipping. The easiest way to do it will be to use “Shipping: Build your own discount” promotion, then set name, coupon code and reward to “get % off shippment”. And this is the point when the problems starts. EPiServer Commerce won’t allow us to save second promotion with same coupon code, and it also won’t allow to add shipment discount to order promotion. What else we can do? It looks like that without modifying commerce files we won’t meet our criteria.
Fortunately, as a criteria for order promotion we can also use OrderForm metafields, so I decided to add a new metafield called “Coupon code”. When user saves coupon code it is also saved against that metafield. Then configured shipment promotion to use “Coupon code” metafield as a criteria and left standard “Coupon code” field empty. Whole configuration is visible on following image:
There is also another option, if our gift is an item that is non sellable, so user cannot add it itself to the basket, we can create shipment promotion based of that item added to the basket. We can do it because shipment promotions are always calculated after order promotions, but the first approach seems to be more universal and bulletproof.
Sometimes, especially when you create your custom promotions, you may like your promotions to meet some criterias. In our latest project due to a nature of our custom promotions we needed to made it “inclusive only”, so if user put in his cart products that are eligible for two configured promotions both should be applied. This is the default option when new promotion is created but editor has the possibility to change that default behaviour by using “Combination with other promotions” setting. To reduce number of mistakes made by editors we decided to disable/hide that field. Fortunately EPiServer Commerce Framework is very flexible and by following few easy steps described below you can hide that field from editors.
First of all we need to find out which template is used to generate add/edit promotion form. As we know that Promotions are part of Marketing application we can start searching in Marketing folder. In Config\Views folder we can find Promotion-Edit.xml config file and then a reference to ascx file used to generate promotion edit form (“marketing/tabs/PromotionEditTab.ascx”). To change default behaviour we either need to edit that file or create a new custom ascx and update reference to promotions form in Promotion-Edit.xml. In my case I needed to change “only” a codebehind class so I decided to backup existing PromotionEditTab.ascx and then edit it to replace control directive to:
<%@ Control Language="C#" AutoEventWireup="true"
My customized PromotionEditTab class is defined as:
public class PromotionEditTab : Mediachase.Commerce.Manager.Marketing.Tabs.PromotionEditTab
private readonly string _hideExclusivityTypeFor =
protected override void OnPreRender(EventArgs e)
ExclusivityType.Visible = false;
protected override void OnLoad(EventArgs e)
ExclusivityType.SelectedIndex = 0;
All changes are limited to override OnPreRender to hide ExclusivityType control from editors and on OnLoad to set default value for save.
It is also worth to mention that above steps can be used to override default behaviour of other forms used by EPiServer Commerce, but remember that changes like that might break out of the box functionality so need to be properly tested!
By default when rendering ContentAreas EPiServer 7 adds a number of empty (without any style or class defined) divs – one outlining each content area item and another one for ContentArea itself. Although it may be problematic when rendering page for visitors (not semantic and don’t allow you to optimize css selectors) it’s neccessary for on page edit. There are both cons and pros for rendering that divs in default mode but EPiServer developers decided that more beneficial for developers will be to render those divs also for visitors1. If you are one of those who thinks totally different I will show you how to force EPiServer to add that divs ONLY in edit mode, but please be aware that this is a global change and you might rather like to do it separatelly for each conent area that needs it.
I started to check what’s wrong. First of all I added IP address of the first web server used for a proxy source to my local host file. After checking again it all worked good, so I realized that the problem is either with our load balancer (nginx) or IIS configuration.
If you ever found that issue, use following cmd command to fix it:
appcmd.exe set config -section:system.webServer/httpCompression /noCompressionForProxies:false /commit:apphost
appcmd.exe set config -section:system.webServer/httpCompression /noCompressionForHttp10:false /commit:apphost
From time to time there is a need to translate whole XML document into a POCO class. Of course you can use XDocument or XmlDocument to map class property by property, but there is also a great tool called xsd.exe that will help you to serialize and de-serialize XML documents into classes. To generate a POCO class you will only need schema definition of document. This article will show how you can create XSD from XML file and then use it to generate entity classes.