I have recently done some work on an EPiServer build for the first time in a few years. Despite EPiServer’s growing focus on value-add areas such as e-commerce and marketing automation there has also been a lot of investment in the core content management engine.  The overall impression is of a rapidly maturing CMS that is much easier to implement than it used to be.

No longer just about the page

EPiServer used to be a page-orientated CMS in that it was based around the creation of web pages. The template system relied on page types that allowed you to define content and behaviour on a page-by-page basis.

The problem is that a page is too coarse a template.  Modern website designs tend to take a modular approach to content with pages being composed from a number of independent content elements. Rendering also tends to driven more by context, such as the user's device or their past browsing behaviour,

This need for more flexible content can’t be easily addressed at the page level. Sites based on page types tended to suffer either from template bloat where there were either too many page types or property bloat where existing page types had become too complex.

Incorporating the content block functionality into the core CMS that was originally implemented by the Composer add-on has pretty much solved this problem. Blocks provide a finer grained content template that makes it easier to offer flexible layouts and rendering options. It makes EPiServer feels more like a modern content management system rather than one that is too heavily orientated around the increasingly dated notion of a web page.

MVC Support

One challenge for all CMS platforms is that the underlying technology stack is prone to on-going change. This has been the case with Microsoft web development, where the focus has shifted decisively from WebForms to MVC in recent years.

This is a major shift that many platforms have been slow to accommodate and some have been trapped by their previous technology investment. For example, Ektron still delivers much of its marketing functionality using widgets developed via WebForms forcing any sites that need to leverage these features into an older technical stack. EPiServer on the other hand appear to have caught up with Microsoft and the CMS feels like a natural and sympathetic extension to MVC .

Code-driven models

Defining your templates and properties in code is a no-brainer. It just makes your sites easier to develop and a lot more robust. Pretty much everybody was using  PageTypeBuilder before version 7 made it all official and introduced strongly-typed models into the core CMS. Now it’s standard practise rather than a trap for the uninitiated.

Less customisation required

Most sites need to extend the base property types offered by EPiServer. This used to involve a fair amount of tedious work but EPiServer now offers a number of simpler strategies that meet most customisation scenarios. You can tweak the implementation of properties using attributes, define custom lists in a single class and use content blocks to define grouped or complex properties.

This is important as the majority of templates can be created through simple development tasks rather than delving into more challenging framework customisation.

The new media system

The old Virtual Path Provider system always felt like a bit of a fudge. It didn’t play well in vendor selections where customers wanted more control over their asset management.  The architectural purist in me also felt a little sniffy about the dual content repository. After all, why should pages be treated any differently from files? It’s all content, right?

This appears to have been solved now with the introduction of IContent in place of the more page-orientated PageData class. There may still be a separate file repository going on under the hood, but the API does at least treat all content equally.

Deployment options

EPiServer used to come with quite a lot of baggage that had to be deployed onto a server before you could get sites to run. That has been sorted out so sites are now fully self-contained, deployable units.

This is important as it opens the way to deploying on cloud-based environments such as Azure. It was pretty straightforward to get EPiServer to play nice with the entire development and deployment pipeline in Azure, from source code control through to continuous, automated deployment to Azure websites.

More documentation

Earlier versions of EPiServer did suffer from patchy documentation. Some features required guesswork to get working and you would occasionally resort to Reflector to work out what’s going on under the hood.

From my own experience working for software vendors I know how difficult it can be to prioritise decent documentation. It requires considerable on-going effort and tends to lose out to customer-demanded features in any prioritisation shake-down.

In the last couple of years EPiServer do seem to have made more of an effort in filling out the gaps. With the on-going efforts of the development community in the mix (Joel Abrahamsson’s book has been particularly useful) the collective knowledge base seems much more comprehensive these days.

The dashboard

Nope. Still not sure what people use this for.

The other stuff

To be honest, I’m only really interesting in the core content management framework. I tend to preserve CMS for the content use case rather than leveraging the various add-ons for other aspects of an architecture. There are a host of other improvements and features being added as EPiServer expands into areas such as marketing automation and e-commerce. However, they do appear to be continuing to invest heavily in improving their core remit of content management.

Filed under CMS and UI Development.