All posts for "Development"

Here's a quick code snippet for adding a logout link to the Quick Navigator menu in Optimizely CMS 12. This is done a bit differently in CMS 12, since the logout page is using Razor Pages instead of WebForms, and the new logout method requires an antiforgery token.

What first started out as a "nice to have" feature, has now turned into a bigger experiment with EditorDescriptor. The original idea was pretty simple: "Can the font be changed in the Optimizely CMS UI for a textarea (string) property editor, maybe to something like a monospaced font where editors can provide additional styles or scripts?"

Here's a quick write-up about what I've learned when creating and modifying client side property editors.

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.

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.

This post was derived from a book I read many years ago called “An Astronaut's Guide to Life on Earth: What Going to Space Taught Me About Ingenuity, Determination, and Being Prepared for Anything” by Chris Hadfield. This actually started as a talk I gave while working at Nansen, and it was meant for more than just the developers. I really enjoyed this book because it's more than just an autobiography of Chris Hadfield's life, and it provides some great thoughts and takeaways that be applied to your professional career.

With the breaking change release of Episerver CMS 11, the underlying functionality for TinyMCE has been moved into a separate NuGet package and updated to the next major version. One of the biggest changes with TinyMCE version 2 for Episerver, aside from the new editor based on TinyMCE v4, is that you can no longer customize the TinyMCE editor from the CMS Admin area. Now, all changes are done through code. and the way that you make these customizations have changed dramatically. So let's look at the new way to add valid elements into TinyMCE version 2 for Episerver.

A couple of years ago, I wrote a post about how to add valid elements to the TinyMCE WYSIWYG editor in Episerver 7. While the same process generally remains for newer version of Episerver, there are some small updates to my previous post that makes it much easier and quicker. In this post, I'll show you the updated way to add valid elements to TinyMCE.

When developing out our EPiServer 7 MVC and Commerce site, we needed to have some way to ensure that the requested Entry is valid and exists in our catalog. In our solution, since we have multiple actions in our ProductDetailPageController, we created an action filter to validate {entry} parameter in our route, instead of repeating the code for every action.

This is part of a multi-post series regarding integrating EPiServer Commerce 1 R3 with an EPiServer 7 MVC site. In this post, I'll discuss the action filter we created to validate the requested Entry.

Routing to the Product Detail Page is one of the most important components of our EPiServer 7 MVC and Commerce integration. The routing we create will define the primary path to the product's information. Since we are not going to be creating page instances for each product, we need to have some way to determine which Entry should be displayed.

This is part of a multi-post series regarding integrating EPiServer Commerce 1 R3 with an EPiServer 7 MVC site. In this post, I'll discuss the different routing methods to the Product Detail Page.

Over the last couple of months, we've been working on integrating EPiServer Commerce 1 R3 with an EPiServer 7 MVC site. Unfortunately, this is not the most straightforward process, as Commerce 1 R3 is not fully supported with EPiServer 7 sites using MVC. After a lot of trial and error, we've developed a workable solution to getting both to play nicely with each other.

This is part of a multi-post series. In this post, I'll briefly discuss setting up the solution, then cover the basic components needed for our EPiServer 7 MVC and Commerce 1 R3 site.

I've recently been working on translating text that is displayed along with an XForm property. Since the localizations that are shipped with EPiServer 7 are now embedded in the assemblies, it's not as easy as searching through an XML file for the keys you need to override. So, as a reference, here are the system localization keys related to XForms that are embedded into EPiServer 7.

When developing an EPiServer 7 site (or really any site, for that matter), making a link to a page is one of the most common things you'll do. So, I thought I'd do something a little more basic and explore how to handle this task in your front-end page and block templates, specifically using MVC Razor views. In this post, we'll look at what you can currently use to create a link to a page, then I'll introduce some extension methods that you can use to give yourself a little more flexibility in your MVC view.

The creation and editing of content for multiple language sites in EPiServer 7 has recently become a topic of conversation in some of our projects. We occasionally receive feedback from our clients who are looking for ways to reduce the amount of time it takes to enter content, while also being consistent with the page and block layout.

One big change with the new Edit Mode in EPiServer 7, which was available in EPiServer 6 (and technically is still available in the old Edit Mode), is that feature to compare the language branches for a page side-by-side has been removed. This was useful for editors who need to keep the content for pages consistent between each language branch, as it allowed them to easily compare the different language branches.

So to help this, we created a property attribute called [AutoPopulateLanguageBranch]. Whenever a editor translates a page or block, this copies the values from the master language branch to the new language branch for the decorated page or block type properties. This keeps the content consistent between the language branches, which, at the same time, helps speed up the process of entering content.

The release of EPiServer 7 has brought numerous changes to the way editors interact with Edit Mode. One such change is the process needed to remove the language branch for a page or a block. Of course, you could always use the old Edit Mode to complete this task, but let's find out how to do this in EPiServer 7's new Edit Mode.

In a recent EPiServer 7 project, our client needed support for iframes and some other HTML tags in the TinyMCE WYSIWYG editor. Luckily, the way you add valid elements to TinyMCE hasn't changed much between EPiServer 6 and EPiServer 7, though some small issues have made the update a little more involved. In this post, I'll show you how to add valid elements to TinyMCE and how to fix the issues you'll potentially encounter along the way.

I was recently looking into how to fully use the [AvailablePageTypes] attribute in my page models, and after a bit of research and reading the sometimes confusing documentation, and the less confusing class documentation, I found it has some interesting and helpful features. Let's take a closer look at this attribute.

I initially posted this solution on the Nansen blog, but since then the code has been updated for both bug fixes and to reduce unnecessary layers (at least, unnecessary for my situation).

With the flexibility that block types offer in EPiServer 7, it would make sense that one common feature that people would want is an XForm in a block, so editors can freely add, move, and reuse blocks with forms around their website. In a recent project, this was one of my requirements.

If you've ever built a large MVC application, you'll know that your project can sometimes contain a large amount of files, some of which act as a layer of code between two aspects of the application. One such file is the view model, which is used to transfer data from the controller to the view.

When developing with EPiServer 7 MVC, in most situations you can use the page or block model directly in your view. There are some cases, however, where you'll find yourself using a separate view model to satisfy the needs of the view.

One powerful feature that EPiServer 7 provides is the localization of page content and the creation of language branches for your site, which allows you to create a multi-language, international site without the need for a huge amount of work. In this post, we'll look at how to configure, utilize, and develop for localization in EPiServer 7.