Blogs

Virtual Opticon 2026: Where AI Can Improve DXP Delivery

2026-10-21T21:59:52.0000000Z

Consider a campaign whose first draft takes ten minutes to generate but then waits five days for review. Faster drafting has helped one task. The campaign still reaches the customer five days later.

As an attendee at Opticon Online on October 21, I was particularly interested in how AI could address that delivery problem. Across the customer stories and product keynote, the strongest case for AI was its ability to take responsibility for recurring work across a digital experience program. The value depends on which work we assign it, what context it receives, and how we measure the result.

Optimizely framed the discussion around three experiences: the marketer doing the work, the customer using the experience, and the AI agent increasingly researching or acting on a customer's behalf. Its October Agent Platform updates make that direction more tangible. Here is how I would translate it into DXP decisions.

Measure the time it takes to reach a decision

Robert Chatwani's DocuSign presentation focused on cycle time: the path from a hypothesis to a live experiment, a decision, and the next test. His recommendations were specific: bring the relevant functions together, assign a directly responsible individual with decision authority, and remove the handoffs where work stalls.

For a DXP team, this changes where an AI pilot should start. Map one recurring process before choosing an agent. Record the time spent producing work, waiting for review, resolving missing information, and implementing the decision. If most of the delay sits in an approval queue, another copy generator addresses the wrong part of that process.

A useful pilot might assemble the source material, perform an initial brand check, and route a complete review package to a named approver. Measure elapsed time through approval and publication, alongside the amount of rework. That tells you whether the process improved.

Experimentation needs a further distinction. AI can shorten preparation and analysis work. A valid decision still needs appropriate measurement, traffic, and observation time. Faster launches do not automatically produce reliable learning sooner.

Personalization also needs an explicit decision framework: which observed signal changes the experience, what content is eligible, and what visitors receive when the signal is absent. More content variants are useful when they support a relevant customer choice and an outcome the team can evaluate.

Make approved context part of the delivery process

KPMG's sequence was one of the most useful examples in the event. Lauren Boyman described consolidating intake, incorporating editorial and brand review into workflows, and establishing a shared digital asset library with metadata and usage information. Specialized agents followed that foundation.

That sequence belongs in a DXP roadmap. Before asking AI to reuse an asset or adapt a claim, establish which version is approved, where it can be used, and who maintains it. Otherwise, automation can distribute outdated information more efficiently.

Brand Packs address part of this requirement. Optimizely documents them as structured brand assets and rules that become a skill when published. A default pack supplies brand context unless another is selected. Variants extend the production workflow by creating channel-specific image versions.

The distinction between brand guidance and approval deserves care. Publishing a Brand Pack gives agents approved instructions; it does not establish that every future output is factually accurate, legally acceptable, or suitable for every market. Teams still need to define which outputs require review.

I would give the pack a business owner and a review process. Test it against representative outputs, including difficult cases such as an expired offer or a claim that requires qualification. For image variants, inspect cropping, legibility, and required disclosures. The useful measure is how much work passes review without correction.

The Skills Directory can help distribute reusable guidance across the organization. Administrators can add organization skills, while users can add personal skills. That creates a practical reason to make approved organizational guidance easy to find and maintain, especially when personal instructions also exist.

Give Virtual Teammates a bounded job and an accountable owner

October's Web Manager and Content Marketer additions move the discussion toward recurring responsibilities. The Web Manager documentation describes compliance audits, site-health work, and website updates. Its jobs run through scheduled or triggered workflows; enabled jobs and connected tools determine what is available. The documentation also says it asks for approval before acting on your behalf.

The Content Marketer monitors trends and competitors and can use connected Salesforce data to identify pipeline-related content gaps. The opportunity is to give editorial teams evidence for prioritization. A competitor publishing on a topic is a signal to investigate, not sufficient reason to publish the same thing.

For either role, I would define a short operating brief: the pages or topics in scope, the approved sources, the actions it can propose or execute, the person who resolves exceptions, and the conditions that stop a run.

Then follow the work through to completion. An audit that generates fifty findings has created a queue. Track how many findings were accepted, corrected, verified, and prevented from recurring. For content recommendations, track whether briefs address an agreed audience need and progress through review. Activity counts alone will overstate the value.

The platform's workflow-priority controls also deserve attention as usage grows. They distinguish interactive work from background runs when execution capacity is constrained. A team needs to decide which processes can wait before scheduling large volumes of automated work.

Evaluate orchestration before expanding a migration

The keynote positioned Agent Platform as an orchestration layer across Optimizely applications and external systems, including competing content platforms. The October update adds connections spanning advertising, analytics, collaboration, and content tools.

For organizations with an established technology stack, this creates an option worth evaluating: improve a workflow across the systems already in use before adding a broader platform replacement to the plan.

Connector availability is only the start of that assessment. Validate the actual operations the workflow needs, the permissions required, and how failures are handled. A connector that retrieves campaign data does not, by itself, prove that the complete review and publishing process can run through it.

A contained workflow gives the team a way to test that boundary. For example, investigate whether an agent can gather performance data, prepare a recommendation, and create a review task while publication remains in the established CMS workflow. The result should inform the architecture decision.

Prepare for agents completing customer tasks

The agent-experience discussion extends beyond visibility in AI-generated answers. A prospective customer may ask an assistant to find a suitable product, locate its documentation, or arrange a meeting. The website then needs to support the task as well as explain the offering.

Optimizely's WebMCP material describes a proposed standard for exposing structured website capabilities to agents. Its Agent Ready Experiences implementation is currently described as a closed beta. This warrants a controlled pilot and a check of current availability before committing a production roadmap.

I would start with one journey, such as finding a product and retrieving its current technical document. Check whether the product identifiers, versions, eligibility rules, and document relationships are explicit and consistent. If the journey progresses to an action, define the authorization and confirmation requirements.

Measure successful task completion, incorrect selections, and points where a person must take over. Being cited in an AI answer and helping a customer finish a task are separate outcomes. Both need their own evidence.

Build the business case around accepted work

The evolution from Opal toward Mark, including domain-specific models and a marketing context layer, brings AI economics into the DXP discussion. The keynote described some model capabilities as forthcoming, particularly models trained for customers' own agents. Those plans should remain separate from capabilities verified in a customer's environment.

Optimizely reported a 67% benchmark all-pass rate against 60% for Claude Code at half the cost in the cited default configurations. That is a seven-percentage-point gap on that evaluation. The separate claim of up to tenfold model cost efficiency came from early testing. Neither establishes the savings a particular customer will achieve, and multiplying them into a twentyfold business-case assumption is not justified without a combined test.

For a pilot, calculate cost per accepted output or completed workflow. Include platform consumption, setup and maintenance, review time, corrections, and failed runs. Compare that with the baseline for the same work. Cheap generation can still produce an expensive process if reviewers must reconstruct the answer.

The next thirty days can be straightforward: select one recurring workflow with a visible delay, assign an owner, establish the baseline, and run a bounded pilot using approved context. Expand when it reduces elapsed time or effort while meeting the agreed quality standard.

Seth Godin's closing session brought the discussion back to the audience: who the work serves, what change it should create, and whether people want to hear from the brand. That is a useful test for the time AI gives back. Use it to understand customers better, improve an experience, or test a substantive idea. A higher publishing count is a weak return if the work gives customers no additional reason to care.

About the Author

I am Augusto Davalos, a Senior Project Manager at Oshyn, a digital transformation consultancy helping brands get more value from composable DXP platforms such as Optimizely. My work sits at the intersection of digital strategy, agile delivery, content operations, and business outcomes. I share practical perspectives on Optimizely, DXP, MarTech, and digital leadership.

The Low-Level API Is Not Automatically Fast. Part 4: Counting Round Trips

2026-10-21T08:00:00.0000000Z

The low-level Commerce DTO API is not automatically fast: counting the database round trips per imported row, and four fixes I would apply first.

The Migration Bugs That Actually Caught Us Out

2026-10-20T17:28:21.0000000Z

The less obvious issues we hit migrating Optimizely CMS 11 to CMS 12 and .NET 8, including routing changes, JSON model binding, package dependency issues, Optimizely Forms email failures, and CMS authorization.

Camp Opticon 26 (London): AI requires a different operating model

2026-10-20T08:41:02.0000000Z

Introduction

Last week I attended Camp Opticon 26 in London and although it was far from my first time at Opticon, it was in fact my first time that I spent Day 1 not at the Partner Forum, but at the OMVP Summit. Needless to say, this brought back all of the excitement that I felt when I first attended Opticon back in 2022! This blog post isn't about the OMVP Summit but I did want to include that it was awesome spending the day with so many other Optimizely Most Valuable Professionals that I usually only connect with online and occasionally see on stage at Optimizely events. It was also a great preparation for Day 2, when I was joined by several colleagues from iO and a handful of our Optimizely customers.

Upon returning to The Netherlands, I was asked to write an article with some insights and my key takeaways from Camp Opticon 26. This was subsequently published on the Dutch blog Marketing Report.

Disclaimer: it's not a tech article and as per the provided author guidelines it doesn't contain product and feature names. Those who were at Camp Opticon will be able to map the takeaways to the specific topics that were discussed there, but for those that weren't (and that should definitely sign up for Opticon Online tomorrow!), a short list that maps the most important parts of this write-up to applicable Optimizely products / themes:

AI becomes a digital colleague → Virtual Teammates
Governance becomes the real bottleneck → Agent Platform (knowledge integration, quality evaluation, human-in-the-loop) and Agentic Content Ops
- Also see: Execution Guardrails, Output Evaluation and Execution Advisor
Personalisation becomes continuous → Limitless Personalization and Dynamic Experiences
Second audience: AI agents → Agentic CMS ("Stay visible automatically" -- SEO/GEO/AI), Agentic Commerce ("Commerce without clicks"), Agent Visibility and WebMCP

Seeing as the article is written in Dutch, I took the liberty of having Agent Platform / Mark translate it for me so that I could paste it below!

Note: this content was originally published on https://marketingreport.nl/william-parr-ai-vraagt-om-een-ander-operating-model by Saskia van Weert, and has been translated to English and enriched with several images below.

Camp Opticon 26 (London): AI requires a different operating model

Last year, AI was still often discussed as an experiment or a standalone productivity tool. Now the conversation is more about workflows, governance and measurable impact.

That was the main conclusion from Opticon London, Optimizely's leading conference for digital experience professionals. As an Optimizely Most Valuable Professional at iO, I had the chance to attend a conference where the conversations are clearly heading in a different direction.

Here are five key insights:

1. AI becomes a digital colleague, not just a tool

The most important shift isn't that AI writes better copy or generates images faster. The bigger change is that AI is increasingly given a role within teams, with tasks, permissions, context, memory and human checkpoints. This changes how marketing and digital teams organise their work. We are moving from "AI as assistant" to "AI as colleague", and that demands a fundamentally different approach to workflows, roles and governance.

2. Content production scales, but governance becomes the real bottleneck

AI makes it easier than ever to create, translate, rewrite and personalise content at scale. But without a solid content structure, clear brand rules, defined approval flows and clear ownership, you mainly create more complexity and risk. The organisations that win are not those that produce the most content with AI. They are the ones that have built the governance infrastructure to manage that content. Investing in AI content governance is no longer optional. It is the foundation.

3. Personalisation becomes continuous, not campaign-driven

Most organisations still personalise or experiment on a limited scale today, simply because teams don't have enough time or capacity to build and test variants for every audience, every market or every page. AI fundamentally changes that. It enables continuous learning, testing and optimisation, but only if the right frameworks are in place. The shift from campaign-driven to continuous personalisation is one of the most impactful changes AI makes possible, and at the same time one of the least discussed.

4. Your website now has a second audience: AI agents

Findability is no longer just about SEO and human visitors. AI systems increasingly read, interpret and cite web content, and in doing so they are becoming an intermediary layer between brand and customer. That means companies need to think about AI visibility: does an AI system understand your brand, your offering and your expertise? Are you part of the answers it gives? This is a new discipline that most organisations still aren't taking seriously enough.

5. The winners don't have the most AI tools, but the best operating model

The biggest challenge is no longer "what can AI do?", but "how do we make AI safe, scalable and genuinely useful within our organisation?" The answer lies in the fundamentals: data quality, content models, workflows, roles, permissions and governance. Without that foundation, AI remains a collection of isolated pilots that consume budget without delivering results.

From separate tools to integrated operations

Across all five themes, I see the same underlying movement: the market is shifting from separate CMS, DXP and AI tools to integrated digital experience operations. Content, personalisation, experiments, analytics and AI are becoming more and more connected, and the platforms are evolving in that direction.

My key takeaway from Opticon is that the AI conversation is maturing. This aligns with what we increasingly see with clients: the challenge isn't only the choice of platform, but how content, data, technology, AI and teams come together in one workable operating model. Organisations that want to create value quickly need to look beyond the technology and focus on content structure, governance and the workflows that connect everything. Those who invest in structure, governance and collaboration now will get more out of AI later than organisations that simply add new tools.

And with that, we're already having conversations with several customers based on the above and are looking forward to helping them prepare for this agentic era we're collectively venturing into. This year's Camp Opticon was another stellar edition and I am looking forward to seeing what Optimizely has in store for us in 2027!

Migrating ContentArea.FilteredItems in Optimizely CMS 13

2026-10-19T15:31:24.0000000Z

If you have

Categories have landed in Optimizely SaaS CMS: structure, translate, tag and query

2026-10-19T14:37:13.0000000Z

Categories arrived in Optimizely SaaS CMS at the end of August, with Graph support alongside. I have wanted a proper taxonomy in SaaS since the first build I did on it. Until now we have been faking it with select lists, string arrays or a folder of "tag" blocks. None of those are great. They are hard for editors to maintain, they do not translate cleanly and they make filtering in Graph clumsy.

So I spent an afternoon putting the new feature through its paces on our sandbox instance. This post walks through the whole flow with screenshots: building a category structure, translating it, tagging pages and then querying it all in Optimizely Graph. There are a couple of gotchas in the Graph section that are worth knowing before you start building filters.

Where to find it

Categories live under Settings > Taxonomy > Categories. On a fresh instance you get an empty grid with a locale switcher, a search box and a Create button. Ours already had a single test category in it.

The grid shows Display name, Key, Description, Visible, Selectable, Usage and the usual audit columns. It is wide, so on a laptop you will be scrolling sideways to reach the actions menu at the end of each row.

Creating a structure

I went with a typical B2B example: an Industry parent, three sectors under it, and a third level under Financial Services. I prefixed everything with "Demo" so it is easy to clean up later.

Click Create and you get a row-based dialog.

Each category has these fields:

Field	Notes
Display name	What editors see. Up to 255 characters. Translatable.
Key	The identifier you use in code and Graph. Up to 100 characters, unique, not translatable. It auto-fills from the display name with spaces swapped for underscores.
Description	Optional, up to 500 characters. Translatable.
Parent	Read only. It is set by where you start the create action.
Visible	Whether the category shows in the editor's picker.
Selectable	Whether editors can assign it to content.
Usage	Public or Internal.

The key is the field to get right first time. It is what your front end will depend on, so agree a naming convention with the team before anyone starts typing. The auto-generated value is fine for most cases, but I would not leave it to chance on a real project.

To add children, open the ... menu at the end of a row and choose Create child.

The nice touch here is the + button at the end of each row. You can add several categories in one go rather than opening the dialog for each one. The Parent column is pre-filled and locked.

I repeated that on Financial Services to add Banking and Insurance as a third level.

The result is an expandable tree.

A few things from the documentation that are worth calling out, because they will bite you if you do not plan for them:

You cannot move a category to a different parent after it is created. You have to delete it and recreate it. Get the hierarchy agreed before you load it.
Optimizely recommend keeping trees to three or four levels. I agree. Deeper than that and editors stop being able to find anything.
Visible and Selectable do not cascade. Hiding a parent does not hide its children. This is useful, though. Clearing both flags deprecates a category without deleting it. Leaving Visible on and clearing Selectable gives you a "historic" category that still shows on old content but cannot be applied to anything new.
Usage is metadata only. Marking a category as Internal does not stop it being indexed or returned by Graph. It is a hint for your front end to filter on, not a security control. You also cannot create a Public child under an Internal parent.

My advice: deprecate rather than delete. Deleting a category removes it from every piece of content it was tagged on.

Translating categories

The Locale dropdown at the top of the grid lists the languages enabled for CMS content. Our instance has English as the master, plus Chinese, Spanish and Swedish.

Switch to another language and anything without a translation falls back to the master value. It is shown in italics with a small EN badge so you can see at a glance what still needs doing. This fallback behaviour came in with a fix on 7 October. Before that, untranslated rows just showed blank.

Open ... > Edit on a row and you get an "Edit español translation" dialog. The master values appear as placeholder text. That placeholder is never saved as a translation, so you will not end up with English silently copied into your Spanish data. The key is greyed out because it is shared across all languages.

Once translated, the tree shows the Spanish names. I translated the whole Demo Industry branch. Note that the grid re-sorts by the translated display name, so rows move about as you work through them.

Translation is one row at a time for now. Fine for a demo. For a real taxonomy of a few hundred terms across several languages, I would want a bulk option, or I would script it. The 22 September release also lets you ask Mark, the Agent Platform assistant, to create and update categories for you if you have CMS admin rights. I have not tried that for translations yet.

Tagging pages with categories

This is the part that surprised me. There is no Category property to add to your content types. I went looking under Add Property on our Blog post type and there is nothing taxonomy related in the list. Categories are built in.

Open any page in the editor and a Category field is already there. Start typing and it searches across the whole tree, showing the full path for each match. That path matters when you have two terms with similar names in different branches.

Tick as many as you need. Each one becomes a removable chip.

Only categories that are both Visible and Selectable show up here, which is exactly what you want for the deprecated and historic cases above.

Two behaviours from the docs to be aware of. Categories are assigned in the master language, and the localised names appear on translated versions automatically. Categories are also versioned with the content, so a change on a draft only goes live when that draft is published.

Our Blog post type still has an old "Topic" select list from before this feature existed. If you have something similar, I would plan to migrate it. One managed taxonomy beats a dozen hard-coded option lists scattered across content types.

Querying categories in Optimizely Graph

I published the demo page and moved over to Settings > GraphiQL. The documentation for this part is thin right now, so everything below comes from introspecting the schema and testing queries.

Querying the category tree

Categories are indexed as their own items under a new root query: _TaxonomyTerm.

query CategoryTree {
  _TaxonomyTerm(
    locale: en
    where: { _metadata: { taxonomy: { eq: "categories" } } }
    orderBy: { _metadata: { displayName: ASC } }
  ) {
    total
    items {
      _metadata {
        key
        displayName
        parent
        usage
      }
    }
  }
}

The useful fields on _metadata are key, displayName, description, parent, usage, locale, status and taxonomy. parent holds the parent's key, or null for a root category. That gives you everything you need to rebuild the tree on the front end.

taxonomy returns "categories" for everything today. My guess is that it is there so Optimizely can add more than one taxonomy later. Filtering on it now costs nothing and saves a refactor if that happens.

To get the direct children of a term, filter on parent:

query ChildrenOfIndustry {
  _TaxonomyTerm(
    locale: en
    where: { _metadata: { parent: { eq: "Demo_Industry" } } }
  ) {
    items {
      _metadata {
        key
        displayName
      }
    }
  }
}

Localised category names

Pass a locale and you get the translated values back:

query LocalisedCategory {
  _TaxonomyTerm(
    locale: sv
    where: { _metadata: { key: { eq: "Demo_Industry" } } }
  ) {
    items {
      _metadata {
        key
        displayName
        description
        locale
      }
    }
  }
}

Two gotchas here.

First, the master language fallback you see in the CMS does not apply in Graph. I translated the display name into Swedish but left the description empty. The CMS shows the English description in italics. Graph returns null. If you need a fallback, you have to build it yourself, either with a second query on the master locale or in your front-end mapping.

Second, my Spanish translations never appeared in Graph. Querying with locale: es fails validation because es is not in the schema's Locales enum.

On our instance the only languages in the enum are en, sv and zh. Those are the languages we already have content in. Spanish is enabled in the CMS, but nothing else on the site is published in Spanish. Swedish translations, on the other hand, showed up within ten seconds of saving.

My working theory is that a language has to exist in Graph's index before category translations in that language are picked up. I have not confirmed that with Optimizely, so treat it as an observation rather than documented behaviour. If your translated categories are not coming through, check the Locales enum in GraphiQL first.

Querying content by category

This is the bit you will use most, and it is not where I expected it to be. Categories are not on the usual _metadata field. They are on a separate field called _itemMetadata, which exists on every content type in the schema.

The values are URIs rather than plain keys, in the format cms://taxonomy/categories/<Key>:

"_itemMetadata": {
  "categories": [
    "cms://taxonomy/categories/Retail",
    "cms://taxonomy/categories/Banking"
  ]
}

So to find every blog post tagged with Banking or Insurance, and get facet counts back at the same time:

query PagesByCategory {
  BlogPostPage(
    where: {
      _itemMetadata: {
        categories: {
          in: [
            "cms://taxonomy/categories/Banking"
            "cms://taxonomy/categories/Insurance"
          ]
        }
      }
    }
  ) {
    total
    items {
      Heading
      _metadata {
        url {
          default
        }
      }
      _itemMetadata {
        categories
      }
    }
    facets {
      _itemMetadata {
        categories {
          name
          count
        }
      }
    }
  }
}

eq, in, startsWith and exist all worked as you would expect on a string array. Swap BlogPostPage for _Content and the same filter works across every content type, which is handy for a site-wide "everything tagged Banking" listing.

The facets come back keyed by URI, so your front end needs to strip the prefix and join to the _TaxonomyTerm results to get display names. Something like this does the job:

const keyFromUri = (uri: string) => uri.split("/").pop() ?? uri;

No roll-up through the hierarchy

This is the gotcha most likely to catch people out. Filtering on a parent does not return content tagged with its children. The demo page is tagged Banking, which sits under Financial Services. Filtering on cms://taxonomy/categories/Financial_Services returns zero results.

The hierarchy exists in the taxonomy, but content only knows about the exact terms it was tagged with. If you want "show me everything in Financial Services", you need to:

Query _TaxonomyTerm to collect the keys of the parent and all its descendants.
Turn them into URIs.
Pass the list to an in filter on _itemMetadata.categories.

Two round trips, but both are cheap and the taxonomy query caches well. Build it once as a helper and reuse it everywhere.

Final thoughts

This is a good first release. The admin UI is quick to work with, the multi-row create saves real time, and having categories built into every content item removes a pile of modelling work we used to do by hand. The Graph side gives you everything you need. It just needs a bit of plumbing.

What I would like to see next:

Graph docs that cover _TaxonomyTerm and _itemMetadata, including the URI format.
An option to roll content up through the hierarchy in Graph.
Master language fallback in Graph to match the CMS.
Bulk import and export of categories and translations.
The ability to change a category's parent without deleting it.

If you are starting a new SaaS build, I would use categories from day one rather than rolling your own taxonomy. If you have an existing build with select-list or block-based tagging, it is worth planning the migration now, before the content volume makes it painful.

Exploring Cached Templates and Cursor Pagination in the Optimizely Graph C# SDK

2026-10-19T04:22:59.0000000Z

While experimenting with the Optimizely Graph C# SDK (13.3.0) in my local Optimizely CMS 13 Alloy project, I came across two interesting findings: how cached templates are handled by the SDK, and how cursor-based pagination differs between typed and untyped queries.

I used ILSpy to inspect the SDK implementation and Fiddler to verify the outgoing HTTP requests.

Here are my findings.

1. Cached Templates: What Does Enabled by Default Mean?

The Optimizely Graph cached templates documentation includes the following note:

Cached templates are enabled by default for queries created on or after January 1, 2025.

This caught my attention while testing queries through the C# SDK.

For example, consider this query:

var query = _graphClient
    .QueryContent<ISearchableContent>()
    .Limit(5)
    .IncludeTotal()
    .Fields<SearchResult>(x => x.SearchTitle);

var result = await query.GetAsync();

After inspecting the outgoing request using Fiddler, I noticed that the SDK sends a request to:

POST https://cg.optimizely.com/content/v2

However, the request didn't include either of the parameters documented for explicitly enabling cached templates:

?stored=true
cg-stored-query: template

Looking Inside the SDK

Using ILSpy, I inspected the request construction inside Optimizely.Graph.Core.Client.GraphClient.

The relevant code looked like this:

var fullQuery = new { query, variables };

var request = new HttpRequestMessage(
    HttpMethod.Post,
    allowCachedResults
        ? "content/v2"
        : "content/v2?cache=false")
{
    Content = JsonContent.Create(fullQuery)
};

AddCustomHeaders(request, customHeaders);

In the execution path I inspected, the SDK didn't explicitly append stored=true or add the cg-stored-query header.

Does this mean cached templates aren't enabled?

Not necessarily.

The documentation describes default behavior, which may be handled by the Graph service itself without requiring these parameters from the client.

My observation confirms only that the SDK doesn't explicitly send them in this scenario.

Since the SDK communicates with the hosted Graph service, I wouldn't assume that running CMS 13 locally explains the difference.

This remains an interesting point to clarify.

2. Explicitly Enabling Cached Templates with a DelegatingHandler

To experiment with explicit cached-template requests without modifying the SDK package, I used a custom DelegatingHandler.

The idea was straightforward: intercept outgoing Graph requests and add the required query parameter and header.

Custom HTTP Handler

public sealed class GraphCachedTemplateHandler : DelegatingHandler
{
    protected override Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request,
        CancellationToken cancellationToken)
    {
        if (request.Method == HttpMethod.Post &&
            request.RequestUri?.AbsolutePath.TrimEnd('/') == "/content/v2")
        {
            var uri = new UriBuilder(request.RequestUri);

            var query = uri.Query.TrimStart('?');

            uri.Query = string.IsNullOrEmpty(query)
                ? "stored=true"
                : $"{query}&stored=true";

            request.RequestUri = uri.Uri;

            request.Headers.TryAddWithoutValidation(
                "cg-stored-query", "template");
        }

        return base.SendAsync(request, cancellationToken);
    }
}

Registering the Handler

After registering the Graph SDK, I attached the handler to its named HTTP client:

services.AddContentGraph();

services.AddTransient<GraphCachedTemplateHandler>();

services
    .AddHttpClient("Optimizely.Graph.Core.Client.Authenticated")
    .AddHttpMessageHandler<GraphCachedTemplateHandler>();

Verifying with Fiddler

After executing the same Graph query, I confirmed the outgoing request:

POST https://cg.optimizely.com/content/v2?stored=true
cg-stored-query: template

This demonstrated that I could explicitly request cached-template behavior without changing the SDK source code.

Important: This handler applies to matching requests made through the configured HTTP client. It is not a per-query opt-in.

What About a Fluent WithCachedTemplate() Extension?

I also explored adding a custom extension method to support syntax such as:

var query = _graphClient
    .QueryContent<ISearchableContent>()
    .Limit(5)
    .WithCachedTemplate()
    .Fields<SearchResult>(x => x.SearchTitle);

However, there's an important limitation.

The SDK's existing fluent methods, such as WithoutCache(), update internal query state that is later used during execution.

Although a custom WithCachedTemplate() extension can store metadata against a query, the SDK's existing GetAsync() doesn't automatically read that metadata or propagate it to the HTTP layer.

As a result, the extension method can compile and fit naturally into the fluent API, but it doesn't change the outgoing HTTP request.

The custom DelegatingHandler demonstrated earlier works at the HTTP-client level, but it cannot determine which individual query opted into cached templates without additional integration.

A proper per-query implementation would therefore require an execution wrapper or, ideally, native SDK support to propagate the setting through the execution pipeline.

3. Cursor-Based Pagination: Typed vs. Untyped Queries

The second finding came while experimenting with cursor-based pagination.

Initially, I tried to use SetCursor() with the strongly typed query API:

var query = _graphClient
    .QueryContent<ISearchableContent>()
    .SetCursor(null);

However, this doesn't compile because SetCursor() isn't exposed through the typed ISearchableContentQuery<T> interface in the SDK version I tested.

After inspecting the implementation, I found that SetCursor() is available through the untyped query API:

_graphClient.Query("ISearchableContent")

First Page

var query = _graphClient
    .Query("ISearchableContent")
    .SetCursor(null)
    .Limit(5)
    .IncludeTotal()
    .Fields("SearchTitle");

var result = await query.GetAsync();

Passing null enables the cursor field without specifying a previous cursor.

For subsequent pages, the cursor returned by the previous response can be passed to SetCursor():

var query = _graphClient
    .Query("ISearchableContent")
    .SetCursor(nextCursor)
    .Limit(5)
    .Fields("SearchTitle");

var result = await query.GetAsync();

Here, nextCursor represents the cursor obtained from the previous response.

Both requests use the same page size and content selection. The cursor value is null for the initial request and the cursor returned by the previous response for subsequent requests.

Looking Inside SetCursor()

The implementation is straightforward:

public IQuery SetCursor(string? cursor)
{
    _queryExpression.IncludeCursor = true;
    _queryExpression.Cursor = cursor;

    return this;
}

It performs two operations:

Enables inclusion of the cursor in the GraphQL response.
Assigns the supplied cursor for pagination.

This explains why SetCursor(null) is useful for the initial request.

An SDK API Difference

The distinction is worth highlighting:

Query API	Cursor support
QueryContent<T>()	SetCursor() not exposed
Query("TypeName")	SetCursor() available

This is a difference in the SDK's public fluent interfaces, rather than evidence that the Graph service doesn't support cursor pagination for typed content.

4. Final Thoughts

These experiments helped me better understand how the Optimizely Graph C# SDK builds and executes queries.

A few takeaways:

The SDK doesn't explicitly send cached-template parameters in the execution path I inspected, even though the documentation describes cached templates as enabled by default for newer queries.
A custom DelegatingHandler can add the documented parameters to outgoing Graph requests.
A fluent per-query WithCachedTemplate() extension requires more than storing a flag; the setting must reach the HTTP execution layer.
Cursor pagination is exposed through the untyped Query("TypeName") API, while the typed QueryContent<T>() interface doesn't expose SetCursor() in version 13.3.0.

These are relatively small observations, but they illustrate why exploring the SDK implementation and inspecting actual HTTP traffic can be useful when working with Graph.

I'd be interested to hear from the Optimizely Graph team how the documented default behavior for cached templates applies to queries executed through the C# SDK, particularly when the outgoing requests don't explicitly include the cached-template parameters.

References

EPiServer.ImageLibrary.ImageSharp 2.0.7 delisted from NuGet feed

2026-10-19T01:15:34.0000000Z

We have delisted version 2.0.7 of the EPiServer.ImageLibrary.ImageSharp package from the NuGet feed due to a packaging issue.

This version was intended to depend on SixLabors.ImageSharp 3.2.0, but due to a build error, it still depends on SixLabors.ImageSharp 3.1.12, which has a known CVE.

If you're already using EPiServer.ImageLibrary.ImageSharp 2.0.7, please wait for version 2.0.8, which will correctly depend on the patched SixLabors.ImageSharp 3.2.0 and will be released shortly.

We apologize for the inconvenience and appreciate your understanding!

Update Oct-21: the package EPiServer.ImageLibrary.ImageSharp 2.0.8 is now available on our public feed https://nuget.optimizely.com/packages/episerver.imagelibrary.imagesharp/2.0.8

Surviving a Dirty Feed. Part 3: Error Handling and Event Batching

2026-10-16T08:00:00.0000000Z

Committing a 250,000-row Optimizely catalog import row by row, returning a per-row failure report, and coalescing catalog events into one per batch.

Building UI Extensions for Optimizely SaaS CMS

2026-10-15T16:59:39.0000000Z

Introduction

Developers have been extending the functionality of Optimizely PaaS CMS for years using addons built in C# and deployed as NuGet packages. Where you have control of the code for the CMS, this is the optimum approach for seamless integration. As Optimizely SaaS CMS becomes a more common approach for composable architecture, the way we extend the CMS has had to change. To fill this gap, Optimizely have created a new feature for Optimizely Connect Platform (OCP) and SaaS CMS called CMS UI Extensions which is in beta at the time of writing.

A CMS UI Extension is an application built in Node.js and JavaScript that is deployed into the OCP. From there, your app can be installed into any SaaS CMS that is within your organisation. There are currently three ways that your CMS UI Extension can manifest within your SaaS CMS:

Sidebar: Appears within the CMS editor interface within a panel mounted to the right-hand side of the screen.
View: Mounts a standalone full-width page that is accessed via the Extensions option in the left-hand menu.
Property Editor: Replaces the built-in editor for a single content property of a declared type.

Setting Up Your Environment

To build apps for OCP, you need to be an Optimizely Partner or Customer with Developer access to an OCP environment. You may need to raise a ticket with Optimizely Support to activate the developer functionality for OCP for the first time. From there additional members of your team can be granted developer access by assigning the Developer role for OCP in the Admin Centre.

Once you have access to the OCP Developer Portal, generate an API key for the OCP CLI. Save the key to a credentials file at ~/.ocp/credentials.json and then install the CLI:

Windows:

# Create the folder
New-Item -Path "~/.ocp" -Name "home dir" -ItemType "directory"

# Create the credentials file
Write-Output '{"apiKey": "<your-api-key>"}' | out-file "~/.ocp/credentials.json" -encoding utf8

# Install OCP CLI
iwr -useb https://cli.ocp.optimizely.com/install.ps1 | iex

Mac:

# Create the folder
mkdir ~/.ocp (home dir)

# Create the credentials file
echo '{"apiKey": "<your-api-key>"}' > ~/.ocp/credentials.json

# Install OCP CLI
curl -fsSL https://cli.ocp.optimizely.com/install.sh | bash

You should then be able to verify access with the whoami command:

ocp accounts whoami

Before Building Your Solution

Before you get started with building your application you should look at installing the Optimizely OCP Skills for your AI coding assistant. Whether you clone these into your own repo or install them as a plugin is going to be your own decision. It does come with 4 skills, 2 of which are migration skills. If you are new to OCP app development, you can focus on the ocp-app-development and ocp-local-testing skills.

💡 Tip: These AI skills know how to build your app, how to register it, how to publish it for developer testing, beta testing and for production review. It is highly recommended that you use them.

Optimizely have also created a sample OCP CMS UI Extension called Unsplash Viewer that has both a sidebar panel and a full-page view. It is worth looking at this sample repository to see how the two entry points are configured and to understand the general architecture of a CMS UI Extension.

Thinking About Data

When building add-ons for Optimizely PaaS CMS, you had access to your own tables within the CMS database through tooling such as Entity Framework or by using the Dynamic Data Store. These options are not available to us when building CMS UI Extensions. OCP does however provide access to the following data stores which are key-value pairs:

Secrets Store: Allows the storing of primitive data types only and is your general purpose storage for sensitive data such as API keys. This store is accessible from the backend of your OCP application.
Settings Store: Allows the storing of primitive data types only and is the preferred place to store application settings, including sensitive data such as API keys. This data store can be accessed either by the backend of your application or as the settings form directly with the application settings within OCP.
Key Value Store: Allows the storing of primitive data types and complex JSON objects for short-term and long-term storage. Do not store sensitive data here. This data store is typically accessed by the backend of your application.
Shared Key Value Store: Works like the Key Value Store, but is accessible by both your application and third-party applications.

If you are planning to store a lot of data to the Key Value Store, consider co-locating the data as a JSON object. Each entry in the Key Value Store can be up to 400 KB in size and storing data together can reduce the number of API calls needed by your application.

If the data you are storing to the Key Value Store is intended to have a limited lifespan, e.g. 1 hour, then data should be saved with a TTL (Time to Live). Data saved without a TTL will have a lifespan limited to the application installation.

If you require data permenance, then you need to consider an alternative place to store your data. The Key Value Store is expected to be rebuildable in the same way that the Content Graph index is expected to be rebuildable. Any value without a TTL will be persisted for the life span of the application. If you need to reinstall or update the application or move it from one regional store to another, then the Key Value Store is completely reset.

Options for permance should include:

Using SDKs to store your data as content in the CMS or CMP.
Using a third-party data store accessible via API using an API key stored within the Settings Store.

Reviewing the Stott Security for SaaS CMS Solution

Stott Security for SaaS CMS is a CMS UI Extension port of the popular Stott Security add-on for Optimizely PaaS CMS. This has been built as a full-width page with a publicly accessible endpoint to be consumed by a separate headless frontend.

Solution Structure

The following is a folder and file structure for the Stott Security for SaaS CMS solution. I’m only including core files here to prevent information overload, but do check out my solution or the Optimizely Unsplash Viewer example.

- assets
  - icon.svg
  - logo.png
  - directory
    - overview.md
- forms
  - settings.yml
- src
  - backend
    - functions
      - CmsExtension.ts
      - CompiledHeaders.ts
  - cms-ui-extensions
    - SecurityConsole.view.tsx
- app.yml

You may notice that the code is split into two separate runtimes, the backend and the CMS UI Extensions:

Frontend
- Runs within an iFrame hosted within Optimizely CMS
- Code lives in src/cms-ui-extensions/
- Talks to the backend through context.extension.invokeFunction()
- Exposes endpoints through ExtensionContext
Backend
- Runs on OCP in the node22-cms-ext context
- Code lives in src/backend/
- Talks to
  - External APIs over HTTPS
  - OCP storage
  - Lifecycle APIs

Understanding the app.yml

The app.yml file contains the manifest for your CMS UI Extension. You can see the full YAML file for this solution on GitHub. The metadata for the application and all of its entry points and functions are declared within this file.

meta:
  app_id: stott_security_saas
  display_name: Stott Security
  vendor: mark_stott
  summary: Manage Content Security Policy and response headers for Optimizely CMS (SaaS).
  categories:
    - Content Management
  availability:
    - all

runtime: node22-cms-ext

ui_extensions:
  view:
    - name: stott-security-console
      entry_point: SecurityConsole
      display_name: Stott Security

functions:
  cms_extension:
    entry_point: CmsExtension
    description: Backend for the Stott Security console (draft CRUD and publish).
    accepts: cms_ui_extension

  compiled_headers:
    entry_point: CompiledHeaders
    description: Serves compiled security headers to the site head.

app_id: This must be a globally unique name for your application and it is permanent. Changing this name is essentially publishing the application a second time.
vendor: This is your vendor name and must match the vendor associated with your partner or customer organisation.
runtime: This must be node22-cms-ext for a CMS UI Extension and tells OCP that this application will be run in the CMS Extensions runtime operating on Node.js 22.
ui_extensions: This is where you declare your entry points into the CMS and can be declared as:
- view: A full-width embedded page.
- sidebar: A sidebar embedded in a panel on the right-hand side of the editor interface.
- property-editor: A replacement UI for a specific property type.
functions: This is where you declare your backend functions.
- entry_point: This is the name of your entry point.
- accepts: If you set this to cms_ui_extension, then it means the endpoint has no public URL and can only be accessed by the frontend using the invokeFunction() method. Omit this if you want to provide a public endpoint.

SDKs

A CMS UI Extension uses three Optimizely packages, plus a design system for the UI:

@zaiusinc/app-sdk (Backend): The OCP App SDK, which provides the framework for functions, storage and application lifecycle.
@optimizely/ocp-cms-ui-extensions-sdk (Build and Backend): A plugin for the OCP App SDK that adds support for defining and validating your app.
@optimizely/cms-extensibility-sdk (Frontend): The SDK for the CMS side of your extension that provides registration, delivery and access to your backend.
@optiaxiom/react (Frontend): The React implementation of Optimizely’s Axiom design system, which helps your extension look and feel like part of the CMS.

The plugin must be registered within ocp-app.config.mjs, otherwise your ui_extensions declarations will not be recognised and ocp app validate will fail:

import { defineConfig } from '@zaiusinc/app-sdk';
import { cmsUiExtensions } from '@optimizely/ocp-cms-ui-extensions-sdk';

export default defineConfig({
  plugins: [cmsUiExtensions()]
});

Backend

Each function declared within the functions section of your app.yml has a matching entry file within src/backend/functions/. The entry_point must match the name of the exported class, and that class must extend App.Function from the @zaiusinc/app-sdk package and implement a perform() method that returns an App.Response. One thing to watch out for is that the status code is the first argument for App.Response, which is the opposite of the standard web Response object.

import * as App from '@zaiusinc/app-sdk';

export class HelloWorld extends App.Function {
  public async perform(): Promise<App.Response> {
    return new App.Response(200, { message: 'Hello World' });
  }
}

Stott Security for SaaS CMS has two backend functions, one private and one public.

CmsExtension.ts

This is the private backend for the security console. Because it is declared with accepts: cms_ui_extension, it has no public URL and can only be called by the frontend using context.extension.invokeFunction(). Rather than creating a function per operation, the convention is to have a single function that accepts an action and a set of params and then switches on the action:

export class CmsExtension extends App.Function {
  public async perform(): Promise<App.Response> {
    const body = (this.request.bodyJSON ?? {}) as RequestBody;
    const action = typeof body.action === 'string' ? body.action : '';
    const params = body.params ?? {};

    switch (action) {
      case Actions.GetDraft:
        return ok(await this.getDraft(params));

      case Actions.SaveDraft:
        return ok(await this.saveDraft(params));

      case Actions.Publish:
        return ok(await this.publish(params));

      // ... additional actions

      default:
        return fail(400, ErrorCodes.UnknownAction, `Unknown action '${action}'.`);
    }
  }
}

This function is responsible for reading and writing the draft configuration, validating it, compiling it into a set of headers and then publishing the compiled headers. All of the data is held as JSON documents within the Key Value Store using storage.kvStore from the app SDK. Saving a draft and publishing are deliberately separate actions as an incorrect Content Security Policy can break a website, so making changes live should be an explicit act by the user.

Every response is wrapped in a consistent envelope of { ok: true, result } or { ok: false, error, message } so that the frontend has a single and predictable way of handling success and failure.

The function also uses functions.getEndpoints() to resolve the public URL of the compiled_headers function for the current installation. This allows the console to show the editor exactly which URL their website should consume.

CompiledHeaders.ts

This is the public endpoint that the head of the website calls in order to retrieve the published security headers. As accepts is omitted within the app.yml, OCP gives this function a public URL which contains a unique identifier for the installation. This matters because a regular App.Function resolves the installation from that URL and can therefore read the same Key Value Store that CmsExtension writes to. If this were declared as a global function, it would have no installation context and could only reach the Shared Key Value Store.

export class CompiledHeaders extends App.Function {
  public async perform(): Promise<App.Response> {
    if (this.request.method !== 'GET') {
      return new App.Response(405, { error: 'Only GET is supported.' });
    }

    try {
      const compiled = await readCompiled(scope);

      return new App.Response(200, {
        headers: compiled?.headers ?? [],
        publishedAt: compiled?.publishedAt ?? null,
        cacheSeconds: CACHE_SECONDS
      });
    } catch (error) {
      logger.error(`Failed to read compiled headers: ${String(error)}`);

      return new App.Response(503, { error: 'Compiled headers are temporarily unavailable.' });
    }
  }
}

A few design decisions are worth highlighting here:

The endpoint only reads the compiled headers, all of the work to compile the configuration happens once on publish rather than on every request.
The response includes a cacheSeconds value to encourage the consuming website to cache the response. Without this, every page request on the head would result in a request to OCP.
Having nothing published yet returns an empty array with a 200 status so the head can apply its own defaults, while a genuine failure returns a 503 so the head can tell the difference and fall back gracefully.
The response contract is identical to the compiled headers endpoint in the PaaS version of Stott Security, allowing a single consumer implementation to work with either product.
The endpoint is anonymous by design. These headers are visible on every response from the website anyway, but this is a deliberate decision and you should consider carefully what data you expose from any public function. If your data has privacy needs, then consider requiring an API Key.

📰 Please note that I will cover consuming this endpoint in a headless solution in a future article so as to not detract from the topic of this article.

Frontend

Each entry within the ui_extensions section of your app.yml has a matching entry file within src/cms-ui-extensions/. For Stott Security for SaaS CMS, this is a single view with an entry point of SecurityConsole, which maps to SecurityConsole.view.tsx. The frontend is built with React and is rendered within an iFrame inside of the CMS.

Your CMS UI Extension may have multiple entry points that manifest within the CMS in different ways. The naming convention for a UI entry file is as follows:

<Name>.<injection-point>.{ts,tsx,js,jsx}

// Examples
MyExtension.view.tsx
MyExtension.sidebar.ts
MyExtension.property-editor.js

SecurityConsole.view.tsx

The most important line in this file is at the very bottom. The register() method from the @optimizely/cms-extensibility-sdk package is how your extension is mounted into the CMS. This must be called exactly once at the top level of the module and never inside of a component or effect. The CMS passes an ExtensionContext into the callback, which you then pass down into your components:

import { register, type ExtensionContext } from '@optimizely/cms-extensibility-sdk';

function SecurityConsole({ context }: { context: ExtensionContext }): React.JSX.Element {
  useEffect(() => {
    void context.extension.setReady();
  }, [context]);

  // ... render the console
}

register((context) => <SecurityConsole context={context} />);

The ExtensionContext is your bridge between the frontend and both the CMS and your backend. Within the console, this is used for two key purposes:

context.extension.setReady() is called once the component has mounted to let the CMS know that the extension has loaded.
context.extension.invokeFunction() is used to call the private CmsExtension backend function.

All backend calls are wrapped within a small typed client, so the components never need to know about the transport:

const result = await context.extension.invokeFunction('cms_extension', { action, params });

A nice benefit of this approach is that there are no URLs, authentication cookies, CORS rules or CSRF tokens to manage within the frontend. The call never leaves the CMS host and OCP takes care of routing it to your backend function. It is worth noting that invokeFunction() will only reject on a transport failure, application errors are returned as a normal response with a non-2xx status code, so you will want to handle both.

The ExtensionContext offers more than the console needs. Which members are available depends on where your extension manifests within the CMS:

context.extension: Available to all extensions.
- setReady() tells the CMS that your extension has finished loading. The CMS may show a loading indicator until this is called.
- getDefinition() returns the id, display name, type and configuration of your extension.
- invokeFunction(functionId, parameters) calls a backend function. The functionId is the key under functions in your app.yml (e.g. cms_extension) and not the class name.
context.content: Only meaningful within a sidebar.
- get() returns a snapshot of the content currently being edited, including its key, version, locale and public URL.
- subscribe(callback) notifies you when the content being edited changes.
context.property: Only bound within a property-editor.
- get() returns the current value of the property, whether it is read-only and any property settings.
- set(value) updates the value of the property. This resolves to { success, error } rather than throwing an error, so make sure you check success.
- subscribe(callback) notifies you when the value of the property changes.

For both content and property, the subscribe() method only fires on subsequent changes. You should call get() to read the initial value and then subscribe() to receive later changes, otherwise your component will remain empty until something changes. The subscribe() method also returns a function that you should call to unsubscribe when your component unmounts.

The rest of the file is a fairly standard React component. The UI is built with Optimizely Axiom (@optiaxiom/react), which is Optimizely’s own design system, and helps the extension look and feel like a native part of the CMS. Every Axiom component reads its design tokens from the AxiomProvider, so this needs to wrap your entire extension or the components will render unstyled.

function Shell({ children }: { children: React.ReactNode }): React.JSX.Element {
  return (
    <AxiomProvider>
      <main>{children}</main>
    </AxiomProvider>
  );
}

There are a few other things to be aware of when building a view:

A view is a single mounted bundle. For my multi-tab interface I manage what is visible through component state rather than using a client side router.
The CMS already renders a title for your extension, so there is no need to repeat it within your own UI.
The ExtensionContext does not currently carry the identity of the user, so you cannot rely on it for attributing actions to a named editor.

App Directory Information

The assets folder of your repository is used to provide additional information for when your app is added to the app directory:

assets/logo.png and assets/icon.svg provide a logo to be used both within the card on the App Directory and within the summary card on the app page.
assets/directory/overview.md provides the content to be displayed in the Overview tab within OCP.

Application Settings

Your app must have a forms/settings.yml which is used to declare the settings form within OCP for your app. This allows you to manage data within the Settings Store for your installation of the app directly within OCP.

As Stott Security for SaaS CMS does not require any data from the Settings Store, my entry contains a single information entry:

sections:
  - key: about
    label: Stott Security
    elements:
      - type: instructions
        text: >
          Everything is configured in the security console...

Other options you can add to your settings.yml include the following, you can see a full description and examples of each option by viewing OCP Form Elements:

Toggle: An option you can toggle on or off.
Text: A plain input box, additional options can be set to change the input type to text, email, number or phone.
Secret: A secure field for sensitive data that will be displayed as asterisks. Data added to one of these fields cannot be retrieved through the settings form interface.
Select: A single-select field that renders differently based on the number of options provided.
Multi-Select: A multi-select field that renders differently based on the number of options provided.
Button: Allows for an action to be triggered within the form e.g. “Begin Integration”
Link Button: Allows for a link to an external URL and supports Mustache syntax for URL variation.
OAuth Button: Supports authentication with a third party in order to support integrations.
Divider: Renders a simple divider mid-form.
Instructions: Supports instructions to be displayed to the user written in Markdown.

Summary

CMS UI Extensions are a significant leap forward for Optimizely SaaS CMS. For the first time, we can extend the SaaS editor interface in the same way that we have been extending PaaS CMS with add-ons for years, whether that is a full-width tool, a sidebar that works alongside the editor or a custom property editor.

The technology choice also makes a lot of sense. CMS UI Extensions are built with Node.js & JavaScript potentially with frameworks such as TypeScript and React. These are the same tools that developers building headless solutions on SaaS CMS are already using every day. This means the barrier to entry is low for the teams most likely to want to build them.

There are still some challenges to work through. Data storage is limited to key value stores that are tied to the lifespan of the application installation, so anything that needs permenance requires some careful thought. As this is a new feature, best practices are also still emerging.

Overall, CMS UI Extensions are a really good addition to Optimizely SaaS CMS, and I’m looking forward to seeing what the community builds with them. If you are about to build your first CMS UI Extension, here are a few tips to help you get started:

Install the Optimizely OCP Skills as this will help your AI assistant to structure your application correctly.
Review Optimizely’s example CMS UI Extension: Unsplash Viewer
Consider app ownership and naming very carefully. App names must be unique and are permanent.
Consider whether you need data permanence and where that data will live.
Build for performance and leverage caching wherever possible.
If you are using the Key Value Store, co-locate your data as JSON to reduce the number of API calls.

Appendix

I'm a Platinum Optimizely MVP and the maintainer of two open source add-ons: Stott Security for SaaS CMS and PaaS CMS 12 & 13, and Stott Robots Handler for PaaS CMS 12 & 13. All of my writing is collated at https://www.stott.pro.

Cheapskate AI Translator: Because Translation Should Not Require a Second Mortgage

2026-10-15T08:06:38.0000000Z

There is a particular kind of software project that begins with a detailed architecture document, a product roadmap, and a carefully assembled budget.

This is not that kind of project.

This project began with a simpler question:

Can I create language versions in Optimizely CMS without paying more for an LLM than I absolutely have to?

The answer is now an open source add-on: Cheapskate.AITranslator.

You can find the source code on GitHub and install the published package from the Optimizely NuGet feed.

The honest motivation

I am a cheapskate.

Not in the charming, coupon-clipping sense. In the practical engineering sense. If a free tier, a generous quota, or a small amount of careful request batching can do the job, I would prefer that to adding another monthly AI bill to the household budget.

The goal is not to avoid paying for good services forever. The goal is to pay as little as I can get away with while still delivering useful translations and a maintainable CMS workflow.

That means the add-on is designed around choice:

Google Gemini-compatible chat completions
GroqCloud-compatible chat completions
Microsoft Azure Translator
DeepL API Free
Custom OpenAI-compatible providers

Some providers offer free tiers, some offer free quotas, and some are inexpensive enough to be useful when a free option is not appropriate. The add-on does not assume that one provider, one pricing model, or one API will remain the best choice forever.

What the add-on does

Optimizely content editors can create draft language versions from the editor and choose whether to translate them with AI after the drafts are created.

The add-on can:

Create all missing language branches or one selected target language
Keep the new versions as drafts rather than publishing them
Optionally follow linked content in ContentArea properties
Translate language-specific text and Rich Text content
Preserve HTML structure while translating visible text
Run translation in the background after draft creation
Use different providers through one CMS settings screen

The workflow is intentionally modest. It creates drafts, starts translation work, and reports the job status. It does not pretend that an automated translation should bypass editorial review.

That last part is important. A translation engine can be very good and still occasionally produce something that makes a human editor stare at the screen for a while. Drafts are a useful place for that staring to happen.

The small trick that saves API calls

The add-on can combine multiple translatable properties into one JSON request instead of making one API request per property.

Without batching, a page with a title, teaser, body, call to action, and several blocks can turn into a small parade of API calls. That is inefficient, costs more, and can hit provider rate limits faster than necessary.

With batching enabled, the worker groups translation entries into bounded requests according to configured input and output token limits. The provider receives a structured payload, translates the values, and returns the translated entries for the background worker to write back to the draft.

In plain English:

Fewer trips to the API means fewer opportunities for the API to say, "Please slow down."

Batching does not remove provider limits, and it does not make an unlimited service out of a limited one. It simply uses the available quota more sensibly. The request-size limits remain configurable because different providers have different capabilities and pricing rules.

Why support several providers?

Because depending on one provider is an excellent way to discover that provider's outage page at the worst possible moment.

More seriously, different projects have different constraints:

A project may already have an Azure subscription and prefer Azure Translator.
A developer may want to use a free Gemini or GroqCloud quota.
A team may prefer DeepL for a particular language pair.
An organization may have its own OpenAI-compatible gateway.
A provider's model, pricing, quota, or terms may change.

The add-on keeps the CMS workflow stable while allowing the translation backend to change. Provider credentials and options live in CMS settings rather than in source control, and the custom provider option gives developers room to connect a compatible internal service.

This is not Optimizely Language Manager

A very important clarification: Cheapskate.AITranslator is not intended to replace Optimizely's official Language Manager add-on.

Language Manager is the official product for teams that need its supported translation-management workflow, integrations, governance, and product support. This add-on has a narrower and more developer-oriented purpose.

Cheapskate.AITranslator brings the implementation into the developer's control. The source code is available, the behavior can be inspected, and the add-on can be customized for a particular Optimizely CMS solution.

That may mean changing:

Which content properties are translated
How linked content is traversed
How prompts are written
Which provider is called
How batches are sized
How translation jobs are queued or reported
Which editorial safeguards are required

If your project needs an officially supported translation-management product, use Language Manager. If your project needs a small, inspectable starting point that your team can adapt, this add-on may be useful.

It is not a product-versus-product argument. It is a choice between a supported official solution and a source-controlled developer tool with a smaller scope.

Open source is the point

The most valuable part of this add-on is not the skate icon or the settings page. It is the ability to see what happens between clicking Create Language Versions and saving a translated draft.

Developers can review the code, change the translation rules, add provider behavior, adjust batching, and fit the workflow to their own content model. The add-on is deliberately not a sealed box that asks everyone to accept the same assumptions.

That also means responsibility comes with the freedom:

Review generated translations before publishing.
Protect provider credentials.
Check provider terms and quotas.
Test prompts and content types in a non-production environment.
Keep the add-on aligned with the CMS version used by the project.

Cheap is good. Cheap and mysterious is less good.

Getting started

The project targets Optimizely CMS 13 and .NET 10 on the main branch. The legacy CMS 12 implementation remains on the CMS-12-base branch.

Install the CMS 13 package with:

dotnet add .\YourCmsProject.csproj package Cheapskate.AITranslator --version 2.0.0

Then configure a provider under Settings > AI Translator, open localizable content in the editor, and use the Create Language Versions command.

The resulting versions are drafts. The AI translation runs in the background when enabled, and the editor remains responsible for the final content review.

Final accounting

The philosophy is simple:

Use the provider that fits the project.
Use free quotas where they are enough.
Batch requests so the quota lasts longer.
Keep the workflow in developer-controlled source code.
Spend money when spending money is actually justified.

That is the entire cheapskate strategy. It is not glamorous, but neither is discovering a surprisingly large AI invoice after a bulk translation job.

Cheapskate.AITranslator is open source under the MIT license: a small Optimizely add-on for teams that want draft language creation, optional AI translation, multiple provider choices, and a little more control over where the money goes.

Computed Fields in CMS 13 Content Contracts with Optimizely Graph

2026-10-14T05:01:48.0000000Z

Content Contracts in Optimizely CMS 13 allow different content types to share a common structure when querying Optimizely Graph.

But what if the shared field doesn't exist as a stored CMS property, and its value needs to be calculated differently depending on the content type?

For example, imagine a search feature that includes articles, events, and images:

Articles use Heading as their search title.
Events use EventName.
Images use ImageTitle, falling back to their name.

We want all three to expose a common SearchTitle field in Graph, without adding another persisted property to each content type.

Here's a working approach tested with Optimizely CMS 13.3.0.

1. Define a Content Contract

First, define a Content Contract with a method that each implementing content type uses to provide its search title.

[ContentType]
public interface ISearchableContent : IContentData
{
    string GetSearchTitle();
}

Each content type implements the same contract but calculates the search title using its own properties. For example, an article page uses Heading, while an event page uses EventName.

public class ArticlePage : PageData, ISearchableContent
{
    public virtual string Heading { get; set; }

    public string GetSearchTitle() =>
        string.IsNullOrWhiteSpace(Heading) ? Name : Heading;
}

public class EventPage : PageData, ISearchableContent
{
    public virtual string EventName { get; set; }

    public string GetSearchTitle() =>
        string.IsNullOrWhiteSpace(EventName) ? Name : EventName;
}

Both content types implement the same contract but calculate SearchTitle differently. The same approach works for media types, such as images, using their own properties.

Make sure the relevant content types implement or are associated with the Content Contract in CMS so they can be queried together in Graph.

This keeps the calculation close to each content type and avoids maintaining a central switch statement.

2. Expose the Computed Field in Graph

Next, create an extension method and register it using Graph indexing conventions.

public static class SearchExtensions
{
    public static string SearchTitle(this ISearchableContent content)
        => content.GetSearchTitle();
}

services.AddContentGraph(configureConventions: conventions =>
{
    conventions.ForInstancesOf<ISearchableContent>()
        .IncludeField(
            x => x.SearchTitle(),
            IndexingType.Searchable);
});

The important detail is that SearchTitle is computed during indexing. We don't need to add a persisted SearchTitle property to our CMS models.

The resulting Graph schema exposes the field through ISearchableContent, regardless of the underlying content type.

3. Query It with the Graph C# SDK

The interesting part is that the computed field can also be used in strongly typed SDK queries.

First, define a lightweight result model:

public class SearchResult
{
    public string SearchTitle { get; set; }
}

Then query the Content Contract:

var query = graphClient
    .QueryContent<ISearchableContent>()
    .Where(x => x.SearchTitle().Contains("Optimizely"))
    .Limit(20)
    .IncludeTotal()
    .Fields<SearchResult>(x => x.SearchTitle);

var result = await query.GetAsync();

In our test, the SDK translated the filtering expression into GraphQL:

query ISearchableContentQuery {
  ISearchableContent(
    where: { SearchTitle: { contains: "Optimizely" } }
    limit: 20
  ) {
    items {
      SearchTitle
    }
    total(all: true)
  }
}

The query returned one matching event with SearchTitle equal to Optimizely Developer Webinar.

Here's the interesting detail: SearchTitle() is a C# extension method, not a stored CMS property. Graph indexing conventions expose it as a searchable field, and the Graph C# SDK translates the expression into a server-side GraphQL filter rather than filtering an in-memory collection.

We also verified sorting by the computed field, language-specific values, and recalculation after updating and publishing the underlying content.

Key Takeaway

By combining CMS 13 Content Contracts, Graph indexing conventions, and the Graph C# SDK, we can expose a shared searchable field across different content types while keeping the calculation specific to each type.

No additional persisted CMS properties are required.

Keep computed field calculations lightweight and deterministic, since they run as part of the indexing process.

References

Opal Workflow Agents And The Graph Webhook Trap

2026-10-14T01:06:16.0000000Z

What we did?

We built a compliance review workflow agent in Opal. The job was simple: when an editor submits a page for review in Optimizely CMS 13, the agent reads the content, checks it against defined compliance rules, and writes its findings back onto the item so a human reviewer sees them before approving.

One editorial action in, one review out. That was the whole contract. A complete run costs 100–130 credits and takes 2-4 minutes. This makes a single run fairly expensive on credits. Now picture that same run firing over and over, several at once, and the consumption climbs fast.

The trigger was the only open question. Opal workflow agents can fire a few ways — chat input, a schedule, email, or a webhook — but for a run that kicks off automatically when something happens in the CMS, the webhook is the one that fits. So something in Optimizely CMS had to notice “this page entered review” and POST to the trigger URL. The obvious source was Optimizely Graph. It’s pure configuration — register a webhook through the API, no CMS code to deploy — and it already models content changes, which is more or less what we were reacting to. So we started there: a Graph subscription pointed at the Opal trigger, filtered to the InReview status.

What we didn’t see coming?

The first run worked exactly as intended. An editor submitted a page, the status went to InReview, Graph synced, the webhook fired, and the agent ran its compliance check.

Then the agent did the one thing it was built to do: it wrote its findings back onto the page.

That write-back was a save. The save synced to Graph. The content was still InReview — writing findings doesn’t change an approval status — so Graph delivered a webhook for an InReview document, which is exactly the event we’d subscribed to. The agent fired again. Checked again. Wrote back again. Synced again.

By the time we were looking at it, we had four pages of execution logs: the same agent, on the same page, running over and over, several instances going at once. We started cancelling runs manually to stop them burning through credits. The agent was triggering itself, and nothing in the loop was going to stop it.

Nothing was broken, which is what made it hard. Graph was doing exactly what Graph does.

Why it looped?

Seeing the behaviour was easy. Finding the cause took a while. Two facts about Graph, neither of them a bug, combined into the loop:

Graph syncs on save, not on intent. It re-indexes whenever content is saved, published, moved, deleted, or expired. Our agent’s write-back is a save like any other, so every write re-syncs.

Status is part of a document’s identity. Graph identifies an indexed document as {contentGuid}_{version}_{locale}_{status}. Our write-back changed the content but left the status at InReview — so every re-sync produced the same InReview document, indistinguishable from the submit event we’d subscribed to. There was no status change to mark the work as handled, and no state anywhere saying “this one’s done.” So each sync looked like a fresh reason to run.

Underneath it, the mistake was conceptual: we were inferring an editorial decision from index activity. But the index was churning every time our own agent touched the page — and the agent never stopped touching the page.

The fix: subscribe to the decision, not the side effect

Optimizely CMS already raises an event for the exact moment we cared about. The approval engine exposes IApprovalEngineEvents, and its Started event fires once, when an approval instance begins — i.e. when a human submits for review. It’s raised by the approval lifecycle, not the persistence layer. Background saves, forced writes, and our own agent’s write-back don’t start approval instances, so they don’t raise it.

So instead of inferring the decision from Graph, we subscribed to it directly in the CMS solution and POSTed to the Opal trigger ourselves:

[InitializableModule] [ModuleDependency(typeof(EPiServer.Web.InitializationModule))] public class ComplianceReviewTriggerModule : IInitializableModule { private IApprovalEngineEvents _approvalEvents; // IContentLoader, IHttpClientFactory, config resolved in Initialize() public void Initialize(InitializationEngine context) { _approvalEvents = context.Services.GetRequiredService<IApprovalEngineEvents>(); _approvalEvents.Started += OnApprovalStarted; // raised once, on submit } private void OnApprovalStarted(object sender, ApprovalEventArgs e) { if (!e.IsContentApproval()) return; // approvals are generic var contentLink = e.GetContentLink(); // extension method if (ContentReference.IsNullOrEmpty(contentLink)) return; if (!_contentLoader.TryGet<MyCustomPage>(contentLink, out var page)) return; // scope to our content type // Mirror Graph's docId shape so the workflow is source-agnostic. var docId = $"{page.ContentGuid}_{contentLink.WorkID}_{page.Language.Name}_InReview"; _ = Task.Run(() => TriggerOpalAsync(docId)); // fire and forget, with a timeout } }

A few things that mattered in practice:

• ApprovalEventArgs has no ContentLink. Approvals are a general mechanism; content approvals are one implementation. You reach the item through the IsContentApproval() and GetContentLink() extension methods in EPiServer.Approvals.ContentApprovals.

• The Opal trigger wants auth. The webhook trigger takes an Auth Key and sends it as a header (e.g. Authorization: Bearer {token}). Our POST sets that header from config; a request that doesn’t match is rejected.

• We mirrored Graph’s docId shape in the payload, so the downstream workflow didn’t need to change. If we ever switch sources again, the agent doesn’t care.

• Fire-and-forget has a cost. Blocking the editor’s submit on an outbound call is a bad idea, so we don’t. The trade is that if Opal is unreachable the moment Started fires, that trigger is lost — at-most-once. For a review flow that’s fine, because an editor can resubmit. If it weren’t, we’d add retries or a durable queue.

Result: one submit, one execution. The write-back still syncs to Graph, but we’re no longer listening to Graph for this trigger, and writing content doesn’t start an approval — so there’s nothing left to re-fire. The loop was gone, not because we out-guarded it, but because we stopped listening to the wrong layer.

So when is Graph the right source?

The lesson isn’t “Graph is wrong.” Graph is excellent — for the thing it actually reports, which is content as the published world sees it.

Reach for Graph when:

• You’re reacting to content state, not editorial intent — a page got published, purge the CDN; rebuild the static site. This is Graph’s canonical use case, and duplicate deliveries are harmless because the second purge is a no-op.

• The consumer is idempotent — ISR cache invalidation, deploy hooks, downstream sync. Firing twice costs nothing.

• You don’t own the CMS codebase, or you’re on SaaS CMS. Graph is configuration, no deploy required.

• The consuming system is decoupled from CMS and you don’t want to couple to its internals.

Reach for a CMS server-side event (the code path) when:

• The trigger is an editorial decision — submitted, approved, rejected. That lives in the approval engine, and Graph can’t model it.

• Your workflow writes back to the item that triggered it. This is the one that bit us; any index-based trigger risks the same loop.

• Each execution is expensive. When a run costs real credits and minutes, precise firing matters far more than easy setup.

• You need business rules before firing — content type, language, site. Strongly typed C# beats filtering on payload shape.

For us it was a compliance review agent that wrote back to the page it reviewed, at 100+ credits a run. Three of those four boxes. Graph was the wrong tool for this job. We kept Graph for delivery-side concerns and moved the editorial trigger to the approval event. They answer different questions.

The takeaway

Both sources are honest. Graph faithfully reports that an indexed document changed. The approval engine faithfully reports that a person made a decision. Neither is broken.

The real question is which of those you care about — a document changing or a person deciding — and subscribing at that layer instead of inferring it from the one below. When a workflow fires more often than the business event behind it, the instinct is to bolt on a guard. Sometimes you need one. But first ask what your event source is actually reporting.

Ours was reporting every save. Our agent just happened to be the thing doing the saving.

cms13-scan: A Deterministic CMS 13 Readiness Scanner

2026-10-12T10:09:07.0000000Z

Every CMS 12 to CMS 13 upgrade I have looked at starts the same way. Someone opens the solution and starts hunting. A text search for the APIs

Setting Up an Optimizely CMS 13 MCP Server Locally with Codex

2026-10-12T04:41:05.0000000Z

Optimizely CMS 13 supports Model Context Protocol (MCP), allowing AI tools such as Claude and Codex to interact with CMS content and metadata through an MCP server.

In this post, I'll show how I configured the MCP server in my local CMS 13 Alloy project, connected it to Codex in Visual Studio Code, and used it to explore content types, create pages, and build a Visual Builder experience.

Prerequisites:

Optimizely CMS 13 (I'm using Alloy with CMS 13.3.0).
An MCP-compatible AI client (I'm using Codex in VS Code).
A local CMS instance running over HTTPS, for example, https://localhost:5000.

Configure the MCP Server

Install the Optimizely.Cms.Opal.Tools NuGet package (version 13.2.0 or later):

dotnet add package Optimizely.Cms.Opal.Tools --version 13.2.0

services.AddCmsMcpServer()
    .WithClientSecretAuthentication();

Then map the MCP endpoint and require client-secret authorization:

app.UseEndpoints(endpoints =>
{
    endpoints.MapContent();

    endpoints.MapMcp("/mcp")
        .RequireClientSecretAuthorization();
});

The MCP endpoint is now available at https://localhost:5000/mcp, or your application's configured HTTPS address.

Configure Client-Secret Authentication

Make sure a client secret is configured for your local CMS application. We'll use it to authenticate Codex when connecting to the MCP server.

Security note: Never commit your client secret to source control or expose it in screenshots.

Connect Codex in VS Code

Open Codex Settings → MCP servers → Add server and select Streamable HTTP.

Name: optimizely-cms
URL: https://localhost:5000/mcp
Bearer token env var: Leave empty.
Header: Authorization, with your configured client secret as the value.

Alternatively, configure the server in Codex's config.toml:

[mcp_servers.optimizely-cms]
type = "http"
url = "https://localhost:5000/mcp"

[mcp_servers.optimizely-cms.headers]
Authorization = "your-secret-value"

Replace the placeholder with your actual secret and enable the server in Codex Settings. The secret is passed directly in the Authorization header, without a Bearer prefix.

Configuring the local Optimizely MCP server in Codex.

Verify the Integration

With the CMS running, open a new Codex chat in VS Code and try:

List the available content types in my local Optimizely CMS instance using the MCP server.

Codex retrieved the registered content types, including StandardPage and StandardExperienceData, and could inspect their properties, locales, and available Visual Builder components.

You can also retrieve existing content:

Find the published content items of type ProductTestPage and show their properties.

These read-only operations confirm that Codex can access CMS content and metadata through MCP.

Codex retrieving content types from the local CMS instance.

Create Content Using Codex

Next, I asked Codex to create an unpublished page:

Create "MCP Demo Page" under Start using StandardPage. Add a heading and paragraph to MainBody, and save it as an English draft.

Codex created the page and updated its content through the MCP server.

I also tested Visual Builder:

Create an unpublished "Alloy Demo Experience" using StandardExperienceData, with a BlankSection containing a VisualBuilderTestBlock.

Codex created the experience using the existing CMS content types and Visual Builder components. Both items were saved as drafts without publishing.

The MCP Demo Page created through Codex and saved as a draft.

Troubleshooting Content Permissions

During content creation, I encountered an authorization error:

Access denied: You do not have permission to create content in this location.

The MCP client authenticated successfully with a CmsAdmins role claim, which was mapped to WebAdmins in the application configuration. Although the Start page granted Create permission to WebAdmins, the MCP client was still denied access.

The issue was resolved by explicitly granting the MCP Client permissions on the Start page through CMS access rights. Afterward, Codex could create and update content.

Granting the MCP Client access on the Start page resolved the create denial.

Security note: For this local demo, all permissions were enabled, including Publish and Administer. In a real environment, grant only the permissions needed for the intended operations.

Conclusion

With Codex connected to Optimizely CMS 13 through MCP, we were able to explore content types, create pages, and work with Visual Builder directly from VS Code.

One thing worth noting is that connecting successfully doesn't necessarily mean the MCP client has permission to create or update content. You'll still need to configure the appropriate access rights in CMS.

Handling SixLabors.ImageSharp vulnerability warnings in Optimizely CMS 12 (unofficial)

2026-10-10T06:01:41.0000000Z

2nd UPDATED: we’ve gotten a SixLabors license file, CMS team is working on update ImageSharp to a safe version (both SaaS and Paas CMS) in this story CMS-57368

Written by Claude Opus 5.5 (Anthropic) on behalf of Cuong Nguyen, Optimizely Technical Support.

A note from Cuong: Thanks to Optimizely for giving me access to Claude, which made this kind of deep dive possible within a support ticket.

SixLabors.ImageSharp is one of the most popular image libraries in the .NET world. Chances are it's in your solution too, even if you never added it yourself. Then one morning you open the project, run a build like any other day, and the output is suddenly full of NU1902/NU1903 warnings. Nothing changed in your code. If TreatWarningsAsErrors is on, the build simply fails.

That's the story behind a lot of tickets we've been getting in Optimizely Support lately. This post covers where the dependency comes from, why "just upgrade ImageSharp" doesn't work, and the four options you have today, including a SkiaSharp-based IImageService sample.

1. What you'll see

$ dotnet list package --include-transitive --vulnerable

   Transitive Package          Resolved   Severity   Advisory URL
   > SixLabors.ImageSharp      3.1.11     Moderate   https://github.com/advisories/GHSA-gwg2-r3hj-4w44
                                          High       https://github.com/advisories/GHSA-j3p4-wp97-rph4
                                          High       https://github.com/advisories/GHSA-j9gm-c75j-xc9q
                                          Moderate   https://github.com/advisories/GHSA-wmxv-xphr-5c9g
                                          High       https://github.com/advisories/GHSA-jjfr-hcj7-qf5w

You'll also get NU1902/NU1903 during restore and build. With TreatWarningsAsErrors enabled, the build fails.

2. Where the dependency comes from

The CMS uses IImageService for thumbnails and the image editor. The default implementation lives in EPiServer.ImageLibrary.ImageSharp, which depends on SixLabors.ImageSharp:

EPiServer.CMS 12.34.x
└── EPiServer.ImageLibrary.ImageSharp  (>= 1.0.6)   ← NuGet picks the lowest matching version
    └── SixLabors.ImageSharp 2.1.11

NuGet resolves dependencies with the lowest applicable version rule (docs). So EPiServer.CMS 12.34.8 resolves EPiServer.ImageLibrary.ImageSharp 1.0.6, which brings in ImageSharp 2.1.11. This is standard NuGet behavior, not something specific to Optimizely packages.

To get a newer version, reference the CMS components directly instead of the EPiServer.CMS metapackage, and pin EPiServer.ImageLibrary.ImageSharp to 2.0.6:

<PackageReference Include="EPiServer.CMS.UI" Version="12.34.6" />
<PackageReference Include="EPiServer.Hosting" Version="12.24.1" />
<!-- ... -->
<PackageReference Include="EPiServer.ImageLibrary.ImageSharp" Version="2.0.6" />

That moves you to ImageSharp 3.1.11, which clears the older advisories but not the five listed above.

3. Why not force a newer ImageSharp?

The advisories above are fixed in ImageSharp 4.x. Six Labors changed the licensing model in 4.x, and Release builds require a license key (discussion). Forcing 4.x through Directory.Packages.props therefore gives you a build error unless you have a Six Labors license. The 3.1.x line, the last one usable without a license, still carries the advisories.

4. Your options

#	Option	Pros	Cons
1	Remove EPiServer.ImageLibrary.ImageSharp	No code, warnings disappear	No image processing: thumbnails and the image editor stop working
2	Provide your own IImageService, e.g. with SkiaSharp	Clean audit, features kept	Custom code that your team owns and maintains
3	Suppress the audit warnings	Quick	The vulnerable package stays in your solution
4	Wait for an updated EPiServer.ImageLibrary.ImageSharp	No custom code	No committed timeline today

On risk: the image service only processes media that authenticated editors upload through the CMS. It doesn't handle arbitrary anonymous input. That lowers the exposure, and editors validating images on upload lowers it further. Whether that's acceptable is a decision for your own security policy and threat model.

5. Option 2: a custom IImageService with SkiaSharp

IImageService is a public extension point with a single method:

public interface IImageService
{
    void RenderImage(Stream input, Stream output, RenderRequest request);
}

The default implementation maps each ImageEditorCommand like this, and a replacement should do the same:

ImageEditorCommand	Default (ImageSharp)	SkiaSharp equivalent
Grayscale	Grayscale() (BT.709)	SKColorFilter.CreateColorMatrix with BT.709 coefficients
Crop	Crop(rect)	DrawBitmap(src, -left, -top)
FlipX / FlipY	Flip(Horizontal/Vertical)	canvas.Scale(-1, 1, cx, 0) / Scale(1, -1, 0, cy)
Resize	ResizeMode.Stretch	DrawBitmap(src, destRect, Mitchell)
ResizeKeepScale	ResizeMode.BoxPad + BackgroundColor	fit the box, no upscaling, center, Clear(bg)
Rotate	Rotate(deg), canvas expands	Translate + RotateDegrees on an expanded canvas

Packages

Remove EPiServer.ImageLibrary.ImageSharp and add SkiaSharp. If you reference the EPiServer.CMS metapackage, switch to individual component references first (see section 2). The metapackage brings EPiServer.ImageLibrary.ImageSharp in transitively, so you can't remove it otherwise.

<!-- remove: <PackageReference Include="EPiServer.ImageLibrary.ImageSharp" Version="..." /> -->
<PackageReference Include="SkiaSharp" Version="4.153.1" />
<!-- Required on Linux, containers and DXP: -->
<PackageReference Include="SkiaSharp.NativeAssets.Linux.NoDependencies" Version="4.153.1" />

The service

ResizeKeepScale matters most, because thumbnail generation calls it with BackgroundColor = "#00000000". The full implementation:

using EPiServer.ImageLibrary;
using SkiaSharp;

namespace YourSite.Business.Imaging;

/// <summary>
/// SkiaSharp-based replacement for EPiServer.ImageLibrary.ImageSharp's DefaultImageService,
/// which pulls in vulnerable SixLabors.ImageSharp versions. Mirrors the default behavior:
/// same commands, ResizeKeepScale = ImageSharp "BoxPad" + background color, ZoomFactor applied last.
/// </summary>
/// <remarks>
/// Skia only encodes PNG, JPEG and WebP. GIF/BMP/TIFF output is not supported (NotSupportedException),
/// and animated GIF input is flattened to its first frame.
/// </remarks>
public class SkiaImageService : IImageService
{
    private static readonly SKSamplingOptions ResizeSampling = new(SKCubicResampler.Mitchell);
    private static readonly SKSamplingOptions RotateSampling = new(SKFilterMode.Linear);
    private static readonly SKSamplingOptions CopySampling = new(SKFilterMode.Nearest);

    // ITU-R BT.709 luma, same coefficients as ImageSharp's Grayscale().
    private static readonly float[] GrayscaleMatrix =
    [
        0.2126f, 0.7152f, 0.0722f, 0, 0,
        0.2126f, 0.7152f, 0.0722f, 0, 0,
        0.2126f, 0.7152f, 0.0722f, 0, 0,
        0, 0, 0, 1, 0,
    ];

    public void RenderImage(Stream input, Stream output, RenderRequest request)
    {
        ArgumentNullException.ThrowIfNull(input);
        ArgumentNullException.ThrowIfNull(output);
        ArgumentNullException.ThrowIfNull(request);

        var image = Decode(input);
        try
        {
            foreach (var operation in request.Operations ?? [])
            {
                image = Replace(image, Apply(image, operation));
            }

            if (request.ZoomFactor != 1f)
            {
                var width = (int)Math.Floor(image.Width * request.ZoomFactor);
                var height = (int)Math.Floor(image.Height * request.ZoomFactor);
                image = Replace(image, Resize(image, width, height));
            }

            Encode(image, output, request);
        }
        finally
        {
            image.Dispose();
        }
    }

    private static SKBitmap Decode(Stream input)
    {
        using var codec = SKCodec.Create(input)
            ?? throw new NotSupportedException("The source image format is not supported.");

        var info = codec.Info
            .WithColorType(SKImageInfo.PlatformColorType)
            .WithAlphaType(SKAlphaType.Premul);

        return SKBitmap.Decode(codec, info)
            ?? throw new NotSupportedException("The source image could not be decoded.");
    }

    private static SKBitmap Replace(SKBitmap current, SKBitmap next)
    {
        current.Dispose();
        return next;
    }

    private static SKBitmap Apply(SKBitmap source, ImageOperation operation) => operation.Command switch
    {
        ImageEditorCommand.Grayscale => Grayscale(source),
        ImageEditorCommand.Crop => Crop(source, operation),
        ImageEditorCommand.FlipX => Draw(source.Width, source.Height, canvas =>
        {
            canvas.Scale(-1, 1, source.Width / 2f, 0);
            canvas.DrawBitmap(source, 0, 0, CopySampling);
        }),
        ImageEditorCommand.FlipY => Draw(source.Width, source.Height, canvas =>
        {
            canvas.Scale(1, -1, 0, source.Height / 2f);
            canvas.DrawBitmap(source, 0, 0, CopySampling);
        }),
        ImageEditorCommand.Resize => Resize(source, operation.Width, operation.Height),
        ImageEditorCommand.ResizeKeepScale => ResizeKeepScale(source, operation),
        ImageEditorCommand.Rotate => Rotate(source, operation.Angle),
        _ => throw new InvalidOperationException($"Unknown command {operation.Command}"),
    };

    private static SKBitmap Draw(int width, int height, Action<SKCanvas> draw)
    {
        var bitmap = new SKBitmap(width, height, SKImageInfo.PlatformColorType, SKAlphaType.Premul);
        using var canvas = new SKCanvas(bitmap);
        canvas.Clear(SKColors.Transparent);
        draw(canvas);
        return bitmap;
    }

    private static SKBitmap Grayscale(SKBitmap source)
    {
        using var filter = SKColorFilter.CreateColorMatrix(GrayscaleMatrix);
        using var paint = new SKPaint { ColorFilter = filter };
        return Draw(source.Width, source.Height, canvas => canvas.DrawBitmap(source, 0, 0, CopySampling, paint));
    }

    private static SKBitmap Crop(SKBitmap source, ImageOperation operation)
    {
        var area = SKRectI.Create(operation.Left, operation.Top, operation.Width, operation.Height);
        if (area.IsEmpty || !SKRectI.Create(source.Width, source.Height).Contains(area))
        {
            throw new ArgumentOutOfRangeException(nameof(operation), $"Crop area {area} is outside the image bounds.");
        }

        return Draw(area.Width, area.Height, canvas => canvas.DrawBitmap(source, -area.Left, -area.Top, CopySampling));
    }

    private static SKBitmap Resize(SKBitmap source, int width, int height)
    {
        var size = TargetSize(source, width, height);
        return Draw(size.Width, size.Height, canvas =>
            canvas.DrawBitmap(source, SKRect.Create(size.Width, size.Height), ResizeSampling));
    }

    /// <summary>ImageSharp BoxPad: fit inside the box without upscaling, center, fill the rest with the background color.</summary>
    private static SKBitmap ResizeKeepScale(SKBitmap source, ImageOperation operation)
    {
        var box = TargetSize(source, operation.Width, operation.Height);
        var scale = Math.Min(1f, Math.Min(box.Width / (float)source.Width, box.Height / (float)source.Height));
        var width = Math.Max(1, (int)MathF.Round(source.Width * scale));
        var height = Math.Max(1, (int)MathF.Round(source.Height * scale));
        var destination = SKRect.Create((box.Width - width) / 2, (box.Height - height) / 2, width, height);
        var background = ParseColor(operation.BackgroundColor);

        return Draw(box.Width, box.Height, canvas =>
        {
            canvas.Clear(background);
            canvas.DrawBitmap(source, destination, ResizeSampling);
        });
    }

    private static SKBitmap Rotate(SKBitmap source, double degrees)
    {
        var radians = degrees * Math.PI / 180;
        var cos = Math.Abs(Math.Cos(radians));
        var sin = Math.Abs(Math.Sin(radians));
        // Round before Ceiling so right angles don't grow by a pixel from floating point noise (50.0000001 -> 51).
        var width = (int)Math.Ceiling(Math.Round(source.Width * cos + source.Height * sin, 3));
        var height = (int)Math.Ceiling(Math.Round(source.Width * sin + source.Height * cos, 3));

        return Draw(width, height, canvas =>
        {
            canvas.Translate(width / 2f, height / 2f);
            canvas.RotateDegrees((float)degrees);
            canvas.DrawBitmap(source, -source.Width / 2f, -source.Height / 2f, RotateSampling);
        });
    }

    /// <summary>Same as ImageSharp: a 0 dimension is derived from the other one, keeping the aspect ratio.</summary>
    private static SKSizeI TargetSize(SKBitmap source, int width, int height)
    {
        if (width == 0 && height > 0)
        {
            width = Math.Max(1, (int)MathF.Round(source.Width * height / (float)source.Height));
        }

        if (height == 0 && width > 0)
        {
            height = Math.Max(1, (int)MathF.Round(source.Height * width / (float)source.Width));
        }

        if (width <= 0 || height <= 0)
        {
            throw new ArgumentOutOfRangeException(nameof(width), $"Invalid target size {width}x{height}.");
        }

        return new SKSizeI(width, height);
    }

    /// <summary>Parses ImageSharp-style hex colors (#RGB, #RGBA, #RRGGBB, #RRGGBBAA). Empty means white.</summary>
    private static SKColor ParseColor(string value)
    {
        if (string.IsNullOrEmpty(value))
        {
            return SKColors.White;
        }

        var hex = value.TrimStart('#');
        // Skia expects the alpha first (#ARGB / #AARRGGBB).
        var argb = hex.Length switch
        {
            4 => hex[3..] + hex[..3],
            8 => hex[6..] + hex[..6],
            _ => hex,
        };

        return SKColor.TryParse(argb, out var color)
            ? color
            : throw new ArgumentException($"Invalid background color '{value}'.", nameof(value));
    }

    private static void Encode(SKBitmap image, Stream output, RenderRequest request)
    {
        using var pixmap = image.PeekPixels();
        var quality = Math.Clamp(request.Quality, 0, 100);

        var encoded = request.MimeType switch
        {
            "image/png" or "image/x-icon" =>
                pixmap.Encode(output, new SKPngEncoderOptions(SKPngEncoderFilterFlags.AllFilters, PngZLibLevel(request.Quality))),
            "image/jpg" or "image/jpe" or "image/jpeg" or "image/pjpeg" =>
                pixmap.Encode(output, new SKJpegEncoderOptions(quality)),
            "image/webp" =>
                pixmap.Encode(output, new SKWebpEncoderOptions(SKWebpEncoderCompression.Lossy, quality)),
            _ => throw new NotSupportedException($"Not supported image format [{request.MimeType}] when creating images."),
        };

        if (!encoded)
        {
            throw new InvalidOperationException($"Failed to encode image as [{request.MimeType}].");
        }
    }

    /// <summary>Same quality -> compression mapping as the default service: 100 = level 0 ... &lt;20 = level 9.</summary>
    private static int PngZLibLevel(int quality) => quality < 0 ? 6 : Math.Clamp(10 - quality / 10, 0, 9);
}

Two details that are easy to miss:

Channel order (ParseColor). ImageSharp parses #RRGGBBAA, Skia parses #AARRGGBB. Rotate the hex string before parsing, or #00FF0080 comes out as a different color.
90° rotation (Rotate). cos(90°) evaluates to 6e-17, not 0, so Math.Ceiling(50.00000000000001) gives 51 and the output gains an extra pixel. Round before taking the ceiling.

Registration

using EPiServer.ImageLibrary;
using YourSite.Business.Imaging;

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services
            .AddCmsAspNetIdentity<ApplicationUser>()
            .AddCms();

        // Replaces EPiServer.ImageLibrary.ImageSharp for thumbnails and the CMS image editor.
        services.AddSingleton<IImageService, SkiaImageService>();
    }
}

The CMS only registers a fallback IImageService when none exists (TryAddSingleton), so your implementation takes precedence. Without any registration, that fallback throws InvalidOperationException the first time it's resolved.

$ dotnet list package --include-transitive --vulnerable
The given project `Alloy` has no vulnerable packages given the current sources.

Known limitations

Skia encodes PNG, JPEG and WebP only. GIF, BMP or TIFF output throws NotSupportedException, so the image editor won't work for those formats. Thumbnails aren't affected, because the CMS always stores them as .png.
Skia can't decode TIFF, so TIFF uploads get no thumbnail. The upload itself still succeeds, because the CMS handles thumbnail errors.
Animated GIFs are flattened to the first frame.

Note: this sample is not an officially supported Optimizely package. It's provided as guidance, and you own it once it's in your solution. Test it against your own media library before you deploy.

6. Option 3: suppress the warnings

<ItemGroup>
  <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-gwg2-r3hj-4w44" />
  <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-j3p4-wp97-rph4" />
  <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-j9gm-c75j-xc9q" />
  <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-wmxv-xphr-5c9g" />
  <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-jjfr-hcj7-qf5w" />
</ItemGroup>

Suppressing only hides the warning, the vulnerability is still there. Record the decision (reason, owner, review date) wherever your team tracks accepted risks.

7. Option 4: wait for an updated package

An updated EPiServer.ImageLibrary.ImageSharp would remove the problem at the source. We can't share a timeline for that yet. If you go this route:

Watch the Optimizely release notes for a new EPiServer.ImageLibrary.ImageSharp version, or check from the command line:
```
dotnet list package --outdated --include-transitive | grep -i imagelibrary
```

Combine it with option 3 in the meantime, and add a review date so the suppression gets removed once the update ships:

<!-- TEMP: waiting for an EPiServer.ImageLibrary.ImageSharp update without the vulnerable ImageSharp.
     Review by: 2026-12-31. Owner: @team-cms -->
<NuGetAuditSuppress Include="https://github.com/advisories/GHSA-j3p4-wp97-rph4" />

If you're on option 2, moving to the official package later means deleting your IImageService implementation and its registration.

References

SixLabors/ImageSharp, 4.x license discussion: https://github.com/SixLabors/ImageSharp/issues/3205#issuecomment-6062121101
Optimizely IImageService API: https://world.optimizely.com/CsClassLibraries/cms/EPiServer.ImageLibrary.IImageService?version=12
SkiaSharp: https://github.com/mono/SkiaSharp
NuGet dependency resolution: https://learn.microsoft.com/nuget/concepts/dependency-resolution
NuGet Audit: https://learn.microsoft.com/nuget/concepts/auditing-packages
Advisories: GHSA-gwg2-r3hj-4w44, GHSA-j3p4-wp97-rph4, GHSA-j9gm-c75j-xc9q, GHSA-wmxv-xphr-5c9g, GHSA-jjfr-hcj7-qf5w

Optimizely CMS 12 on .NET 10: Fixing a Siteimprove TypeMismatchException

2026-10-09T21:58:00.0000000Z

Recently, while upgrading an Optimizely CMS 12 solution from .NET 8 to .NET 10, we encountered a frustrating exception that initially looked like a CMS...

The post Optimizely CMS 12 on .NET 10: Fixing a Siteimprove TypeMismatchException appeared first on Madhu Anbalagan's Blog.

What made Scheduled Jobs faster in Optimizely CMS 13.3.0

2026-10-09T06:00:00.0000000Z

A look under the hood at the update that made scheduled jobs faster.

New DDS explorer addon for Optimizely CMS

2026-10-08T18:27:59.0000000Z

I wanted to be able to manage Dynamic Data Store from within Optimizely CMS, so I created another addon.

Queryable or Searchable? How indexing type changes your Optimizely Graph query

2026-10-08T13:06:39.0000000Z

The Property Indexing Type on a CMS field decides whether Optimizely Graph will return it, filter it, or run full-text search on it. Default, Queryable, Searchable, and Disabled each change the GraphQL query.

Blogs

Virtual Opticon 2026: Where AI Can Improve DXP Delivery

Measure the time it takes to reach a decision

Make approved context part of the delivery process

Give Virtual Teammates a bounded job and an accountable owner

Evaluate orchestration before expanding a migration

Prepare for agents completing customer tasks

Build the business case around accepted work

About the Author

The Low-Level API Is Not Automatically Fast. Part 4: Counting Round Trips

The Migration Bugs That Actually Caught Us Out

Camp Opticon 26 (London): AI requires a different operating model

Introduction

Camp Opticon 26 (London): AI requires a different operating model

1. AI becomes a digital colleague, not just a tool

2. Content production scales, but governance becomes the real bottleneck

3. Personalisation becomes continuous, not campaign-driven

4. Your website now has a second audience: AI agents

5. The winners don't have the most AI tools, but the best operating model

From separate tools to integrated operations

Migrating ContentArea.FilteredItems in Optimizely CMS 13

Categories have landed in Optimizely SaaS CMS: structure, translate, tag and query

Where to find it

Creating a structure

Translating categories

Tagging pages with categories

Querying categories in Optimizely Graph

Querying the category tree

Localised category names

Querying content by category

No roll-up through the hierarchy

Final thoughts

Further reading

Exploring Cached Templates and Cursor Pagination in the Optimizely Graph C# SDK

1. Cached Templates: What Does Enabled by Default Mean?

Looking Inside the SDK

2. Explicitly Enabling Cached Templates with a DelegatingHandler

Custom HTTP Handler

Registering the Handler

Verifying with Fiddler

What About a Fluent WithCachedTemplate() Extension?

3. Cursor-Based Pagination: Typed vs. Untyped Queries

First Page

Next Page

Looking Inside SetCursor()

An SDK API Difference

4. Final Thoughts

References

EPiServer.ImageLibrary.ImageSharp 2.0.7 delisted from NuGet feed

Surviving a Dirty Feed. Part 3: Error Handling and Event Batching

Building UI Extensions for Optimizely SaaS CMS

Introduction

Setting Up Your Environment

Before Building Your Solution

Thinking About Data

Reviewing the Stott Security for SaaS CMS Solution

Solution Structure

Understanding the app.yml

SDKs

Backend

CmsExtension.ts

CompiledHeaders.ts

Frontend

SecurityConsole.view.tsx

App Directory Information

Application Settings

Summary

Appendix

Cheapskate AI Translator: Because Translation Should Not Require a Second Mortgage

The honest motivation

What the add-on does

The small trick that saves API calls

Why support several providers?

This is not Optimizely Language Manager

Open source is the point

Getting started

Final accounting

Computed Fields in CMS 13 Content Contracts with Optimizely Graph

1. Define a Content Contract

2. Expose the Computed Field in Graph