TLDR; Update CookieDropBlock if you want to keep using it.
Over five years ago I released a simple tool called CookieDropBlock who's sole purpose was to allow editors to create a block to drop a cookie for an end user. You can read more about it here: https://www.david-tec.com/2015/09/cookie-drop-block-for-episerver/. This has worked largely untouched for all this time.
However there is a bug that will affect anyone who is using it today.
Geta has created an alternative to the built in Episerver category system called EpiCategories. Its a well maintained and mature add on that adds some great capabilities over and above the built in category system in Episerver. It can wholly replace the built in category system and adds nice features like the ability to create/edit categories in edit mode, access rights, category routing and the ability to translate categories (amoungst others).
I wanted to migrate a site to start using Geta Categories but noticed the default package doesn't have any migration tools. So this post shares two scheduled jobs I wrote to do two things:
The latest version of the Episerver UI comes with a new look which changes up how things work and is intended to create a consistent look/feel across all parts of the Episerver platform. The UI update as described in the CMS UI refresh post and is designed to be an opt in so for any existing modules the UI should remain the same.
The blog describes how I updated Virtual Template System for Episerver to be compatible with the new Episerver Platform UI.
A new version of Virtual Template System is now available that adds the ability to search in file contents. This runs a case-insentive search on the file contents and also on the file name. This now means its possible to quickly search through all templates when looking at a live site to try and track down the template that was rendering a particular piece of content. In the example above I quickly track down the template that's used to render the contacts in Alloy:
A new version of Virtual Template System is now available that adds the ability to see a version history of the template from the UI. It also changes some of the UI to add icons.
The version history can now be accessed by clicking on the changed by button as shown below:
A new version of Virtual Template System is now available with UI updates, bug fixes and refactoring to the internals. Virtual Template System allows users to view and edit templates in the Episerver UI.
The updated UI can be seen in the video below:
A new version of Virtual Template System is now available that adds the ability to diff and merge an edited template with the original version that is deployed on disk. Virtual Template System allows users to view and edit templates in the Episerver UI.
The diff/merge tool can be seen in action in the video below:
Some time ago I built an add-on that allowed users to edit the Views/CSS/JS that are used to deliver an Episerver site called Virtual Template System. This has now been updated to be compatible with Episerver 11.
Why would we wish to let users edit templates in the UI?
Clients are in a rush, editors are continually getting smarter and are more demanding too. People hate waiting for the dev team or a deployment to happen particularly when the issue can be solved with a simple template change. In short people just don't want to wait and with the right power/skills users should be given the power to make changes themselves as long as they have a full understanding of the consequences.
Episerver Profile store is an tool for capturing profile information and behaviours that can be visualised in Episerver Insight. Episerver Profile store can be connected to any system using standard RESTful APIs to update and add profile information for users. However there isn't currently an out the box way for users to collect user data using Episerver Forms and push this data into Episerver Profile store which can be seen in the Episerver Insight UI.
So I decided to create an add-on that would allow editors to map Episerver Form fields to Episerver Insight/Profile store fields. When using it editors set up their form as normal but also get an additional tab called "Insight profile mappings". This tab can be used to specify a property to save the form data to in the Episerver Insight profile:
By default when installing the Episerver Campaign connector its possible to configure the connection through admin mode. However in some occasions (such as in development and test scenarios) it may be desirable to configure these credentials through code.
This posts describes how to configure the Episerver Campaign Connector through code using an Episerver initialisation module:
The official Episerver documentation has been updated to include some of the content in this post. More information: https://world.episerver.com/documentation/developer-guides/CMS/dynamic-content/migrating-dynamic-content-to-blocks/
Episerver Dynamic Content was a tool that allowed developers to programmatically insert content into XHTML property values and was introduced in Episerver around 2010.
My blog runs Episerver 11 and I’ve used Dynamic Content in the past for embedded code snippets (though I normally just embed straight from Gist these days). So I decided it was long overdue that I move away from using Dynamic content as it’s a obsolete piece of tech, isn’t compatible with the new TinyMCE editor, doesn’t work with the new Episerver Headless API and sooner or later will go out of support completely.
This is the approach I took when migrating from Episerver Dynamic Content to Episerver Blocks.
A new compare option is available for Episerver 11 which gives editors the ability to visually compare two pieces of content as shown in the example below:
In the example above the text changes are highlighted with appropriate red/green highlights. When a text change has been made it means its easy to spot that has been changed quickly.
A scope in Episerver Insight defines a logical grouping of profiles. So given this scenario:
Just a quick note to self on how to control access to the Episerver Insight UI.
Episerver Insight Profiles UI access
Access to the profiles section is allowed if any of the following is true:
The Episerver visitor group criterion that allows editors to define visitor groups depending on whether an end user is participating in an A/B test is now available for Episerver 11.
The package adds a new visitor group called “Participating in A/B test” as shown below:
Episerver has recently released Episerver Insight which is the user interface for viewing, filtering visitor profiles and creating segments. This relies on Episerver Profile store in order to store profile data.
This post describes how its possible to load a user profile and update some properties on it using the Episerver Profile Store API. As Episerver Profile store is a pure RESTful API it means developers can choose any way to interact with it. For this example RestSharp is used to connect to the API and uses Newtonsoft.Json to manipulate the data.
In this example I want to perform the following operations:
A new version of the cookie visitor group criteria is now available on the Episerver Nuget feed that is compatible with Episerver 11.
The package adds two new visitor groups called "Cookie exists" and "Cookie Value Equals". These visitor groups allow your site editors to personalise content based on whether a cookie exists or on the value contained within a cookie.
A new version of the Visitor Group Usage Viewer is now available on the Episerver Nuget feed that is compatible with Episerver 11.
The visitor group usage viewer adds a new component that shows the visitor groups that are used on the current content item when in Episerver edit mode. It also separately shows any content that's referenced on the current content item (such as blocks or pages in a content area) as this could also affect the rendering of the current piece of content:
How do I get it?
I've occasionally seen the requirement for tokenised content in Episerver. By tokenised I mean the ability to insert a token such as [ContactUsEmail] or [Telephone] site wide and have it populated based on values set at a site/section level. This allows site editors to set the value of a token once and have it populated across the site.