A journey through the changes between EPiServer CMS 6 and 7


A journey through the changes between EPiServer CMS 6 and 7

A journey through the changes between EPiServer CMS 6 and 7


The intention of this blog post is to help developers who are new to EPiServer 7 to get a quick overview of how they can expect to use their EPi 6 knowledge and get started with version 7. It provides a starting point for further reading and a few easy-to-understand code samples.

So, let's give it a go starting with the breaking changes!

Breaking Changes

The first thing I have looked up is the article about the breaking changes since version 6.

These are the ones I found the most important from dev's point of view:

  • Content model changes
  • MVC support
  • Initialization engine
  • Client resources

Those that won't affect us a lot, but still need to be addressed, are:

  • IIS 6 support removed
  • MVC 4 required
  • Parts of configuration are removed or restructured
  • Localization service classes and methods

Content Model Changes

Perhaps the best explanation of content model changes is given by Joel Abrahamsson in his blog post here. It's a blog post I strongly recommend everyone to start with. It's clear and to the point, giving an overview of EPi 6 data model and explaining the new EPi 7 concepts.

IContent instead of Page

At Mogul, we needed the concept of blocks a while ago. So, we created our own blocks, which were, in fact, containers of properties, but essentially saved to database as an EPiServer page. With the old concept of Pages, being the exclusive data container, we could have done a lot, but now, with IContent, blocks, content folders and pages, the needed support from the CMS itself makes it a lot neater.

Blocks, blocks, blocks!

Blocks are (usually) reusable content parts, that define a set of properties and are rendered via user control (ascx or cshtml, in case you, as we did, prefer MVC + Razor).

Things get a bit complicating when you try to unveil the meaning of a word usually written in Italic in the paragraph above. You can have "shared blocks" and "local blocks".


Shared blocks are those you see in the blocks tree, when you click on the top right assets pane in edit mode.


The "local block", is saved as part of a Page and can't be added to the above displayed block tree. It is more of a container of properties whose block type will be reused on pages, but not the specific block instance. The values for these properties will be local to the page and versioned along with page versioning.

Defining "shared" vs. "local" block

There is no difference between the definition itself of a shared and local block. Both are inheriting from the BlockData. If you click on the image example bellow, you can see a basic example of a standard block, or download the example class here:

       GroupName =  GroupNames.PushBlocks,
       GUID = "6291D0C7-8DB0-4BCD-9216-7B3FD3F50573")]
    public class StandardBlock : SiteBlockData
            GroupName = SystemTabNames.Content,
            Order = 100)]
        public virtual PageReference TeaserUrl { get; set; }

            GroupName = SystemTabNames.Content,
            Order = 300)]
        public virtual string Heading { get; set; }
            GroupName = SystemTabNames.Content,
            Order = 400
        public virtual XhtmlString MainContent { get; set; }

The real difference is how you use the block.

Using local and shared block on IContent

Once a block is defined, it can be used in two ways, either referenced directly on the page or put to a ContentArea. If a block has:

    AvailableInEditMode = true;

it won't be available for creation inside the block tree. Usually, local block has this property set to true, but it's possible to use a block type as both shared and local block.

Basically, on a page type (or another block type), you would either use:

    public virtual ImageBlock Image { get; set; }

or have a content area for as many blocks as you like:

    public virtual ContentArea Block { get; set; }

The former is adding properties to IContent you have created; the latter requires a block from the tree and just saves a reference to its blocks.

Block in a block in a block...

It can get pretty wild if you define a page with a ContentArea and place a block inside with another ContentArea, where you again... oh, you get the point.

Here at Mogul, we have recently had a lunch seminar on the very same topic (Intro to EPi7) and an interesting discussion arose regarding this topic. These were the conclusions:

  • The blocks and content areas concept do give a huge flexibility
  • We, as developers, are always thinking how we can take the maximum of new possibilities
  • Users **still need to be guided** by good system design and things could get pretty complex if you keep nesting

We have come to the conclusion that it is better to sometimes sacrifice the flexibility in order for the customer to have a better user experience. Apart from that, it's pretty non-standard to use the block -> block -> block structure to retrieve data from the block tree. The code tends to become rather complex if you browse through this structure, especially if the user is allowed to place anything to a content area.

Not everything is a block!

Another important conclusion would be when to use a shared block and when "static" properties on the page (everything seems so static without blocks).

When some info is related to the page content, it is much clearer for the editor to have it on a page as a property or as a local block (not much difference for the editor there). When there is, let's say a contact page teaser that would be placed on many pages or a product teaser, a shared block seems like an excellent choice!

When there is some content that includes other content, like having sub-steps inside steps, it's better to define maximum number of steps than to have an extra ContentArea.

Tough start, but much learnt!

The start date of our first EPi 7 public web was in December last year. To be honest, it was not super easy to get started, especially if deciding to use MVC. Without the EPiServer forum and a strong community, it would be tough to solve some of the problems we have stumbled upon in the process.

However, common development mistakes and challenges are well known now and we are so happy we have gained the experience so early.