A critical vulnerability was discovered in React Server Components (Next.js). Our systems remain protected but we advise to update packages to newest version. Learn More

ling
ling  -  CMS
Mar 31, 2020
  4265
(4 votes)

Improve OPE with client-side rendering (features out of beta in 11.24.0)

Several features to improve the client-side rendering in OPE have been tested with beta customers for a while. With EPiServer.CMS.UI 11.24.0, they have finally dropped the beta tag.

The features are:

  1. contentSaved: introduced in CMS UI 10.12.0 (Taking control of client-side rendering in OPE)

    When a property value has been saved, a message is published on the topic contentSaved, together with an object containing the content link to the content that was just updated.

    Now you can listen to this event with:

    // Wait for the scripts to run so we can use the 'epi' global object.
    window.addEventListener("load", function() {
        epi.subscribe("contentSaved", function(event) {
            console.log("On Page Edited!");
            console.log(event.contentLink);
        }
    }

    The event will look like this:

    {  
        "contentLink": "6_164",
    }​
  2. epiReady: introduced in CMS UI 11.11.0 (Routing in a SPA with a working On-Page Editing experience)

    The epiReady event will be raised as soon as the iframe inside the UI is loaded. It contains information regarding if the current content is editable. In addition to that event, a few properties are set on the global epi object that are available in edit view. Those properties are:
    epi: {
        isEditable: false, // true in edit mode, and false in preview mode
        inEditMode: true,  // true in both edit mode and preview mode
        ready: true  // true if the property isEditable has been initialized        
    }​

    isEditable value will not be correct until the event has been raised. By looking at the ready property you will know if the property isEditable has been initialized or not.

    Here is a sample of how this event and properties could be used:

    const context = {
        inEditMode: false,
        isEditable: false
    };
    
    // Listen to the `epiReady` event to update the `context` property.
    window.addEventListener('load', () => {
        // Expect `epi` to be there after the `load` event. If it's not then we're
        // not in any editing context.
        if (!window.epi) {
            return;
        }
    
        function setContext() {
            // The event only has `isEditable`, but the epi object has both.
            context.inEditMode = window.epi.inEditMode;
            context.isEditable = window.epi.isEditable;
        }
    
        // Check that ready is an actual true value (not just truthy).
        if (window.epi.ready === true) {
            // `epiReady` already fired.
            setContext();
    
        // The subscribe method won't be available in View mode.
        } else if (window.epi.subscribe) {
            // Subscribe if the `epiReady` event hasn't happened yet.
            window.epi.subscribe('epiReady', () => setContext());
        }
    });


  3. domUpdated: first introduced in CMS.UI 11.2.0 (Taking more control of client-side rendering in OPE 2). At that time, you needed to tell the OPE view to remap all the overlays on the page by publishing to the domUpdated topic like epi.publish("beta/domUpdated").
    From CMS.UI 11.4.0, you didn't need to publish to that topic anymore because the overlays automatically get updated. BUT, this feature applied only for beta users.

    From CMS.UI 11.24.0, it will work with all users - when a new element with the attribute data-epi-edit, or an existing element change their value to another property name (which makes the DOM changes), the overlays will update themselves automatically.

Related topics

Mar 31, 2020

Comments

Please login to comment.
Latest blogs
Scheduled job for deleting content types and all related content

In my previous blog post which was about getting an overview of your sites content https://world.optimizely.com/blogs/Per-Nergard/Dates/2026/1/sche...

Per Nergård (MVP) | Jan 30, 2026

Working With Applications in Optimizely CMS 13

💡 Note:  The following content has been written based on Optimizely CMS 13 Preview 2 and may not accurately reflect the final release version. As...

Mark Stott | Jan 30, 2026

Experimentation at Speed Using Optimizely Opal and Web Experimentation

If you are working in experimentation, you will know that speed matters. The quicker you can go from idea to implementation, the faster you can...

Minesh Shah (Netcel) | Jan 30, 2026

How to run Optimizely CMS on VS Code Dev Containers

VS Code Dev Containers is an extension that allows you to use a Docker container as a full-featured development environment. Instead of installing...

Daniel Halse | Jan 30, 2026

A day in the life of an Optimizely OMVP: Introducing Optimizely Graph Learning Centre Beta: Master GraphQL for Content Delivery

GraphQL is transforming how developers query and deliver content from Optimizely CMS. But let's be honest—there's a learning curve. Between...

Graham Carr | Jan 30, 2026

Optimizely Graph Best Practices - Security, Access Control and Performance Optimisation

Introduction Building on Part 1's content modeling and querying practices , this Part 2 focuses on the security and performance considerations...

Jon Williams | Jan 29, 2026