Blog posts by Mardy Abdelkareem

Introducing Publishing Timeline for Optimizely CMS 13

2026-11-02T09:36:42.0000000Z

When working with scheduled content in Optimizely CMS, having a clear overview of what's going live and when can be really helpful, especially when managing content across multiple languages and timezones.

Following my previous add-on for scheduling content across different timezones, I wanted to explore another part of the publishing experience: making it easier for editors to see what's coming up.

That led me to build Publishing Timeline, a free, open-source add-on for Optimizely CMS 13.

What does Publishing Timeline do?

Publishing Timeline adds a panel below the native Workflow Status gadget on the CMS Dashboard. It appears when the Scheduled tab is selected, without replacing or modifying the existing gadget.

It provides two ways to explore upcoming publications.

Table view

The table provides a list of scheduled content, including the publishing date, language, and who last modified each item. Editors can filter the results and open content directly in the CMS editor.

Publishing Timeline — Table view

Calendar view

The calendar displays scheduled publications in a monthly view, making it easier to see what's planned for a particular day or across the month. When multiple items are scheduled for the same day, the +N more option opens a popup showing additional publications and their scheduled times.

Publishing Timeline — Calendar view with additional scheduled items

Both views share the same language, date, and timezone filters, so editors can switch between them without losing their selections.

Working across timezones

One of the features I wanted to include was the ability to view scheduled publishing times in different timezones.

For example, if you're coordinating content across Cairo, London, and New York, you can switch the timeline to see when each item is scheduled to go live in the selected timezone.

This only changes how the publishing times are displayed. The actual publishing schedule remains unchanged.

Getting started

Publishing Timeline supports Optimizely CMS 13.4.0 and later (below 14.0.0) and .NET 10.

The add-on is now available on the Optimizely NuGet feed.

Install the package using the .NET CLI:

dotnet add package Mardy.Optimizely.PublishingTimeline --version 1.0.0

Make sure the Optimizely NuGet feed is configured as a package source in your project or development environment.

No additional startup configuration is required. After installation, open the CMS Dashboard and navigate to Workflow Status → Scheduled. The Publishing Timeline panel will appear below the native gadget.

The add-on is read-only and doesn't change how Optimizely schedules or publishes content.

Source code and feedback

The project is open source under the MIT license.

GitHub: Mardy.Optimizely.PublishingTimeline

NuGet package: Optimizely NuGet feed (v1.0.0)

I'd be happy to hear your feedback or ideas for future improvements!

Time Zone-Aware Scheduled Publishing in Optimizely CMS 13

2026-10-26T07:02:50.0000000Z

Scheduling content for audiences in different time zones is a common requirement, especially for websites managed by editors across multiple regions.

Optimizely CMS already supports scheduled publishing, but editors working across time zones may need to calculate the equivalent time in their own time zone before scheduling content.

For example, an editor in Cairo might want a page to go live at 5:00 PM in London. Without a target time-zone selector, the editor needs to calculate the corresponding local time, taking daylight saving time changes into account.

To simplify this workflow, I built Time Zone Publishing, a lightweight, open-source add-on for Optimizely CMS 13.

How it works

The add-on introduces a new Schedule Publish by Time Zone command alongside the existing scheduling option in the CMS Publish menu.

Figure 1: The new scheduling command in the native CMS Publish menu.

Editors can access the feature directly from the familiar publishing interface without navigating to a separate tool.

Selecting the command opens a scheduling dialog where editors can:

Search for and select an IANA time zone.
Choose the intended publication date and time in that zone.
See the equivalent time in their browser's local time zone.
Confirm the schedule using the existing CMS publishing mechanism.

Figure 2: Scheduling publication in London with a local-time preview for Cairo.

In this example, the page is scheduled for October 30, 2026, at 5:00 PM in London, which corresponds to 7:00 PM in Cairo.

Once the editor confirms the schedule, the add-on converts the selected local date and time to UTC and uses the native CMS scheduled publishing functionality.

This keeps the scheduling workflow aligned with the platform rather than introducing a separate background job or publishing service.

Handling daylight saving time

One important consideration when scheduling across time zones is daylight saving time (DST).

During DST transitions, certain local times may be:

Nonexistent: When clocks move forward and skip a period of time.
Ambiguous: When clocks move backward and a local time occurs twice.

The add-on validates both scenarios and prevents editors from confirming a schedule with an invalid or ambiguous local time.

Key features

Schedule publishing using a selected target time zone.
Searchable IANA time-zone selection.
Automatic conversion to UTC.
Preview of the equivalent browser-local time.
Validation of daylight saving time transitions.
Integration with the native CMS Publish menu.
No additional scheduling service or background job required.

Compatibility and installation

Time Zone Publishing v0.1.1 targets .NET 10 and supports Optimizely CMS 13.0.0 or later. The add-on has been successfully tested with CMS 13.0.0 and 13.4.0.

The add-on is available on the Optimizely NuGet feed and can be installed directly into an existing CMS 13 application.

Installation:

dotnet add package Mardy.Optimizely.TimeZonePublishing --version 0.1.1

Source code

GitHub: Optimizely.TimeZonePublishing

NuGet package: Optimizely NuGet feed

Note: The add-on is designed for CMS 13 and is not intended for direct installation into CMS 12 applications.

Feedback, suggestions, and contributions are welcome.

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

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

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.

Blog posts by Mardy Abdelkareem

Introducing Publishing Timeline for Optimizely CMS 13

What does Publishing Timeline do?

Table view

Calendar view

Working across timezones

Getting started

Source code and feedback

Time Zone-Aware Scheduled Publishing in Optimizely CMS 13

How it works

Handling daylight saving time

Key features

Compatibility and installation

Source code

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

Computed Fields in CMS 13 Content Contracts with Optimizely Graph

1. Define a Content Contract

2. Expose the Computed Field in Graph

3. Query It with the Graph C# SDK

Key Takeaway

References

Setting Up an Optimizely CMS 13 MCP Server Locally with Codex

Configure the MCP Server

Configure Client-Secret Authentication

Connect Codex in VS Code

Verify the Integration

Create Content Using Codex

Troubleshooting Content Permissions

Conclusion