All posts for "Multi-site"

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.

In my last blog post from many years ago, I provided various ways that a multi-site Episerver solution could be architected. If you haven't read that post yet, you should do so before continuing with this one.

One of the ways I mentioned is by using MVC Areas, which Episerver does support with a little bit of work. In the time that post was written, I've gotten to build a couple multi-site Episerver solutions using MVC Areas, and I'd like to share some of my approaches to make the development and content editing process smoother.

This post is the first in a series of posts related to architecting and developing multi-site Episerver solutions using MVC Areas. In this post, I'll cover the high-level architecture decisions we've made, and what was involved in creating that base framework.

You may be aware that Episerver is a powerful platform that can be used for more than just a single website. You can utilize the underlying functionality of the platform to handle large-scale management of multiple websites in one single environment. Editors can share content throughout multiple sites, administrators can quickly launch new sites, and developers can work with one code base and database, making the sites easier to maintain.

Let's focus on the development of these multi-site Episerver solutions. How do you actually architect and develop these solutions? If you've ever tried to search for Episerver's best practices around this topic, you'll likely come up short. Sure, there's some documentation on Episerver World, but the documentation doesn't really provide any good guidelines or starting points. That's really because there's no correct way to do it. The Episerver platform doesn't force development teams to use any specific conventions when developing the multi-site solution.

So in this post, I want deep-dive into this topic to provide some considerations and approaches that you should think about before starting development on your next multi-site Episerver solution.