SUGCON Europe 2019

I attended the SUGCON event in 2019 and thought I'd jot down my thoughts on the various presentations I went to as well as some overall thoughts about the conference in general. I have a lot more to say about the talks I attended on day 2 for some reason, maybe the talks were structured that way, maybe I had just had more coffee. Below are my breakdowns for both days and then my thoughts on a few things in general.

Restricting the number of times a rendering can be added to a placeholder

This is another one of those tasks that shouldn't really be necessary to do. Every time a client says "We don't want two of these components added to this placeholder" my answer is always "So don't add two." It's a people problem that companies want solved with technology. This solution is geared more toward the use of the Experience Editor and it is going to stop a rendering appearing in the "Select a rendering" dialog if it already exists in that placeholder the maximum number of times.

Post-Processing html after it has been generated in Sitecore

Sometimes we might want to do an operation on the entire html generated for a page, such as move elements around, do some text replacements or regex-based url amendments.  The MVC framework has various features like action filters, result filters and so on, but we can't really use these with Sitecore the same way we would a native MVC site.  In traditional MVC your page is the result of a single action, but in Sitecore it is lots of actions stitched together so there is a little more work to do, so let's get started.

Restricting the number of sub items in Sitecore

In this blog I will be showing a technique that lets us use the Sitecore Rules Engine to restrict how many sub-items an item can have. This restriction is fully configurable and can be based on template types, path locations, item names or any other condition you would like to define.

Managing CSS files in Sitecore

This article shows how you can manage CSS files in Sitecore. This is one of those techniques that I don't exactly recommend as it shouldn't really be needed, but sometimes it can be a compromise to allow front-end designers to modify CSS on the fly. One of the advantages of doing this is that having Sitecore drive your CSS means your CSS can also follow the restricted publication process allowing your CSS to change depending on the date. I was working on a site that had a "deal of the day" where each day had a different offer and that offer was reflected on the home page. This technique allowed the designer to version the home page for each day, and also version the css tweaks for each day and set up the site for the whole week in advance. On each morning we simply did a publish and the publish restrictions we'd set up on the versions meant the homepage and css reflected that day's deal.

Note that the css for the majority of the site was still handled in css files, the css that we made driven from Sitecore contained only slight modifications the designer wanted so that buttons looked different, fonts for some components were different and so on.

Design issues with Sitecore sites

When building a website most companies tend to have designers, or front-end developers, that are fairly hands-on.  Not only do they do the actual site designs but they do the html\css too and sometimes the javascript if needed, or the implementation of any javascript frameworks that are used.  It's also not unusual for this to be the company's first Sitecore solution and all of these things can create their own challenges which I'm going to talk about in this blog.  It's not all technical issues though, it often comes down to politics and people management too.

MVC Validation with Sitecore

MVC comes with a validation framework that supports both server-side and client-side validation with very little coding.  You can still use this framework with Sitecore MVC if you wish, but it breaks a few fundamental aspects of content management systems, namely that the error messages you use won't be content editable as they are embedded in your code.  This article shows how we can use the built-in MVC framework and also allow the messages to be content manageable, and also multi-lingual.

IDataSourceFilterFactory error when using SwitchMasterToWeb.config

When configuring your content delivery servers you might well be using the SwitchMasterToWeb.config available from Sitecore.  When using this file you might find your site's analytics data stops gathering and that it generates an error like this with every page request;

Exception: System.InvalidCastException
Message: Invalid cast from 'System.String' to 'Sitecore.Analytics.Reporting.Filters.IDataSourceFilterFactory'.

Dynamic placeholders and tabs in Sitecore

The problem

One issue with using placeholders embedded inside Sitecore renderings is that a placeholder can only appear once on the page. If a placeholder with the same name is placed multiple times then Sitecore doesn't know which placeholder is being referenced when it comes to adding the placeholder's controls. If you are using renderings as reusable layouts then this can be restrictive. As an example, let's say your pages have places where you want to show three columns of renderings, and what renderings go inside each component will be decided on a per-page basis. You might create a rendering that looks like this

<div class="columncontainer">
    <div class="col-33">
        @Html.Sitecore().Placeholder("left column")
    </div>
    <div class="col-33">
        @Html.Sitecore().Placeholder("middle column")
    </div>
    <div class="col-33">
        @Html.Sitecore().Placeholder("right column")
    </div>
</div>

and you can then drop that rendering on any page where you want to show three things in columns. Great, but what if you want to show two of these on the same page? Maybe on top of each other giving two rows of three columns. There is nothing stopping you adding two of the renderings to the same page, but when you do you end up with this

<div class="columncontainer">
    <div class="col-33">
        @Html.Sitecore().Placeholder("left column")
    </div>
    <div class="col-33">
        @Html.Sitecore().Placeholder("middle column")
    </div>
    <div class="col-33">
        @Html.Sitecore().Placeholder("right column")
    </div>
</div>
<div class="columncontainer">
    <div class="col-33">
        @Html.Sitecore().Placeholder("left column")
    </div>
    <div class="col-33">
        @Html.Sitecore().Placeholder("middle column")
    </div>
    <div class="col-33">
        @Html.Sitecore().Placeholder("right column")
    </div>
</div>

Now when you tell Sitecore you want to put "Featured product" in the "middle column"...how does Sitecore know which "middle column" you are reffering to? There are two on the page. This limitation can also affect you if you want to do a flexible tab component. Let's say you want a rendering that can show tabbed content and you want the number of tabs to be dynamic. This does have a workaround, when you are creating your tabs you can give each placeholder a unique id based on its index.

<div class="tabs">
    <div class="tab">
        @Html.Sitecore().Placeholder("tab_1")
    </div>
    <div class="tab">
        @Html.Sitecore().Placeholder("tab_2")
    </div>
    <div class="tab">
        @Html.Sitecore().Placeholder("tab_3")
    </div>
</div>

That will work ok, but how do you control what renderings are valid to go inside each placeholder? What renderings can be placed where is configured in the Placeholder Settings section;

/sitecore/layout/Placeholder Settings

Here you create a "Placeholder" item for each placeholder and that item contains the placeholder key and a list of renderings that are valid for that placeholder. If you have placeholders like "tab_1", "tab_2 and "tab_3", then you will need to create 3 Placeholder items, one for each tab, and for each one defining what controls can go in that tab. Not only is this a lot of messy duplication, what happens when someone wants 4 tabs?

Customising wrappers

Introduction

When trying to build flexible, generic components that are highly configurable by content editors or designers, sometimes the issue of configurable wrapper element comes up.  For example I might have a text or image field, and I might want to be able to specify if it is wrapped in an h1 tag, or I might want it in an h2 tag, a div with a certain class, or maybe just a p tag will do.  Wrapping elements isn't a problem if your field is defined as a rich text field and you're selecting the styles from the toolbar; this solution is intended for fields that aren't.

Creating your own context objects

Context objects

Sitecore provides a number of contexts to allow you to enable and disable certain framework features on a case by case basis. For example if you want to run a piece of code without any security concerns you can use the SecurityDisabler.

using (new SecurityDisabler())
{
    // your code here
}

Any code inside the SecurityDisabler block will ignore all security concerns, so it can create items, edit items, delete items etc without the logged in user having the appropriate permissions. Another common context to use is the BulkUpdateContext. If you are doing a lot of updates to Sitecore items as part of a maintenance routine then putting your code inside a BulkUpdateContext stops Sitecore from recording things in the history engine which will increase the performance of your code.  Similarly the EventDisabler prevents events from being raised.

It's a handy technique that you might want to leverage yourself. In one solution we had caching built at a deep layer, but for certain admin functions we didn't want to use the cache, we always needed the actual data. The solution was to use our own context that could disable caching.

Giving content editors control over styles

Introduction

When building a Sitecore solution one of the largest mindset decisions is who the client of your solution is going to be.  Is your site going to be managed by developers?  Or is it going to be managed by the business?  One of the advantages of a CMS is that it gives the business the ability to manage the site themselves, ie your marketing people, your product people and so on, who can run the site without needing help from a developer.  This concept of an end product that can be managed without developer input is of benefit to everyone; the business can instantly do the things they want to do, and developers only need to spend their time developing and not changing META data or page titles.  However many of the Sitecore solutions I get asked to consult on can only realistically be maintained by developers.

There are a few common practices that make for a "developer only" Sitecore solution, but the one I am going to discuss in this blog revolves around configuring styles.  This article assumes you already understand the basics of creating renderings, it's not going to be a complete tutorial on creating Sitecore components.

Using Membership with Sitecore

Sitecore's authentication and user management uses asp.net membership with the membership schema in the Core database.  To use authentication in your own sites you can use this membership system yourself, or if you have your own existing membership database you want to use, or you want to implement membership on your site and don't want to use a separate database rather than keeping your users in the Core database, then it is possible to configure Sitecore to implement multiple asp.net membership databases.

How Sitecore manages icons

Introduction

Any Sitecore developer knows that building a Sitecore solution is 20% writing code and 80% choosing icons.  You might not have given icon management any thought, but not only is it possible to create your own icons for use with Sitecore, but there are already more icons available to you than you think.

Sitecore pipelines in high volume sites

Introduction

If you use class-level variables in your Sitecore pipelines you might discover inconsistent and unwanted behaviour.

Using .net caching with Sitecore

Introduction

Sitecore has an extensive caching framework that allows it to cache everything from items in its database all the way to the html output of its renderings.  When using Sitecore's cache framework it employs a number of techniques to ensure that the cached data remains valid, and if you use .net's own caching framework this can sometimes conflict with Sitecore.  For example, let's say you have a menu control that appears on every page so you use .net's output caching to cache the html.  If a content editor changes something in Sitecore that affects your menu such as creating new elements, renaming titles etc, then your site is going to continue serving up the cached version which is no longer valid.  If you use Sitecore's own caching framework by setting cache parameters on the rendering then Sitecore will clear these cached items when a publish happens, ensuring that the cached html is rebuilt using the new data.  Furthermore, Sitecore will disable caching when you are in preview or edit mode so you know your data is always fresh.

As well as html caching, you might want to cache data structures you have built from Sitecore items.  Let's say you have a list of countries and in each country is a list of cities and you use this data often, so would like to cache it.  If you use .net caching and the underlying data in Sitecore changes, your cached data is now invalid.  You could set an expiry on the cache, but that's far from ideal as you don't want to tell your content editors that they have to wait before they see their changes go live.
In this article I am going to show you how to hook into the publishing mechanism such that your cached items are removed when a publish occurs.