I have written multiple posts about how I architect and develop multi-site solutions in Episerver (now Optimizely). With the release of Optimizely CMS 12, which now runs on .NET 5, not much has changed with how I approach this, but the previous way I handled dependency injection is no longer supported.

In this post, I want to show how I'm now handling when multiple sites implement the same service (site-specific services).

Depending on your architecture and requirements for a multi-site solution in Episerver, you may need to completely separate the content types associated for each site within the editor experience. This was one of the considerations I mentioned when I wrote "Architecting Multi-site Episerver Solutions". Separating content types not only cleans up the editing experience, but also helps to streamline the page and block creation process, while also preventing editors from selecting the wrong content type (i.e. template) for the site.

To make this happen, there's multiple areas of the editing experience which we have to address differently to limit what content types are available to the editor.

This post is the fifth in a series of posts related to architecting and developing multi-site Episerver solutions using MVC Areas. In this post, I'll cover how we handle restricting content types.

An important piece of the editing experience, which is often overlooked, is block preview. This feature is an efficient way for content editors to create and edit blocks that are meant to be reused across a site. Though, when used in the context of a multi-site solution, you could run into some issues that hinder those efficiencies.

This post is the forth in a series of posts related to architecting and developing multi-site Episerver solutions using MVC Areas. In this post, I'll cover how we handle block preview.

As you are building out a multi-site solution with Episerver, you'll likely find some reuse between sites. You might be reusing page types and templates (in those cases where the sites have similar designs or wireframes) or you might be reusing block types and templates (as those smaller components don't generally need to be specific to a site). If you're not reusing content types, then maybe just the content type class names might be the same between sites.

In whichever case of reuse, getting the proper template for the content type is important. For page types, this is usually handled by a specific controller for the type, and that controller points directly to the view. But for blocks, there's a bit more flexibility about how this can be done.

This post is the third in a series of posts related to architecting and developing multi-site Episerver solutions using MVC Areas. In this post, I'll cover how we handle block controllers.

The nice part about building a multi-site solution in Episerver is the flexibility around how the project can be architected. I demonstrated this in my post "Architecting Multi-site Episerver Solutions" by providing multiple approaches in which this could be accomplished. While using the MVC Areas approach allows you to easily separate each site, it can pose a problem if each site needs to implement a specific service.

This post is the second in a series of posts related to architecting and developing multi-site Episerver solutions using MVC Areas. In this post, I'll cover how we handle multiple sites implementing the same service.