Blog posts by Maris Krivtezs

Blog posts by Maris Krivtezs2021-12-23T00:00:00.0000000Zhttps://world.optimizely.com/blogs/Maris-Krivtezs/ Optimizely World Upgraded Geta Optimizely packages<h1 id="geta-optimizely-extensions">Geta.Optimizely.Extensions</h1> The old package Geta.EPi.Extensions has been renamed to Geta.Optimizely.Extensions. Install it using Nuget package manager or from the command line: <pre><code>Install-Package Geta.Optimizely.Extensions </code></pre>The package has almost the same functionality as the previous version. The only change is that we have removed <code>XForms</code> related functionality as it is not supported in Optimizely 12 anymore. For more information check the <a href="https://github.com/Geta/geta-optimizely-extensions">Github page</a>. <h1 id="sitemaps-and-sitemaps-commerce">Sitemaps and Sitemaps.Commerce</h1> The old packages Geta.SEO.Sitemaps and Geta.SEO.Sitemaps.Commerce has been renamed to Geta.Optimizely.Sitemaps and Geta.Optimizely.Sitemaps.Commerce. Install those using Nuget package manager or from the command line: <pre><code>Install-Package Geta.Optimizely.Sitemaps Install-Package Geta.Optimizely.Sitemaps.Commerce </code></pre>After installation, you have to configure it. Register the Sitemaps and/or Sitemaps Commerce in the service collection first: <pre><code>services.AddSitemaps(x => { x.EnableLanguageDropDownInAdmin = false; x.EnableRealtimeCaching = true; x.EnableRealtimeSitemap = false; }); services.AddSitemapsCommerce(); </code></pre>Then make sure that you have razor pages mapped: <pre><code>app.UseEndpoints(endpoints => { endpoints.MapRazorPages(); }); </code></pre>After that, you will see a new top menu item for the Sitemaps in the Optimizely administration UI. There is a new administration user interface, but it has the same functionality as the old one. For more information check the <a href="https://github.com/Geta/geta-optimizely-sitemaps">Github page</a>. <h1 id="geta-optimizely-googleproductfeed">Geta.Optimizely.GoogleProductFeed</h1> The package Geta.GoogleProductFeed has been renamed to Geta.Optimizely.GoogleProductFeed so that all the naming is consistent with other Optimizely packages. Install it using Nuget package manager or from the command line: <pre><code>Install-Package Geta.Optimizely.GoogleProductFeed </code></pre>After installation, you have to configure it. Register the GoogleProductFeed in the service collection first: <pre><code>services.AddGoogleProductFeed(x => { x.ConnectionString = _configuration.GetConnectionString("EPiServerDB"); }); </code></pre>Then you have to create your <code>FeedBuilder</code>. See the <a href="https://github.com/Geta/geta-optimizely-googleproductfeed">documentation</a>. Once, it is created register it in the service collection: <pre><code>services.AddTransient<FeedBuilder, MyFeedBuilder>(); </code></pre>For more information check the <a href="https://github.com/Geta/geta-optimizely-googleproductfeed">Github page</a>. <h1 id="geta-optimizely-contenttypeicons">Geta.Optimizely.ContentTypeIcons</h1> We had a package Geta.Epi.FontThumbnail for the older Episerver/Optimizely versions. The package name did not describe what it was. So we renamed it to Geta.Optimizely.ContentTypeIcons. Install it using Nuget package manager or from the command line: <pre><code>Install-Package Geta.Optimizely.ContentTypeIcons </code></pre>After installation, you have to configure it. Register the ContentTypeIcons in the service collection first: <pre><code>services.AddContentTypeIcons(x => { x.EnableTreeIcons = true; x.ForegroundColor = "#ffffff"; x.BackgroundColor = "#02423F"; x.FontSize = 40; x.CachePath = "[appDataPath]\\thumb_cache\\"; x.CustomFontPath = "[appDataPath]\\fonts\\"; }); </code></pre>Now you can start using it by adding the <code>ContentTypeIcon</code> attribute to your content types. For example: <pre><code>[ContentTypeIcon(FontAwesome5Brands.Github)] </code></pre>This attribute on a page type will show you a Github icon when you will create a new page of this page type. Also, if you have the <code>EnableTreeIcons</code> setting enabled, you will see the icon in the content tree. You can also use the <code>TreeIcon</code> attribute to override the behavior for the content tree. You can set a different icon or ignore the icon completely: <pre><code>[TreeIcon(Ignore = true)] [TreeIcon(FontAwesome5Solid.CheckDouble)] </code></pre>For more information check the <a href="https://github.com/Geta/geta-optimizely-contenttypeicons">Github page</a>. 2021-12-23T00:00:00.0000000Z

Blog post

New Geta.NotFoundHandler<h1 id="the-new-name-geta-notfoundhandler">The new name - Geta.NotFoundHandler</h1> We have changed the name of the package again. The reason for this is that the old name was inconsistent throughout the code. The assembly name was <code>Geta.404Handler</code>, but namespaces started with <code>Geta.NotFoundHandler</code>. We could have changed namespaces to have <code>404Handler</code> in the name, but namespaces' parts in .NET can't start with a number. <h1 id="asp-net-5-and-optimizely">ASP.NET 5 and Optimizely</h1> After reviewing the library, we found that it was not so dependent on Optimizely (Episerver). So we refactored the library that supports ASP.NET 5 and added administrative UI integration in Optimizely. Now there are three separate packages: <ul> <li><code>Geta.NotFoundHandler</code> - the core library for ASP.NET 5.</li> <li><code>Geta.NotFoundHandler.Admin</code> - the administrative UI.</li> <li><code>Geta.NotFoundHandler.Optimizely</code> - a module that integrates administrative UI in Optimizely UI.</li> </ul> <h1 id="getting-started-in-asp-net">Getting started in ASP.NET</h1> In an ASP.NET 5 project install <code>Geta.NotFoundHandler.Admin</code> and in the <code>Startup.ConfigureServices</code> method configure the NotFoundHandler. You have to provide a connection string at least. <pre><code>public void ConfigureServices(IServiceCollection services) { var connectionString = ... // Retrieve connection string here services.AddNotFoundHandler(o => { o.UseSqlServer(connectionstring); }); } </code></pre>By default, users in the Administrators role will have access to the administration UI. You can change the default policy in the configuration: <pre><code>public void ConfigureServices(IServiceCollection services) { var connectionString = ... // Retrieve connection string here services.AddNotFoundHandler(o => { o.UseSqlServer(connectionstring); }, policy => { policy.RequireRole("MyRole"); }); } </code></pre>Next, initialize NotFoundHandler in the <code>Configure</code> method as the first registration. It will make sure that the handler will catch all 404 errors. <pre><code>public void Configure(IApplicationBuilder app) { app.UseNotFoundHandler(); } </code></pre>Now you should be able to access administrative UI by <code>https://mysite/Geta.NotFoundHandler.Admin</code>. <img src="/img/2021-11/redirects.png" class="img-responsive" alt="" /> <h1 id="getting-started-in-optimizely">Getting started in Optimizely</h1> In an Optimizely project install <code>Geta.NotFoundHandler.Optimizely</code> package. Then configure the handler in <code>Startup.ConfigureServices</code> method. Set the connection string and add access for the CMS administrators. <pre><code>public void ConfigureServices(IServiceCollection services) { var connectionString = ... // Retrieve connection string here services.AddNotFoundHandler(o => { o.UseSqlServer(connectionString); }, policy => { policy.RequireRole(Roles.CmsAdmins); }); services.AddOptimizelyNotFoundHandler(); } </code></pre>As in the ASP.NET case, initialize NotFoundHandler in the <code>Configure</code> method as the first registration. <pre><code>public void Configure(IApplicationBuilder app) { app.UseNotFoundHandler(); } </code></pre>Run the application and in the Optimizely administrative UI you will find a link to the NotFounHandler administrative UI in the top menu. <img src="/img/2021-11/optimizely-redirects.jpg" class="img-responsive" alt="" /> <h1 id="summary">Summary</h1> NotFoundHandler now is ready for use in the new Optimizely 12, but if you are using older versions of Optimizely/Episerver, then we will still support those as <a href="https://github.com/Geta/404handler">Geta.404Handler</a>. The source code and documentation for the new NotFoundHandler is available on <a href="https://github.com/Geta/geta-notfoundhandler">GitHub</a>. 2021-11-04T00:00:00.0000000Z

Blog post

Managing settings in Episerver project - part 3<h1 id="settings-page">Settings page</h1> If we look at the single responsibility principle, a start page with settings is doing too much. It has start page related content and also site-wide settings. When you have a large site, the start page becomes a settings page - the primary purpose of it is settings management. But that is not a good approach. The start page should contain only the page related stuff. To solve the issue, create a separate page type that has only one purpose - storing settings. You can group settings properties or add local blocks to this page type, as I described in my previous <a href="/2020/02/28/managing-settings-in-episerver-project-2/">article</a>. <pre><code class="lang-csharp">[ContentType(GUID = "16BA6D0E-49D1-4A49-95A9-88B7FAE65E63")] public class SettingsPage : PageData { [Display(GroupName = GroupNames.Header, Order = 10)] [UIHint(UIHint.Image)] [AllowedTypes(typeof(ImageFile))] public virtual ContentReference CompanyLogo { get; set; } [Display(GroupName = GroupNames.Footer, Order = 10)] public virtual LinkBlock Links { get; set; } } </code></pre> Now you can create a page in the root of the site and set required settings. To load and use the page in your code, you can use an extension method from the <a href="https://github.com/Geta/EPi.Extensions"><code>Geta.EPi.Extensions</code> package</a> <code>GetFirstChild</code> or create one: <pre><code class="lang-csharp">public static T GetFirstChild<T> this IContentLoader contentLoader, ContentReference contentReference) where T : IContentData { return contentLoader.GetChildren<T>(contentReference).FirstOrDefault(); } </code></pre> Then in your code, use this extension to load settings from the site root. <pre><code class="lang-csharp">var settings = _contentLoader.GetFirstChild<SettingsPage>(ContentReference.StartPage); </code></pre> <h1 id="multiple-sites">Multiple sites</h1> As you have the settings page type already created, you need to create new settings pages on each site. Then when you load the settings by using <code>ContentReference.StartPage</code> in your code, it will load the correct settings page for each of your sites. <h1 id="global-settings">Global settings</h1> You can use the same approach for global settings. Create a separate page type that will contain global settings. Then create this page in the root of the Episerver instance. To load global settings, use <code>ContentReference.RootPage</code> as the settings page parent in <code>GetFirstChild</code> method. <pre><code class="lang-csharp">var settings = _contentLoader.GetFirstChild<GlobalSettingsPage>(ContentReference.RootPage); </code></pre> <h1 id="summary">Summary</h1> A custom page type is an excellent tool when you have to separate settings from other site data. You can create a site-specific settings page type, a settings page type that is used in multiple sites, or a page type that is used globally in the whole Episerver instance. 2020-03-31T00:00:00.0000000Z

Blog post

Managing settings in Episerver project - part 2<h1 id="grouping-settings-in-tabs">Grouping settings in tabs</h1> The easiest way to improve the way how settings are displayed for the users (administrators), is by grouping those in tabs. For example, you have several setting properties on the start page, and those are mixed now with other properties. <pre><code class="lang-csharp">[ContentType(GUID = "6C709414-18C6-4E97-9B83-7220FA87D05A", Order = 10, AvailableInEditMode = true)] public class StartPage : PageData { [CultureSpecific] public virtual string Header { get; set; } public virtual Url FacebookUrl { get; set; } } </code></pre> The <code>Header</code> property, in this example, is displayed on the start page, but <code>FacebookUrl</code> is used for the whole site. So the last one is a setting we would not like to see mixed with start page related stuff in UI. By adding the <code>Display</code> attribute and setting <code>GroupName</code> property on it, we will move the setting property to the separate tab in UI. <pre><code class="lang-csharp">[ContentType(GUID = "6C709414-18C6-4E97-9B83-7220FA87D05A", Order = 10, AvailableInEditMode = true)] public class StartPage : PageData { [CultureSpecific] public virtual string Header { get; set; } [Display(GroupName = "Site Settings")] public virtual Url FacebookUrl { get; set; } } </code></pre> It is also a good approach to extract group name constants into a separate class and add <code>GroupDefinitions</code> attribute so that Episerver will pick it up. For more info, read <a href="/link/99e06ec8c73243f18cc50b2f00bfe71f.aspx">Episerver documentation</a>. <pre><code class="lang-csharp">[GroupDefinitions] public static class GroupNames { [Display(GroupName = "Site settings", Order = 10)] public const string SiteSettings = "SiteSettings"; } </code></pre> <h1 id="grouping-settings-with-local-blocks">Grouping settings with local blocks</h1> While grouping with a <code>Display</code> attribute allows separating settings in UI, in code, the setting properties are kept together with content properties. One way to work around this issue is by creating blocks and adding those as properties to the start page. Create a block first. <pre><code class="lang-csharp">[ContentType(GUID = "13304E95-B697-444E-B0D4-F8806B70BF20")] public class SettingsBlock : BlockData { public virtual Url FacebookUrl { get; set; } } </code></pre> And then add it to the start page. <pre><code class="lang-csharp">[ContentType(GUID = "6C709414-18C6-4E97-9B83-7220FA87D05A", Order = 10, AvailableInEditMode = true)] public class StartPage : PageData { [CultureSpecific] public virtual string Header { get; set; } [Display(GroupName = GroupNames.SiteSettings)] public virtual SettingsBlock Settings { get; set; } } </code></pre> As you see, I have kept the <code>Display</code> attribute and set <code>GroupName</code> so that the block with settings is still displayed in a separate tab. Now, when you need to use settings in your code, you can just pass <code>SettingsBlock</code> around and do not mess with other start page related settings. <pre><code class="lang-csharp">var startPage = _contentLoader.Get(ContentReference.StartPage); var settings = startPage.Settings; DoSomething(settings); </code></pre> <h1 id="summary">Summary</h1> As you see, there are some simple ways how to improve settings on your site for both - end-users in UI and developers in code. Though in large projects, it is not enough to add grouping or extract settings into a local block. You might need a more advanced approach. But that's for another time. P.S. Check out <a href="https://talk.alfnilsson.se/2014/04/01/creating-modular-settings-with-blocks/">Alf's blog</a> about his approach to managing settings. 2020-02-28T00:00:00.0000000Z

Blog post

Managing settings in Episerver project - part 1<h1 id="appsettings-in-web-config">appSettings in Web.config</h1> In the ASP.NET world (.NET Framework, not Core), the most common place for settings is the <code>appSettings</code> section in the Web.config file. You can configure solution-wide settings here. It is possible to add transformations for different environments where you are deploying the application. Also, you can add "partial" settings in a separate file. This is useful when each developer has their own settings. Just add the "partial" file to the <code>.gitignore</code>, and in the Web.config on the appSettings tag, add <code>file</code> attribute that points to your "partial" settings file. <pre><code class="lang-xml"><appSettings file="appSettings.dev.config"> <add key="MySetting" value="The configuration"> </appSettings> </code></pre> Once you configured your application, you can retrieve settings using <code>ConfigurarionManager</code>. <pre><code class="lang-csharp">var mySetting = ConfigurationManager.AppSettings["MySetting"]; </code></pre> It returns a string value. If you need another type, you have to cast to it. <h2 id="pros">Pros</h2> <ul> <li>Built-in ASP.NET feature.</li> <li>Easy to use.</li> <li>Transformations allow creating separate setting values for different environments.</li> </ul> <h2 id="cons">Cons</h2> <ul> <li>Unable to change values in runtime. Requires re-deploy.</li> <li>By default, everything is a string. You need to cast to other types.</li> <li>Unable to store complex types without serializing to some string format (comma-separated strings, XML, JSON).</li> </ul> <h1 id="custom-settings-section-in-web-config">Custom settings section in Web.config</h1> A custom settings section is a good alternative to <code>appSettings</code>. It is harder to implement and use, but has several benefits over <code>appSettings</code>. With it, you do not mix your settings with other application settings. I will not cover creating a custom configuration section here, but Joel Abrahamsson has a excellent article about it: <a href="http://joelabrahamsson.com/creating-a-custom-configuration-section-in-net/">Creating a custom Configuration Section in .NET</a>. <h2 id="pros">Pros</h2> <ul> <li>Built-in ASP.NET feature.</li> <li>Separates your settings from other application settings.</li> <li>Transformations allow creating separate setting values for different environments.</li> <li>You can create complex types using configuration Elements and Collections.</li> </ul> <h2 id="cons">Cons</h2> <ul> <li>More complex implementation and usage than <code>appSettings</code>.</li> <li>Unable to change values in runtime. Requires re-deploy.</li> <li>Properties of the configuration are still just strings, and you need to cast those to other types.</li> </ul> <h1 id="settings-on-the-start-page">Settings on the Start page</h1> It is quite common to use a start page as setting storage in Episerver projects. You can add properties on the start page and configure it to display on the separate tab. <pre><code class="lang-csharp">[Display(GroupName = GroupNames.Settings, Order = 100)] public virtual ContentReference MyLink { get; set; } </code></pre> Then you can use Episerver API to load the start page and use the setting. <pre><code class="lang-csharp">var startPage = _contentLoader.Get<StartPage>(ContentReference.StartPage); var myLink = startPage.MyLink; </code></pre> When using a start page, you can define properties of any type Episerver has support. You can use integers, strings, content references, or even use blocks for complex types. A full list of supported types can be found here: <a href="/link/52e3713caeb44099beb7fe421304c130.aspx">Built-in property types</a>. Another advantage of using the start page is UI. You can easily change settings by opening the start page, changing settings, and then publishing the page. For example, it can be used for "feature switching" to enable/disable some functionality on the site. <h2 id="pros">Pros</h2> <ul> <li>Easy to use Episerver API.</li> <li>Multi-language settings.</li> <li>It can be changed in runtime.</li> <li>Configure from UI.</li> </ul> <h2 id="cons">Cons</h2> <ul> <li>Environment specific configuration should be configured manually in each environment.</li> <li>The start page is not specifically built for settings.</li> </ul> <h1 id="summary">Summary</h1> As you see in this article, each approach for storing and using settings has its advantages and disadvantages. So all approaches also have their use cases. <code>appSettings</code> and custom configuration sections are great for a configuration that differs by the environment. Also, you would not want to setup settings that often change in <code>Web.config</code>. So this is the right place for settings that are required for 3rd party API integration, some connection details, etc. The start page can be used for settings that you might change often or should be changed at runtime. As I mentioned previously, it is the right place for "feature switching." Also, you would not want to setup settings on the start page when you need those different in different environments. The right decision where and how to store settings should be made by a project team depending on requirements. In the next article, I will describe other options you can use and better organize settings in Episerver. 2020-01-06T01:00:00.0000000Z

Blog post

Getting promotion value from the order<code>IOrderForm</code> has a property with all promotions applied to the order. Each promotion record provides information about the saved monetary amount, about the type of the reward, has a reference to the promotion data and more information. But it lacks information about the percentage value of promotion if a promotion's type is a percentage. The only way to get the percentage value of the promotion is by loading the promotion by a reference and then getting its value. <pre><code class="lang-csharp">public static decimal GetDiscountValue(this PromotionInformation promotionInfo, IContentLoader contentLoader) { if (promotionInfo.RewardType != RewardType.Percentage) { return promotionInfo.SavedAmount; } if (contentLoader.TryGet<PromotionData>(promotionInfo.PromotionGuid, out var promotion) && promotion is IMonetaryDiscount monetaryDiscount) { return monetaryDiscount.Discount.Percentage; } return promotionInfo.SavedAmount; } </code></pre> Here I have created an extension method to get the correct value based on a reward type. When the reward type is not a percentage, return saved amount value from the promotion. Otherwise, load the promotion and return percentage value. Only the promotion of <code>IMonetaryDiscount</code> can have a percentage value. Now you can use this method to get a percentage or monetary value like this: <pre><code class="lang-csharp">public void WorkOnPromotionValue(IOrderForm orderForm, IContentLoader contentLoader) { var promotion = orderForm.Promotions.First(); var value = promotion.GetDiscountValue(contentLoader); if (promotion.RewardType == RewardType.Percentage) { var percentage = value; // Do some work with percentage ... } else { var money = value; // Do some work with money ... } } </code></pre> It would be much better if Episerver would store percentage value in the order too. Promotions might be removed, and it will not be possible to get the percentage value anymore. And promotions are removed quite often as too many promotions severely affect the site's performance when calculating discounted price. 2019-10-23T02:00:00.0000000Z

Blog post

A more flexible way to hide category property in EpiserverIn Episerver you can hide properties in edit mode using a <code>ScaffoldColumn</code> attribute by using it like this: <pre><code class="lang-csharp">[ScaffoldColumn(false)] </code></pre> This does not work for the <code>Category</code> property though. To fix it, you can add an editor descriptor similar to Joel's but instead of filtering on content types, filter on <code>ScaffoldColumn</code> and use its <code>Scaffold</code> value: <pre><code class="lang-csharp">[EditorDescriptorRegistration(TargetType = typeof (CategoryList))] public class HideCategoryEditorDescriptor : EditorDescriptor { public override void ModifyMetadata( ExtendedMetadata metadata, IEnumerable<Attribute> attributes) { var attrs = attributes as Attribute[] ?? attributes.ToArray(); base.ModifyMetadata(metadata, attrs); if (metadata.PropertyName != "icategorizable_category") return; var scaffoldAttribute = attrs .SafeOfType<ScaffoldColumnAttribute>() .FirstOrDefault(); if (scaffoldAttribute == null) return; metadata.ShowForEdit = scaffoldAttribute.Scaffold; } } </code></pre> NOTE: I am using <code>SafeOfType</code> extension method from the <a href="https://nuget.episerver.com/package/?id=Geta.Net.Extensions">Geta.Net.Extensions</a> library. Now you can use <code>ScaffoldColumn</code> to control the visibility of the <code>Category</code> property. <pre><code class="lang-csharp">[ScaffoldColumn(false)] public override CategoryList Category { get; set; } </code></pre> Here I am overriding a category property from the base class and applying the attribute. 2019-08-02T02:00:00.0000000Z

Blog post

Promotion exclusion levels in Episerver Commerce<h1 id="the-issue">The issue</h1> We have item level discounts on two categories where one category has a 30% discount and the second one has a 50% discount. Then we defined an order level discount of 40% when a coupon code is applied. The order of discounts is 50% -> 40% -> 30%. When we tried to add products from both categories and then apply a coupon code, we got a validation error that it is an invalid discount combination. <h1 id="the-research-and-the-solution">The research and the solution</h1> Episerver support sent us a Quicksilver example where this setup worked but with a small difference - 40% discount was an item level discount. We tried to re-create the same setup, but it still did not work. After some research, I found that Episerver support changed Quicksilver code, which applies discounts. They have changed the exclusion level from <code>Order</code> to <code>Unit</code> when calling <code>ApplyDiscounts</code> on the cart. <pre><code class="lang-csharp">cart.ApplyDiscounts(_promotionEngine, new PromotionEngineSettings { ExclusionLevel = ExclusionLevel.Unit }); </code></pre> The default value for <code>ExclusionLevel</code> is <code>Order</code>. So the combination we tried to apply didn't work. Strangely, this is a default value as such discount combinations are common in e-commerce solutions. So if you need control of combining different discounts on item level, always use <code>ExclusionLevel.Unit</code>. Thanks to Cuong Phan from Episerver support for help! 2019-06-18T02:00:00.0000000Z

Blog post

Episerver: starting a Scheduled Job programmaticallyWhile Episerver's async methods for starting a scheduled job do not work well, there is a workaround. You can schedule the job to run later. Then the scheduler will pick up the job and start it. Here I have created an extension method to schedule the job to run after ten seconds. <pre><code class="lang-csharp">public static class ScheduledJobExtensions { public static void ScheduleRunNow( this ScheduledJob job, IScheduledJobRepository scheduledJobRepository) { job.IntervalType = ScheduledIntervalType.None; job.IntervalLength = 0; job.IsEnabled = true; job.NextExecution = DateTime.Now.AddSeconds(10); scheduledJobRepository.Save(job); } } </code></pre> You can use this extension method like this: <pre><code class="lang-csharp">var job = _scheduledJobRepository.Get(new Guid(MyJob.Guid)); job.ScheduleRunNow(_scheduledJobRepository); </code></pre> 2019-04-23T02:00:00.0000000Z

Blog post

Investigating missing products in content areasAfter research, we found that it was caused by the import changing content GUIDs on products. It caused other issues too. In this article, I do not want to go into the details of that issue but cover how products are linked in content areas. With a few SQL scripts, you can get all you need. The first thing to find out is the ID of the content area property. You can find it in the <code>tblPropertyDefinition</code> by querying it on <code>fkContentTypeID</code> column (if you do not know the ID of the content type, find it in the <code>tblContentType</code> table). <pre><code class="lang-sql">SELECT * FROM [dbo].[tblPropertyDefinition] where fkContentTypeID = 100 </code></pre> In the results, find your property and use it's <code>pkID</code> value in the next query. In the <code>tblContentProperty</code> table, Episerver stores values of all properties. You can easily get values for all properties by querying by content ID on the <code>fkContentID</code> column and property definition ID on the <code>fkPropertyDefinitionID</code> column (the value you get in the previous step). The easiest way to get a content ID is by going into the Episerver edit mode and check the ID under the content properties. <img src="/img/2019-02/content-id-in-edit.jpg" class="img-responsive" alt="Content ID in the edit mode." /> Once you get all IDs, run the query. To get values of a content area, you should look into <code>LongString</code> column. <pre><code class="lang-sql">SELECT [LongString] FROM [dbo].[tblContentProperty] where fkPropertyDefinitionID = 800 and fkContentID = 9000 </code></pre> Episerver stores content area data in an <code>XML</code> format which looks like <code>Html</code>. Each item in the content area is represented as a <code>DIV</code> tag with some attributes. I was interested only in two - <code>data-contentguid</code> and <code>data-contentname</code>. The first attribute is a GUID which links to the content in the content area and the second helps to identify an item by the name. <pre><code class="lang-html"><div data-classid="36f4349b-8093-492b-b616-05d8964e4c89" data-contentgroup="" data-contentguid="00000000-0000-1234-0000-000000010000" data-contentname="Fancy stuff">{}</div> </code></pre> In our case, product GUIDs were generated in a specific format and those where changing in some cases. In this example, it would be <code>1234</code> part. Once we found the issues in IDs, we could easily fix it with a script. <pre><code class="lang-sql">UPDATE tblContentProperty SET LongString = REPLACE(LongString, '00000000-0000-1234-0000-', '00000000-0000-0000-0000-') </code></pre> I know that it might be dangerous to modify Episerver DB directly, but we haven't risked much as products in content areas were not visible anyway. Luckily, this fixed our issues. There is another table which might be useful when researching issues with content areas. It is <code>tblContentSoftlink</code> table. <pre><code class="lang-sql">SELECT * FROM [dbo].[tblContentSoftlink] where fkReferencedContentGUID = '00000000-0000-1234-0000-000000010000' </code></pre> There is one important column in this table - <code>ContentLink</code>. You can find a matching content link for a content GUID in it. In our case, we still saw a content link and it was a valid one - the content existed in the DB. But once we edited content in the edit mode without touching our content area, the content link became empty. The data in the content area still remained (in the <code>tblContentProperty</code> table). 2019-02-28T01:00:00.0000000Z

Blog post

EPiServer: working with Scheduled Jobs programmatically. Revisited.In the latest version, you still have a repository. However, instead of using a class, you should ask for an interface - IScheduledJobRepository. It still has the same set of methods: <ul> <li>Get(Guid id):ScheduledJob</li> <li>Get(string method, string typeName, string assemblyName):ScheduledJob</li> <li>List():IEnumerable<scheduledjob></scheduledjob></li> <li>Save(ScheduledJob job):void</li> </ul> <a href="/2015/05/04/episerver-working-with-scheduled-jobs-programmatically/">See my previous article for detailed information</a>. The main changes in the API are about executing these jobs. Stop, ExecuteManually and other methods of a ScheduledJob class now are obsolete. You should use IScheduledJobExecutor instead. IScheduledJobExecutor has three methods: <ul> <li>StartAsync(ScheduledJob job, JobExecutionOptions options, CancellationToken cancellationToken):Task<jobexecutionresult></jobexecutionresult> - starts a job with provided options and cancellation token,</li> <li>Cancel(Guid id):void - cancels a job by Id,</li> <li>ListRunningJobs():IEnumerable - - returns a list of running jobs.</li> </ul> IScheduledJobExecutor also has several extension methods. These extension methods make it much easier to work with scheduled jobs: <ul> <li>StartAsync(this IScheduledJobExecutor executor, ScheduledJob job):Task<jobexecutionresult></jobexecutionresult> - starts a job without any parameters,</li> <li>StartAsync(this IScheduledJobExecutor executor, ScheduledJob job, JobExecutionOptions options):Task<jobexecutionresult></jobexecutionresult> - starts a job with options,</li> <li>ListRunningJobs<T>(this IScheduledJobExecutor executor):IEnumerable<T> - lists jobs of a specific type.</li> </ul> So with all this in your tool belt, you can load a job by id and start it. <pre><code class="lang-csharp">public async RunMyJob() { var job = _scheduledJobRepository.Get(new Guid(MyJob.Guid)); if (job.IsRunning) { return; } var result = await _scheduledJobExecutor.StartAsync(job); if (result.Status == ScheduledJobExecutionStatus.Succeeded) { return; } Log.Error($"Failed to start a job: {result.Status} {result.Message}"); return; } </code></pre> You also, can pass some options: <pre><code class="lang-csharp">await _scheduledJobExecutor.StartAsync(job, new JobExecutionOptions { Trigger = ScheduledJobTrigger.User, RunSynchronously = true, ContentCacheSlidingExpiration = null }); </code></pre> Here the trigger just indicates how this job was started. It has four values - Unknown, Scheduler, User, Restart. So you can fake how it was started :) RunSynchronously set to true will run the job synchronously. With ContentCacheSlidingExpiration you can set how long content is cached when executed. 2019-01-31T01:00:00.0000000Z

Blog post

Refactoring 404 handler to use SQL storeIf you want to get started with the new version, head over to <a href="https://getadigital.com/blog/404-handler-with-performance-improvements-released/">Geta's blog</a> for details. <h1 id="refactoring-steps">Refactoring steps</h1> The first challenge I faced was that data access was mixed with some logic in a <code>DataStoreHandler</code>. However, it was not so easy to extract it out. So I started abstracting away the logic behind the <code>DataStoreHandler</code> and created an interface for it - <code>IRedirectsService</code> and implemented it in the <code>DataStoreHandler</code>. I didn't like method names in the <code>DataStoreHandler</code>. So I used different naming in <code>IRedirectsService</code>: <pre><code class="lang-csharp">public interface IRedirectsService { IEnumerable<CustomRedirect> GetAll(); IEnumerable<CustomRedirect> GetSaved(); IEnumerable<CustomRedirect> GetIgnored(); IEnumerable<CustomRedirect> GetDeleted(); IEnumerable<CustomRedirect> Search(string searchText); void AddOrUpdate(CustomRedirect redirect); void AddOrUpdate(IEnumerable<CustomRedirect> redirects); void DeleteByOldUrl(string oldUrl); int DeleteAll(); int DeleteAllIgnored(); } </code></pre> This new interface works as a facade for all actions that could be done with a redirect. The next task was extracting data access. I wanted to separate reads from writes. For writes, I have introduced a generic <code>IRepository</code> interface. For now, it just supports saving and deleting of requests. <pre><code class="lang-csharp">public interface IRepository<TEntity> where TEntity : class { void Save(TEntity entity); void Delete(TEntity entity); } </code></pre> For reads, I have created an interface specific for redirect querying - <code>IRedirectLoader</code>. <pre><code class="lang-csharp">public interface IRedirectLoader { CustomRedirect GetByOldUrl(string oldUrl); IEnumerable<CustomRedirect> GetAll(); IEnumerable<CustomRedirect> GetByState(RedirectState state); IEnumerable<CustomRedirect> Find(string searchText); } </code></pre> I could use a query pattern here, but it would complicate things. I also wanted to stick to Episerver naming convention (for example, <code>IContentLoader</code> for content querying in Episerver). With these two interfaces, I could extract out data access. So I have implemented <code>DdsRedirectRepository</code> by extracting all data access logic from <code>DataStoreHandler</code>. Once this was done, it was simple to move the rest of the <code>DataStoreHandler</code> logic into a separate <code>IRedirectsService</code> implementation and leave <code>DataStoreHandler</code> just for backward compatibility (if someone uses it). I have implemented <code>DefaultRedirectsService</code> which mostly coordinates data access. <h1 id="sql-store">SQL store</h1> As I have finished refactoring, I could start implementing SQL store. The first task was creating a new table and implement upgrade steps. The 404 handler has <code>Upgrader</code> class which already creates a table for suggestions. I have used it as an example for the redirects table. However, before implementation of it, <code>Upgrader</code> needed a refactoring. I have extracted all upgrade steps in separate methods so that it is easier to add new steps. Once table creation was implemented in the <code>Upgrader</code>, I could start working on <code>SqlRedirectRepository</code>. I used Episerver's <code>IDatabaseExecutor</code> to run ADO.NET queries. For more straightforward data reading I have used <a href="https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/queries-in-linq-to-dataset">Linq to DataSet</a>. <pre><code class="lang-csharp">private IEnumerable<CustomRedirect> ExecuteEnumerableQuery(DbCommand command) { var table = ExecuteDataTableQuery(command); return table .AsEnumerable() .Select(ToCustomRedirect); } private DataTable ExecuteDataTableQuery(DbCommand command) { var adapter = _executor.DbFactory.CreateDataAdapter(); if (adapter == null) throw new Exception("Unable to create DbDataAdapter"); adapter.SelectCommand = command; var ds = new DataSet(); adapter.Fill(ds); return ds.Tables[0]; } private static CustomRedirect ToCustomRedirect(DataRow x) { return new CustomRedirect( x.Field<string>("OldUrl"), x.Field<string>("NewUrl"), x.Field<bool>("WildCardSkipAppend")) { Id = Identity.NewIdentity(x.Field<Guid>("Id")), State = x.Field<int>("State") }; } </code></pre> The last step was adding data migration from DDS to the SQL store. I have just added an action to the gadget's controller, then used the <code>DdsRedirectRepository</code> to read old records and the new <code>IRedirectsService</code> to save records. <h1 id="performance">Performance</h1> After I have implemented SQL store, I wanted to see how much faster the 404 handler become. I have imported <code>6000</code> redirects in DDS and SQL stores and tried to load all redirects. The results were fascinating. Loading of all records from DDS store took <code>~16000 ms</code> while from SQL store it took only <code>26 ms</code>. It is more than 600 times faster. <h1 id="summary">Summary</h1> While it didn't seem much work implementing support for multiple storages, it took some time to finish it. Ideally, I would write integration tests to make sure that nothing was broken, but it was too hard to implement those to work with Episerver APIs - DDS and SQL. # New Year! 2018-12-31T01:00:00.0000000Z

Blog post

New version of Geta Tags releasedFor more information see <a href="https://getadigital.com/blog/new-version-of-geta-tags-released/">Geta's blog</a>. 2018-12-12T01:00:00.0000000Z

Blog post

A complete configuration recipe for Episerver library<h2 id="introduction">Introduction</h2> I have created an example library to show how the configuration should be set up. The library adds Episerver content event logging. A library user can configure the log level and to which events to subscribe (it supports two events in an example). <h2 id="library-implementation">Library implementation</h2> First of all, let's create the functionality of our library. I am creating a class which logs an event using Episerver logging. It has two parameters - the name of an event and ContentEventArgs arguments, and it logs the provided information. <pre><code class="lang-csharp">public class ContentEventLogger { private readonly ILogger _logger = LogManager.GetLogger(typeof(ContentEventLogger)); public virtual void Log(string name, ContentEventArgs args) { _logger.Log(Level.Information, $"Event: {name}; Content: {args.Content?.Name}"); } } </code></pre> The requirements stated that we should be able to change the log level by some configuration. For this purpose, I am creating a settings class and inject it in our logger. <pre><code class="lang-csharp">public class LoggerSettings { public LoggerSettings() { Level = Level.Information; } public Level Level { get; private set; } public LoggerSettings LogLevel(Level level) { return new LoggerSettings { Level = level }; } } public class ContentEventLogger { private readonly LoggerSettings _settings; private readonly ILogger _logger = LogManager.GetLogger(typeof(ContentEventLogger)); public ContentEventLogger(LoggerSettings settings) { _settings = settings ?? throw new ArgumentNullException(nameof(settings)); } public virtual void Log(string name, ContentEventArgs args) { _logger.Log(_settings.Level, $"Event: {name}; Content: {args.Content?.Name}"); } } </code></pre> <h2 id="library-s-settings-configuration">Library's settings configuration</h2> Now we provided settings of our logger through dependency injection. However, how to configure it so that settings are injected, and it is simple enough for our library users? Episerver has an API for dependency injection configuration. We can use it to register our settings and our logger in an IConfigurableModule. <pre><code class="lang-csharp">public void ConfigureContainer(ServiceConfigurationContext context) { var settings = new LoggerSettings(); context.Services.AddSingleton(settings); context.Services.AddSingleton<ContentEventLogger>(); } </code></pre> While this works, the question is who is responsible for this registration. If we create an IConfigurableModule in our library, then the user will not be able to set the settings they need. If we make the user responsible for all registrations, the user will need proper documentation to not mess up with it. In this example, the configuration is simple, but what would happen if the user has to register ten or more services? The solution is in the middle. We can provide a simple API for the user to configure the library in their IConfigurableModule but same time without too many details. For this purpose, I am creating several extension methods for ServiceConfigurationContext. There is one extension method which uses default configuration and the second one which allows setting log level you want. Notice that I prefixed extension methods with Add. This approach is a convention used in ASP.NET Core. <pre><code class="lang-csharp">public static void AddContentEventLogger( this ServiceConfigurationContext context) { context.AddContentEventLogger(_ => _); } public static void AddContentEventLogger( this ServiceConfigurationContext context, Func<LoggerSettings, LoggerSettings> configure) { var settings = configure(new LoggerSettings()); context.Services.AddSingleton(settings); context.Services.AddSingleton<ContentEventLogger>(); } </code></pre> With these extension methods, the user can register our logger in their IConfigurableModule. <pre><code class="lang-csharp">public void ConfigureContainer(ServiceConfigurationContext context) { context.AddContentEventLogger(); // or context.AddContentEventLogger(x => x.LogLevel(Level.Error)); } </code></pre> <h2 id="initialization-configuration">Initialization configuration</h2> While we have implemented our logging functionality, it is not used anywhere. We have to attach it to Episerver events. So we need some initialization logic. Again, we can create an initialization module in our library and attach to the events but this way our library user loses control. They are not able to configure to which events to attach. Instead, let's create a particular class for our library initialization for which we provide additional settings. <pre><code class="lang-csharp">public enum ContentEvent { Created, Published } public class InitializerSettings { public IEnumerable<ContentEvent> Events { get; private set; } public InitializerSettings() { Events = Enumerable.Empty<ContentEvent>(); } public InitializerSettings SubscribeTo(ContentEvent contentEvent) { return new InitializerSettings { Events = Events.Union(new [] {contentEvent}) }; } } public class Initializer { private readonly IContentEvents _contentEvents; private readonly ContentEventLogger _logger; public Initializer( IContentEvents contentEvents, ContentEventLogger logger) { _contentEvents = contentEvents ?? throw new ArgumentNullException(nameof(contentEvents)); _logger = logger ?? throw new ArgumentNullException(nameof(logger)); } public void Initialize(InitializerSettings settings) { foreach (var contentEvent in settings.Events) { Subscribe(contentEvent); } } private void Subscribe(ContentEvent contentEvent) { switch (contentEvent) { case ContentEvent.Created: _contentEvents.CreatedContent += _contentEvents_CreatedContent; break; case ContentEvent.Published: _contentEvents.PublishedContent += _contentEvents_PublishedContent; break; default: throw new ArgumentOutOfRangeException(nameof(contentEvent), contentEvent, null); } } private void _contentEvents_PublishedContent(object sender, ContentEventArgs e) { _logger.Log("Published", e); } private void _contentEvents_CreatedContent(object sender, ContentEventArgs e) { _logger.Log("Created", e); } } </code></pre> By calling Initialize and providing settings, we can attach to different (or multiple) events. As with dependency injection configuration, we can add a helper extension method. Notice that for this extension method I used Use prefix. Also, same as in ASP.NET Core. <pre><code class="lang-csharp">public static void UseContentEventLogger( this InitializationEngine context, Func<InitializerSettings, InitializerSettings> configure) { var settings = configure(new InitializerSettings()); var initializer = context.Locate.Advanced.GetInstance<Initializer>(); initializer.Initialize(settings); } </code></pre> Besides, do not forget to register our initializer in a container with AddContentEventLogger extension method. <pre><code class="lang-csharp">public static void AddContentEventLogger( this ServiceConfigurationContext context, Func<LoggerSettings, LoggerSettings> configure) { var settings = configure(new LoggerSettings()); context.Services.AddSingleton(settings); context.Services.AddSingleton<ContentEventLogger>(); context.Services.AddSingleton<Initializer>(); } </code></pre> Once this is done, the user can attach to the different events in their IInitializableModule. <pre><code class="lang-csharp"> public void Initialize(InitializationEngine context) { context.UseContentEventLogger( x => x .SubscribeTo(ContentEvent.Created) .SubscribeTo(ContentEvent.Published)); } </code></pre> <h2 id="summary">Summary</h2> Providing configuration options for your library users is important. However, it is also important to have a good API. By following ASP.NET Core example, we can create nice configuration API for Episerver too. For the full example, check <a href="https://github.com/marisks/examples/tree/master/ContentEventLogger">GitHub</a>. # configuring! 2018-10-30T01:00:00.0000000Z

Blog post

Fluent configuration API for your Episerver libraryIn the <a href="/2018/08/28/configuring-your-epsiserver-libraries-net-core-way/">previous article</a>, I have created an extension method for InitializationEngine to be able to pass configuration settings to my library: <pre><code class="lang-csharp">public void Initialize(InitializationEngine context) { context.UseMyLibrary(settings => { settings.MyProperty = 20; return settings; }); } </code></pre> The extension method expects a function parameter which will return configured settings. This could be simplified by passing an action method (<code>Action<MySettings></code>) instead, but the function was used on purpose. It gives us an option of creating a fluent API. The usage of such API could look like this: <pre><code class="lang-csharp">public void Initialize(InitializationEngine context) { context.UseMyLibrary(settings => settings .WithMyProperty(20) .WithAnotherProperty("Hello")); } </code></pre> There are two ways how we can build this - with mutable and immutable settings class. There are several benefits of using one over another. <h2 id="mutable-fluent-api">Mutable fluent API</h2> A mutable option is simple. You have to create methods which manipulate the internal state of the object and returns it as a result: <pre><code class="lang-csharp">public class MySettings { public int MyProperty { get; } public string AnotherProperty { get; } public MySettings() { MyProperty = 10; AnotherProperty = string.Empty; } public MySettings WithMyProperty(int value) { MyProperty = value; return this; } public MySettings WithAnotherProperty(string value) { AnotherProperty = value; return this; } } </code></pre> <h2 id="immutable-fluent-api">Immutable fluent API</h2> An immutable fluent API is harder to implement, but it allows for sharing the settings and modifying those independently. It would enable pre-build settings and then create different configurations based on the pre-built. <pre><code class="lang-csharp">var settings = new MySettings() .WithMyProperty(10); var settings1 = settings.WithAnotherProperty("Hello"); var settings2 = settings.WithAnotherProperty("world!"); </code></pre> Here settings1 and settings2 are two different objects with different values. Such a scenario is not possible with mutable settings - there would be only one object which would hold the last value; The most straightforward implementation would require you to copy all unchanged values to the new object in each method: <pre><code class="lang-csharp">public class MySettings { public int MyProperty { get; private set; } public string AnotherProperty { get; private set; } public MySettings() { MyProperty = 10; AnotherProperty = string.Empty; } public MySettings WithMyProperty(int value) { return new MySettings { MyProperty = value, AnotherProperty = AnotherProperty }; } public MySettings WithAnotherProperty(string value) { return new MySettings { MyProperty = MyProperty, AnotherProperty = value }; } } </code></pre> This works, but with lots of properties, it would be annoying to do copying manually in each method. In F# there is a copy-and-update record expression (with) for record types (immutable classes). <pre><code class="lang-fsharp">let settings = {myProperty=10; anotherProperty=""} let settings1 = {settings with anotherProperty="Hello"} let settings2 = {settings with anotherProperty="world!"} </code></pre> In C#, you can create a method which internally could mutate the new object. Then there would be only one place where you should modify copying logic: <pre><code class="lang-csharp">public class MySettings { public int MyProperty { get; private set; } public string AnotherProperty { get; private set; } public MySettings() { MyProperty = 10; AnotherProperty = string.Empty; } public MySettings WithMyProperty(int value) { return With(settings => settings.MyProperty = value); } public MySettings WithAnotherProperty(string value) { return With(settings => settings.AnotherProperty = value); } private MySettings With(Action<MySettings> mutate) { var settings = new MySettings { MyProperty = MyProperty, AnotherProperty = AnotherProperty }; mutate(settings); return settings; } } </code></pre> <h2 id="summary">Summary</h2> Fluent APIs give us simple, easy discoverable APIs. Those can be useful when configuring your application or library. You can implement those as mutable or immutable. Mutable APIs are simpler to implement but has trouble with sharing. Immutable APIs are a little bit harder to implement but are more flexible. So for simple scenarios with few settings, it would be okay to use a mutable API. When you have lots of properties which you need to share and create different configurations for different cases, use immutable solution. 2018-09-14T02:00:00.0000000Z

Blog post

Configuring your Episerver libraries .NET Core way<h1 id="drawbacks-of-initializable-modules-and-configuration-settings">Drawbacks of initializable modules and configuration settings</h1> The main drawback of initializable modules in libraries is that a library user cannot control when an initializable module is called. The user might want to disable initialization code too. Another drawback is the startup time. Episerver scans for initializable modules, and it will take slightly more time to find and run those. If each small library would have an initializable module, then a more significant project which uses several libraries might be slow at startup. Putting configuration settings in the Web.config forces to use only one way of configuration. If a developer wants to retrieve a configuration from another source (for example, database), then there is no way to do it. Also, in the future when we will get to .NET Core in Episerver, the library which forces usage of Web.config will not work anymore. <h1 id="the-new-way">The new way</h1> First of all, the configuration should be done in the code. This allows a developer to choose the source of configuration. In the simplest form, it is hardcoded in the code. ASP.NET Core has an excellent example of how to achieve it. It uses <a href="https://docs.microsoft.com/en-us/aspnet/core/fundamentals/startup?view=aspnetcore-2.1#the-configureservices-method">ConfigureServices</a> method for IoC configuration and <a href="https://docs.microsoft.com/en-us/aspnet/core/fundamentals/startup?view=aspnetcore-2.1#the-configure-method">Configure</a> method for request handling (and other) configuration. In Episerver, we have two similar extension points - <a href="/link/ebeb7390a6de4c16a2530221b226e292.aspx">IConfigurableModule</a> for IoC configuration and <a href="/link/be4f88d913c443549fcc389dc543fc42.aspx">IInitializableModule</a> for other initialization code. Previously, we used to create own IConfigurableModule and IInitializableModule in our libraries, but instead, we should allow our library users to call library configuration code in their modules. The usage of an imaginable library's - MyLibrary configuration might look like this: <pre><code class="lang-csharp">[InitializableModule] public class IoCModule : IConfigurableModule { public void ConfigureContainer(ServiceConfigurationContext context) { context.AddMyLibrary(); } public void Initialize(InitializationEngine context) { } public void Uninitialize(InitializationEngine context) { } } [InitializableModule] [ModuleDependency( typeof(EPiServer.Web.InitializationModule), typeof(EPiServer.Commerce.Initialization.InitializationModule))] public class AppInitialization : IInitializableModule { public void Initialize(InitializationEngine context) { context.UseMyLibrary(settings => { settings.MyProperty = 20; return settings; }); } public void Uninitialize(InitializationEngine context) { } } </code></pre> Here I am using the same naming as in ASP.NET Core - IoC configuration extension methods start with Add and configuration methods in an initializable module start with Use. In the initializable module, you will have an option to configure the library by passing an action with settings configuration as a parameter. An extension for IoC configuration is simple. It just registers your classes in an IoC container. <pre><code class="lang-csharp">public static class IoCExtensions { public static void AddMyLibrary(this ServiceConfigurationContext context) { context.Services.AddTransient<IService, Service>(); } } </code></pre> An extension with configuration is a little bit more complicated. First of all, you will need a settings class. You can add default settings in the constructor. <pre><code class="lang-csharp">public class MySettings { public MySettings() { MyProperty = 10; } public int MyProperty { get; set; } } </code></pre> Next, you need a class as an entry point for your library initialization. This class is responsible for passing settings to an appropriate destination. It could be some context class, storing in a database, passing settings to the service classes, etc. <pre><code class="lang-csharp">public class MyLibraryInitializer { IService _service; public MyLibraryInitializer(IService service, IService2 service2 ...) { _service = service; } public void Initialize(MySettings settings) { _service.AddMyProperty(settings.MyProperty); } } </code></pre> Now you can create an extension. This extension is just responsible for passing configured settings to the initializer. <pre><code class="lang-csharp">public static class InitializationExtensions { public static void UseMyLibrary(this this InitializationEngine context, Func<MySettings, MySettings> configure) { var settings = new MySettings(); settings = configure(settings); var initializer = context.Locate.Advanced.GetInstance<MyLibraryInitializer>(); initializer.Initialize(settings); } } </code></pre> Now with this approach developers are free to choose how and when to call the initialization code of your library. 2018-08-28T02:00:00.0000000Z

Blog post

Finding content type conflict reasons with Episerver Developer toolsAfter writing the previous article about this topic, I have created a pull request to Episerver Developer Tools with the changes required to solve this issue. I have made some changes though. I have added support for ACL conflicts. Now when using Episerver Developer Tools, you will be able to see those too. You can see content type conflicts in the Developer tools under Content Type Analyzer section. There is a separate column - Conflicts where you will find conflict details. Here is an example of how those will be displayed. <img src="/img/2018-07/content-type-conflicts.png" class="img-responsive" alt="Content type conflicts" /> Field order here is a conflicted property name. Then you will see the value defined in the code and a database. Below is a list of conflicts it displays. For content types: <ul> <li>Model type</li> <li>Name</li> <li>Description</li> <li>Display name</li> <li>Sort order</li> <li>GUID</li> <li>Availability</li> <li>ACL</li> </ul> For property types: <ul> <li>Tab name</li> <li>Name</li> <li>Description (help text)</li> <li>Display name (edit caption)</li> <li>Culture specific (language specific)</li> <li>Required</li> <li>Searchable</li> <li>Available in edit mode (display edit UI)</li> <li>Field order</li> </ul> 2018-07-16T02:00:00.0000000Z

Blog post

Dangerous scheduled jobsOur project was throwing exceptions related to database deadlocks and other concurrency issues. However, this was occasionally happening during the import. The first thing I thought, that maybe there is an issue with multiple Azure website instances. I checked if two instances are running the same job in parallel. However, it seemed that those weren't. Recently, we were migrating the project to the DXC and were copying blobs to the DXC. We have stopped all scheduled jobs which could update blobs. Then we have noticed that blobs were still changing as if import job is running. I have checked the jobs, and all were disabled in admin UI. Then checked those in a database and found that there are multiple records with the same jobs. The only difference was a display name. As I understand, it happened when we have changed the display name of the scheduled job. Episerver created a new record and didn't remove the old one. I have checked with other colleagues that they also have this issue in Episerver CMS 11, but it doesn't appear in CMS 10. You can omit this issue if you set GUID of your scheduled job: <pre><code class="lang-csharp">[ScheduledPlugIn(DisplayName = "ScheduledJobExample", GUID = "d6619008-3e76-4886-b3c7-9a025a0c2603")] public class ScheduledJobExample : ScheduledJobBase { } </code></pre> You also should check if in your current database there are job duplicates. The easiest way is to sort the jobs by the type name in a SQL query: <pre><code class="lang-sql">SELECT * FROM [dbo].[tblScheduledItem] ORDER BY TypeName </code></pre> I have noticed that even Episerver scheduled jobs are duplicated. Once you found all your duplicated jobs, you can remove those with a script: <pre><code class="lang-sql">DECLARE @id AS uniqueidentifier = '3134D210-6971-4DF4-8662-FB4E67E41B80' DELETE [dbo].[tblScheduledItemLog] WHERE [fkScheduledItemId] = @id DELETE [dbo].[tblScheduledItem] WHERE [pkID] = @id </code></pre> <h2 id="summary">Summary</h2> This was a nasty issue we haven't noticed for a long time. It could be omitted if GUID field would be made mandatory by Episerver. Also, Episerver should handle duplicate jobs - remove which doesn't match the job definition in code. 2018-06-12T02:00:00.0000000Z

Blog post

Episerver Commerce 11 to 12 upgrade market breaking changesEpiserver has made the Market property on IOrderGroup obsolete. If you are using it, you will see this warning message: <pre><code class="lang-text">'IOrderGroup.Market' is obsolete: 'This property is no longer used. Use IMarketService to get the market from MarketId instead. Will remain at least until May 2019.' </code></pre> At first, you are tempted to ignore it and fix later as this is just obsolete. You expect it to work as before for some time. However, this is a breaking change you will notice in runtime. The Market property will be null. So fix all warnings related to this property and use IMarketService to get the market you need: <pre><code class="lang-csharp">private readonly IMarketService _marketService; public ProductController(IMarketService marketService) { _marketService = marketService; } private void Run(ICart cart) { var market = _marketService.GetMarket(cart.MarketId); } </code></pre> Episerver has documented all breaking changes here: <a href="/link/900665308fdf4e1ab4ade839886c3af2.aspx">Breaking changes in Commerce 12</a>. 2018-05-31T02:00:00.0000000Z

Blog post