Blog posts by Minesh Shah

Personalisation in CMS 13 Using Audiences

Thu, 12 Feb 2026 09:00:01 GMT

One of the common questions around CMS 13 is whether it still supports personalisation without requiring additional products. The short answer is yes.

CMS 13 includes built in personalisation using what were previously known as Visitor Groups. In CMS 13 these have been renamed to Audiences (Correction they changed to Audiences in latter versions of CMS12 which somehow I missed, Thanks Scott for pointing this out), but the core concept remains the same. You can define audiences based on visitor behaviour and use them to tailor content across your site.

Audiences are managed directly within the CMS interface. For example, you might create an audience made up of visitors who have viewed pages with a specific category more than a set number of times. Once an audience is defined, it can be used to control how content is displayed.

Personalisation is applied at the content level using standard content areas. Editors can choose to show or hide individual components such as a hero or jumbotron based on the selected audience. This allows targeted experiences without introducing additional complexity for editors.

CMS 13 also supports previewing content as a specific audience. This makes it easy to validate personalisation rules and understand exactly what different users will see before changes are published.

This approach provides traditional, rules based personalisation out of the box and offers a clear path to more advanced personalisation in the future if needed. For many organisations, it delivers exactly the right level of capability from day one.

A short video walkthrough is included below to demonstrate this in action.

Experimentation at Speed Using Optimizely Opal and Web Experimentation

Fri, 30 Jan 2026 10:24:02 GMT

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 learn, optimise, and deliver impact.

In this short video, I demonstrate just how quick and easy it is to use Optimizely Opal alongside Optimizely Web Experimentation to create and execute an experiment at pace. What normally takes multiple manual steps can be dramatically accelerated, with Opal helping to streamline the entire workflow.

The scenario: make a quick change and run an experiment

The goal of the demo is simple. I want to make a small change to a website and show how fast I can turn that into a working experiment using Opal.

Rather than spending time manually setting everything up, Opal can assist with the process and help generate what you need, quickly and efficiently.

Why this matters: speed and experimentation velocity

The real value here is the speed.

Using Optimizely Opal with Web Experimentation means you can:

reduce time spent on setup
increase experimentation throughput
test more ideas more frequently
accelerate learning cycles across your digital estate

It is genuinely exciting to see experimentation becoming this efficient, and it opens up huge potential for teams who want to move faster without compromising quality.

Final thoughts

Using Optimizely Opal and Web Experimentation together is an absolute dream. The speed in which you can execute experiments, and have Opal support so much of the process for you, is truly impressive.

If you are exploring ways to increase experimentation velocity, this is well worth looking at.

Thank you for watching.

Building an Agent Replicator for Optimizely Opal

Wed, 21 Jan 2026 11:46:47 GMT

Introduction

A couple of months ago, my team and I took part in the Opal Innovation Challenge (Which we proudly won). We decided to create an agentic AI experience that brings audience insight directly into content workflows, the Virtual Focus Group. By simulating real customer segments and offering instant, nuanced feedback on messaging, this solution helps teams validate messaging in minutes rather than weeks, reduces costly research cycles, and captures behavioural insights that traditional analytics often miss.

To learn more about exactly what we delivered, please find further information here: Virtual Focus Group by Netcel.

However, whilst building the Virtual Focus Group, we quickly discovered that creating and managing multiple specialised agents through the Opal user interface became time consuming and repetitive. Each customer segment needed its own agent with specific configurations, and manually creating dozens of agents was not scalable. This led to the development of the Agent Replicator, a comprehensive toolkit that enables programmatic agent creation, management, and execution following the official Opal Agent JSON Schema specification.

Whilst the Opal API does not yet support programmatic agent creation, this implementation is production ready and can be immediately integrated once Optimizely opens those endpoints. The system includes full CRUD operations, parameter validation, prompt template processing, and request context propagation, everything needed to dynamically create and orchestrate AI agents at scale.

What the Agent Replicator is in practice

In practice, the Agent Replicator is an Opal tool that enables users to create new Virtual Focus Group persona agents quickly and consistently, without leaving Opal.

Once an Opal administrator has registered the Agent Replicator tool endpoint, the capability becomes available in Opal Chat and Opal Workflows. A user can provide a persona scenario and empathy map, and the tool generates a new specialised persona agent, including a tailored prompt template and the parameters needed to run it. That persona agent can then be used by the Virtual Focus Group to review content from a specific audience perspective.

This shifts persona creation from a manual, repetitive task into a fast, repeatable workflow that teams can run whenever new customer segments are needed. It also keeps persona definitions consistent by generating them in a schema aligned format, which makes them easier to manage and evolve over time.

How it works

At a high level, the implementation follows a simple flow.

You deploy the Agent Replicator as a small web service.
The service exposes Opal compatible tool endpoints.
An Opal administrator registers the endpoint inside Opal, which makes the tools available in Chat and Workflows.
Users call the tool to generate persona agents, and then use those persona agents as part of the Virtual Focus Group experience.

The core implementation

The Agent Replicator is built around three pieces:

Schema aligned agent models that match the Opal Agent JSON Schema
Opal tool methods that create and retrieve agent definitions
A small host application that exposes tool endpoints for Opal to register

The sections below show the key parts of the implementation.

1. Adding the Opal tools package

This project references the Optimizely.Opal.Tools package, which provides the infrastructure for exposing tools in a way that Opal can discover and invoke.

<ItemGroup>
  <PackageReference Include="Optimizely.Opal.Tools" Version="0.4.0" />
</ItemGroup>

2. Hosting the tools and exposing endpoints for Opal

This is the important wiring in Program.cs.

It registers the Opal tool service, registers your tool class, and maps the tool endpoints. Once deployed, the mapped routes are what an Opal administrator registers inside Opal.

// Register Opal Tool Service and Tools
builder.Services.AddOpalToolService();

// Register Agent Management Tools
builder.Services.AddOpalTool<AgentManagementTools>();

// ...

app.MapOpalTools();

3. Creating the tool that generates a new persona agent

The Agent Replicator tool methods live in AgentManagementTools.cs. Each method that Opal can call is decorated with [OpalTool] and has a description that Opal can surface in the interface.

The method below creates a new agent definition that matches the Opal Agent JSON Schema fields, stores it for the proof of concept, and returns the created agent back to Opal.

[OpalTool(Name = "create-opal-agent")]
[Description("Creates a new Opal agent within the virtual focus group. This agent can be assigned specific roles, tools, and a prompt template that defines its behavior.")]
public Task<object> CreateOpalAgent(CreateAgentParameters parameters)
{
    var agentId = Guid.NewGuid().ToString();

    var agent = new AgentDefinition
    {
        // Internal tracking fields
        Id = agentId,
        DisplayName = parameters.DisplayName,
        Role = parameters.Role,
        CreatedAt = DateTime.UtcNow,
        UpdatedAt = DateTime.UtcNow,

        // Opal schema fields
        SchemaVersion = "1.0",
        AgentId = parameters.AgentId,
        AgentType = parameters.AgentType,
        Name = parameters.DisplayName,
        Description = parameters.Description,
        Version = parameters.Version,
        PromptTemplate = parameters.PromptTemplate,
        Parameters = parameters.Parameters ?? new List<AgentParameterDefinition>(),
        EnabledTools = parameters.EnabledTools ?? new List<string>(),
        Creativity = parameters.Creativity,
        InferenceType = parameters.InferenceType,
        Output = parameters.Output ?? new AgentOutputDefinition(),
        FileUrls = parameters.FileUrls ?? new List<string>(),
        AgentMetadata = parameters.AgentMetadata,
        IsActive = true,
        IsDeleted = false,
        InternalVersion = 1
    };

    if (!_agents.TryAdd(agentId, agent))
    {
        return Task.FromResult<object>(new
        {
            IsSuccess = false,
            Message = "Failed to create agent due to ID collision. Please try again."
        });
    }

    return Task.FromResult<object>(new
    {
        IsSuccess = true,
        Message = $"Successfully created agent '{parameters.DisplayName}' with agent_id '{parameters.AgentId}'.",
        Agent = agent
    });
}

4. Listing persona agents inside Opal

Once users start generating persona agents, it is useful to list what exists. This tool method returns all agents that have not been deleted, ordered by creation date. This aligns with the experience of listing agents from within Opal.

[OpalTool(Name = "list-opal-agents")]
[Description("Lists all available Opal agents in the virtual focus group (excluding deleted agents).")]
public Task<object> ListOpalAgents(ListAgentParameters parameters)
{
    var agents = _agents.Values
        .Where(a => !a.IsDeleted)
        .OrderByDescending(a => a.CreatedAt)
        .ToList();

    return Task.FromResult<object>(new
    {
        IsSuccess = true,
        Message = $"Found {agents.Count} agent(s).",
        TotalAgents = agents.Count,
        Agents = agents
    });
}

5. Retrieving an agent and its prompt template

To support review and reuse, the next tool fetches a specific agent. This is the foundation for showing an agent’s prompt template inside Opal, which helps teams understand exactly how the persona will evaluate content.

[OpalTool(Name = "get-opal-agent")]
[Description("Retrieves details of a specific Opal agent by ID or agent_id.")]
public Task<object> GetOpalAgent(GetAgentParameters parameters)
{
    var agent = _agents.Values.FirstOrDefault(a =>
        a.Id == parameters.AgentId ||
        a.AgentId.Equals(parameters.AgentId, StringComparison.OrdinalIgnoreCase));

    if (agent == null)
    {
        return Task.FromResult<object>(new
        {
            IsSuccess = false,
            Message = $"Agent '{parameters.AgentId}' not found."
        });
    }

    return Task.FromResult<object>(new
    {
        IsSuccess = true,
        Message = $"Successfully retrieved agent '{agent.DisplayName}'.",
        Agent = agent
    });
}

6. Defining tool parameters so Opal can guide users

Tool parameter models use [Required] and [Description] attributes. This makes the tool self describing, helps validation, and helps Opal present a clear input contract when the tool is used in Chat or Workflows.

public class CreateAgentParameters
{
    [Required]
    [Description("Human-friendly name of the new agent.")]
    public string DisplayName { get; set; } = string.Empty;

    [Required]
    [Description("What this agent does and when to use it.")]
    public string Description { get; set; } = string.Empty;

    [Required]
    [Description("Unique identifier for the agent (e.g., 'brand_lp_research'). Use lowercase with underscores.")]
    public string AgentId { get; set; } = string.Empty;

    [Description("Type of agent: 'specialized', 'workflow', or 'autonomous'. Default is 'specialized'.")]
    public string AgentType { get; set; } = "specialized";

    [Required]
    [Description("Prompt template with agent's instructions. Use [[parameter_name]] syntax for parameters.")]
    public string PromptTemplate { get; set; } = string.Empty;

    [Description("Agent parameters that can be passed at execution time.")]
    public List<AgentParameterDefinition>? Parameters { get; set; }

    [Description("List of tool names the agent can call (e.g., 'browse_web', 'search_web').")]
    public List<string>? EnabledTools { get; set; }

    [Description("Creativity level from 0.0 (deterministic) to 1.0 (creative). Default is 0.5.")]
    public double Creativity { get; set; } = 0.5;

    [Description("Inference type: 'simple' or 'complex'. Default is 'complex'.")]
    public string InferenceType { get; set; } = "complex";

    [Description("Agent version (e.g., '1.0.0'). Default is '1.0.0'.")]
    public string Version { get; set; } = "1.0.0";
}

Registering the Agent Replicator in Opal

Once the service is deployed, an Opal administrator registers the tool provider inside Opal using the URL exposed by MapOpalTools().

After registration, the tools become available within Opal:

In Opal Chat, a user can invoke the tool to generate a new persona agent.
In Opal Workflows, a step can call the same tool to create personas dynamically as part of a workflow.
The newly created persona agents can then be used by the Virtual Focus Group experience to evaluate content from a specific audience perspective.

Conclusion

The Agent Replicator makes it practical to scale Virtual Focus Group personas directly within Opal.

By deploying a small tool service and registering it in Opal, teams can generate persona agents quickly and consistently, inspect the prompt templates those agents use, and reuse the agents across Workflows and Chat. This reduces the manual effort of building and maintaining dozens of audience segments and provides a stable foundation for future integration when Optimizely opens official agent creation endpoints.

Cleaning Up Content Graph Webhooks in PaaS CMS: Scheduled Job

Wed, 17 Dec 2025 12:42:30 GMT

The Problem

Bit of a niche issue, but we are building a headless solution where the presentation layer is hosted on Netlify, when in a regular delivery cycle and work has to be tested a deployment preview is generated with a unique url, as part of the frontend deployment a new Web Hook is registered in Optimizely Content Graph so when content is published the frontend cache can be invalidated. The problem here is that with so many deployments occuring the list of web hooks can become quite long. While we could have configured deployment previews to skip webhook registration, that would have meant cached content on those environments, preventing proper testing of real-time content updates.

The Solution

Instead of compromising our testing workflow, we built an automated cleanup solution using Optimizely's Scheduled Jobs feature. This job periodically scans all registered webhooks and removes any that don't belong to our production environments, keeping the list clean and manageable.

Implementation

using EPiServer.PlugIn;
using EPiServer.Scheduler;
using RestSharp;
using System.Text;
using System.Text.Json;

namespace Client.Cms.Infrastructure.Jobs
{
    [ScheduledPlugIn(DisplayName = "Clear Graph Webhooks", GUID = "D4F5A6B7-C8D9-4E0F-AB12-3456789ABCDE")]
    public class ClearGraphWebhooksJob : ScheduledJobBase
    {
        private readonly IConfiguration _configuration;
        private readonly IContentLoader _contentLoader;
        private bool _stopSignaled;

        public ClearGraphWebhooksJob(IConfiguration configuration, IContentLoader contentLoader)
        {
            _configuration = configuration;
            _contentLoader = contentLoader;
            IsStoppable = true;
        }

        public override string Execute()
        {
            try
            {
                // Fetch Content Graph Gateway Address, AppKey and Secret from appSettings
                var gatewayAddress = _configuration["Optimizely:ContentGraph:GatewayAddress"];
                var appKey = _configuration["Optimizely:ContentGraph:AppKey"];
                var appSecret = _configuration["Optimizely:ContentGraph:Secret"];

                if (string.IsNullOrEmpty(gatewayAddress) || string.IsNullOrEmpty(appKey) || string.IsNullOrEmpty(appSecret))
                {
                    return "Failed: Missing configuration values for ContentGraph";
                }

                var auth = Convert.ToBase64String(Encoding.UTF8.GetBytes($"{appKey}:{appSecret}"));
                var baseUrl = $"{gatewayAddress}/api/webhooks";

                var client = new RestClient(new RestClientOptions(baseUrl));
                var request = new RestRequest();
                request.AddHeader("Accept", "application/json");
                request.AddHeader("Authorization", $"Basic {auth}");

                var response = client.GetAsync(request).GetAwaiter().GetResult();

                if (!response.IsSuccessful)
                {
                    OnStatusChanged($"Failed to fetch webhooks: {response.StatusCode} {response.ErrorMessage}");
                    return $"Failed: {response.StatusCode} - {response.ErrorMessage}";
                }

                var json = response.Content;
                var webhooks = JsonSerializer.Deserialize<List<WebhookItem>>(json, new JsonSerializerOptions
                {
                    PropertyNameCaseInsensitive = true
                });

                if (webhooks == null || webhooks.Count == 0)
                {
                    OnStatusChanged("No webhooks found or failed to deserialize response.");
                    return "Success: No webhooks to process";
                }

                int deletedCount = 0;
                int skippedCount = 0;

                foreach (var webhook in webhooks)
                {
                    if (_stopSignaled)
                    {
                        return $"Stopped: Processed {deletedCount} deletions, {skippedCount} skipped";
                    }

                    var urls = GetUrls().ToList();
                    if (urls.Any(url => webhook.Request.Url.Contains(url)))
                    {
                        OnStatusChanged($"Skipping webhook {webhook.Id} with URL {webhook.Request.Url}");
                        skippedCount++;
                        continue;
                    }

                    DeleteWebhook(webhook.Id.ToString(), auth, baseUrl);
                    deletedCount++;
                }

                return $"Success: Deleted {deletedCount} webhooks, skipped {skippedCount}";
            }
            catch (Exception ex)
            {
                OnStatusChanged($"Error: {ex.Message}");
                return $"Failed: {ex.Message}";
            }
        }

        public override void Stop()
        {
            _stopSignaled = true;
            base.Stop();
        }

        private void DeleteWebhook(string id, string auth, string baseUrl)
        {
            var client = new RestClient(new RestClientOptions($"{baseUrl}/{id}"));
            var request = new RestRequest();
            request.AddHeader("Authorization", $"Basic {auth}");

            var response = client.DeleteAsync(request).GetAwaiter().GetResult();

            if (!response.IsSuccessful)
            {
                OnStatusChanged($"Failed to delete webhook {id}: {response.StatusCode} {response.ErrorMessage}");
            }
            else
            {
                OnStatusChanged($"Deleted webhook {id}");
            }
        }

        // Fetch URLs from Site Config Block
        private IEnumerable<string> GetUrls()
        {
            var globalSettingsBlock = _contentLoader
                .GetChildren<OptimizelySettingsBlock>(ContentReference.GlobalBlockFolder)
                .FirstOrDefault();

            return globalSettingsBlock?.FrontendUrls ?? Enumerable.Empty<string>;
        }
    }

    public class WebhookRequest
    {
        public string Url { get; set; }
        public string Method { get; set; }
        public Dictionary<string, string> Headers { get; set; }
    }

    public class WebhookItem
    {
        public Guid Id { get; set; }
        public WebhookRequest Request { get; set; }
        public string Preset { get; set; }
    }
}

How It Works

Authentication: The job authenticates with Content Graph using your AppKey and Secret from configuration
Fetch Webhooks: It retrieves all registered webhooks via the Content Graph API
Filter by URL: The job checks each webhook URL against a configurable list of production URLs stored in a global settings block
Smart Deletion: Webhooks matching production URLs are preserved; all others are deleted
Progress Tracking: The job reports its progress and provides a summary of deletions and skips

Key Features

Content-Driven Configuration: Production URLs are stored in an Optimizely block, making them editable by content editors without code changes
Stoppable: The job implements IsStoppable = true and properly handles stop signals for graceful cancellation
Comprehensive Logging: Uses OnStatusChanged() to provide detailed progress updates visible in the Scheduled Jobs interface
Error Handling: Robust try-catch blocks and validation ensure the job fails gracefully with meaningful error messages

Benefits

Deployment previews can register webhooks and test real-time content updates
The webhook list stays clean through automated maintenance
No manual intervention required
Content editors control which URLs to preserve through the CMS interface

Conclusion

By leveraging Optimizely's Scheduled Jobs framework, we've created an automated solution that maintains a clean webhook registry while preserving full functionality across all environments. This approach is far more maintainable than manually managing webhooks or compromising testing capabilities on deployment previews.

The scheduled job can run daily, weekly, or at any interval that suits your deployment frequency, ensuring your Content Graph webhook list remains lean and manageable.

Building a Lightweight Optimizely SaaS CMS Solution with 11ty

Wed, 03 Dec 2025 10:59:17 GMT

Modern web development often requires striking a difficult balance between site performance and the flexibility needed by content editors. To address this, myself and fellow Optimizely OMVP Graham Carr embarked on a Proof of Concept (POC) to build a solution that prioritises speed and simplicity, while fully leveraging the powerful capabilities of the Optimizely SaaS CMS.

The Challenge: Performance vs. Preview

Our Frontend Architect / Lead, Allyn Thomas, set a clear challenge: find a solution with minimal bloat that is statically generated but still fully compatible with the CMS's live preview capabilities. While frameworks like Next.js are popular, they often come with a significant amount of client-side JavaScript (hydration) that isn't always necessary for content-heavy sites. We wanted something leaner.

The goal was to build a site that is:

Statically Generated: For blazing-fast load times and security.
Lightweight: Avoiding the "hydration tax" of heavier frameworks.
Editor-Friendly: Allowing editors to see live previews of their content in the Optimizely Visual Builder before publishing.

The Solution: 11ty Meets Optimizely SaaS CMS

We chose 11ty (Eleventy) as our Static Site Generator (SSG). 11ty is renowned for its simplicity and flexibility. Unlike other frameworks that force you into a specific client-side architecture, 11ty gives you full control over the output. It generates pure HTML, which is exactly what we needed to keep the bloat to a minimum.

To connect 11ty with Optimizely, we utilised the Optimizely SaaS CMS and the Content JS SDK.

Optimizely SaaS CMS & Content Graph

Our solution centers on the Optimizely SaaS CMS as the headless content repository. We use Optimizely Content Graph, a high-performance GraphQL API, to fetch content. This lets us query exactly what we need, when we need it, keeping our build process efficient.

The Content JS SDK

The Content JS SDK was essential to our architecture. It allowed us to define our content models directly in code using a type-safe builder pattern.

For example, defining a "Button Block" becomes a straightforward TypeScript definition:

import { contentType } from '@optimizely/cms-sdk';

export const ButtonBlock = contentType({
  key: 'ButtonBlock',
  baseType: '_block',
  displayName: 'Button Block',
  properties: {
    Text: { type: 'string', displayName: 'Text' },
    Url: { type: 'url', displayName: 'Url' },
  },
});

This approach ensures that our codebase stays in sync with our content models, providing excellent developer ergonomics and reducing runtime errors.

Structured for Scalability

To maintain sanity as the project grows, we adopted a strict directory structure that mirrors both our content strategy and modern component design principles.

The Models Folder

Our src/models directory is the source of truth for all content definitions. We organized it to reflect the different types of content in the CMS:

src/models/pages/: Definitions for full pages (e.g., ArticlePage, LandingPage).
src/models/experiences/: Composition-based content types used in the Visual Builder.
src/models/components/: Reusable content blocks (e.g., ButtonBlock, TextBlock).

Atomic Component Library

For the frontend implementation, we embraced Atomic Design. This methodology breaks the UI down into its smallest fundamental units, ensuring consistency and reusability across the site.

Our src/components directory is structured as follows:

atoms/: Basic building blocks like buttons, inputs, and text blocks.
molecules/: Groups of atoms working together (e.g., a search form).
organisms/: Complex UI sections like headers, footers, and hero banners.
templates/: Page-level layouts that stitch everything together.

This clear separation of concerns allows developers to work on individual components in isolation while ensuring they fit perfectly into the larger system. It also naturally encourages adherence to the Single Responsibility Principle, as each atom, molecule, or organism has a distinct and focused purpose.

Dynamic Routing with 11ty Pagination

One of the challenges with a static site generator is mapping dynamic content from a CMS to static routes. 11ty handles this elegantly through its pagination feature. We treat our entire content repository as a single "paginated" data set, where each item becomes a page.

First, we fetch all routable content in a global data file, src/_data/routes.js:

// src/_data/routes.js

module.exports = async function () {
  // ... client setup ...

  // Fetch all content items that have a URL
  const query = getRoutePagesQuery(blockFragments);
  const data = await client.request(query);

  // Filter out items without a default URL
  const pages = data._Content.items.filter(item =>
    item._metadata &&
    item._metadata.url &&
    item._metadata.url.default
  );

  return pages;
};

Then, we create a single template, src/pages.11ty.ts, that iterates over this data. By setting size: 1, 11ty generates a separate HTML file for each item in the routes array. The permalink function ensures the file is saved to the correct path as defined in the CMS.

// src/pages.11ty.ts

export const data = {
  pagination: {
    data: 'routes',
    size: 1,
    alias: 'contentItem',
    addAllPagesToCollections: true,
  },
  layout: 'base.11ty.ts',
  permalink: (data: any) => {
    const item = data.pagination.items[0];
    return item._metadata.url.default;
  },
  // ...
};

export function render(data: any): string {
  const item = data.pagination.items[0];
  return ComponentFactory(item);
}

This pattern is incredibly powerful. It means we don't need to manually configure routes or create separate templates for every page type. As editors add new pages in Optimizely, 11ty automatically discovers them and builds the corresponding static pages.

The Component Factory

To handle the diverse range of content types returned by the CMS, we implemented a Component Factory. This function acts as a dispatcher, inspecting the __typename or content type of each item and rendering the appropriate component.

// src/components/ComponentFactory.ts

export function ComponentFactory(content: ContentItem): string {
  // Handle CompositionComponentNode wrapper
  if (content.component) {
    return ComponentFactory(content.component);
  }

  const types = content._metadata?.types || [];
  const typename = content.__typename || '';

  // Dynamic component lookup from registry
  const ComponentView = getView(typename);
  if (ComponentView) {
    return ComponentView(content);
  }

  // Fallback for unknown types
  return `
    <div class="unknown-component" data-epi-block-id="${content._metadata?.key}">
      <h3>${content.Title || content._metadata?.displayName || 'Unknown'}</h3>
      <p>Unknown component type: ${typename}</p>
    </div>
  `;
}

This architecture adheres to the Open/Closed Principle. We can add new component types to our registry without modifying the core routing or rendering logic.

Enabling Live Previews

The most critical part of this POC was ensuring that 11ty's static nature didn't hinder the editing experience. We implemented a dedicated Express Preview Server that runs alongside our 11ty build.

This server acts as a dynamic bridge between the Optimizely Visual Builder and our static templates.

The Express Server Implementation

We chose Express for its robustness and ease of use. The server handles several key responsibilities:

HMAC Authentication: Securely fetches draft content using preview tokens.
Context Awareness: Toggles between "Edit Mode" (injecting data-epi-* attributes) and "Preview Mode".
Real-time Updates: Listens for webhooks to trigger 11ty rebuilds when content is published.

Here is a glimpse of how we handle preview requests in src/preview/server.ts:

// src/preview/server.ts

app.get('/preview/:contentKey', async (req: Request, res: Response) => {
  const { contentKey } = req.params;
  const { preview_token, ctx } = req.query;

  try {
    // 1. Set context mode for Visual Builder (edit vs preview)
    const contextMode =
      ctx === 'edit' ? 'edit' :
      ctx === 'preview' ? 'preview' :
      null;
    setContextMode(contextMode);

    // 2. Set preview token to enable access to draft content
    if (preview_token && typeof preview_token === 'string') {
      previewClient.setPreviewToken(preview_token);
    }

    // 3. Fetch content dynamically
    const content = await previewClient.getContentByKey(contentKey);

    if (!content) {
      return res.status(404).send(renderNotFound(contentKey));
    }

    // 4. Render using the same shared templates as 11ty
    const html = renderContent(content);
    res.send(html);
  } catch (error) {
    res.status(500).send(renderError('Server Error', String(error)));
  }
});

Handling Webhooks

To keep the static site in sync with published content, we also exposed a webhook endpoint. When an editor publishes a page, Optimizely notifies our server, which triggers a debounced rebuild of the 11ty site.

// src/preview/server.ts

app.post('/webhook/content-published', (req: Request, res: Response) => {
  // ... validation ...

  // Debounce rebuilds to handle rapid updates efficiently
  if (rebuildTimeout) {
    clearTimeout(rebuildTimeout);
  }

  rebuildTimeout = setTimeout(() => {
    triggerRebuild();
  }, REBUILD_DEBOUNCE_MS);

  res.json({ status: 'ok', message: 'Rebuild scheduled' });
});

This dual approach gives us the best of both worlds: a static site for production visitors and a dynamic, interactive preview for editors.

Why 11ty Over Next.js?

While Next.js is a fantastic framework, for this specific use case, 11ty offered distinct advantages:

Zero Client-Side JS by Default: 11ty doesn't assume you want a Single Page Application (SPA). It serves HTML. If you want JavaScript, you add it. This results in significantly smaller bundle sizes and faster Time to Interactive (TTI).
Build Speed: 11ty is incredibly fast at building static pages, which is crucial when scaling to thousands of pages.
Simplicity: The learning curve is gentler, and the architecture is easier to reason about. There is no complex hydration logic to debug.

Conclusion

This POC has demonstrated that you don't need a heavy JavaScript framework to build a modern, dynamic, and editor-friendly website with Optimizely SaaS CMS. By combining the raw power and simplicity of 11ty with the robust APIs of Optimizely, we have delivered a solution that delights both developers and content editors.

We have achieved the best of both worlds: the performance of a static site with the dynamic editing capabilities of a CMS-driven application.

You can view the final result here: 11ty-netcel-saas.netlify.app

The full source code is available on GitHub: github.com/MineshS/11ty (Currently a private repo but please do reach out with Git Username so can add)

Extending Application Insights in an Optimizely PaaS CMS Solution

Wed, 24 Sep 2025 23:19:07 GMT

As part of a recent Optimizely DXP project, I needed richer telemetry from the Content Delivery API than the default Application Insights integration provides. The aim was to capture custom properties such as content IDs and cache status so that we could slice and query API performance in more detail. Here is the approach I took.

Creating a Custom Telemetry Processor

The first step was to create a custom 'ITelemetryProcessor' implementation to enrich telemetry for Content Delivery API requests. This processor inspects each telemetry item, checks whether it relates to the Content Delivery API, and then adds custom properties such as 'ApiType', 'IsOptimizelyApi', and the extracted 'ContentId'.

public class ContentDeliveryApiTelemetryProcessor(ITelemetryProcessor next) : ITelemetryProcessor
{
    private readonly ITelemetryProcessor _next = next;

    public void Process(ITelemetry item)
    {
        if (item is RequestTelemetry requestTelemetry &&
            IsContentDeliveryApiRequest(requestTelemetry.Name))
        {
            requestTelemetry.Properties["ApiType"] = "ContentDeliveryApi";
            requestTelemetry.Properties["IsOptimizelyApi"] = "true";

            var contentId = ExtractContentIdFromUrl(requestTelemetry.Url?.ToString());
            if (!string.IsNullOrEmpty(contentId))
            {
                requestTelemetry.Properties["ContentId"] = contentId;
            }
        }

        _next.Process(item);
    }

    // Helper methods to identify API requests and extract IDs omitted for brevity
}

Register the processor with Application Insights in 'startup.cs' or the Program configuration so that it runs for every request.

Adding Request and Response Logging Middleware

To go further, I introduced a middleware component to log the full request and response cycle for API calls. This middleware captures request and response bodies, headers, and timing, and sends a single 'RequestTelementry' entry to Application Insights with custom properties such as cache status.

Below is a reduced example focusing on adding custom properties to a tracked request:

public class RequestResponseLoggingMiddleware(RequestDelegate next, TelemetryClient telemetryClient)
{
    private readonly RequestDelegate _next = next;
    private readonly TelemetryClient _telemetryClient = telemetryClient;

    public async Task InvokeAsync(HttpContext context)
    {
        // … capture request/response details …

        var telemetry = new RequestTelemetry
        {
            Name = $"{context.Request.Method} {context.Request.Path}",
            Url = new Uri($"{context.Request.Scheme}://{context.Request.Host}{context.Request.Path}{context.Request.QueryString}"),
            Duration = stopwatch.Elapsed,
            ResponseCode = context.Response.StatusCode.ToString(),
            Success = context.Response.StatusCode < 400
        };

        telemetry.Properties["ApiType"] = "ContentDeliveryApi";
        telemetry.Properties["IsOptimizelyApi"] = "true";
        telemetry.Properties["CacheStatus"] = cacheStatus;
        telemetry.Properties["RequestHeader_UserAgent"] = context.Request.Headers["User-Agent"];

        _telemetryClient.TrackRequest(telemetry);
    }
}

app.UseMiddleware<RequestResponseLoggingMiddleware>();

And configure logging levels in 'appSettings.json:

"Logging": {
  "LogLevel": {
    "Default": "Warning",
    "Cms.Infrastructure.Middleware.RequestResponseLoggingMiddleware": "Information"
  },
  "ApplicationInsights": {
    "LogLevel": {
      "Default": "Information"
    }
  }
}

This approach provides structured, queryable telemetry for each Content Delivery API call.

Example Output

Benefits of Extended Telemetry

Extending telemetry offers several practical advantages:

Deeper diagnostics: You can quickly isolate performance bottlenecks, such as slow content retrieval or cache misses.
Better observability: Custom properties allow you to group or filter requests by content item, making it easier to identify patterns.
Operational insight: Logging cache status and request headers reveals how your CDN, edge caching, and client applications interact with the CMS.

In large Optimizely solutions, where API calls power multiple front ends, this level of detail is invaluable for proactive monitoring.

Dynamic CSP Management for Headless and Hybrid Optimizely CMS with Next.js

Mon, 08 Sep 2025 09:43:10 GMT

In the evolving realm of web security, Content Security Policy (CSP) is essential for defending against XSS and injection attacks. Traditional approaches often fall short because policies are embedded in code and hard to coordinate across environments.

Optimizely CMS supports dynamic CSP in a headed setup, where the CMS renders pages. This is straightforward with third-party modules such as the Stott Security Optimizely module. Installation is simple, configuration is clear, and the headers flow with the response.

Headless and hybrid architectures introduce a gap. The frontend is separate, so CSP headers often end up fixed in the application tier. That limits agility for security and content teams.

By combining the Stott Security module with Next.js middleware, dynamic CSP becomes possible in headless and hybrid environments. Policies remain CMS-managed, even when the site is delivered through a decoupled frontend.

What we’re solving

Policy changes without releases: Update CSP in CMS and apply instantly.
Environment variations: Manage dev, staging, and production policies centrally.
Cross-team flow: Security and marketing can adjust policies without blocking frontend teams.

Headed vs headless

In headed Optimizely CMS, dynamic CSP is native to the page response. This remains a solid and current pattern. In headless and hybrid setups, the CMS serves content APIs while a separate frontend handles rendering. Without a bridge, CSP is usually hardcoded in that frontend. The approach below restores the same dynamic control you expect in headed.

Architecture

User Request → Next.js Middleware → Stott Security API → Optimizely CMS → Dynamic CSP Headers

The user requests a page from the Next.js app.
Middleware intercepts the request.
Middleware calls the Stott Security endpoint to retrieve current headers.
Headers are applied to the response before it is returned.

Implementation in Next.js middleware

The example below removes development-only branches. It always sources headers from CMS for consistency.

import { NextRequest } from "next/server";

export async function middleware(request: NextRequest) {
  const baseCmsUrl = process.env.DXP_URL || "https://localhost:5000";
  const headersUrl = `${baseCmsUrl}/stott.security.optimizely/api/compiled-headers/list/`;

  // Create or reuse a Response object from your app logic prior to this point.
  // For illustration we assume you already have a 'response' to enrich.
  let response = new Response();

  try {
    const cmsResponse = await fetch(headersUrl, {
      headers: { "Content-Type": "application/json" },
      // Consider short caching and timeouts at edge to keep latency tight
    });

    if (!cmsResponse.ok) {
      // Replace with your logger
      console.error({
        status: cmsResponse.status,
        statusText: cmsResponse.statusText,
        url: headersUrl,
        path: request.nextUrl.pathname,
        context: "middleware - security headers fetch failed"
      });
      return response; // graceful fallback
    }

    const securityHeaders: Array<{ key: string; value: string }> = await cmsResponse.json();

    securityHeaders.forEach(h => response.headers.set(h.key, h.value));

    return response;
  } catch (error) {
    // Replace with your logger
    console.error({
      error,
      url: headersUrl,
      path: request.nextUrl.pathname,
      context: "middleware - security headers processing error"
    });
    return response; // fail safely
  }
}

In your production app, you’ll attach these headers to the actual page or asset response you are returning from Next.js. Keep the fetch lean, and prefer edge runtime where possible.

Key benefits

CMS-managed security: Update CSP without code changes. See the effect immediately.
Environment flexibility: Dev can be relaxed, staging can mirror production with test tools, production can stay strict.
Operational speed: Emergency updates and new integrations go live from CMS.
Resilience: If the CMS API is unavailable, the site continues with safe defaults.
Developer experience: Clear separation of concerns. No more per-environment hardcoding.

Practical considerations

Performance

Enable caching at the CMS endpoint for short periods.
Return compact JSON from the Stott Security module.
Use edge middleware for minimal latency.

Security

Rely on the module’s validation to prevent invalid CSP syntax.
Keep an audit trail of edits to support compliance.

Workflow

Document your policy structure in CMS.
Align environments through content, not code.
Test policy variations in staging, then promote.

Why the Stott Security module

Comfortable CMS UI for policy editing.
Validation before changes go live.
CSP violation reporting integration.
Support for multiple sites and additional security headers.

Explore the module on GitHub: GeekInTheNorth/Stott.Security.Optimizely.

Conclusion

Headed Optimizely CMS already delivers dynamic CSP with ease. The approach above brings the same control to headless and hybrid builds. Policies stay in CMS, the frontend stays decoupled, and security remains responsive to change.

With Next.js middleware, Optimizely CMS, and the Stott Security module, CSP moves from static configuration to a manageable, collaborative capability. It works with the speed of your teams and the realities of modern delivery.

Resources

The Sweet Spot: Hybrid Headless Architecture

Thu, 04 Sep 2025 10:54:45 GMT

When it comes to content management architecture, the pendulum often swings between tightly coupled “headed” CMS setups and the flexibility of fully headless. In reality, many organizations are finding the sweet spot in between: hybrid headless. Pair that with Optimizely PaaS CMS and GraphQL, and you get an architecture that balances agility, scalability, and most importantly, content editor empowerment.

The Three Approaches: Headed, Headless, and Hybrid

Traditional headed CMS
CMS and presentation are tightly coupled. It is easy for content editors and fast for classic web builds, but it struggles to expand into multi-channel experiences.
Fully headless CMS
The CMS acts purely as a content repository, serving JSON via APIs. Front-ends can be built with any technology, but editors lose in-context previewing, and development teams bear additional complexity.
Hybrid headless CMS
With Optimizely, you retain in-context editing while exposing content via APIs. Add GraphQL, and your content architecture gains flexibility, typing, and API efficiency, all while keeping the editorial experience intact.

Why Hybrid Headless with Optimizely PaaS + GraphQL Wins

1. Editor-first without compromise

Editors stay in their familiar Optimizely interface, including on-page preview, content workflows, and drag-and-drop editing, without workarounds required in fully headless setups.

2. Developer agility with GraphQL

GraphQL gives developers precise, efficient data access in a single request. It is strongly typed, self-documenting, and accelerates onboarding as well as development velocity.

3. Why Optimizely PaaS CMS

One of the main advantages of running on PaaS rather than SaaS is the additional control it gives development teams. With PaaS, you are not limited to purely configuration-driven approaches. You can implement bespoke functionality, advanced business logic, and integrations that go beyond what SaaS-only solutions allow.

PaaS also provides deeper control over GraphQL and custom properties, which can be crucial when modelling complex content or delivering advanced omnichannel experiences. This level of flexibility ensures you can tailor the platform to your unique business needs rather than shaping your requirements around the platform.

For organizations with more sophisticated demands, this makes PaaS the better fit. You get the stability and scalability of Optimizely’s managed environment while still retaining the freedom to innovate and customize.

4. Scale baked in with Optimizely One

Optimizely’s DXP handles infrastructure, scaling, uptime, and resilience. Crucially, infrastructure is managed directly by Optimizely, so your team does not need to worry about patching servers or handling traffic spikes.

What is new is that you now also have the option to host your decoupled presentation layer on Optimizely. This means you can run your React, Next.js, or other modern front-end applications side by side with your CMS in a fully managed environment. Optimizely takes care of hosting, CDN, and security, the same way it already does for your CMS (If PaaS CMS, inhouse engineering team will need to handle upgrades, SaaS CMS is fully managed by Optimizely). This makes hybrid headless even more compelling, since both your content layer and your front-end layer can be managed under one roof. For more background, see my earlier take on Frontend Hosting (early thoughts and key questions).

5. Reduced complexity vs. fully headless

Going fully headless often means every template, component, and preview experience has to be engineered from scratch. While that gives developers maximum flexibility, it also creates a lot of operational overhead.

Hybrid headless takes a more balanced approach. Editors retain control over templates, layouts, and content structures directly in the CMS, without needing to wait on engineering teams for every change. This lets marketing teams spin up new landing pages, adjust layouts, or test different content formats on their own, while still benefiting from in-context previewing.

When it comes to personalization, hybrid headless works hand in hand with Optimizely’s Personalization Platform and Web Experimentation Platform. Editors and marketers can create personalized variants or run experiments without relying heavily on developers to rewire the front end. The CMS ensures content and templates are structured in a way that these platforms can easily consume, so experimentation and targeting become smoother across channels.

The result is less engineering effort, faster time to market, and greater autonomy for editors and marketers to deliver tailored customer experiences.

6. Personalization and future-proofing

Optimizely’s personalization and experimentation capabilities extend naturally in a hybrid model. Using the Optimizely Personalization Platform and Web Experimentation Platform, marketing teams can deliver tailored content and run experiments across websites, apps, and other channels.

Because the CMS provides structured content and GraphQL enables efficient delivery, these platforms can target the right segments without requiring heavy developer involvement. As new channels like AR or VR, wearables, or AI-driven assistants emerge, the same approach applies: structured content from the CMS, flexible delivery via GraphQL, and personalization layered on top through Optimizely’s dedicated platforms.

Where Opal and the JS SDK Fit In

Opal: Generative AI capabilities embedded in the CMS help editors query content, generate ideas, and streamline content-to-experience workflows.
Content JS SDK: The Content JS SDK abstracts GraphQL wiring, giving front-end developers a clean, easy-to-use interface for consuming CMS content. This cuts boilerplate and speeds up delivery.

Conclusion: The Sweet Spot

Editors stay empowered
Developers get modern flexibility
Optimizely manages infrastructure, including the option to host your decoupled front-end alongside your CMS
Future personalization and multi-channel strategies remain fully open

It is not about swinging to one extreme. It is about choosing an architecture that enables speed now and adaptability tomorrow. With GraphQL, Opal, the Content JS SDK, and the ability to host both CMS and presentation layer on Optimizely, hybrid headless is the architecture that delivers the sweet spot.

Optimizely Frontend Hosting Beta – Early Thoughts and Key Questions

Wed, 23 Apr 2025 13:43:24 GMT

Optimizely has opened the waitlist for its new Frontend Hosting capability. I’m part of the beta programme, but my invite isn’t due until May, while I haven’t had hands-on access yet, I’ve already been digging into what I’ll be looking for once it lands.

What is Frontend Hosting?

This new offering is designed to simplify how frontend apps are deployed and managed alongside Optimizely CMS. It’s available as an add-on to both CMS SaaS and PaaS, and brings together:

Hosting for headless frontend applications
A built-in delivery network
Web Application Firewall (WAF)
Managed services for build, deploy and performance

This could offer a tighter, more integrated experience for those already using a headless CMS setup.

If you’re after background on other frontend hosting options, I covered related topics in these earlier blog posts:

What I’ll Be Exploring in the Beta

Environment & Compatibility

Will it work cleanly across CMS SaaS and CMS PaaS?
What frameworks will be supported out of the box (e.g. Next.js, Astro)?
Will it handle different build strategies?
- Static
- Dynamic
- Incremental builds
Are serverless functions on the roadmap (Lambda, Edge functions)?
Is there a CDN and WAF already in place?
Are preview environments supported (e.g. URLs for pull requests)?

Developer Experience

Any limits around build minutes, concurrent builds?
Built-in CI/CD or integrations with GitHub/GitLab?
How is secret management handled? (Environment Variables)
What kind of logging and observability is available?
Will it help surface key metrics (e.g. Core Web Vitals, SEO signals)?
Can I get alerts if a deploy fails or performance drops?

Access & Security

Can access be restricted (IP allow lists, password protection)?
Is traffic control through WAF configurable?
Can we apply rate limits?

Commercial Considerations

How will pricing work?
- Bandwidth
- Seats
- Execution time for serverless
Multi-project or multi-site support — all under one roof?

Why It’s Interesting

For teams running hybrid headless setups, this could remove a fair bit of friction. No need to spin up hosting separately or stitch things together manually, this could mean fewer moving parts, more predictable deployment workflows, and a clearer support model.

And being Optimizely-native, it should also mean closer alignment with the rest of the platform ecosystem.

Discovery & Early Access

I was part of an early discovery interview with the team last year, which gave me a first look at the thinking behind this product. Here’s part of the follow-up I received:

"As you may recall, you participated in a discovery interview with us about CMS frontend hosting last year. Your feedback back then was extremely helpful! I wanted to let you know that we are now in a beta testing phase of frontend hosting!"

I’ve also some early preview screenshots from the discovery. I’ll include a few of those in this post to give a sense of what might be coming.

Note: The screenshots shown here are from early design mockups shared during the initial discovery phase. The UI and features in the current beta release may differ significantly as the product has continued to evolve.

Get Involved

Optimizely is actively inviting feedback to help shape this feature before full release. If this looks like something you’d want to test, you can still register via the waitlist.

I’ll post more as soon as I’m hands-on in May — including walkthroughs, findings, and observations from real use cases.

Stay tuned.

Experimentation strategies with Optimizely: Web, Edge, and Feature Experimentation

Sat, 05 Apr 2025 12:24:37 GMT

Experimentation is a cornerstone of data-driven decision-making, and Optimizely offers multiple ways to run experiments across your digital experiences. Whether you are optimising a website, personalising a user journey, or testing new features, choosing the right experimentation strategy can have a significant impact on both user experience and performance.

In this post, we’ll explore three key experimentation approaches in Optimizely: Web Experimentation, Edge Experimentation, and Feature Experimentation—highlighting their strengths, trade-offs, and performance considerations.

Web Experimentation: Client-Side Testing

Optimizely Web Experimentation is the most commonly known form of A/B testing, where experiments are executed client-side via JavaScript. This means that changes are applied dynamically in the browser after the page has loaded.

Benefits of Web Experimentation

Fast iteration: Non-technical teams (e.g. marketers, designers) can quickly create and deploy experiments without engineering support.
Rich visual editing: The WYSIWYG editor enables easy modification of elements without touching code.
Wide experimentation scope: Ideal for A/B testing landing pages, copy variations, UI elements, and other front-end components.

For more information, refer to the official Optimizely Web Experimentation documentation: Optimizely Web Experimentation Introduction

Performance considerations

Flickering effect: Since changes are applied after the page loads, some users may briefly see the original content before the variation is applied.
JavaScript overhead: As the number of experiments grow, the required JavaScript also increases, which may affect page load times.
Execution time: Performance can vary depending on the complexity of the variation and network conditions.

Despite these considerations, Web Experimentation remains a powerful tool for non-technical teams looking to optimise experiences without needing backend development effort.

Edge Experimentation: Server-side, high-performance testing

Edge Experimentation moves the execution of experiments from the browser to the edge layer, where content delivery happens closer to the user (e.g. via a CDN or middleware). This approach ensures experiments are applied before the page reaches the end user.

Benefits of Edge Experimentation

Near-zero performance impact: Since variations are applied before the response reaches the client, there’s no flickering or delay.
More reliable data: Eliminates client-side inconsistencies, ensuring accurate measurement of experiment results.
Faster experimentation for global users: Leveraging CDNs and edge computing reduces latency, making experiences smoother for users worldwide.

For more information, refer to the official Optimizely Performance Edge documentation: Optimizely Performance Edge Overview

Use cases

Edge Experimentation is ideal for personalisation at scale, content experiments, and changes that impact performance-sensitive areas such as eCommerce checkout flows and high-traffic landing pages.

Feature Experimentation: Server-side testing for feature rollouts

Feature Experimentation allows teams to test and control feature rollouts via feature flags at the server or middleware level. Unlike Web Experimentation, which focuses on front-end changes, this method is geared towards testing new functionalities before full deployment.

Benefits of Feature Experimentation

No performance trade-offs: Since variations are applied server-side, users receive the final content without delay.
Safe feature rollouts: Teams can progressively roll out features to a subset of users before full release.
Deeper experimentation possibilities: Beyond UI tests, Feature Experimentation enables testing changes in logic, APIs, and infrastructure.

For more information, refer to the official Optimizely Feature Experimentation documentation: Optimizely Feature Experimentation Introduction

Use cases

This approach is perfect for testing new functionalities, backend optimizations, and product feature toggles while minimising risks.

Choosing the right experimentation strategy

When deciding between Web, Edge, and Feature Experimentation, consider the following:

Factor	Web Experimentation	Edge Experimentation	Feature Experimentation
Performance	Can introduce flickering and JavaScript overhead	Near-instant, no flickering	No client-side impact
Experiment Scope	Front-end UI elements	Content and UI changes at the edge layer	Feature toggles, backend logic
Execution Location	Client-side (browser)	CDN/Edge layer	Server-side or middleware
Implementation Effort	Low (no engineering needed)	Medium (requires setup)	High (involves development)
Best For	Marketing, UI tweaks, messaging tests	Performance-critical content changes	Feature rollouts, backend logic experiments

Final thoughts

Each experimentation approach in Optimizely has its place. Web Experimentation remains a powerful tool for marketers and teams that need agility, despite its minor performance trade-offs. Edge and Feature Experimentation, on the other hand, offer superior performance and scalability by shifting execution away from the client.

Ultimately, leveraging a combination of these approaches based on your goals, performance requirements, and team capabilities will lead to the most effective experimentation strategy.

Exploring Optimizely SaaS CMS – What’s New & How to Accelerate your Build

Thu, 27 Feb 2025 11:00:25 GMT

In my latest video, I take a fresh look at Optimizely SaaS CMS, covering some of the recent improvements aimed at enhancing the editor experience. Plus, I dive into the fantastic work Remko has done with his helper packages and starter solutions, making development even more seamless.

🔹 Learn how to effortlessly create an Element in the UI and scaffold it in the frontend.
🔹 See how you can generate a new element directly in the frontend and push it to the CMS.

If you're working with Optimizely or just curious about headless CMS solutions, this one's for you!

📺 Watch here: https://youtu.be/m8zvDgdYmpk

Links I used in the video:

Remkos Git Repository: https://github.com/remkoj
Optimizely Mosey Demo: https://github.com/episerver/cms-saas-vercel-demo

Let me know your thoughts in the comments!

SaaS CMS - Pages and Blocks get the Visual Builder Treatment

Tue, 17 Dec 2024 16:27:43 GMT

I’m thrilled to see that Optimizely has now enabled Visual Builder for OG Pages and Blocks within SaaS CMS, and I’m guessing this will become standard for CMS13. Previously, Visual Builder was only available for Experiences, forcing us to revert to traditional on-page editing which was somewhat clunky or use the "All Properties" view, which didn’t provide a great preview experience.

With Visual Builder, we now get the best of both worlds: an intuitive editor experience combined with the ability to preview our changes in real time. I haven’t taken this for a proper spin yet, but the early signs are very promising.

When editing structured pages, the new interface looks like this:

As shown above, updates can be made in the left panel, and they are instantly reflected in the main preview panel.

In contrast, the old on-page editing view looked like this and was never as responsive:

Additionally, Visual Builder is now available for Blocks as well. The interface for Blocks is similar to Pages, and it looks like this:

Although my templates aren’t perfect, this is entirely within our control via the frontend presentation layer (Next.js).

This is just a quick post to share my initial impressions, but I’ll provide more updates as I integrate this into my own templates.

SaaS CMS - Self-hosting Presentation Layer with Coolify

Mon, 23 Sep 2024 19:00:11 GMT

Introduction

In my previous post, I explored the hosting options for the Hybrid Headless/Fully Headless presentation layer (frontend) using Netlify and Vercel. These platforms are my top recommendations due to their ease of use and feature-rich offerings. However, there are situations where they may not entirely meet your needs, or their pricing models might pose challenges.

If you're looking for more control over your hosting costs, self-hosting is a viable third option, whether on physical servers or virtual private servers (VPS). To make the self-hosting process more manageable, I’ve created a proof of concept using Coolify. Coolify is an open-source project that simplifies server configuration for hosting your frontends with minimal effort. It offers many of the same features as Vercel and Netlify, but without the associated costs.

Here are some of Coolify's standout features:

Language Agnostic: Supports a wide range of programming languages and frameworks, including Next.js.
Flexible Deployment: Can be deployed on any resource, including your own servers, VPS, EC2, and DigitalOcean—all you need is an SSH connection.
Push to Deploy: Easily deploy by pointing to any Git repository.

PR/Commit Deployments: Automatically deploy new commits and pull requests.

Additional Features:

SSL certificates
Automatic backups
Webhooks
API-first approach
Collaboration tools
Monitoring and notifications

Azure Example

Coolify offers flexible installation and configuration options, allowing deployment on virtually any environment. For full documentation, you can refer to Coolify's official guide.

For this example, I chose to test Coolify on a Linux (Ubuntu 24.04) Virtual Machine. The setup process in Azure is straightforward, so I won't dive into each setup step, but here’s a quick overview of my configuration below:

I also had to open a few ports to allow for communication to and from the virtual machine. This was for both setup purposes and public site access (I was adding these as and when required).

Port 22 for SSH Access
Port 8000 for initial Coolify server Access
Port 80 for Public HTTP Access
Port 443 for Public HTTPS Access

Once my virtual machine was configured, I made an SSH connection. You can connect either via the Azure Portal or using your favorite terminal.

Install and Configure Coolify

Once connected via SSH, the installation of Coolify was simple. Running the following command started the process:

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

This installs Docker and runs the Coolify image. The entire process took about 5 minutes. After installation, Coolify provides a URL to complete the configuration. Once I registered, I was taken to the Coolify dashboard, ready to create a new project.

Domain Configuration

To make access easier, I connected a domain to my server. I used an existing domain from Fasthosts and made simple DNS changes by adding two A Records (@ and *), pointing them to my server’s public IP address.

In Coolify’s settings, I configured the domain name for the control panel at http://coolify.chillicrunch.co.uk. I also set up Wildcard Subdomains to allow deployments to URLs like https://<my-project-name>.chilicrunch.co.uk/, similar to how Netlify and Vercel manage deployments.

This was done by navigating to Servers > General and adjusting the settings.

Connecting to Git Hub Repo

To enable continuous deployment, I connected Coolify to my private GitHub repository. Coolify supports several Git sources, but for this example, I used GitHub. You can add your GitHub repo by navigating to Sources and clicking Add. The process requires setting up Client ID, Secret, and Webhook Secret, which are generated during the setup.

Adding a new Project

With the Git connection established, I was able to add my first project. In the Projects section, I clicked New, provided a name and description, then selected the Git repo I wanted to deploy.

The deployment process took about 3 minutes. Thanks to the wildcard subdomains setup, the subdomain was automatically configured. I also added the necessary environment variables for my project. You can find more details on this process in this video.

With everything in place, my website was live: https://saas-cms-visual-builder.chilicrunch.co.uk/

Conclusion

Setting up Coolify on an Azure Virtual Machine was smooth and straightforward. As you can see, it's easy to get Coolify up and running on your private servers with minimal effort, making it a cost-effective alternative to traditional hosting platforms like Vercel and Netlify.

Frontend Hosting for SaaS CMS Solutions

Sat, 20 Jul 2024 00:21:31 GMT

Introduction

Now that CMS SaaS Core has gone into general availability, it is a good time to start discussing where to host the head. SaaS Core is natively a Headless CMS, and regardless of whether you plan to use it in a "Pure Headless" or "Hybrid Headless" manner, the presentation layer (Head/Frontend) needs to be hosted somewhere.

Cloud Native Providers: Vercel and Netlify

Optimizely has partnered with Vercel and Netlify, both of which offer fantastic services for hosting the frontend of your application. Both platforms support a variety of frontend frameworks and static site generators, making them versatile choices for a project's hosting needs.

They provide a seamless experience for developers with continuous deployments, user-friendly CLI tools, unlimited deployment environments, and highly efficient build processes. Every time a pull request is raised, or a commit has been made to a branch, both services automatically build a preview with a unique URL. Like a staging environment for every PR or branch, previews are perfect for testing and collaboration.

To ensure the frontend is fast and scalable, both platforms offer a CDN to serve requests and support edge or serverless functions to execute any business logic. Serverless functions are a way to deploy server-side code as API endpoints. These will spin up automatically when triggered by an event, handle and process server ran code, and then spin down until the next event. Edge Functions are similar to serverless functions that are generally more efficient and faster than traditional Serverless compute, since they operate within a much leaner runtime. Deployed globally by default, Edge Functions run in the region closest to the request for the lowest latency possible.

Commercial Models

Vercel and Netlify are designed to simplify the deployment and management of your website’s frontend, ensuring reliability, speed, and ease of use. Their commercial models are quite similar; both offer customizable enterprise pricing based on the specific needs of the organization. Pricing typically includes multiple developer seats, high bandwidth limits with additional costs for overage, and extensive usage of serverless and edge functions with charges for higher usage. Both platforms provide enterprise-grade support, including dedicated account management and service level agreements (SLAs) to ensure high availability and priority issue resolution.

Demonstration

Here is a quick video demonstrating the deployment of the Mosey Template to Vercel: Watch the video.

A similar process was replicated on Netlify with very few changes to the frontend code or configuration.

Conclusion

By leveraging the robust hosting capabilities of Vercel and Netlify, you can ensure that the frontend of your application is performant, scalable, and easy to manage. Whether you choose Vercel or Netlify, both platforms offer the tools and support needed to seamlessly deploy and maintain your website.

But Wait

... Oh and for a bit of fun I also looked at self hosting either on prem or on a VPS using Coolify, surprisingly this was also very easy and in less than an hour I had this : https://saas-cms-visual-builder.chilicrunch.co.uk

Hopefully have a demo on this early next week :)

Exploring SaaS CMS: API Clients and Content Management APIs

Wed, 06 Mar 2024 20:29:56 GMT

Introduction

In continuation of my previous post on leveraging the Content Management API and OpenID Connect Authentication on the PaaS-based Optimizely CMS, I delve into the delivery mechanisms within the SaaS-based CMS Platform. Surprisingly, the majority of functionalities are readily available and seamlessly integrated into the system. In this article, I provide a quick preview of the available features and guide on configuring the exposed API for definition and content management.

Note: It's essential to bear in mind that while I explore these features, the SaaS platform is still in its BETA phase, and APIs are currently at version 0.5. Changes might occur as the SaaS CMS transitions into general availability.

Configuring the API Client (Equivalent to OpenID Connect Package)

The API client functionality comes pre-installed in the SaaS CMS, and the setup is near identical to what we found on the PaaS platform with the Open ID Connect package. The tool can be found within Settings and the Access Rights section as highligted in the image below.

Once on the API Client interface we can create a Client ID, the Client Secret is automatically generated please store this safely as there is no way of retrieving once you leave the page. The option to "Allow the client to impersonate users" is self-explanatory; enabling this allows the client to function as another user within the CMS.

Using the credentials

I'll demonstrate how to utilize these credentials using Postman to retrieve a JWT token for subsequent API calls. To obtain a Bearer Auth Token, a GET call needs to be made to the designated URL:

https://app-xxxprod.cms.optimizely.com/_cms/v0.5/oauth/token

Sending the required parameters along with the request, including grant_type, client_id, client_secret, and optionally act_as, will result in the generation of a token for future requests. Notably, this token expires automatically after 300 seconds.

Example:

Authorisation to API using the Bearer Token

With the Bearer Token generated, subsequent API requests can now be authenticated by passing this token as the "Authorization" Header parameter.

Example:

Content Definitions API

Now armed with the bearer token, we can interact with the Content and Definitions API. The first API we explore is the Content Definitions API. Detailed API reference can be found here.

Get Content Types

A simple GET request to the following URL provides a list of all content types within the CMS:

https://app-xxxprod.cms.optimizely.com/_cms/v0.5/contenttypes

Example:

To only get the details of a certain known type we pass in the definition name (key) to the URL:

https://app- xxxprod.cms.optimizely.com/_cms/v0.5/contenttypes/articlepage

Create Content Type

To create a content type, a POST request is made to the same URL, passing in the necessary parameters.

Example:

Content {Delivery} API

The API reference to the Content API can be found here : Create content (optimizely.com)

Get Content

To retrieve a content item, a GET request is made to the designated URL, using the Guid of the page as the key. The key is in a UUID format so should not include any dashes e.g. 115988243510434482925671c3ee601a

https://app- xxxprod.cms.optimizely.com/_cms/v0.5/content/{key}

Example:

Conclusion

As you can see its very easy to interact with the API’s and retrieve the relevant information you may need, as well as programmatically being able to create Content Models and Instances of these models. Its great to see this has all been included from the get go and provides a lot of scope to decide on how we manage the content definition creation process.

A Quick Guide to Using the Content Management API and OpenID Connect Authentication

Wed, 01 Nov 2023 22:44:53 GMT

Introduction

Content management in Optimizely CMS becomes more efficient and streamlined with the power of the Content Management API.

The Optimizely Content Management API adds REST endpoints for basic content management operations such as:

Create content objects
Modify existing content objects
Delete content objects
Get draft content objects
Move content objects

The REST API is useful for pushing external content to Optimizely without having to deploy custom integration code to the Optimizely Content Management System (CMS).

In this quick guide, I'll walk through the steps to set up a solution for content creation using the API.

Prerequisites

Before diving into the process, ensure you have the following:

An active Optimizely CMS instance (For Alloy site setup, refer to my guide here).
Familiarity with an API request tool like Postman.
A good understanding of your CMS's content structure and types.

Step 1: Install and Configure the Content Management API

First, let's set up the Content Management API. If you're using Visual Studio, you can install it via the Package Manager or via the CLI using this command:

dotnet add package EPiServer.ContentManagementApi

Once installed, modify the Startup Class to include the basic configuration. In the ConfigureServices method, add the following line:

services.AddContentManagementApi(o => o.DisableScopeValidation = true);

Then, build and run your solution with:

dotnet run

Step 2: Test the Endpoint

After installing the Content Management API, you can test the endpoint using Postman. Send a simple POST request to /api/episerver/v3.0/contentmanagement. As we haven't added any parameters, expect a 400 Bad Request status code with a specific JSON response.

{
    "errors": {
        "filename": [
            "The filename field is required."
        ],
        "content-Type": [
            "The contentType field is required."
        ]
    },
    "type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
    "title": "One or more validation errors occurred.",
    "status": 400,
    "traceId": "00-b2f4877cb70b04fc20ea6fc0dfe1d2fe-d37b0cf2e4dc9458-00",
    "code": "InvalidModel"
}

This response tells us the endpoint is operational. Alternatively, it would have resulted in a 404 status code. At this stage, we can try adding content to Optimizely CMS via Postman. Use the provided JSON body, but you'll likely encounter a 401 status due to permissions.

{
  "name": "Text Block (Content Management API)",
  "language": {
      "name": "en"
  },
  "contentType": [
      "Block",
      "EditorialBlock"
  ],
  "parentLink": {
      "id": "33"
  },
  "mainBody": {
      "value": "<p>Hello World</p>"
  },
  "status": "Published"
}

Response Example

{
    "type": "https://tools.ietf.org/html/rfc7235#section-3.1",
    "title": "Unauthorized",
    "status": 401,
    "detail": "Access was denied to content 33. The required access level was \"Create, Publish\".",
    "instance": "/api/episerver/v3.0/contentmanagement",
    "traceId": "00-c91883ef32f39b8dda0571df62c44b7b-d48fe0471f6254da-00"
}

For testing purposes, you can temporarily grant access rights to "Everyone" for creating and publishing pages. After making this change, re-run the request. You should now receive a 201 (Success) status code with the content successfully created in CMS.

Step 3: API Authentication via OpenID Connect

In the real world, giving "Everyone" access to publish content is not acceptable. To ensure authorized individuals/services create and publish content, we need to authenticate Content Management API requests using OpenID Connect and Bearer Tokens (JWT). Here's how:

Install the OpenIDConnect NuGet package with this command:
```
dotnet add package EPiServer.OpenIDConnect.UI
```

Amend the Startup class to configure this package and make Content Management API support it. Update the code as follows:

services.AddContentManagementApi(OpenIDConnectOptionsDefaults.AuthenticationScheme, options =>
{
    options.DisableScopeValidation = true;
});

services.AddOpenIDConnect<ApplicationUser>(
    useDevelopmentCertificate: true,
    signingCertificate: null,
    encryptionCertificate: null,
    createSchema: true
);

services.AddOpenIDConnectUI();

After saving the file, build and run the solution and access Optimizely Admin mode. Look for "OpenID Connect" in Settings, create a new application (set Scopes as "epi_content_management").
Test if it all works by making a POST request in Postman to /api/episerver/connect/token with the following parameters:
- client_id: api-client
- client_secret: SuperSecret
- grant_type: client_credentials
You'll receive a time-limited access token.

Having got this far and sucessfully being able to generate a bearer token, we have to grant our newly created client permissions to create and publish content, we do this by managing access rights in Optimizely. Remove additional rights given to the "Everyone" group and add them to the api-client with the same rights instead.

Finally, copy the access token from Postman and make another POST request to /api/episerver/v3.0/contentmanagement, this time also setting the Authorization Token.

That's it! We're now securely creating content via the Content Management API using a JWT Bearer Token.

** For additional Security measures you can add some additional CORS policies to your Optimizely Solution so only certain services can call the Content Management API requests or even lock the API down via IP Restrictions.

Conclusion

The Content Management API alongside Content Definitions API are quite powerful tools, they are not difficult to setup and have many use cases for example with the Content Management API we can quite easily utilise for migration processes and import a large amount of content into the CMS in bulk all programmatically. With the recent announcement of the SaaS CMS offering the Content Definitions API is quite useful in creating Content Types and something that can quite easily be source controlled, so definitely something to look out for and try-out.

References

Insights from Setting up and Getting Started with SaaS Core [Beta]

Mon, 23 Oct 2023 15:36:59 GMT

Introduction

Shortly after Opticon San Diego OMVPs were given a chance to test drive and evaluate the SaaS Core CMS [Beta]. Having seen David Knipe’s demo in one of the breakout sessions I initially felt this should be plain sailing how wrong I was, fully expected considering it is in early Beta.

Below I write about some of the pain points I found which will hopefully help the wider community avoid the issues I faced, and hopefully get to a fully working solution a lot quicker.

Initial Setup

So like David I wanted to utilise Remko’s Next.JS Presentation Layer and CMS Content Types, this is based on Mosey Bank Demo Templates. The Git Repository for this can be found here.

Firstly, I started by Importing the Content Definitions and Content Instances into Optimizely, the import file is called InitialData.episerverdata.

Optimizely Graph Synch Issues

The content imported just fine although indexing this to Optimizely Graph was not working, later it was found that one of the properties utilised “LinkItem” property was not being serialized properly which was causing the whole indexing Job to fail. This is a known Bug and Optimizely are currently working on rectifying this.

There's an issue during contents are being indexed: An error while sync content. Status: 0, message: Error when building index operation for contentIds: 27_30., An error while sync content. Status: 0, message: Error when building index operation for contentIds: 84_89.. (see log for more information)

I felt the best way to resolve the issue would be to delete the properties from the Content Types:

Button
Hero Banner
Menu Item
Website Footer

Upon doing so my Content Graph Indexing Job ran thru fine. (This would cause knock on affects with my presentation layer as the property is expected to be present in templates and graph more on this later).

Vercel Deployment

Ok so now we have Content in CMS and the Graph Indexing Job looks to be working it was time to move onto deploying the presentation layer. For this we need to have a Git and Vercel account (Hobby account as a bare minimum).

Navigating to Remok’s Git repo you will see the following Deploy button, simply click this to start the process.

When configuring the project you will need to populate some of the Optimizely Graph Security Tokens and DXP URL, these can be found in the Dashboard tab within Optimizely and the DXP URL will be the domain address you see in CMS e.g. https://app-ocxcxxxx122w0uprod.cms.optimizely.com/

So, my first run of this did not work the build process failed due to missing properties of course I should have known this having deleted the LinkItem properties earlier.

Rather than amend the frontend templates I added the LinkItem properties back into the Content Types ensuring they were not populated, this meant the serialization process for this property would not break.

On my next run the build process did get further although I was getting errors on all of my landing pages which stated the following:

Error occurred prerendering page "/en/services". Read more: https://nextjs.org/docs/messages/prerender-error
Error: Expected to load exactly one content item, received 0 from Optimizely Graph.
    at cms_content_CmsContent (/vercel/path0/apps/frontend/.next/server/chunks/998.js:197:2804)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async /vercel/path0/apps/frontend/.next/server/chunks/998.js:197:4372
    at async Promise.all (index 0)
    at async CmsContentArea (/vercel/path0/apps/frontend/.next/server/chunks/998.js:197:3977)

Having tried to resolve this issue via Content update on the specific Page Instances, I gave up as nothing I was changing in the Content was making an affect with the Build Process. Not getting far I thought it would be best to clear out all the content from Optimizely and start again with just a single Homepage and no block instances.

e.g.

I then deleted my Graph Index and re-ran the Indexing Job. After a successful Index I re-ran the deployment via Vercel and this time it was sucessful and a skeleton homepage was presented

On Page Editing

With my homepage loading I decided to add some content to the content area like a simple Rich Text Block into the Main Content Area, initially I created this as an Inline Block which did not work, the template or graph currently cant handle this and it is something Optimizely are working on rectifying. Having changed the Inline Block to a Shared Block the content was rendering just fine on my Homepage.

My next steps were to try and get the On Page Editing aspect of the CMS working for this I had to set the Hostnames up correctly within Manage Websites, my Edit Host is the SaaS CMS and Primary Host is the Vercel Front end i.e.

Navigating to the CMS “On Page Edit” mode I assumed it would just work like shown in the Demo, to my dissmay I was presented with a 404 status code. After lots of digging and discussing with Optimizely it turned out they had turned off ContentReference ID in Optimizely Graph, thus the presentation layer could not route to the correct page to display the On Page edit view. Luckily after a day they re-enabled the numerical identifiers I cleared and re-indexed Opti Graph went back to On Page Edit Mode, and everything was now working.

Summary

Despite several challenges, I was happy to get the solution working including the On Page Editing aspect. If trying yourself after importing the Initial Data I would delete all the Content in Page Tree and Assets Folder and start building the content up once you have a successful deployment. Some known bugs, such as Link Item Serialization and issues with Inline Blocks, require further investigation. Overall, I'm optimistic about the potential of the SaaS CMS Core and look forward to its evolution.

Responsive Image Rendering at the Edge

Thu, 12 Oct 2023 19:29:24 GMT

Dynamic Image Resizing

At Netcel, we recognize the significance of delivering high-performance solutions that enhance user experience and contribute to better Google rankings.

To achieve this, we prioritize serving optimized images tailored to a user's viewport size, commonly referred to as responsive images. Our approach involves advising our clients to upload the highest quality image available, while we take care of dynamically resizing and serving the appropriate version to end users.

Here's an example of what the image tag would resemble in the HTML source:

In the given example, the image file "about-intro-people-collage-4.jpg" represents the original high-quality image. The srcset attribute complements the sizes attribute by specifying various image options with their corresponding widths. Together, these attributes determine the appropriate sizes of the image for different viewport widths, display pixel density and layout.

Seeing this in Action:

Small viewport (320 pixels width)

Medium viewport (768 pixels width)

Large viewport (1200 pixels width)

As you can see with each request at different viewports the images returned were different in both storage size and width this in return meant the time taken to load was also different.

To achieve dynamic resizing and optimization of images, it is common to employ specialized tools and libraries that can handle the processing on the server side. Some popular examples of such tools are Image Resizer, Image Processor, and Six Labors ImageSharp.

Here's how the process typically works:

Image Resizing and Optimization:

These tools provide APIs or server-side libraries that can be integrated into your web application. When a request is made to an image, the server-side code utilizes these tools to resize and optimize the image on-the-fly based on the requested dimensions and optimization settings. This ensures that the image is served in the most appropriate format, size, and quality for the specific user's device and viewport.
Content Delivery Network (CDN) Caching:
Once an image is processed and served by the server, it is often beneficial to cache the optimized image in a Content Delivery Network (CDN). CDNs are distributed networks of servers located worldwide, designed to deliver content with low latency. By caching the optimized image in the CDN, subsequent requests for the same image can be served directly from the CDN servers, reducing the load on the origin server and improving response times for users across different regions.

The advantage of this approach is that the image processing and optimization tasks are performed dynamically on the server side, enabling flexibility and adaptability to different image requests. Once the image is processed and cached in the CDN, subsequent requests for the same image can be efficiently served directly from the CDN, reducing the need for repeated processing on the server.

Edge Resizing and .NET 6 Tag Helpers in Action

With the evolution to CMS12, we encountered challenges with compatibility and licensing agreements for the image optimization tools we previously used, especially in the context of .NET 6+ compatibility. We sought a solution that would alleviate the need for server-side processing and overcome these hurdles. Fortunately, Optimizely with Cloudflare are now enabling, "Image resizing at the edge for CMS and Commerce." (Beta)

This innovative feature from Optimizely allows us to leverage Cloudflare's powerful edge platform to transform images directly at the edge. It eliminates the necessity for additional tooling within our solution, removing the optimization burden from our servers entirely. Now, we can seamlessly resize, adjust quality, and even convert images to next-generation formats on demand.

The HTML tags on the front end remain unchanged. However, instead of specifying the image widths as query string parameters, we construct the image URL in a specific format to leverage Cloudflare's functionality for resizing and serving the appropriate image. For example, we might use a URL structure like "/cdn-cgi/image/width=80/siteassets/test-folder/demo.jpg" to indicate that we want Cloudflare to resize and deliver the image with a width of 80 pixels.

Model Attribution + Tag Helper

How we manage this all via code and attribute our Image Content References with the Width and Sizes attributes is quite very simple, here is an example of an Image on a Promo Block

    [Display(
            Name = "Image",
            Description = "Image",
            GroupName = TabsGroups.Content,
            Order = 100)]
    [CultureSpecific]
    [UIHint(UIHint.Image)]
    [ImageSize(Width = 210)]
    [ImageSize(Width = 280)]
    [ImageSize(Width = 335)]
    [ImageSize(Width = 420)]
    [ImageSize(Width = 452)]
    [ImageSize(Width = 526)]
    [ImageSize(Width = 550, IsDefault = true)]
    [ImageSize(Width = 560)]
    [ImageSize(Width = 630)]
    [ImageSize(Width = 670)]
    [ImageSize(Width = 840)]
    [ImageSize(Width = 904)]
    [ImageSize(Width = 1005)]
    [ImageSize(Width = 1052)]
    [ImageSize(Width = 1100)]
    [ImageSize(Width = 1356)]
    [ImageSize(Width = 1578)]
    [ImageSize(Width = 1650)]
    [ImageSizes(Sizes = "(min-width: 1280px) 550px, (min-width: 1024px) calc(100vw - 120px) / 2, (min-width: 768px) calc(100vw - 80px) / 2, calc(100vw - 40px)")]
    [Required]
    public virtual ContentReference PromoImage { get; set; }

We have then created a simple Tag Helper to read these attributes and generate the Image Tag for us, some caveats to remember, resizing at the edge only works when routing via the CDN so not locally, also not when in the Optimizely Edit Interface. We have fallen back to not resizing in these scenarios and can be seen below.

[HtmlTargetElement("img", Attributes = "image-for")]
public class EdgeImageTagHelper : TagHelper
{
    private readonly IUrlResolver _urlResolver;
    private readonly IContentLoaderService _contentLoader;
    private readonly IWebHostEnvironment _webHostEnvironment;
    public ModelExpression ImageFor { get; set; }
    public string CssClass { get; set; }
    public string Fit {get; set; }

    public EdgeImageTagHelper(IUrlResolver urlResolver, IContentLoaderService contentLoader, IWebHostEnvironment webHostEnvironment)
    {
        _urlResolver = urlResolver;
        _contentLoader = contentLoader;
        _webHostEnvironment = webHostEnvironment;
    }

    public override void Process(TagHelperContext context, TagHelperOutput output)
    {
        if (ImageFor.Model is not ContentReference edgeImage) return;
        if(ContentReference.IsNullOrEmpty(edgeImage)) return;
        if(!_contentLoader.TryGet(edgeImage, out ImageFile imageFile)) return;
            
        var actualUrl = _urlResolver.GetUrl(edgeImage);
        var property = ImageFor
            .Metadata
            .ContainerType
            .GetProperties()
            .FirstOrDefault(x => x.Name == ImageFor.Metadata.PropertyName);

        if (property == null)
        {
            RenderNonResponsiveImage(output, actualUrl);
            return;
        }

        var shouldSkipEdgeResizing = _webHostEnvironment.IsDevelopment() || _contentLoader.IsContentInEditMode;
        var imageSize = property.GetCustomAttributes<ImageSizeAttribute>().ToList();
        var imageSizes = property.GetCustomAttribute<ImageSizesAttribute>();

        var defaultImageSize = imageSize.FirstOrDefault(x => x.IsDefault);
        if (defaultImageSize == null)
        {
            RenderNonResponsiveImage(output, actualUrl);
            return;
        }

        var srcSetUrls = imageSize
            .OrderBy(x => x.Width)
            .Select(s => GetEdgeUrl(actualUrl, s.Width, shouldSkipEdgeResizing)).ToList();

        SetAttribute(output, "src", GetEdgeUrl(actualUrl, defaultImageSize.Width, shouldSkipEdgeResizing, true));
        SetAttribute(output, "srcset", string.Join(",", srcSetUrls));
        if (imageSizes != null) SetAttribute(output, "sizes", imageSizes.Sizes);
        SetAttribute(output, "alt", imageFile.AlternativeText);
        SetAttribute(output, "loading", "lazy");
        SetAttribute(output, "decoding", "auto");
        SetAttribute(output, "fetchpriority", "auto");
        SetAttribute(output, "class", CssClass);

        if (imageFile is not IHasPixelSize pixelSize) return;

        if (pixelSize.Width > 0)
        {
            SetAttribute(output,"width", pixelSize.Width.ToString());
        }

        if (pixelSize.Height > 0)
        {
            SetAttribute(output, "height", pixelSize.Height.ToString());
        }
    }

    private void RenderNonResponsiveImage(TagHelperOutput output, string url)
    {
        SetAttribute(output, "src", url);
        SetAttribute(output, "class", CssClass);
    }

    private string GetEdgeUrl(string actualUrl, int width, bool isLocal, bool isDefault = false)
    {
        if (!isLocal)
        {
            return isDefault 
                ? $"/cdn-cgi/image/{GetEdgeImageOptions(width)}{actualUrl}" 
                : $"/cdn-cgi/image/{GetEdgeImageOptions(width)}{actualUrl} {width}w";
        }
        else
        {
            return isDefault
                ? $"{actualUrl}?{GetLocalImageOptions(width)}"
                : $"{actualUrl}?{GetLocalImageOptions(width)} {width}w";
        }
    }

    private string GetLocalImageOptions(int width)
    {
        var options = $"width={width}";
        if (!string.IsNullOrWhiteSpace(Fit))
        {
            options += $"&fit={Fit}";
        }

        return options;
    }

    private string GetEdgeImageOptions(int width)
    {
        var options = string.Empty;
        if (!string.IsNullOrWhiteSpace(Fit))
        {
            options = $"fit={Fit},";
        }

        options += $"width={width}";
        return options;
    }

    private void SetAttribute(TagHelperOutput output, string key, string value)
    {
        if (!string.IsNullOrWhiteSpace(value))
        {
            output.Attributes.SetAttribute(key, value);
        }
    }
}

Then finally to utilise the Tag Helper in the Razor View we simple do the following :

        <div class="image" @Html.EditAttributes(x=>x.PromoImage)>
            <img image-for="@Model.PromoImage" css-class="promoBlockImage" fit="cover" FlexibleAttribute="Goes Here"/>
        </div>

Tag helpers for me are easier to comprehend and manage I also have the flexibility to add any additional attributes to my HTML tag without any additional coding.

Conclusion

The benefits of this new approach are numerous. First and foremost, the image transformation takes place at the edge, leveraging Cloudflare's global network of servers. This ensures lightning-fast delivery of optimized images with minimal latency, enhancing overall performance and user experience.

Furthermore, as the solution is provided by Optimizely and integrated into CMS12 and the Optimizely DXP, we can confidently rely on their support and compatibility with the latest versions of .NET. Say goodbye to the worries of compatibility issues and the hassle of ever-changing licensing agreements.

By leveraging "Image resizing at the edge for CMS and Commerce," we have the potential to simplify our image optimization workflow. There's no longer a need for server-side processing or the installation of additional tools. The optimization process seamlessly occurs within the Cloudflare edge platform, making our solution more scalable and efficient.

In conclusion, Optimizely's solution will empower us to overcome the challenges we faced with previous tools and server-side optimization. With image processing now taking place at the edge, we can deliver optimized images effortlessly, enhancing user experience and performance without adding complexity to our server infrastructure.

How to Write an xUnit Test to Verify Unique Content Type Guids in Content Management

Mon, 27 Mar 2023 12:55:15 GMT

When developing an Optimizely CMS solution, it is important to ensure that each content type has a unique GUID. If two or more content types share the same GUID, the CMS can have unexpected behavior and issues. In this blog post, we will explore how to write an xUnit test to verify that all Content Type Guids are unique in an Content Management solution.

The Problem

When developing an Optimizely CMS solution, it is common to define content types using C# classes that implement the IContentData interface. Each content type is typically decorated with the ContentType attribute, which defines properties such as the name and GUID of the content type.

When multiple content types share the same GUID, it can cause unexpected behavior and issues in the CMS. For example, if two content types have the same GUID, it can cause an exception to be thrown when attempting to create a new instance of one of the content types.

The Solution

To verify that all Content Type Guids are unique in an Optimizely Content Management solution, we can write an xUnit test that iterates through all the content types in the solution and checks that each content type has a unique GUID. Here is the code for the test:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Reflection;
using EPiServer.Core;
using EPiServer.DataAbstraction;
using Xunit;

namespace YourProject.Tests
{
    public class ContentTypesGuidTest
    {
        [Fact]
        public void VerifyContentTypesGuidsAreUnique()
        {
             // Get the assembly that contains the Project.Cms.Domain project
             var domainAssembly = Assembly.Load("Project.Cms.Domain");

            // Get all content types in the solution, this covers Pages, Blocks and Assets
            var contentTypes = typeof(PageData).Assembly.GetTypes()
                .Where(x => typeof(IContentData).IsAssignableFrom(x) && !x.IsAbstract);

            // Create a dictionary to hold the Guids and their counts
            var guidDictionary = new Dictionary<Guid, int>();

            // Iterate through all the content types
            foreach (var contentType in contentTypes)
            {
                // Get the SiteContentType attribute of the content type
                var siteContentTypeAttribute = contentType.GetCustomAttribute<SiteContentTypeAttribute>();

                // Get the value of the Guid property in the SiteContentType attribute
                var guid = siteContentTypeAttribute.GUID;

                // Check if the Guid already exists in the dictionary
                if (guidDictionary.ContainsKey(guid))
                {
                    // Increment the count for the Guid if it already exists
                    guidDictionary[guid]++;
                }
                else
                {
                    // Add the Guid to the dictionary if it doesn't exist
                    guidDictionary.Add(guid, 1);
                }
            }

            // Iterate through the dictionary to check if there are any Guids with a count greater than 1
            foreach (var guid in guidDictionary)
            {
                Assert.Equal(1, guid.Value); // Ensure the count for each Guid is equal to 1
            }
        }
    }
}

This test code uses reflection to get all the content types in the solution that implement the IContentData interface and are not abstract. It then iterates through all the content types and checks that each content type has a unique GUID. The test fails if any content type has a GUID that is not unique.

By writing an xUnit test to verify that all Content Type Guids are unique in an Optimizely solution, we can ensure that the CMS has expected behavior and avoid potential issues caused by duplicate GUIDs.

URL Rewrites in CMS12 (.Net 6)

Tue, 28 Feb 2023 23:22:56 GMT

URL rewriting is a common technique used in web applications to create user-friendly URLs that are easier to understand, provide consistency and have SEO benefits. In the past, URL rewriting was commonly accomplished using IIS URL Rewrite module. However, with the release of .NET Core, the process of rewriting URLs has undergone some changes.

Microsoft has introduced a new URL rewriting middleware called Microsoft.AspNetCore.Rewrite. This middleware is part of the ASP.NET Core framework and is designed to rewrite URLs in a much more flexible and efficient way.

One of the key benefits of using the Microsoft.AspNetCore.Rewrite middleware is that it allows URL rewriting without requiring IIS or any other web server. This means that we can create Optimizely Solutions that are completely self-contained and can be run on any platform.

Here is an example of how to use the Microsoft.AspNetCore.Rewrite middleware in .NET 6 to handle some common conventions like redirecting to https, enforcing lowercase urls and adding trailing slash to the end of all URLs:

Lower Case URL – Implement IRule Base Rule

    public class LowercaseUrlsRule : IRule
    {
        public int StatusCode { get; } = (int)HttpStatusCode.MovedPermanently;

        public void ApplyRule(RewriteContext context)
        {
            HttpRequest request = context.HttpContext.Request;
            PathString path = context.HttpContext.Request.Path;
            HostString host = context.HttpContext.Request.Host;

            if (path.HasValue && path.Value.Any(char.IsUpper) || host.HasValue && host.Value.Any(char.IsUpper))
            {
                HttpResponse response = context.HttpContext.Response;
                response.StatusCode = StatusCode;
                response.Headers[HeaderNames.Location] = (request.Scheme + "://" + host.Value + request.PathBase.Value + request.Path.Value).ToLower() + request.QueryString;
                context.Result = RuleResult.EndResponse;
            }
            else
            {
                context.Result = RuleResult.ContinueRules;
            }
        }
    }

Use Rules in Middleware Startup.cs

In the example below we are using the RewriteOptions class to define paths that should be negated, and adding the rules for forcing HTTPS, Lowercase and Trailing Slashes. I have explicitly added below app.UseStaticFiles() so the rules do not get added to files like css, javascript or images.

        app.UseStaticFiles();

        var options = new RewriteOptions()
            .Add(context =>
                {
                    if (context.HttpContext.Request.Path.StartsWithSegments("/util") || 
                        context.HttpContext.Request.Path.StartsWithSegments("/episerver") || 
                        context.HttpContext.Request.Path.StartsWithSegments("/modules"))
                    {
                        context.Result = RuleResult.SkipRemainingRules;
                    }
                })
            // Redirect to HTTPS
            .AddRedirectToHttpsPermanent()
            // Enforce lower case. 
            .Add(new LowercaseUrlsRule())
            // Enforce trailing slash.
            .AddRedirect("(.*[^/])$", "$1/");



        app.UseRewriter(options);

These techniques are not Optimizely specific and can be applied to any .Net Solution, more info on IRule based rewrites can be found here