Blog posts by Robert Svallin

CMS 13 Preview 4 — Upgrading from Preview 3

Fri, 20 Mar 2026 12:08:15 GMT

This is the third post in a series where I use the Alloy template as a reference to walk through each CMS 13 preview. The first post covered upgrading from CMS 12 to Preview 2, and the second looked at the key changes in Preview 3. If you're following along, pick up where we left off.

Preview 4 is out. The package bump is easy enough, but there's an API change around how you resolve the start page that'll ripple through your code. Here's what to change and what's worth knowing about.

Step 1: Update Packages

Bump your package references from preview3 to preview4:

<PackageReference Include="EPiServer.CMS" Version="13.0.0-preview4" />
<PackageReference Include="EPiServer.CMS.UI.AspNetIdentity" Version="13.0.0-preview4" />
<PackageReference Include="Optimizely.Graph.Cms" Version="13.0.0-preview4" />

Known Issue: Database Schema Upgrade from Older CMS 12 Versions

If you're upgrading directly from an older CMS 12 version (e.g. 12.34.1 or earlier) to a CMS 13 preview and not from preview3 (which this article assumes), the database schema migration may fail with an error like:

Column names in each table must be unique. Column name 'Failed' in table 'dbo.tblNotificationMessage' is specified more than once.

This happens because certain columns were added in later CMS 12 releases, and the CMS 13 migration scripts don't check whether they already exist before trying to add them.

Workaround: First upgrade to the latest CMS 12 version so that your database schema is fully up to date, then upgrade from there to the CMS 13 preview. This ensures all intermediate schema changes are applied before the CMS 13 migration runs.

Step 2: Resolving the Start Page

In Preview 3, Alloy template resolved the start page by casting to Website and accessing RoutingEntryPoint. In Preview 4, the simplest approach is to use ContentReference.StartPage directly — no need to go through IApplicationResolver in most cases.

Before (Preview 3)

var website = _applicationResolver.GetByContext() as Website;
var startPageContentLink = website?.RoutingEntryPoint;

After (Preview 4)

var startPageContentLink = ContentReference.StartPage;

In the Alloy template this simplified things across several files by using ContentReference.StartPage
- PageViewContextFactory.cs — CreateLayoutModel
- ContentLocator.cs — GetContactPages
- PreviewController.cs — the Index action
- StartPageController.cs — the Index action
- Breadcrumbs.cshtml and Header.cshtml — same change

If you do need more control, IRoutableApplication with its EntryPoint property is still available as an alternative.

The SiteDefinition migration keeps getting refined. Issues with default application provisioning and hostname resolution between preview and view modes from earlier previews have been sorted out.

Step 3: DAM Integration (optional)

Preview 4 adds a new package for Optimizely DAM integration. Its important to call out that even though DAM is a fundamental piece of CMS 13 it is possible to run without it. CMS still can store assets in te traditional sense.

Similar to CMS 12 the DAM configuration is handled using options directly requiring an application to be created in CMP from which the credentials can be retrieved for configuration in CMS. You'll also need the SSO ID which can be found under Settings \ Organization \ General in CMP.

The DAM integration no longer talks to the CMP REST API directly. Instead it's built on External Sources, which means DAM assets need to be indexed into the Optimizely Graph instance connected to your CMS. So before wiring up the code below, make sure you have Optimizely Graph set up, then contact Optimizely Support to connect DAM to your Graph instance. The onboarding steps — selecting your DAM instance, activating asset types — follow the same process as CMS SaaS and are documented in the Onboard DAM to CMS guide. Updated documentation specific to CMS 13 will be available at release. Once that's done, Content Manager can be used to discover and pick DAM assets directly from the editing UI.

Add the package:

<PackageReference Include="EPiServer.Cms.DamIntegration.UI" Version="13.0.0-preview4" />

services.AddDamUI();

Add the DAM HTML helpers namespace to Views/_ViewImports.cshtml:

@using EPiServer.Cms.DamIntegration.UI.Helpers

This gives you access to helpers like RenderTagWithMetadata(...) for rendering DAM assets. Note that the epi-property tag helper you're already using comes from EPiServer.Cms.AspNetCore.TagHelpers, which should already be registered in your _ViewImports.cshtml via @addTagHelper.

Then configure your CMP credentials (note that these have defaults, included here for transparency) in appsettings.json:

"Optimizely": {
  "Cms": {
    "DamUI": {
      "Endpoint": "https://cmp.optimizely.com",
      "SsoId": "<your-sso-id>",
      "NavigationUrl": "https://cmp.optimizely.com/cloud/library"
    }
  },
  "Cmp": {
    "Client": {
      "TokenUrl": "https://accounts.cmp.optimizely.com/o/oauth2/v1/token",
      "ApiUrl": "https://api.cmp.optimizely.com/v3/",
      "ClientId": "<your-client-id>",
      "ClientSecret": "<your-client-secret>"
    }
  }
}

The DAM picker now also supports multi-select, which is a nice improvement for editors working with lots of media.

Migrating from CMS 12 DAM Integration

For the GA release of CMS 13, a standalone migration package will be available that converts the CMS 12-style DAM integration to the new one. This package will handle the migration of existing DAM asset references so that they work with the new EPiServer.Cms.DamIntegration.UI package.

The first version of the migration package will support:
- ContentReference properties
- IList<ContentReference> properties

Support for additional property types will be added in future releases.

Using DAM Assets in Your Content

To use DAM assets on a page, add a ContentReference property with the UIHint.Image hint:

using EPiServer.Web;
using System.ComponentModel.DataAnnotations;

public class DamExamplePage : StandardPage
{
    [Display(GroupName = Globals.GroupNames.Content)]
    [UIHint(UIHint.Image)]
    public virtual ContentReference Image { get; set; }
}

In the view, render it with the epi-property tag helper — same pattern as any other CMS property:

<img epi-property="@Model.CurrentPage.Image" />

Step 4: Audiences (optional)

Audiences are a separate package in CMS 13. If you were using services.AddVisitorGroups() in Preview 3, you'll need to add the new NuGet package and update your service registration.

Add the package:

<PackageReference Include="EPiServer.Cms.UI.VisitorGroups" Version="13.0.0-preview4" />

Then update your Startup.cs — the old AddVisitorGroups() call is replaced with two separate registrations:

using EPiServer.Cms.UI.VisitorGroups;
services.AddVisitorGroupsMvc().AddVisitorGroupsUI();

A few audience-related bugs have also been fixed: the policy-not-found error is gone, Geographic Location criteria works, and context menu positioning for personalized groups has been corrected.

What Else Is New in Preview 4

A few things worth knowing about beyond the upgrade steps:

Graph .NET SDK

There's a new .NET SDK for Optimizely Graph with a fluent API covering facets, caching, auth, tracking, and object-to-Graph field mapping. Extensibility points have also been added to ContentGraph.CMS so you can hook into the indexing pipeline.

Improved Migration from SiteDefinition

The migration from SiteDefinition to the Application Model has been improved. Creating in-process websites via the settings UI works again, and typed content types now show up correctly when picking the start page for an application.

For the full list of changes, check the official release notes.

CMS 13 Preview 3: Key changes

Thu, 19 Feb 2026 13:44:31 GMT

If you've been following along with the CMS 13 preview, you've likely worked through the initial upgrade path covered in my previous post. Preview 3 brings us another step closer to a production-ready release. Based on feedback on Preview 2 we have made changes so that Content Manager and Optimizely Graph are no longer enabled by default.

It is however important to understand that: while these features are opt-in from a technical perspective, Optimizely Graph is effectively required if you want to unlock the full potential of CMS 13. In practice, we expect most customers to adopt Graph as part of their CMS 13 journey, since many of the platform’s most meaningful innovations depend on it. Let’s unpack what that means.

What's New in Preview 3?

Preview 3 includes the usual improvements and bug fixes, but I wont highlight them here but instead refer to the official release notes. What is worth discussing is the change in having Optimizely Graph and Content Manager enabled through opt in.

Why Optimizely Graph Matters

Several of CMS 13's new features are built on top of Optimizely Graph. Let´s look at some of the bigger examples:

Content Manager: The new editorial experience relies on Graph for content discoverability.
External Content: Integrating content from external sources outside of CMS requires Graph's indexing capabilities
Content Binding: The approach to rendering external content leverages Graph's structured queries
RAG for Opal: Graph allows Opal to “see” and “understand” your content. Allowing Opal to query all content, understand tone of voice, and more.

In other words, if you're planning to use any of the new CMS 13 features that differentiate it from CMS 12, you need Optimizely Graph - they wont work without it. At Optimizely, we view Optimizely Graph as a mandatory and foundational component for using CMS 13 to its full potential. Running CMS 13 without Optimizely Graph will be very close to running CMS 12 compiled for .NET 10 with a smaller subset of new features. Over time, Optimizely Graph will increase in usage in CMS 13 and beyond since it is at the very center of functionality that we build.

For organizations that truly cannot adopt Graph, it’s worth carefully evaluating the value of moving to CMS 13 in the near term, since several of the headline innovations will not be available without it.

Is Optimizely Graph required?

Let's be pragmatic about this. You can run CMS 13 without Graph in some scenarios, for example:

You're maintaining a CMS 12 codebase with minimal changes during migration
You're in the early phases of migration and haven't yet enabled the new features

One example is customers with strict on-prem or data residency requirements where introducing a cloud service is not feasible. That said, many customers who run CMS “on-prem” Today are already operating in hybrid models (self-hosted in cloud environments, partner-hosted infrastructure, etc.), and in those cases Graph is often still a viable option.

If you're upgrading to CMS 13 for its new capabilities, then its likely that you will be adopting Graph. The question probably isn't "if" but rather "when" in your migration timeline.

Enabling Content Manager and Optimizely Graph

Since you'll almost certainly need these features, or at least want to try them out, here's the straightforward opt-in process:

Step 1: Add the NuGet Packages
Reference the appropriate packages in your project:

dotnet add package EPiServer.Cms.UI.ContentManager
dotnet add package Optimizely.Graph.Cms

Step 2: Update Your Startup Configuration
In your Startup.cs (or wherever you're configuring services in your Alloy-based project), add the following calls to your service registration:

public void ConfigureServices(IServiceCollection services)
{
  // ... your existing service configuration
  services.AddContentGraph();
  services.AddContentManager();
  // ... rest of your configuration
}

Notice the order matters here: AddContentGraph() should come before AddContentManager() since Content Manager depends on Graph's infrastructure.

My perspective on Graph Adoption

Here's what I am thinking with this change on Opt In approach: Graph isn't a nice-to-have feature add-on—it's a corner stone for content delivery in the Optimizely ecosystem.

Content Manager gives editors a performant content discovery experience powered by Graph queries
External Content lets you unify disparate content sources through Graph's indexing
Content Binding enables developers to work with strongly-typed content models backed by Graph's schema

These aren't isolated features; they are puzzle pieces that tell a joint story. And Graph is the connective tissue that bind them together.

If you're building greenfield projects or undertaking significant modernization efforts, I think that you should embrace Graph from day one. Trying to retrofit it later when you want to adopt Content Manager or External Content will be more painful than including it from the start.

So, Alloy Template

If you're working with the Alloy template as a learning tool or project foundation, you'll want to enable both features to get the full editorial experience. The Alloy template shows Content Manager's capabilities, and Graph powers both its search functionality and the new content delivery patterns.

This is actually a good learning environment to understand how Graph integrates with the platform before you build your production architecture.

As always, remember that Preview 3 is not production-ready. Use it for evaluation, experimentation, and preparation—but keep your production sites on CMS 12 until the official CMS 13 release.

Happy coding!

From 12 to 13 preview: A Developer's Guide to testing an Optimizely CMS 13 Alloy Site

Fri, 23 Jan 2026 14:21:45 GMT

The release of Optimizely CMS 13 marks a significant step forward, embracing a more composable and headless-first architecture. While this unlocks powerful new capabilities, it also introduces important changes to the underlying framework.

This guide provides a hands-on walkthrough for upgrading a standard CMS 12 Alloy starter site to the CMS 13 preview. We'll cover dependency updates, code migrations for obsolete APIs, and the new application configuration model.

Step 1: Create a Baseline CMS 12 Site

First, let's establish a starting point. Create a fresh CMS 12 Alloy site using the Optimizely templates. This ensures we have a clean, working installation before we begin the upgrade.

# Create a new Alloy project
dotnet new epi-alloy-mvc -n alloy13preview

# Build and run the site
dotnet build
dotnet run

Once the site is running, register a new user account so you can log in. Verify that the site is fully functional. When you're ready, shut down the application.

Step 2: Update Project Dependencies

With our baseline established, the next step is to update the project file and NuGet packages.

Update the Target Framework: Open the .csproj file and change the target framework to
```
<PropertyGroup>
  <TargetFramework>net10.0</TargetFramework>
</PropertyGroup>
```
Update NuGet Packages: Update all EpiServer.* package versions to 13.0.0-preview2.
Add AspNetIdentity: CMS 13 decouples the UI's identity management. Add a new package reference for EPiServer.CMS.UI.AspNetIdentity.
```
<PackageReference Include="EPiServer.CMS.UI.AspNetIdentity" Version="13.0.0-preview2" />
```

Step 3: Code Migration and Mitigating Obsolete APIs

CMS 13 refactors several core APIs. The compiler will now report a series of warnings and errors related to obsolete members. Let's work through them.

A Friendly Pro-Tip: As you begin the migration, make it a habit to check the compiler warnings in your IDE or build output. These warnings are your roadmap to finding every instance of a deprecated or obsolete API in your specific project. While this guide covers the common changes for the Alloy template, your codebase may have other areas needing attention.

Use ContentReference and ContentLink

The PageReference and PageData.PageLink types are now obsolete. This change reflects a broader shift to treat all content more generically. The fix is a straightforward replacement across your solution:

Replace PageReference with ContentReference.
Replace .PageLink with .ContentLink.

Replace SiteDefinition with the New Application Model

The concept of SiteDefinition is replaced by a more flexible Application Model. An application connects a starting point in the content tree with a specific rendering mode (e.g., "In-Process" or "Headless") and hostnames.

To resolve this, you'll need to inject IApplicationResolver into your controllers and services to get the context of the current application (IApplication).

Here is an example of how to refactor the StartPageController:

using alloy13preview.Models.Pages;
using alloy13preview.Models.ViewModels;
using EPiServer.Web;
using EPiServer.Web.Mvc;
using Microsoft.AspNetCore.Mvc;
using EPiServer.Applications;
using EPiServer.Shell.Security;
using EPiServer.Web.Routing;

namespace alloy13preview.Controllers;

public class StartPageController : PageControllerBase<StartPage>
{
  private readonly IApplicationResolver _applicationResolver;
  
  public StartPageController(IApplicationResolver applicationResolver)
  {
    _applicationResolver = applicationResolver;
  }

  public async Task<IActionResult> Index(StartPage currentPage, CancellationToken cancellationToken)
  {
    var model = PageViewModel.Create(currentPage);
    var application = await _applicationResolver.GetByContextAsync(cancellationToken);

    var website = application as Website;
    
    if (website is not null && website.RoutingEntryPoint.CompareToIgnoreWorkID(currentPage.ContentLink))
    {
      // Connect the view models logotype property to the start page's to make it editable
      var editHints = ViewData.GetEditHints<PageViewModel<StartPage>, StartPage>();
      editHints.AddConnection(m => m.Layout.Logotype, p => p.SiteLogotype);
      editHints.AddConnection(m => m.Layout.ProductPages, p => p.ProductPageLinks);
      editHints.AddConnection(m => m.Layout.CompanyInformationPages, p => p.CompanyInformationPageLinks);
      editHints.AddConnection(m => m.Layout.NewsPages, p => p.NewsPageLinks);
      editHints.AddConnection(m => m.Layout.CustomerZonePages, p => p.CustomerZonePageLinks);
    }

    return View(model);
  }
}

You will need to apply a similar pattern to other places in the code that reference SiteDefinition.Current. For SiteDefinition.Current.RootPage, you can replace it with ContentReference.RootPage.

Modernize Dependency Injection

Service location using InitializationEngined.Locate is obsolete. Instead, use constructor injection to get an IServiceProvider instance.

Before: context.Locate.Advanced.GetInstance<T>()
After: Inject IServiceProvider and call serviceProvider.GetRequiredService<T>() In an IInitializationModule, you can access it via context.Services.

Other Small API Changes

IContentTypeRepository<T>: The generic argument is no longer needed. Change IContentTypeRepository<PageType>() to IContentTypeRepository()
PageController.PageContext.Page This property is now of type IContent. Update your code to reflect this change.

Step 4: Configuration Updates

Next, we need to make a few adjustments in Startup.cs and appSetting.json

Enable Database Compatibility Update: In Startup.cs, add the following to allow the database compatibility level to be updated automatically.
```
services.Configure<DataAccessOptions>(options =>
{
    options.UpdateDatabaseCompatibilityLevel = true;
});
```

Configure Content Graph: Content Graph is enabled by default in the preview of CMS 13 and cant be disabled. This will likely change in subsequent releases. You must add your credentials to appSettings.json.

"Optimizely": {
  "ContentGraph": {
    "GatewayAddress": "https://staging.cg.optimizely.com",
    "AllowSendingLog": "true",
    "SingleKey": "INSERT SINGLEKEY HERE",
    "AppKey": "INSERT APPKEY HERE",
    "Secret": "INSERT SECRET HERE"
  }
}

Install Visitor Groups: Due to a known issue in the preview, the menu system will not render correctly unless Visitor Groups are installed. Add this to Startup.cs
services.AddVisitorGroups();

Step 5: Fixing the Post-Upgrade 404

After making all the changes, run the application:

dotnet run

You will notice the site returns a 404 Not Found error. This is expected. The migrated database still has the old SiteDefinition configuration, which doesn't align with the new Application Model.

Follow these steps to fix it:

Navigate to the CMS admin interface: https://localhost:5000/Optimizely/CMS.
Go to Settings > Applications. If the page fails to render, clear your browser cache and reload. You will see a default "Headless" application.
Edit the application and click Delete Application.
Click Create New Application.
- Set the Type to In Process.
- Select your original Alloy start page as the Application start page.
- Give it a name.
Edit the new "In Process" application you just created.
- In the Hosts section, add a new host with the name localhost:5000 and set it as the default.

Your Alloy site should now render correctly on the frontend, and preview in Edit mode will be functional.

Conclusion

Congratulations! You have successfully upgraded your Alloy site to CMS 13. This process highlights the key architectural shifts in the new version, particularly the move to a composable Application Model and modernized APIs. You are now ready to explore the new features and possibilities of Optimizely CMS 13.

Important Note: The steps outlined in this guide are intended for developers to explore the CMS 13 preview with the Alloy template. This is an incomplete preview, and these instructions are not recommended for use with an actual development project and certainly not a live production site. We will share more as we get closer to the release date of CMS 13.

CMP DAM asset sync to Optimizely Graph self service

Thu, 13 Feb 2025 10:48:51 GMT

The CMP DAM integration in CMS introduced support for querying Optimizly Graph (EPiServer.Cms.WelcomeIntegration.Graph 2.0.0) for metadata such as alternative texts. Up until now interaction with Optimizely has been needed when adding this integration from CMP to Optmizely Graph but that is no longer the case. CMP now contains a self service feature where Optimizely Graph can be added and initial synchronization of assets started. This makes it easier to get started and reap the performance benefits of moving from REST API integration with CMP to the more performant Optimizely Graph integration.

In CMP simply header over to Settings \ Organization \ Misc, scroll to the bottom of the view and hit the Enable & Sync button that you will find there. Once the sync has completed you will find a URL to the Optimizely Graph UI which contains the SingleKey needed to configure CMS.

The URL will look something like below.

https://cg.optimizely.com/app/graphiql?auth=SINGLE_KEY

If you havent already read about our integration with CMP, either with REST API, or with Optimizely Graph, then please head over to CMP DAM in CMS to find details on how to get started.

DAM integration new major version, performance improvements and Library Picker folder selection

Fri, 29 Nov 2024 04:37:35 GMT

As you might already have seen we have decided to delist the EPiServer.CMS.WelcomeIntegration version 1.4.0 where we introduced Graph support. Unfortunately a return type was changed that we didn’t catch which means that it became a breaking change. We have decided to delist 1.4.0 and release the performance improvements we have been working on as a new major. We apologize for any inconvenience this has caused and suggest that you either downgrade to 1.3.9 and rely on the CMP API instead of Graph, or upgrade to 2.0.0 instead. We recommend to upgrade to 2.0.0 for the best performance.

Performance

The integration between CMS and CMP uses a combination of the CMP Library Picker, in which the editor selects the asset to reference and, either the CMP´s REST API, or indexed assets in Graph. The API or Graph is used to pull metadata regarding the assets such as sizing or alt texts. The integration with REST API has been around for quite some time and the Graph integration was released in the previous version, 1.4.0, and we described how to configure it in this blog post by Bartosz Sekula.

We are now releasing a change in how metadata is cached in the CMS for assets referenced from CMP DAM. Moving forward from version 2.0.0 the cache will move to the database and stored permanently. This removes the need for any page request that contain CMP DAM assets to perform outbound network requests to retrieve that metadata when cache has expired.

The metadata will be fetched for Image assets from CMP when a content that contains references to those images is published. So metadata will be available once the page starts to receive traffic. Please note that fetching the metadata is handled in the background to not block the editor from interacting with the UI. If the images are already referenced by other pages or block then the already existing metadata will be used.

Should for some reason the metadata not have been populated then the image will still render but with the public URL which was stored the first time the asset was referenced, instead of the latest URL provided by CMP through the metadata.

Renditions of Images is a bit different and a topic to which we will return. Currently the renditions for an image asset will render without alt-text. As already stated, we are working on resolving that. The HtmlHelper and TagHelper as well as DamImageAssetViewComponent will still render the correct rendition.

Example of using HtmlHelper

@model PageViewModel<StandardPage>
@using EPiServer.Cms.WelcomeIntegration.UI.Helpers

@await Html.RenderTagWithMetadata(p => p.CurrentPage.Image)

Example of using TagHelper

@model PageViewModel<StandardPage>
@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers

<dam-asset content-reference="@Model.CurrentPage.Image" />

Maintaining asset metadata

Since the metadata for Images now have moved to the database, how does it get updated? A new scheduled job has been created which will, on schedule, pull metadata from CMP DAM for all assets and update in CMS. This job can be executed manually should the need arise to sync metadata between CMP and CMS.

Metrics from testing scenarios indicate big performance improvements when serving content with DAM assets to visitors.

Asset Library folder selection

CMP has the possibility to organize content in folder structures and it is now possible configure either globally or by type which folder to open in the CMP Library Picker. Configuration is done at startup or appSettings as usual.

.AddDAMUi(o => {
    o.Enabled = true;
    o.GlobalRootFolderGuid = "a7fd6357c13d49829715f38fe8114c40";
    o.RootFolderForTypes = new Dictionary<string, IEnumerable<Type>>
    {
        { "57523add60d04e328d7fc1e02c05ed40", new Type[] { typeof(DAMImageAsset) } },
        { "7bce1de28e66411590ac32896eff2ce1", new Type[] { typeof(DAMVideoAsset) } },
        { "72b89ab1b83041acaab861a035db7e7b", new Type[] { typeof(DAMAsset) } }
    };
});

EPiServer.CMS UI 12.17.0 delisted from Nuget feed

Wed, 01 Mar 2023 05:30:45 GMT

The 12.17.0 version of the UI packages have been delisted from our Nuget feed and is no longer available. We are working on providing a patch, 12.17.1 to correct an issue that affects string properties that use SelectMany attribute and a ISelectionFactory to handle the available options.

The root issue is that the representation of the selected values is now stored in a different way in the database and that needs to be considered a breaking change. We moved from a comma separated list in favor of a Json array. I.e. from "value1,value2,value3" to "[\"value1\",\"value2\",\"value3\"] in an effort to try and broaden the capabilities. The change only applies to properties that have been updated and saved to the database since the 12.17.0 upgrade was done on the installation.

An installation can be checked if it has been affected by the issue, by running a query against the database to see if the properties store a JSON array or comma separated strings. Please note that only installations using 12.17.0 and that uses properties that are using SelectMany attribute is potentially affected.

An example would be that 12.17.0 would store

["1","2","3"]

Instead of the previously used

1,2,3

CMS-26903
When addressing the issue CMS-23405 a breaking change was introduced in how the values for string properties using SelectManyAttribute and ISelectionFactory are stored in the database. A change was made to serialize the selected options as JSON instead of comma separated strings.

We offer our apologies that this occured and we are sorry that this has affected our customers. For installations that are in the process of migrating to 12.17.0 we ask that you verify if you are affected. Wait for the 12.17.1 version that will arrive shortly and then verify that data is stored correctly.

This blog post will be updated as we move forward with this issue. Thank you for your patience.

Improving And Unifying The UI

Thu, 16 Jun 2022 14:17:55 GMT

We aim to unify and make a seamless user experience across all Optimizely products. This change will make our products more predictable, easy to use, and accessible. Therefor the CMS in Content Cloud has, over the last few versions (starting with 12.3.0), received multiple updates to the UI. This work is still ongoing, and in the coming weeks/months we expect to release even more updates. However, we wanted to pause and talk a bit about what we have done recently.

Let’s start with a direct comparison of how the UI has changed during this period. The screenshots below clearly outline the differences.

Image: A comparison of form edit between 12.7.0 (left) and 12.2.0 (right).

The UI now uses icons from Font Awesome Pro 6, which is a font-based icon library which in turn means that there are fewer resources to download and the icons scale better since they are vector-based. Icons are no longer solid instead, they are outlined, more sharp, crisp, and modern looking. All products from Optimizely use the same set of icons.

The new icons use the same CSS classes as the old ones did, so for example the home icon still uses the .epi-iconObjectStart CSS class. However, the new icons use a licensed version of Font Awesome 6 Pro, and this limits how the icons can be used. Third-party add-ons and extensions need to use either a free version of Font Awesome 6/equivalent or purchase their license. The new icons have the following sizes, small (16 x 20), medium (24 x 30), and large (32 x 40).

Spacing has also been reworked to introduce more padding to create an improved visual clarity, balancing the layout and making it easier to overview. By introducing more white space into the layout important elements draw the user’s attention, allowing the user to focus on call-to-action items and making everything easier to read. In general, alignment has been given an overhaul as well.

Primary buttons have moved to the right-most side in a button group and the secondary button no longer has a border unless it receives focus or the user hovers on it. This further makes the primary button easier for the eye to catch.

Image: Button placement and disabled state in 12.7.0 (left) and 12.2.0 (right)

Disabled buttons are not transparent anymore. Instead, they have a specific look to them to make sure that they stand out as inactive. For example, a disabled primary button was previously a muted blue that became brighter when enabled. Now the disabled version is instead grey and becomes blue once enabled.

Content Selectors have been reworked to support the user in selecting content without using drag and drop. This was made possible by allowing all content selectors to have a drop-down menu that allows the user to select as well as create content. Drag-n-drop is still present in the UI and the borders of drop zones have been adjusted so that they are coherent and visible.

Image: Creating and selecting content in 12.7.0 (left) and 12.2.0 (right).

Multi-targeting .NET 6 and .NET 5

As of EPiServer.CMS.UI 12.4.0 our nugets multi-target both .NET 6.0 and .NET 5.0. EPiServer.CMS.TinyMCE 3.2.0 also supports both as well as EPiServer.Telemetry.UI 2.1.0.

This was a small selection of the many updates that have been made in the UI and as you upgrade you will discover many more. In the coming versions the team will work on more updates, and we are looking forward to your feedback.

New support for tiff files

The CMS UI supports tiff files and adds Tiff to SupportedEditExtensions list. Currently, tiff is quite an old image extension and It is supported by a few browsers (for example, safari, IE11).

What is in the box?

On Chrome/other browsers users can:
- Upload a .tiff image
- Open in Image Editor to edit a .tiff image
On Safari/IE11 browser users can:
- Upload a .tiff image
- DnD a .tiff image into Image property (content reference/content reference list/link item collection/URL to (doc,image, page), XhtmlString, Content Area)
- Open a .tiff image on OPE or All properties mode
- Open in Image Editor to edit a .tiff image
- View a .tiff image on View mode

Known issues

Thumbnails in Media gadget have a hard-coded content-type (image/png) in CMS Core, and they are not going to change it. That explains why tiff or ico files don't show thumbnails.
We only support *.tiff extension. *.tif is not supported