I've recently been working on an Optimizely CMS 12 solution for a customer that creates and publishes a large amount of content during certain times of the year. They typically create all of the content changes and track them within an Project in the CMS, then publish all the changes at once, which is a great benefit of Optimizely's Project feature.

Recently, a question came up about this: "Is there a way we can enforce content to be part of a Project so it can be published?" This feature is more about change control than general functionality. The customer wants to make sure a change to content doesn't get published prior all other content being ready and published.

In the post, I'd like to share an example on how this could be accomplished; how you can require content to be part of a Project in order for it to be published, or on the opposite side, prevent content from being published if it is part of a Project.

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.