UMB.FYI Firehose - News

uTPro.Feature.GeoLocation

Sat, 05 Sep 2026 00:00:00 Z

IP-based geolocation for Umbraco sites. Detects visitor country via CDN headers (Cloudflare CF-IPCountry, AWS CloudFront-Viewer-Country, Azure Front Door X-Azure-ClientIP) with an offline MMDB fallback (iplocate.io). Resolves country codes to .NET CultureInfo for seamless multi-language switching. Pluggable provider chain, Umbraco middleware integration, and configurable culture mapping.

Umbraco.Community.Automate.Salesforce

Fri, 04 Sep 2026 00:00:00 Z

Salesforce connection and actions for Umbraco Automate

Rebuilding our Umbraco Website - Part 1

Tue, 01 Sep 2026 00:00:00 Z

Umbraco CSP Nonces with Output Caching

Tue, 01 Sep 2026 00:00:00 Z

Cache a page containing a CSP nonce and every later visitor gets a stale nonce that no longer matches their header, so the browser blocks the lot. Most advice says pick one. Here is how to have both.

Umbraco 17 Output Caching

Tue, 01 Sep 2026 00:00:00 Z

Umbraco-Sicherheit: Praxisleitfaden zum Schutz Ihres CMS

Mon, 31 Aug 2026 16:05:57 Z

Umbraco gehört zu den weltweit führenden Open-Source-Enterprise-CMS auf .NET-Basis und bietet standardmäßig eine extrem stabile…

Continue reading on Medium »

Limbo.Umbraco.BorgerDk 17.0.0-alpha001

Mon, 31 Aug 2026 13:42:48 Z

Umbraco package for integrating with the Borger.dk web service.

Umbraco 2-way relations - Umbraco Features You Didn't Know You Needed

Mon, 31 Aug 2026 09:47:52 Z

Relations in Umbraco: asking the question your picker can't answer

You've probably used a Content Picker (or a Multinode Treepicker) to wire content together. A page picks a banner, a landing page picks a set of related articles, a policy picks the older policy it replaces. That gives you one direction for free: open the page, and you can see exactly what it points at.

But pickers only answer one question. "What does this page use?" is easy. "What uses this?" is not. The picker property lives on the node that did the picking, not on the node that got picked. If you want to go the other way, your only option is make the pages hierarchical or to loop over every piece of content in the tree and check whether its picker field happens to mention the node you care about.

That's exactly the gap Umbraco's Relations are for. A Relation is a first-class, queryable link between two entities that you can walk in either direction via IRelationService: GetByParentId for "what does this point at", GetByChildId for "what points at this". This post walks through a small example project that uses a Relation to answer a question a picker alone can't.

The scenario: policies that supersede each other

Imagine a "Policy Page" doctype. Editors write a new policy, and pick (via a normal Multinode Treepicker) which older policy or policies it supersedes. That's a completely standard one-way relationship: new policy → picks → old policy.

The picker answers "which policies does this one supersede" perfectly well. What it can't answer is the question an editor actually asks when they land on an old policy page: "Has this been superseded, and by what?" Nothing on that old policy's own data points back to the newer one — the pick lives entirely on the other node. Short of scanning every Policy Page in the site for one whose supersedes field happens to mention this node's ID, there's no way to answer it.

Why not just use Umbraco's built-in "Related Document" relation?

Umbraco ships a built-in relation type for exactly this kind of document-to-document link, aliased umbDocument. It would technically work — except it's a single shared, undifferentiated bucket. Anything in Umbraco (media picker usages, link pickers, whatever else) can write a generic document-to-document reference into it, so a reverse lookup on umbDocument can't reliably tell you "which policy superseded this one" versus any other unrelated reference someone else recorded into the same bucket.

The fix is a relation type of your own policySupersedes so a reverse lookup on that alias only ever returns the thing you actually care about.

The implementation

The example lives in four files.

1. The doctype and the picker. Add a "Policy Page" content type with a bodyText richtext property and a supersedes Multinode Treepicker, filtered so it can only pick other Policy Pages.

This is the plain, one-way picker. Nothing special yet.

2. Syncing the picker into a Relation. PolicySupersedesRelationSyncHandler listens for ContentSavedNotification. Every time a Policy Page is saved, it wipes out whatever relations already exist for that node under the policySupersedes alias and rebuilds them from whatever's currently picked:

    public void Handle(ContentSavedNotification notification)
    {
        foreach (IContent content in notification.SavedEntities)
        {
            if (content.ContentType.Alias == PolicyPageContentTypeAlias)
            {
                SyncSupersedesRelations(content);
            }
        }
    }

    private void SyncSupersedesRelations(IContent newPolicy)
    {
        IRelationType relationType = _relationService.GetRelationTypeByAlias(ExampleConstants.RelationTypeAlias)
            ?? CreateRelationType();

        foreach (IRelation existingRelation in _relationService.GetByParentId(newPolicy.Id, ExampleConstants.RelationTypeAlias))
        {
            _relationService.Delete(existingRelation);
        }

        foreach (int supersededPolicyId in GetPickedContentIds(newPolicy))
        {
            var relation = new Relation(newPolicy.Id, supersededPolicyId, relationType)
            {
                Comment = $"Marked as superseded on {DateTime.UtcNow:u}",
            };
            _relationService.Save(relation);
        }
    }

As shown above, you can also add a comment to a relation, which we use to store additional information on when the policy was superseded in our example, which can then be shown again on the Policy page.

The relation type itself is created on demand as non-bidirectional, Document-to-Document, and importantly isDependency: true:

    private IRelationType CreateRelationType()
    {
        var relationType = new RelationType(
            "Policy Supersedes",
            ExampleConstants.RelationTypeAlias,
            isBidrectional: false,
            parentObjectType: Constants.ObjectTypes.Document,
            childObjectType: Constants.ObjectTypes.Document,
            isDependency: true,
            key: null);
        _relationService.Save(relationType);
        return relationType;
    }

3. Wiring it up. Add the notification handler with the standard IComposer boilerplate, nothing Relations-specific.

4. Reading both directions in the view. This is where the payoff shows up. policyPage.cshtml reads the picker property directly for the forward direction, and calls RelationService.GetByChildId for the reverse direction, the direction the picker alone could never give you:

var supersededByRelations = RelationService.GetByChildId(Model.Id, ExampleConstants.RelationTypeAlias);

@if (supersededByRelations.Any())
{
    <div style="border: 2px solid red; padding: 1em; margin-bottom: 1em;">
        <strong>This policy has been superseded.</strong>
        <ul>
            @foreach (var relation in supersededByRelations)
            {
                var newerPolicy = ContentQuery.Content(relation.ParentId);
                if (newerPolicy is not null)
                    {
                        <li>
                            Replaced by <a href="@newerPolicy.Url()">@newerPolicy.Name</a>
                            <br />
                            <small>@relation.Comment</small>
                        </li>
                    }
            }
        </ul>
    </div>
}

Open an old policy that's been superseded, and the page now knows it without ever scanning the rest of the tree.

The other payoff: you can't delete a still-referenced policy without a warning

Setting IsDependency = true on the relation type isn't just documentation, it plugs straight into Umbraco's own dependency checks. Try to delete or unpublish a policy that's still marked as superseded by another one, and the backoffice will warn you it's in use, the same way it would for a media item still referenced by a Content Picker elsewhere.

This is the practical version of "what if you need to delete a shared component, but three pages still reference it": with a plain picker, deleting the referenced item is silent and the reference just breaks. With a proper Relation, Umbraco already knows something depends on it and stops you.

When to reach for this

A picker is enough when you only ever need to ask "what does this content point at", the normal, forward direction.
The built-in "Related Document" relation is fine for generic, low-stakes cross-references where you don't care about precision on the reverse lookup.
A custom relation type is worth the extra notification-handler code when you need a reverse lookup you can trust "what points at me" and/or you want deletion/unpublish safety for content that's still depended on.

Responsive image markup for Umbraco, driven entirely by configuration. Define breakpoint rule sets once in appsettings.json, then render them anywhere with a tag helper or from Razor: picture elements with per-breakpoint art direction, img tags with srcset and sizes, and responsive CSS background images with focal-point-aware background-position. Every crop is anchored on the focal point the editor set in the back office. That is the part a CDN cannot do for you: an edge resizer has to guess where the subject of an image is, while Umbraco already knows, because someone chose it. Faces stay in frame at every breakpoint. Lazy loading is native browser lazy loading plus inline LQIP (Low-Quality Image Placeholder) blur-ups generated at render time, so there is no runtime JavaScript dependency at all: no lazysizes, no bundler, nothing extra to ship. Above-the-fold images can instead be marked to load eagerly at high fetch priority, and they register preload hints that a single tag helper emits in your layout head, which is what actually moves your Largest Contentful Paint. A strict Content Security Policy is supported first class: pass a nonce and the placeholder styles and scripts are emitted as nonce-tagged blocks instead of inline attributes. Rendered markup and resolved rule sets are cached, and the cache is invalidated automatically when content or media changes, including through the cache refreshers that reach every node in a load-balanced setup. Optionally, hand the resizing off to the edge: point a rule set at Cloudflare Image Transformations and the package composes Cloudflare image URLs, focal point and all, instead of asking your origin to crop. Optional CDN cache purging drops replaced images from the edge when an editor saves new media. Both are off by default. The package ships a JSON schema for full appsettings IntelliSense and auto-registers through an Umbraco composer, so installing it and adding one addTagHelper line is the whole setup.

Tue, 25 Aug 2026 00:00:00 Z

Adds newest-first ordering and Name, Upload Date, and File Size sorting to the Umbraco Media Library.

Esatto.Umbraco.Backoffice.CookieBanner

Mon, 24 Aug 2026 00:00:00 Z

Turnkey GDPR/ePrivacy cookie consent for Umbraco 17 & 18. A blocking consent dialog, per-category gating of scripts and embeds through the and tag helpers, Google Consent Mode v2 signalling, an editor-managed cookie registry (cookieDefinition element type plus a cookieRegistry block list) and a rendered cookie policy page. Wiring is two lines of Razor and one app.UseCookieConsent() call.

Building a Cloudflare Integration for Umbraco Automate

Sun, 23 Aug 2026 11:37:09 Z

When I first started experimenting with Umbraco Automate, I wanted to find a real-world use case instead of creating an integration just for the sake of trying the API. It didn't take long to find one. On several Umbraco projects, we use Cloudflare in front of the website. When content changes, there are situations where we want to invalidate the cached version of the affected page.

Traditionally, I would solve this in code:

Content published
      ↓
Notification handler
      ↓
Determine published URLs
      ↓
Call Cloudflare API
      ↓
Purge cache

That works. But after looking at Automate, I started wondering:

What if the application doesn't need to know anything about Cloudflare at all?

Instead, publishing content could simply trigger an automation, with small reusable actions taking care of the individual steps.

That idea eventually resulted in three NuGet packages:

Umbraco.Community.Automate
Umbraco.Community.Automate.Extensions
Umbraco.Community.Automate.Cloudflare

All currently available as version 17.0.0 for Umbraco 17.

This post describes how I got there, some of the problems I encountered, and what I learned about extending Umbraco Automate along the way.

Starting with the obvious solution

My first idea was simple. Umbraco Automate already provides a Content Published trigger, so I wanted to create a Cloudflare action that could take the published page and purge it from Cloudflare.

Something like:

Content Published
      ↓
Purge Cloudflare

The Cloudflare API itself makes this fairly straightforward.To purge specific URLs you can send a request to:

POST /client/v4/zones/{zoneId}/purge_cache

with:

{
  "files": [
    "https://www.example.com/some-page/"
  ]
}

So initially I thought the Cloudflare action could simply accept the URL of the published page.

The Content Published trigger doesn't provide a URL.

It exposes information such as:

contentKey
contentName
contentTypeKey
contentTypeAlias
cultures

And actually, that makes sense. A URL isn't necessarily a property of the publish event.

A content item doesn't necessarily have one URL

This became the first interesting part of the implementation.

Consider a multilingual Umbraco website:

https://www.example.com/
https://www.example.com/en/

Now add multiple hostnames, which is perfectly valid in an Umbraco installation:

https://www.example-a.com/
https://www.example-a.com/en/

https://www.example-b.com/
https://www.example-b.com/en/

For a single content item, asking:

What is the URL?

is therefore not always the right question.

The better question is:

What are the published URLs for this content item and culture?

That distinction ended up having quite a large influence on the package design.

Separating Umbraco from Cloudflare

My first instinct was to put the URL resolution inside the Cloudflare action.

The action could receive:

Content Key
Culture

and internally:

Resolve the Umbraco content.
Determine its URLs.
Call Cloudflare.
Purge those URLs.

But that didn't feel right.

Resolving published URLs has nothing to do with Cloudflare.

The same functionality could be useful when:

notifying an external API;
updating a search index;
sending a webhook;
invalidating another CDN;
generating a sitemap;
or building another Automate workflow.

So instead I created a generic action:

Get Published Content URLs

and moved it into a separate package:

Umbraco.Community.Automate.Extensions

Cloudflare became its own integration:

Umbraco.Community.Automate.Cloudflare

This allows Automate to do what it is good at: composing small pieces of functionality.

The workflow becomes:

Content Published
      ↓
For Each Culture
      ↓
Get Published Content URLs
      ↓
Purge Cloudflare URLs

That separation is probably the design decision I'm happiest with.

Building Get Published Content URLs

The generic action receives a content key and culture.

Its settings are roughly:

public sealed class GetPublishedContentUrlsSettings
{
    public Guid ContentKey { get; set; }

    public string Culture { get; set; } = string.Empty;
}

The output deliberately contains an array:

public sealed class GetPublishedContentUrlsOutput
{
    public Guid ContentKey { get; set; }

    public string Culture { get; set; } = string.Empty;

    public string[] Urls { get; set; } = [];
}

Notice that it's Urls, not Url.

This is important for installations where a culture is available through multiple domains.

Conceptually the action does:

Content Key + Culture
          ↓
 Umbraco published content
          ↓
 Primary + alternative URLs
          ↓
       string[]

That output can then be consumed by any other Automate action.

Lesson learned: be careful with service lifetimes

While building the action I ran into another useful lesson.

My first implementation injected IPublishedContentQuery directly into the action.

That resulted in:

Cannot consume scoped service
'Umbraco.Cms.Core.IPublishedContentQuery'
from singleton
'GetPublishedContentUrlsAction'.

Automate actions are registered as singletons, while several Umbraco services used for published content are scoped.

Injecting one directly into a singleton therefore isn't safe.

Instead, the action needs to work with the appropriate Umbraco context/service scope when resolving published content.

It's an easy mistake to make when building your first Automate extension because the action itself looks very similar to a normal service.

The important takeaway:

Always consider the lifetime of the services you inject into an Automate action.

Cultures introduced another interesting problem

The Content Published trigger exposes cultures.

Not culture.

That means a single publish operation can involve multiple cultures.

The obvious workflow is therefore:

Content Published
      ↓
For Each
      ↓
Get Published Content URLs

The collection for the loop is:

${ trigger.cultures }

And inside the loop the current culture is:

${ loop.item }

Initially I accidentally passed:

${ trigger.cultures }

directly into the action's Culture field.

That resulted in something like:

["es"]

being passed as the culture instead of:

es

and consequently:

Content '<guid>' is not published for culture '["es"]'.

The correct pattern is:

For Each:
${ trigger.cultures }

Get Published Content URLs:

Content Key:
${ trigger.contentKey }

Culture:
${ loop.item }

A small mistake, but a good example of why understanding the difference between a collection binding and the current loop item matters.

Then I wanted to purge multiple URLs at once

Initially the Cloudflare package had:

Purge Cloudflare URL

with:

public string Url { get; set; } = string.Empty;

This worked perfectly when combined with another For Each:

Get Published Content URLs
      ↓
For Each URL
      ↓
Purge Cloudflare URL

But Cloudflare already accepts multiple URLs in one request.

So why make one HTTP request per URL?

I changed the action to:

Purge Cloudflare URLs

and the Cloudflare client now accepts a collection:

Task PurgeUrlsAsync(
    string apiToken,
    string zoneId,
    IEnumerable<string> urls,
    CancellationToken cancellationToken = default);

The resulting request can contain all URLs:

{
  "files": [
    "https://www.example-a.com/en/",
    "https://www.example-b.com/en/"
  ]
}

This makes the workflow much nicer:

Get Published Content URLs
      ↓
Purge Cloudflare URLs

At least, that was the idea.

And then I learned something interesting about Automate bindings.

Binding an array isn't the same as binding a string

My first settings model looked perfectly reasonable:

public sealed class PurgeUrlsSettings
{
    public string[] Urls { get; set; } = [];
}

The previous action already returned:

string[] Urls

so I expected this binding to work:

${ previous.urls }

Instead Automate failed before the action was even executed:

Failed to resolve model 'community.cloudflare.purgeUrls'
to type PurgeUrlsSettings.

The JSON value could not be converted to System.String[].

That was confusing at first because the source value really was a string[].

The important detail is how action settings are stored.

The binding itself is initially represented as:

{
  "urls": "${ previous.urls }"
}

That's a string expression.

If the property is already declared as string[], JSON deserialization needs to happen before that expression can resolve to its collection value.

So:

"${ previous.urls }"
        ↓
Deserialize as string[]
        ↓
💥

Looking at For Each provided the answer

The interesting thing was that this already worked:

Get Published Content URLs
      ↓
For Each

Collection:
${ previous.urls }

So Automate clearly could consume my array.

That led me into the Automate source code.

The built-in For Each doesn't define its collection setting as an array.

Instead, conceptually it does this:

public string Collection { get; set; } = string.Empty;

The setting contains the binding expression, not the resolved collection.

The expression is evaluated later at runtime.

That same approach works nicely for the Cloudflare action.

The setting can remain:

public sealed class PurgeUrlsSettings
{
    public string Urls { get; set; } = string.Empty;
}

and the configured value remains:

${ previous.urls }

At runtime, Automate's BindingEvaluator can evaluate the raw expression:

var value = _bindingEvaluator.EvaluateRaw(
    settings.Urls,
    context.BindingData
        ?? new Dictionary<string, object?>());

The action can then turn that resolved value into the collection it needs.

This was probably the most interesting technical lesson from building the package.

Sometimes the type of a configuration property shouldn't represent the type of the eventual runtime value.

In this case:

Setting
string expression
      ↓
BindingEvaluator
      ↓
runtime collection
      ↓
Cloudflare API

is a better model.

Normalizing the URLs

Before sending anything to Cloudflare, the action normalizes the collection:

urls = urls
    .Where(url => !string.IsNullOrWhiteSpace(url))
    .Select(url => url.Trim())
    .Distinct(StringComparer.OrdinalIgnoreCase)
    .ToArray();

Then it verifies that something remains:

if (urls.Length == 0)
{
    return ActionResult.Failed(
        new ArgumentException(
            "At least one URL is required."));
}

and validates the URLs:

var invalidUrl = Array.Find(
    urls,
    url => !Uri.TryCreate(
        url,
        UriKind.Absolute,
        out _));

if (invalidUrl is not null)
{
    return ActionResult.Failed(
        new ArgumentException(
            $"'{invalidUrl}' is not a valid absolute URL."));
}

Only after that does the action call Cloudflare.

Creating a reusable Cloudflare connection

I didn't want API tokens and zone IDs to be configured on every action.

Automate has a connection concept for exactly this purpose, so the Cloudflare package provides its own connection type.

The connection contains information such as:

Account ID
Zone ID
API Token

The API token can also be validated against Cloudflare.

Cloudflare provides an endpoint for checking whether a token is valid and active, which makes the connection test much more useful than simply checking whether a value was entered.

A successful response looks roughly like:

{
  "result": {
    "status": "active"
  },
  "success": true
}

This gives users feedback while configuring the connection instead of waiting for their first automation run to fail.

Keep API tokens scoped

For the Cloudflare API token, I recommend granting only the permissions required by the workflow.

For cache purging, don't use a token with unnecessary account-wide permissions.

The connection should know:

API Token
Zone ID

and the action should only perform the operation it was designed for.

It's a small detail, but integrations like these make security boundaries very visible.

The resulting packages

The experiment eventually became three packages.

Umbraco.Community.Automate

The convenience package.

Installing it brings in the complete collection:

dotnet add package Umbraco.Community.Automate

Umbraco.Community.Automate.Extensions

Generic Automate building blocks:

dotnet add package Umbraco.Community.Automate.Extensions

Currently including:

Get Published Content URLs

Umbraco.Community.Automate.Cloudflare

The Cloudflare integration:

dotnet add package Umbraco.Community.Automate.Cloudflare

Currently providing the Cloudflare connection and cache purge functionality.

The packages are versioned alongside their supported Umbraco major version, so the first stable release is:

17.0.0

for Umbraco 17.

Why I like this approach

The part I like most isn't actually the Cloudflare API integration.

Calling an HTTP API isn't particularly complicated.

The interesting part is the separation of responsibilities.

Instead of writing:

public class ContentPublishedHandler
{
    // Find content
    // Determine cultures
    // Determine domains
    // Resolve URLs
    // Read Cloudflare configuration
    // Call Cloudflare
    // Handle failures
}

we can create reusable building blocks:

Content Published
      ↓
For Each Culture
      ↓
Get Published Content URLs
      ↓
Purge Cloudflare URLs

And tomorrow somebody could build:

Content Published
      ↓
Get Published Content URLs
      ↓
Notify external service

or:

Content Published
      ↓
Get Published Content URLs
      ↓
Update search index

without changing Get Published Content URLs.

That's where I think Automate becomes really interesting.

What I learned

A few things stood out while building these packages.

Actions should do one thing

Get Published Content URLs shouldn't know Cloudflare exists.

And Purge Cloudflare URLs shouldn't need to know anything about Umbraco content.

The workflow connects them.

Model collections explicitly

A published content item can have multiple cultures, and one culture can have multiple URLs.

Designing around collections from the start avoids assumptions that only work for simple websites.

Bindings are runtime values

A binding expression such as:

${ previous.urls }

is stored as a string but may resolve to something completely different at runtime.

Looking at how Automate's own For Each implementation handles this was extremely useful.

Watch your DI lifetimes

Automate actions and Umbraco scoped services don't necessarily share the same lifetime.

Be careful when injecting services such as published-content APIs directly into actions.

Composition beats coupling

The Cloudflare use case resulted in a generic action that turned out to be useful completely independently of Cloudflare.

That's a good sign that the responsibility belongs in its own extension.

What's next?

There are plenty of directions this could go.

Cloudflare supports more than purging individual URLs, so possible future actions include:

Purge by cache tag
Purge by prefix
Purge by hostname
Purge everything

But I don't want one giant "Cloudflare action" with every possible option.

I'd rather keep each operation explicit and let Automate compose them.

The generic Extensions package also opens the door to other reusable Umbraco actions that aren't tied to a specific integration.

And that's probably what I find most interesting about Automate: once you start thinking in small triggers, actions and outputs, you quickly start seeing automation opportunities everywhere.

Try it

The packages are available on NuGet:

Umbraco.Community.Automate
Umbraco.Community.Automate.Extensions
Umbraco.Community.Automate.Cloudflare

Demonstrating an approach to migrate a site from Examine to Umbraco Search

Need Senior CMS Talent Fast? Stop Waiting Months for Recruitment.

I built a free, self-hosted PWA package for Umbraco, because the alternative bills per site

Fri, 14 Aug 2026 09:59:54 Z

There are over 900 packages on the Umbraco Marketplace.

Fri, 14 Aug 2026 00:00:00 Z

uSync serializers and handlers for Umbraco Commerce. Extends uSync so store settings — stores, currencies, countries, regions, tax classes, shipping/payment methods, order statuses, and email/print/export templates — export and import as config files, the same way uSync handles content types and the rest of the backoffice. Discounts and gift cards are supported too, opt-in.

BaryoDev.Umbraco.Pwa

Fri, 14 Aug 2026 00:00:00 Z

Turn an Umbraco site into an installable, offline-capable app, and see who installed it from the backoffice you are already signed into. Free and self-hosted: the install data lands in your own database and never leaves your server, so there is no third-party dashboard to log into and no processor to declare.

What Is Umbraco? A Complete Guide to the Open-Source CMS

Hardening against CSV Injection in Umbraco

Sun, 09 Aug 2026 16:11:52 Z

Hello, long time no blog. It has certainly been a while but I am still doing penetration testing.

Continue reading on Medium »

Umb.CacheManager

Sat, 08 Aug 2026 00:00:00 Z

A backoffice dashboard for Umbraco 17 and later that allows you to view, inspect, and clear application caches without restarting the website.

Expanding the backoffice search in Umbraco - Highlighting lesser known Umbraco features

Fri, 07 Aug 2026 12:53:14 Z

Recently, I started using Erik-Jan Westerndorp's community package "Heading". on a project. It’s one of those packages that solves a very specific problem really neatly.

In this case, the client wanted editors to be able to choose the heading level for a title on an element. So, for example, one image block might need an H2, while another might need an H3, depending on where it sits on the page.

The package worked great for that.

But, as often happens, solving one problem uncovered another.

Not long after, the client came back with a new bit of feedback:

I can’t search for the custom title I’ve added.

And honestly, my first reaction was: surely that should just work?

So I gave it a try - and they were right. The backoffice document search was only finding results based on the page name, not on values stored in custom fields.

Searching by page name returns the page
Searching by page title returns no results

The first thing I did was check the internal index — and the title field was there, so that allowed me to cross off one possible issue.

So the content was being indexed - it just wasn’t being searched by the backoffice search.

I asked a few colleagues about it, and the general feeling was that this probably wasn’t something you could change. The assumption was that Umbraco backoffice search just searches a predefined set of fields and that was that.

Still, it felt like there had to be a way.

And there is.

The Missing Piece: UmbracoTreeSearcherFields

It turns out this is already supported and documented, but it was a feature I hadn’t come across before. Since I suspect I’m not the only one, it’s worth highlighting here:

Backoffice Search - A guide to customization of Backoffice Search

That article introduced me to UmbracoTreeSearcherFields, which controls the indexed fields used by backoffice search. By replacing it with a custom implementation, you can expand the list of searchable fields.

My first attempt looked like this:

public class CustomUmbracoTreeSearcherFields(ILanguageService languageService)
    : UmbracoTreeSearcherFields(languageService), IUmbracoTreeSearcherFields
{
    public new IEnumerable<string> GetBackOfficeDocumentFields()
    {
        return new List<string>(base.GetBackOfficeFields()) { "title" };
    }
}

I restarted my environment, tried again… and it still didn’t work.

Backoffice search could still only find the page by name.

The Catch: Variant Field Names

After taking a closer look at the index, the reason became clear: the field key wasn’t simply title. Because the property had language variants, the indexed field name includes the language ISO code.

So instead of hardcoding a single field name, I updated the implementation to generate the variant field names dynamically. That also makes it more future-proof — if new languages are added later, search continues to work without any code changes.

Here’s the updated version:

public class CustomUmbracoTreeSearcherFields(ILanguageService languageService)
    : UmbracoTreeSearcherFields(languageService), IUmbracoTreeSearcherFields
{
    private static readonly string TitleAlias = PublishedModelHelper.GetModelPropertyAlias((Page x) => x.Title);

    public override IEnumerable<string> GetBackOfficeDocumentFields()
    {
        return base.GetBackOfficeDocumentFields().Concat(GetVariantFieldNames(TitleAlias));
    }

    private IEnumerable<string> GetVariantFieldNames(string alias)
        => languageService.GetAllAsync().GetAwaiter().GetResult().Select(l => $"{alias}_{l.IsoCode.ToLowerInvariant()}");
}

And with that in place, the backoffice search started returning results based on the custom title value as well.

Why I’m sharing this

Interim fix for memory issues when running Umbraco on Docker

Tue, 04 Aug 2026 13:54:00 Z

I've released a package as an interim fix for memory issues when running Umbraco on Docker with memory limits, it targets V13, V17 and V18. You can read the issue here: https://github.com/umbraco/Umbraco-CMS/issues/23556 You can grab the package here: https://www.nuget.org/packages/Umbraco.Community.Imaging.ImageSharp/1.1.0 #Umbraco #NuGet

Skrift Issue #130

Tue, 04 Aug 2026 00:00:00 Z

Featuring guest posts by Jesper Mayntzhusen on "Preparing your site and packages for load balancing" and Nathaniel Grantham-Knight on "How to build an Umbraco 17 dashboard with Vite"

Umbraco.Community.Imaging.ImageSharp

Tue, 04 Aug 2026 00:00:00 Z

Stops Umbraco sites being OOM-killed in memory-limited containers while browsing the media section. ImageSharp decodes each source image at full resolution before resizing, and concurrent thumbnail requests are not bounded, so peak memory is the number of images being processed at once multiplied by the decoded source size. This package caps both the unmanaged buffer pool ImageSharp retains between requests and how many images are processed concurrently, deriving both from the memory available to the process. It is a backport of the fix proposed for the CMS in umbraco/Umbraco-CMS#23557, for Umbraco 17 sites that need it before it ships in the product.

Thu, 30 Jul 2026 00:00:00 Z

Create high-fidelity, interactive prototypes and mock-ups in no time. Discover how to build an Umbraco backoffice design system using Claude Design.

ExamineX 10.0 for Azure Search and 7.0 for Elasticsearch released to support Umbraco 18

Wed, 29 Jul 2026 19:52:00 Z

ExamineX 10.0 for Azure Search and 7.0 for Elasticsearch released to support Umbraco 18

Why Umbraco 17 Is More Than an End-of-Life Escape

Wed, 29 Jul 2026 15:40:39 Z

Umbraco.Community.Automate.ClickUp

Wed, 29 Jul 2026 00:00:00 Z

OAuth-based ClickUp provider for Umbraco Automate.

uTPro.Feature.SEOAudit

Wed, 29 Jul 2026 00:00:00 Z

Site-wide SEO & content audit for Umbraco (16, 17, 18). Crawls every Content & Media URL (plus sitemap.xml), checks for broken links, images and resources, and audits each page: SEO (title, meta description, canonical, H1-H3, noindex/nofollow, lang), Open Graph & Twitter cards, technical SEO (HTTPS, gzip, browser caching, schema.org, viewport, favicon), content quality (word count, readability, keyword density, thin & duplicate content), a static accessibility subset and estimated carbon emissions with an A-F rating. Get a per-run health score, a per-page composite SEO score (Lighthouse-style, 0-100), issues grouped by severity and priority, orphaned-page detection, incremental scans, CSV export and a per-page detail view - all inside the backoffice. Adds a per-node SEO Audit tab in the Content and Media editors that auto-audits on open. Runs as a recurring background job (auto-discovered by uTPro Job Monitor). Server-side and SSRF-safe. Built on the framework-agnostic T4VN.Seo.Core engine.

GeoChecker.Umbraco

Wed, 29 Jul 2026 00:00:00 Z

Scores how ready your Umbraco site is to be found and cited by AI engines — llms.txt, robots.txt AI rules, sitemap, structured data and more — from a dashboard in the backoffice.

SA.Automate.QRcode

Wed, 29 Jul 2026 00:00:00 Z

QR code generation actions for Umbraco Automate, powered by QRCoder. Generate a QR code for a URL as part of an automation workflow.

First speaker announced for Dutch Umbraco Alliance Festival

Tue, 28 Jul 2026 12:19:00 Z

First speaker announced for Dutch Umbraco Alliance Festival

MGC.InstagramFeed

Tue, 28 Jul 2026 00:00:00 Z

A high-performance Razor Class Library for Umbraco 17 (.NET 10) that integrates Instagram feeds using the official Instagram Graph API (v21.0). Features automatic Umbraco dictionary item seeding through package migration, secure configuration of Instagram Access Token and User ID via Umbraco Dictionary keys, zero-config dependency injection registration through InstagramComposer, and strongly typed C# models for Instagram profile data and media items including images, reels, and carousel albums with captions, like counts, comment counts, thumbnails, media URLs, and permalinks.

Umbraco.Community.NetlifyDashboard

Tue, 28 Jul 2026 00:00:00 Z

A backoffice dashboard for Netlify: connect with a personal access token, view your last deploys and their status, and purge the Netlify CDN cache (full or by cache tag).

Security Patches for Umbraco Forms are now available

Tue, 28 Jul 2026 00:00:00 Z

A high-level security vulnerability has been identified in Umbraco Forms. A security patch for Umbraco Forms 13, 17, and 18 is out now. We highly recommend upgrading.

A reusable deploy pipeline for Umbraco Cloud

Mon, 27 Jul 2026 00:00:00 Z

Create a reusable deploy pipeline for Umbraco Cloud

UmbHost.Automate.Teamwork

Fri, 24 Jul 2026 00:00:00 Z

Teamwork Projects connection type and actions for Umbraco Automate.

UmbHost.Automate.GitHub

Fri, 24 Jul 2026 00:00:00 Z

GitHub connection type, actions, a jsonpath binding filter and an X-Hub-Signature-256 webhook authenticator for Umbraco Automate.

Security Advisory: Upcoming Security Patch for Umbraco Forms ready on July 28, 2026 at 08 AM UTC

Thu, 23 Jul 2026 00:00:00 Z

A security vulnerability has been identified in Umbraco Forms. A security patch for Umbraco Forms 13, 17, and 18 are scheduled for release on Tuesday, July 28th, 2026 at 08 AM UTC.

uSkinned Upgrade Umbraco Cloud 13 to 17

Wed, 22 Jul 2026 12:56:00 Z

Upgrade Umbraco Cloud 13 to 17 | uSkinned Site Builder 6 to 7 | Tutorial - YouTube

uSkinned Upgrade Umbraco CMS 8 to 17

Wed, 22 Jul 2026 12:56:00 Z

Upgrade Umbraco CMS 8 to 17 | uSkinned Site Builder 1 to 7 | Tutorial - YouTube

uSkinned Umbraco 17 Upgrade Video Guides

Wed, 22 Jul 2026 12:55:00 Z

Umbraco 17 Upgrade Video Guides Ready to make the move to Umbraco 17? We've got you covered. We've created two practical video guides to help you upgrade to the latest Long-Term Support (LTS) release. Whether you're running a long-standing self-hosted project or an Umbraco Cloud website, Marc walks you through the process step by step.

The Green Track to Codegarden

Wed, 22 Jul 2026 00:00:00 Z

Discover how Umbraco's Green Track travelers saved 1.5 tonnes of CO2 by taking the train to Codegarden, redefining productive and sustainable business travel.

Umbraco.Community.AI.MediaJanitor

Tue, 21 Jul 2026 00:00:00 Z

An AI Media Assistant for the Umbraco Media section. Finds images with missing alt text, generic names, or in the wrong folder and suggests a better file name, alt text, caption, and folder — you review, edit, and apply.

Umbraco.Community.LinkedPages

Tue, 21 Jul 2026 00:00:00 Z

Package Description

Umbraco.Community.HeadsUp

Tue, 21 Jul 2026 00:00:00 Z

Protects Umbraco editors against lost content when the same document is open in multiple tabs or edited by multiple users. Notifies other editors in real time when a document they have open is saved or published, lists the changed fields and offers to reload.

Umbraco.Community.AdminOnly

Tue, 21 Jul 2026 00:00:00 Z

A friendlier backoffice for non-admin editors. Hide document types, tabs and properties from everyone who isn't an administrator — without touching user groups, permissions or document type structure. Editors see only what's relevant to their work; admins keep the full picture, with a lock icon marking every hidden item. Configuration is point-and-click from a settings dashboard, so there is no code to write and nothing to recompile. Note: this is a backoffice UX layer, not server-side authorization — use Umbraco's user groups and permissions to protect sensitive data.

Umbraco.Community.IconPicker

Tue, 21 Jul 2026 00:00:00 Z

Pick SVG icons straight from your own sprite. IconPicker adds a property editor that reads any SVG sprite in your site's wwwroot folder and lets editors choose a symbol from it — no icon library to install, no duplicate assets. The icons your designer delivered are the icons your editors get.

Thu, 16 Jul 2026 00:00:00 Z

Bridges Umbraco 17 content Dictionary items into the backoffice UI localization system. After install, any `#Key` in a content-type property label (or anywhere `localize.string()` is called) resolves to the current backoffice user's culture value from the Dictionary section. Works for every existing and future dictionary key; no per-key manifest wiring.

FoxCart.Members

Thu, 16 Jul 2026 00:00:00 Z

Member area addon for FoxCart: profile management, order history, saved addresses and complete authentication flows built on Umbraco Members. Ships as a Razor Class Library with overridable Flowbite-style default views.

Top Umbraco Development Company in Pune | Associative

Wed, 15 Jul 2026 10:15:28 Z

Tue, 14 Jul 2026 00:00:00 Z

Read-and-trigger monitor for Umbraco recurring background jobs (Umbraco 16, 17, 18). Adds a Jobs dashboard under the Settings section that lists every recurring background job registered in the site, shows each job's timing parameters (period, delay, server roles), records execution telemetry the CMS does not persist natively, estimates the next run, reflects load-balancing and server-role behaviour, and lets an authorized backoffice user trigger a job on demand ("Run now"). Discovers both modern IRecurringBackgroundJob implementations and legacy RecurringHostedServiceBase jobs automatically - no per-job wiring. Read-only by default; the only write is the manual trigger, which runs off the request thread, guards against overlap, and records who initiated it.

How I upgraded Umbraco 13 to 17 in less than two hours!

Sat, 11 Jul 2026 10:19:00 Z

Flowcourier.Umbraco.AI.Agents.Translation

Sat, 11 Jul 2026 00:00:00 Z

Translate whole Umbraco pages in one click — every property, nested block content and SEO fields — using the AI provider you already configured through Umbraco AI. Every translation lands as a draft and goes through a human approval flow before anything publishes, with reviewer emails, automatic reminders and a Translation Workflow dashboard inside Umbraco's Translation section. Free for Umbraco 17.5+, including commercial production use.

Flowcourier.Umbraco.AI.Agents.Seo

Sat, 11 Jul 2026 00:00:00 Z

Improve the SEO of any Umbraco page in one click. The SEO Agent reads the open page, works out which properties are SEO and metadata fields — even when they have non-standard names — and drafts optimised meta titles, descriptions and social fields from the page's own content, using the AI provider you already configured through Umbraco AI. Every suggestion is staged into the editor for you to review, edit and Save; nothing is ever written without you. Free for Umbraco 17.5+, including commercial production use.

Migrating Umbraco 13 to Umbraco 17 on Umbraco Cloud

Fri, 10 Jul 2026 23:00:00 Z

A developer guide to upgrading an Umbraco 13 site to Umbraco 17 on Umbraco Cloud by migrating locally and deploying into a fresh Cloud project, covering the full sequence through to a low downtime go live.

Thu, 09 Jul 2026 00:00:00 Z

Providing reliable, proactive and personable freelance support for website updates, SEO, lead generation and ongoing marketing strategies.

Why We Pair Next.js with Umbraco 17 ?

Wed, 08 Jul 2026 07:49:11 Z

When building a content-driven website, there are two goals that are often in tension: give visitors a fast, modern, SEO-friendly site, and give the content team a CMS they can actually use without calling a developer every time a page needs to change.

Our answer is to split the problem in two and let each half of the stack do what it's best at:

Umbraco 17, running on .NET 10, as the content backend
Next.js 16 with React 19, running on the App Router, as the presentation layer

Here's why we made that call, and how it plays out in practice.

Two apps, one clean contract

Rather than bolting a headless CMS onto an existing site, we build the two halves as genuinely independent applications that only talk to each other over HTTP:

The Umbraco installation is the backoffice, the content types, the media library, the database. This is where content editors log in, build pages out of reusable blocks, and manage content like blog posts.
The Next.js app is a standalone frontend. It never touches the Umbraco database directly, every piece of content it renders comes from an HTTP call.

That separation is the whole point of a "headless" CMS: the people managing content and the people managing the website's code can move independently. CMS upgrades don't require a frontend deploy, and frontend releases don't require touching the CMS.

The content pipeline: Umbraco's Delivery API

Umbraco 17 ships with a Content Delivery API a built-in, versioned JSON API that exposes published content without any custom plumbing. We lean on it heavily rather than building a bespoke API from scratch, which saves real development time.

A page fetch from Next.js looks like this in practice:

GET /umbraco/delivery/api/v2/content/item/home?expand=properties[$all[properties[$all[properties[$all]]]]]

That expand parameter is doing a lot of work: pages are built by editors dragging and dropping content blocks (hero sections, feature grids, image-and-text panels, calls to action) using Umbraco's Block Grid editor, and those blocks can be nested. The expansion query lets us pull an entire page blocks inside blocks inside blocks in a single round trip instead of chasing references with follow-up requests.

On the Next.js side, a small typed fetch helper wraps every one of these calls, attaches an API key, and lets Next's own data cache handle short-lived revalidation. There's no GraphQL client, no heavyweight SDK just fetch(), TypeScript types that mirror the Umbraco content model, and a short cache window so published changes show up almost immediately without hammering the CMS on every request.

Rendering: server-rendered, block by block

Generic content pages funnel through a single catch-all route that renders server-side on each request. Instead of one big template, rendering is driven by content type: a dispatcher component looks at what kind of block came back from Umbraco a feature section, an image gallery, a testimonial, a two-column layout and hands it off to the matching React component.

The effect is that adding a new content block is mostly a two-sided change: define the element type in Umbraco, add a matching case in the renderer. Editors get a new building block to compose pages with; developers don't have to build new pages from scratch every time a new layout is needed.

Beyond the CMS defaults

The Delivery API covers page content well, but a few features need more than "fetch a page and render it":

Filtering and search. Category pages, tag pages, and "previous/next" navigation are backed by custom API endpoints that walk the content tree directly, and free-text search runs on Umbraco's built-in Lucene-based indexer rather than an external search service. That avoids standing up and paying for a separate search product just to let visitors search content.
Forms. Submissions are validated in the browser, sent through a Next.js API route, and stored by a small custom endpoint on the Umbraco side with a lightweight dashboard added to the Umbraco backoffice so the team can review submissions without leaving the CMS they already use every day.
Media handling. Images uploaded into Umbraco's media library are served through Next.js's image optimizer, so editors don't need to think about responsive image sizes or formats that's handled automatically on the way out.

What this stack gets you

Putting it together, the architecture gives:

Speed, from server rendering and Next.js's image and asset optimization
SEO control that lives with content, since page titles, descriptions, and indexing rules are authored directly in Umbraco and flow straight into page metadata no separate SEO tooling to keep in sync
A content team that isn't blocked by developers, because new pages are built from existing blocks rather than new code
A frontend that isn't blocked by the CMS release cycle, because the two halves deploy independently

Mon, 06 Jul 2026 00:00:00 Z

Gibe reflects on Codegarden 2026, covering the latest Umbraco announcements, standout sessions, community highlights, and our Package Award nomination.

New Giscus powered comments and H5YR widget!

Sat, 04 Jul 2026 19:18:36 Z

I've added a giscus powered comments, and the awesome H5YR widget, to my blog posts!

Introducing ImageSharp TrimCache for Umbraco

Fri, 03 Jul 2026 23:00:00 Z

A free Umbraco package that trims the ImageSharp.Web image cache by age on a schedule, for both the local physical cache and Azure Blob storage. Stop the media cache growing unbounded on Umbraco Cloud and self hosted sites.

Letting AI agents loose on Examine

Fri, 03 Jul 2026 17:45:20 Z

I've been maintaining Examine for a very long time now. It's the search and indexing library that sits underneath every Umbraco site, and like any project that's been around long enough, it has plenty of hot paths that could be faster, a steady trickle of issues that need triaging, and a backlog of "I'll get to that eventually" performance work that, well… I never actually get to. So a couple of months ago I thought I'd try an experiment - what if I stopped doing all of that myself and instead let a bunch of AI agents do it for me, on a schedule, while I got on with everything else? This post is about how that went. I've shipped a few releases off the back of it and some of the hot-path improvements are genuinely a bit ridiculous. So what are these "agentic workflows"? The thing I installed is GitHub Next's Agentic Workflows - a set of markdown-defined workflows that run in GitHub Actions and drive an AI agent to do actual maintenance work on your repo. They're not chat bots. They run on a schedule, they have persistent memory, they open real pull requests, and they leave the "should this ship?" decision to me. I ended up with a few of them running on Examine: Perf Improver - runs daily, hunts for performance bottlenecks, writes benchmarks to actually prove the improvement, and opens a draft PR with the before/after numbers. Efficiency Improver - its scrappier sibling, focused on the smaller allocation-and-LINQ-state-machine wins that add up over time. Daily Issue Triage - goes through untriaged issues, sets types, applies labels, spots duplicates, and leaves a tidy triage report for me. Agentic Maintenance - keeps the whole setup ticking along. Each one is just a markdown file in .github/workflows/ with a description, a schedule, some safe-outputs limits (things like "you may open at most 4 PRs per run, and they must be drafts") and a big prompt describing how to behave. That's it. The nice part is that the guardrails are declarative, so the agent can't merge its own PRs, it can't touch protected files, and it can only comment so many times per run. All of that is baked in. How it actually works day to day The bit that makes this more than a gimmick is the persistent memory. Every run, the Perf Improver reads its own notes - which build/test/benchmark commands it validated, what's on its optimisation backlog, what it worked on last time, and which suggestions I've already ticked off. Then it does a couple of tasks in a round-robin fashion so it's not endlessly poking at the same corner of the codebase. It also keeps a single rolling "Monthly Activity" issue open with a checklist of what needs my attention. So my side of it is pretty simple: the agent opens a draft PR with measured before/after numbers, I read it and run CI, and if I'm happy with it I merge. That's the whole loop. I'm the reviewer, the agent is the workhorse doing the grind I never had time for. So what did they actually get done? Over roughly the last two months, here's what these workflows actually got up to on Examine: 124 successful Perf Improver runs and 9 successful Efficiency Improver runs 20 successful Daily Issue Triage runs quietly keeping the issue tracker tidy 24 performance/efficiency PRs reviewed and merged (13 from Perf Improver, 11 from Efficiency Improver) between late May and the end of June And the bit that actually matters - three releases shipped off this work: v3.8.0, v3.9.0 and the v4.0.0-beta.7 pre-release That last point is really the whole thing. This isn't a pile of speculative branches rotting in a fork somewhere - it's code that went through my review, passed CI, and is now sitting in NuGet packages that real Umbraco sites are running. Show me the numbers Right, this is the part I actually get excited about. One of my favourite things about the Perf Improver is that its prompt tells it to only attempt improvements it can actually measure - establish a baseline first, make the change, then measure again and document both numbers. For the algorithmic hot-path stuff that means benchmarks, so along the way it built out a proper BenchmarkDotNet suite that compares the current source against the published NuGet packages (3.0.1 through 3.3.0), which means I can show you real, reproducible deltas instead of hand waving. The full-text search hot path ManagedQuery is the primary full-text search entry point in Examine - it's what runs on basically every search. The agent noticed it had no dedicated benchmark, wrote one, and then stacked up a series of small, individually measured changes: a volatile factory cache in SearchContext.GetFieldValueType, an early return in the extract-terms check, and killing off some redundant ConcurrentDictionary lookups in AddDocument. Here's the current source vs the most recent 3.3.0 release, on a 1,000-document index: Method Version Mean Allocated ManagedQueryAllFields 3.3.0 11.42 ms 1,323 KB ManagedQueryAllFields Source 2.17 ms 371 KB That's about 5.3x faster and roughly 3.6x less memory allocated on the single most travelled code path in the whole library. On the busiest thing Examine does. I'll happily take that. Building queries GroupedAnd / GroupedOr / GroupedNot are the workhorses of the query builder. A little string[] fast-path (skipping a defensive .ToArray() copy when the caller already handed it a string[]) plus some allocation trimming got this: Method Version Mean Allocated CreateQueryOnly 3.3.0 3,995 ns 8.34 KB CreateQueryOnly Source 319 ns 2.20 KB GroupedAndStringArray 3.3.0 21,377 ns 21.10 KB GroupedAndStringArray Source 16,659 ns 14.34 KB The CreateQuery() baseline dropping from 8.34 KB down to 2.2 KB is a lovely little win, and the grouped clauses are about 25% faster with a third of the allocation shaved off. Constructing a ValueSet Every single document you index goes through a ValueSet constructor. The old path allocated an intermediate dictionary and a generator state machine per field, which is exactly the kind of thing you don't notice until you're bulk indexing a big site. The agent got rid of both: Method Version Mean Allocated FromDictionary5Fields 3.3.0 1,183 ns 2,200 B FromDictionary5Fields Source 226 ns 592 B FromDictionary20Fields 3.3.0 4,007 ns 6,544 B FromDictionary20Fields Source 654 ns 1,520 B That's roughly 5-6x faster and about 4x less allocated on indexing, and when you're rebuilding the index on a large Umbraco site that adds up fast. The really nice touch is that these benchmark result tables now live in doc-comments right next to the benchmark code, so the numbers are versioned in the repo alongside the thing they measure. The agent did that bit too. Was it actually worth it? For me the thing that makes it work is the measurement. Everything comes to me as a small, focused, draft PR with the numbers attached, so I can look at it, sanity check it, run CI, and decide in a couple of minutes. It's not zero effort - I still read every change before it goes anywhere near main - but the ratio is fantastic. I'm getting a steady stream of well-measured, single-purpose performance PRs on a library I care about, on paths I'd genuinely never have found the time to optimise by hand, and I've shipped real releases because of it. For a project I maintain around everything else, that's a pretty great deal. If you maintain a repo with a backlog you never get to, especially performance work that needs benchmarks to justify it, I'd recommend giving GitHub Next's agentics a go. You can see all of it out in the open on the Examine repo - the [perf-improver] and [efficiency-improver] PRs, the benchmark suite, and the releases they fed into. And there's a nice bonus here for me too: ExamineX, my managed, cloud-hosted Examine search offering, runs on this exact same internal plumbing. So all this work the agents have been doing to tighten up Examine's query and indexing hot paths feeds straight through into ExamineX - the underlying engine gets faster and leaner, and every ExamineX site gets those wins for free without changing a thing. If you'd rather have your search running as a managed service instead of hosting Lucene indexes on your own servers, that's what ExamineX is there for. 🙂

Limbo.Umbraco.Tables 17.0.0-alpha001

Fri, 03 Jul 2026 12:56:06 Z

Limbo.Umbraco.Tables is a package for Umbraco featuring property editor for building table based content.

Umbraco London July Meetup .. the write- up

Fri, 03 Jul 2026 09:18:14 Z

Umbraco London July Meetup .. the write- up

Fri, 03 Jul 2026 09:18:14 Z

Umbraco london is trying something silly a short unprogrammed stream of useless brain fog.

Continue reading on Medium »

Creating A Safe Space for Editors to Be Wrong

Fri, 03 Jul 2026 00:00:00 Z

I spend most of my time these days working on Umbraco AI, bringing AI into the hands of content editors. So I think a lot about what actually makes...

Phases.Umbraco.ContentSearch

Fri, 03 Jul 2026 00:00:00 Z

Advanced content search for the Umbraco backoffice. Editors can search content by document type and property, view results in a sortable grid, export to CSV or Excel, and save searches for later.

UMBRAAD 2026 | Accessibility Manual Testing: Why Lived Experience Matters - Thiago Carmo

Thu, 02 Jul 2026 07:48:53 Z

Accessibility Manual Testing: Why Lived Experience Matters by Thiago Carmo UMBRAAD is a free virtual Umbraco community event packed with practical talks, live demos, and expert Q&A sessions on building a more inclusive web. Read more on https://umbraad.com

UMBRAAD 2026 | Accessibility Debt in Digital Products - Shivansh Mathur

Thu, 02 Jul 2026 07:28:49 Z

Accessibility Debt in Digital Products: What AI Fixes and What It Doesn't by Shivansh Mathur UMBRAAD is a free virtual Umbraco community event packed with practical talks, live demos, and expert Q&A sessions on building a more inclusive web. Read more on https://umbraad.com

UMBRAAD 2026 | Write Once, Reach Everyone: Accessible Writing - Corey Vilhauer

Thu, 02 Jul 2026 07:24:46 Z

Write Once, Reach Everyone: Accessible Writing and GEO Want the Same Solution by Corey Vilhauer UMBRAAD is a free virtual Umbraco community event packed with practical talks, live demos, and expert Q&A sessions on building a more inclusive web. Read more on https://umbraad.com

UMBRAAD 2026 | Why Automated Accessibility Tools Are Not Enough - Shadrack William Kyei

Thu, 02 Jul 2026 07:19:35 Z

Why Automated Accessibility Tools Are Not Enough by Shadrack William Kyei UMBRAAD is a free virtual Umbraco community event packed with practical talks, live demos, and expert Q&A sessions on building a more inclusive web. Read more on https://umbraad.com

UMBRAAD 2026 | What No One Tells You About Working in Accessibility - Danny Lancaster

Thu, 02 Jul 2026 07:16:46 Z

What No One Tells You About Working in Accessibility by Danny Lancaster UMBRAAD is a free virtual Umbraco community event packed with practical talks, live demos, and expert Q&A sessions on building a more inclusive web. Read more on https://umbraad.com

UMBRAAD 2026 | Shift Left on Accessibility: Beyond the Audit - Ramona Domen

Thu, 02 Jul 2026 07:13:10 Z

Shift Left on Accessibility: Beyond the Audit by Ramona Domen UMBRAAD is a free virtual Umbraco community event packed with practical talks, live demos, and expert Q&A sessions on building a more inclusive web. Read more on https://umbraad.com

UMBRAAD 2026 | Designing for cognition - Ellie Barrett

Thu, 02 Jul 2026 07:05:11 Z

Designing for cognition by Ellie Barrett UMBRAAD is a free virtual Umbraco community event packed with practical talks, live demos, and expert Q&A sessions on building a more inclusive web. Read more on https://umbraad.com

UMBRAAD 2026 | Automating Accessibility Audits - Jordan Smith

Thu, 02 Jul 2026 07:00:43 Z

Automating Accessibility Audits: Building a Full-Pipeline A11Y Scanning & Reporting Tool by Jordan Smith. UMBRAAD is a free virtual Umbraco community event packed with practical talks, live demos, and expert Q&A sessions on building a more inclusive web. Read more on https://umbraad.com

UMBRAAD 2026 | Accessibility starts before the software - Carl Sargunar

Thu, 02 Jul 2026 06:44:05 Z

Accessibility starts before the software: hardware, cloud tooling, LLMs and diminishing returns by Carl Sargunar. UMBRAAD is a free virtual Umbraco community event packed with practical talks, live demos, and expert Q&A sessions on building a more inclusive web. Read more on https://umbraad.com

Dutch Umbraco Alliance Festival, a new festival on september 22 in the netherlands.

Thu, 02 Jul 2026 05:29:39 Z

Dutch Umbraco Alliance Festival, a new festival on september 22 in the netherlands. We like to get a lot of people.

Ideo.Umbraco.MediaManager

Thu, 02 Jul 2026 00:00:00 Z

Safe, async media cleanup for Umbraco v17: find and remove orphaned media nodes and orphaned physical files, guarded by a deep reference scan, with dry-run preview and Recycle Bin safety.

The Agent-Ready CMS: Enable the ecosystem

Thu, 02 Jul 2026 00:00:00 Z

Learn how Umbraco’s MCP platform and software factory empower partners and clients to build agentic AI tools for a truly agent-ready CMS ecosystem.

Umbraco.Community.ImageSharp.TrimCache

Thu, 02 Jul 2026 00:00:00 Z

Scheduled, age-based trimming of the ImageSharp.Web image cache for Umbraco. Supports both the Azure Blob cache and the local physical cache, keeping the cache from growing unbounded (for example exceeding Umbraco Cloud media-storage limits). Old variants are removed in the background and regenerated on the next request. Supports Umbraco 13, 17 and 18.

How to setup Claude Design + the Umbraco UI Library

Wed, 01 Jul 2026 17:53:35 Z

Codegarden 2026 - a little late, because it gave me something to build

Wed, 01 Jul 2026 15:53:03 Z

A few weeks ago I was in Copenhagen for my first Codegarden, and one quiet thought has stuck with me since. It didn't come from a keynote. It came from the bit the keynote leaves out.

I've worked with Umbraco for years, but I'd never been to Codegarden, and I turned up without much of a fixed idea of what the two days would be. I kept that open on purpose. I wanted to take it in rather than measure it against something I'd decided in advance. What struck me most was that the value came from two places at once. The sessions were a fantastic source of inspiration; everything from keynotes to guest speakers all seemed to resonate in some way or another. The conversations in between the sessions - drifting around the event space and finding common ground with anyone and everyone - proved just as valuable. I came home more energised than I've been in a while, with a notebook full of half-formed ideas and a better feel for the community I'm part of.

But the thing I kept turning over afterwards was that bit the keynote leaves out. That's what I want to write about.

The easy half and the hard half

Every major Umbraco release gets the same treatment. A polished keynote, a clean demo, a feature that looks effortless on stage. There's plenty in 18, and which part matters most depends on what you're building. For me it's Elements: a new Library section where you manage reusable content and reference it through a new element picker. Create once, use everywhere. It's a genuinely good direction. Reusable content has lived awkwardly in the content tree for years, and Library finally gives it a proper home.

What the demos don't show you is the part I've been playing around with for the past few weeks. Taking a real Umbraco 17 site, with content pickers threaded through block lists, block grids, rich text blocks and base document properties, and getting all of it to point at the new Library without an editor ever noticing anything moved underneath them.

The feature is the easy half. The migration is the half that decides whether anyone actually uses it.

Why migration is where adoption lives

A new way of modelling content only matters if existing sites can get to it. New projects will use Library because it's there and it's the obvious choice. The much bigger pile of work is the sites already in production, built the old way, where reusable content was faked with content pickers pointing at hidden nodes because that was the best tool on offer at the time.

Upgrade conversations with clients are increasingly turning into "end of life is on the way, you need to upgrade!" but Umbraco have given us some genuinely useful new features that can turn those conversations from scaring clients away from security woes to improving their content management and supercharging their marketing activities.

There's a timing thing here. The migration path has to exist when the feature does, not three months later when the upgrade conversation has gone cold. A site that wants Library is at its most willing in the window right after release, while the appetite is fresh and the project is being planned anyway. Miss that window and you're asking someone to reopen a decision they've already made, which almost never happens.

That's the question I bring to every shiny thing on a keynote slide. Not "is this exciting", but "what's the real path from a live production site to it, and how much of that path can be made painless". The exciting idea is the easy part. The route onto it is the work.

What the package actually does

This is the problem the Library Migrator package is built to solve, and the job is less glamorous than it sounds. It moves documents from Content into Library, so the things that were always meant to be reusable end up where they belong. It swaps every content picker on the relevant types for an element picker pointed at Library, so editors keep the same workflow and have nothing new to learn. And it rewrites the stored values, which is the part that earns its keep: every value held in an old content picker is updated to reference the new elements, across block lists, block grids, rich text blocks and base document properties. One reference left behind is a broken link an editor finds at the worst possible moment.

None of that shows up in a demo, using a brand new, tailored project designed to show the feature off at its best. Yet content is the centrepiece of all CMS solutions and the value in existing content is always at the forefront of our clients' minds. Whether it's a same-platform upgrade or a complete rebuild, the question of migration always gets raised.

The Library Migrator is out now. If you're looking at an Umbraco 17 site and wondering how on earth it's going to reach 18's (or 21 if you're LTS-conscious) Library, that's exactly what it's for.

Library Migrator on Umbraco Marketplace

Library Migrator repository

Tue, 30 Jun 2026 18:17:02 Z

This site has started as an Umbraco v4.x site, and has been regularly upgraded since then, never completely rebuilt. It has been running Umbraco 13 for about 3 years now, and it is about time to upgrade to Umbraco 17.

Packages

This is the easy part. The solution contains two projects: a Core project, and a UI project. Open each .csproj file, bump TargetFramework from net8.0 to net10.0, bump Umbraco package references from 13.0.2 to 17.4.0, bump a few other packages as per NuGet's suggestions.

The excellent Breaking Changes documentation tells us to remove RazorCompileOnBuild and RazorCompileOnPublish so, let us do it. It also tells us to clean our Program class a little. Remove a .AddDeliveryApi() call, remove a .UserInstallerEndpoints() calls, that is it.

At this point, rebuilding fails.

ModelsBuilderSettings.ModelsMode used to be an enum, looks like it is now a string. Quite simple to fix. Everything that queried the IPublishedContentCache does not compile anymore, porting to IPublishedContentQuery is trivial. There is no IContentService.SaveAndPublish() anymore, apparently, and one needs to Save() then Publish().

All in all, nothing dramatic.

Some of my custom Markdown property editor and converter will not compile, I am going to comment them out for the time being.

And... it builds.

Database

Trying to boot the site fails... with a BootFailedException. A migration seems to want to delete a non-existing constraint named DF_umbracoUser_createDate. A quick Internet search shows that this happened to others as well, so something must have gone wrong with migrations at some point. Not going to troubleshoot, creating the missing constraints before upgrading is quicker:

 ALTER TABLE umbracoUser ADD CONSTRAINT DF_umbracoUser_createDate DEFAULT GETUTCDATE() FOR createDate;
 ALTER TABLE umbracoUser ADD CONSTRAINT DF_umbracoUser_updateDate  DEFAULT GETUTCDATE() FOR updateDate;

And presto... the site upgrades, boots, and I can log into the back-office.

Data Types

A range of data types are gone or have changed. And of course my custom data types are CompletelyBroken™ which is not a surprise, since the back-office UI has been entirely rebuilt.

First, native data types. Basically, go into the Data Types back-office section, and re-assign those that have issues to the proper property type. Rather simple. Weird enough, a content list datatype is throwing in the back-office, because of its orderBy value. Something a migration did not catch? Manually re-saving the datatype fixes it.

And then, I actually use two custom data types:

ZpqrtBnk.ImgFocus is an image focus data type which is an alternative to crops. It allows the user to define a rectangle that represents the "zone of interest" of an image. That zone is defined on the media itself. Next, whenever we need to render the media, we can automatically figure out the best crop based upon this zone.
ZpqrtBnk.Markdown is a custom Markdown data type that uses the back-office widget pretty much unchanged, but implements some rendering helpers for links or images.

As far as Markdown is concerned, I was using a property editor in order to support additional custom syntax. Turns out a property editor is not needed anymore, a plain IMarkdownToHtmlConverter implementation is all that is needed. So, the property editor is gone, and it is way nicer this way.

On the other hand the image focus editor needs to be completely rebuilt.

My First Property Editor

There is some nice documentation about property editors in v17, so let us follow it.

mkdir PropertyEditors
cd PropertyEditors
npm create vite@latest ZpqrtBnk.ImgFocus
# with Lit
# with TypeScript
# without Vite RollDown (but I was not proposed it)
cd ZpqrtBnk.ImgFocus
npm i && npm install -D @umbraco-cms/backoffice@17.4.0
rm -rf public/* src/*

Then,

Update vite.config.ts
Create src/zpqrtbnk-imgfocus.element.ts
Create public/umbraco-package.json

Is all it takes. OK, it takes a bit of time to figure out how to put everything together but hey, this is my very first time with the new UI. The end result is quite polished. As in, it makes way more sense than the convoluted Angular version.

In the end,

npm run build

Drops files in my site's App_Plugins and we are done. As in, it just works. I have to say the experience is quite pleasant.

Models

We are not entirely done with backend work. A few more things have changed, including the CLR type of objects returned by various data types.

What is new in Umbraco 18

The Umbraco 18 release is (and I quote) "a short and sweet release". The main attraction is the new Library section and the first version of reusable Elements.

Reusable Elements in the Library section are essentially Content nodes without rendering and routing. Other than that, they behave a lot like Content: you can create, delete, move them, and so on. That made them the perfect candidate for support in v18 of the Advanced Permissions package.

Besides Library support, the package also has a few other improvements and additions. Let's talk about them!

Library support!

The first obvious new feature is the Permissions Editor for the Library. Just like with Content, you can set permissions for a User Group using the same inheritance and scoping system as the Content Permissions Editor.

You'll notice that not every permission is applicable in every case, so N/A is displayed when a permission does not apply.

And just like with Content, the Library also has an Access Viewer where you can see the effective permissions for a User Group or an individual User.

I also added a Library Element Type Permissions Editor. Just like the Document Type Permissions Editor, you can set the insert options for Element Types for a specific User Group.

With this Permissions Editor, you can control whether a User Group can create instances of an Element Type. This acts as a filter on the "create" list in the Library. And when a User has multiple User Groups, the well-established resolver will determine the effective permissions.

Currently, because of a limitation in Umbraco, it is not yet possible to scope these permissions to a specific part of the Library tree like the Document Type Permissions Editor does.

And of course, the Element Type Permissions Editor also has an associated Access Viewer.

Redesign

Because of all these new Permissions Editors and Access Viewers, the menu became harder to read at a glance. So the main menu has been redesigned around the scope of the editor and viewer.

All editors and viewers in the menu are now called Permissions Editor and Access Viewer respectively. Their purpose is determined by the menu header they are under: Content, Document Type, Library, or Library Element Type.

In the screenshot, you'll also notice a slight redesign of the workspaces for the editors and viewers. They now look more Umbraco native and display a one-line description of what the editor or viewer is for. And when you have not selected anything yet, it will now display a much nicer view. This will also be ported back to the Umbraco 17 version.

To help or not to help

In the top-right corner of each editor or viewer, you'll also notice a "learn more" button. This button gives access to more detailed documentation. It describes what the editor or viewer is for, and it links to more generic documentation explaining the concepts.

Consider this a first version. It is already much better than nothing, but I think it can still be improved over time. This will also be ported back to the Umbraco 17 version.

Localization support!

And lastly, apart from the expanded documentation, Advanced Permissions now has localization for all languages that the Backoffice supports. Obviously, these translations are automatically generated because I am not fluent in 28 languages, so if you find an error, please let me know!

All in all, I think this is a very nice and complete release. I'm happy that Advanced Permissions can support new Umbraco features as soon as they come out.

You can find Advanced Permissions for Umbraco here:

NuGet:
https://www.nuget.org/packages/Umbraco.Community.AdvancedPermissions/

The Umbraco Marketplace:
https://marketplace.umbraco.com/package/umbraco.community.advancedpermissions

OC.Automate update

Sun, 28 Jun 2026 00:00:00 Z

OC.Automate.LinkedIn is out of beta and OC.Automate.Bluesky and OC.Automate.Mastodon are all working on Umbraco 18

umbraCoffee - Codegarden 2026 Wrapped 🌯

Fri, 26 Jun 2026 23:06:54 Z

Welcome to your monthly dose of #umbraCoffee! Your hosts - Marcin and Callum - together with their guest(s) will drive through all of the community news and happenings in the Umbraco world. So... grab a cuppa, join us LIVE and enjoy! See ya?! --- ☕ Wanna buy us a coffee/pizza/donuts? https://www.buymeacoffee.com/umbracoffee --- Topics: //ToDo:

[Breaking change]: Umbraco Search replaces existing search in Umbraco 19

Umbraco Automate Workflows

Fri, 26 Jun 2026 00:00:00 Z

Building with Claude and Umbraco: Setting Up MCP and Creating Content with AI

Thu, 25 Jun 2026 16:00:16 Z

I'll be honest, when Jason first mentioned setting up an MCP server to connect Claude to our Umbraco dev environment, I assumed it was going to be a difficult dev-heavy project that would take the day at least, and be a bit past my coding comprehension ability as a Front End Developer. I even made a new local branch assuming I was going to have to write and commit code.

Nope! It wasn't like that at all. And I'm still a little surprised about it. It was just setting up a config file in Claude and setting up API users in Umbraco.

If you're an Umbraco developer who's been curious about AI-assisted content workflows but figured the setup overhead wasn't worth it, this post is for you. I'm going to walk through exactly what I did, what tripped me up (spoiler: one small thing), and what became possible on the other side of it.

Part 1: What Is the Umbraco MCP Server, Anyway?

MCP stands for Model Context Protocol. It's an open standard that lets AI assistants like Claude connect directly to external tools and services, not just chat about them, but actually interact with them.

The Umbraco MCP server is an implementation of that standard for Umbraco. Once it's set up and connected, Claude can read and write content in your Umbraco instance through the Management API. We're talking creating pages, updating properties, working with block components, the same things you'd do in the back office, but driven by Claude. It's actually pretty amazing to see it work.

Part 2: Setting Up the MCP Server

Before anything else, a quick note on prerequisites. You'll need an Umbraco site to connect to (we're using our dev environment), and Claude Desktop or Cowork installed on your machine. That's really it on the "before you start" front, which was the first pleasant surprise.

The MCP server itself is configured through a JSON config file in Claude. Go to your Claude settings, then Developer, and click the "Edit Config" button to bring up the claude_desktop_config.json file in your favorite editor.

Note: Close Claude completely (including killing it in the taskbar) while working on the config file. If Claude is running, it will overwrite your changes when it closes.

Note: Make sure you're on the latest version of Node before you start.

Drop this into your config file, change the name as you like, change the BASE_URL to your site, and we'll cover the CLIENT_ID and SECRET in the next steps.

"mcpServers": {
  "YOUR-umbraco-dev-mcp-server": {
    "command": "npx",
    "args": [
      "@umbraco-cms/mcp-dev@latest"
    ],
    "env": {
      "UMBRACO_CLIENT_ID": "umbraco-back-office-api-user",
      "UMBRACO_CLIENT_SECRET": "12345-GUID-OR-PASSWORD-6789",
      "UMBRACO_BASE_URL": "https://your-site.io",
      "UMBRACO_INCLUDE_TOOL_COLLECTIONS": "document,media,document-type,data-type"
    }
  }
}

Part 3: Creating an API User in the Umbraco Back Office

This is the part I was most nervous about. "API user" sounds like something that involves a terminal and a lot of Googling. It does not. It's just a few clicks in the Umbraco back office and I was genuinely a little embarrassed by how straightforward it was.

Head into your Umbraco back office and navigate to the Users section. We're going to create both a new User Group and a new API user. First, the User Group. Create one and call it MCP-User-Developer and give it as much control as a developer would. If you ever wanted another group called MCP-User-Editor with less control, you can do that too. For now, add Content, Media and Settings sections and turn on everything you'd like it to have access to.

Next, go to Users and create a new API User. Name it something like "something-mcp-developer" and make it a member of the MCP-User-Developer group we just made. Add an email address for its username and check on access to start nodes (or give it full access).

Now the key step: click the Client Credentials button to add the key we'll need in the Claude config file. The ID will have a prefix of "umbraco-back-office" and then you name it whatever you want. In my example I went with "api-user", so the full ID becomes "umbraco-back-office-api-user". For the Secret, generate a GUID or secure password however you like.

Note: Once you click Create, the password won't be visible again. Save it somewhere before moving on!

Now we have all the info for the config file. Go back and add "umbraco-back-office-api-user" to the UMBRACO_CLIENT_ID and your password to the UMBRACO_CLIENT_SECRET.

Part 4: Connecting Claude to Your Umbraco Site

At this point you've got the config file set up and your API user created. The last step is getting Claude to actually recognize the connection. Save your claude_desktop_config.json file and restart Claude. Go to Settings, then Developer again, and you should see your MCP server listed there and running.

I was stuck here for a bit because I was not on the latest version of Node, and also because I had the UMBRACO_CLIENT_ID wrong. Woops! So make sure your config has all the correct info. But if everything checks out you should see a "running" label next to your server, and you're now connected!

A quick way to confirm everything is working is to just ask Claude something simple about your site. Something like "list the pages under the home node" or "what document types are available?" If Claude comes back with real data from your Umbraco instance, you're in business. As soon as it gave me the ID of the home node of our dev site, I knew things were about to get real.

Part 5: Creating Content with Claude

This is the fun part.

Once Claude is connected to your Umbraco instance, you can start asking it to do real content work. Not just drafting copy in the chat window, but actually creating and populating pages inside Umbraco. I started simple, asking Claude to create a Basic Page under the home node with a title and some body text. It did it. First try. I went and checked the back office and there it was, sitting as a draft, ready to review.

From there I started pushing it further. Our Basic Page document type has a bunch of block components available, things like Feature Boxes, Statistics, Testimonials, FAQ sections, Numbered Steps, and a Two-Column Comparison block. I described what I wanted the page to be about and asked Claude to use as many relevant components as made sense for the content. The results were genuinely impressive, well-structured pages with appropriate blocks chosen for the content, not just a wall of rich text.

A few tips from what I've learned so far:

Give Claude context about your document types. The more it knows about your block components and what fields they have, the better the output.
Keep pages as drafts first. Claude creates content as drafts by default, which is exactly what you want. Review before publishing.
Be specific about tone and content. Claude will make reasonable choices on its own, but the more direction you give it, the closer the first draft will be to what you actually want.
Watch out for placeholder content. Claude may generate fictional quotes or statistics as placeholders. Always review before anything goes live.

One small thing to be aware of: on our setup, pages created via the MCP server sometimes needed the template set manually in the back office before they'd render on the front end. It's a quick fix, just one more thing to check on your first run through.

Part 6: Real-World Use Cases

So what's this actually good for in practice? After spending some time with it, here are the use cases that have stood out most.

Spinning up draft pages quickly. If you've got a list of pages that need to exist, Claude can create and populate them fast. What might take an editor an afternoon of copying, pasting and formatting can happen in minutes. The drafts still need a human review pass, but you're starting from something solid rather than a blank page.

Consistent page structure across a site. When Claude is working from the same document type and block components every time, the output is naturally consistent. Every page gets a hero, a logical block order, appropriate use of the available components. It's a lot harder to end up with that one orphaned page that's formatted completely differently from everything else.

Exploring content strategy. This one surprised me. Being able to say "create a page making the case for upgrading Umbraco and use whichever block components make sense" and get back a fully structured draft is genuinely useful for figuring out what you actually want to say. It's a fast way to go from a topic to a first draft you can react to.

Auditing and rewriting existing content. Claude can read your existing pages too, which means you can ask it to review copy, flag inconsistencies, or suggest rewrites across multiple pages without touching the back office yourself.

Like I said, I knew things were about to get real.

We're still figuring out the best workflows ourselves at ProWorks, but it's already changing how we think about content production. I'm excited to see where it goes from here.

If you have questions or want to share what you've built with it, feel free to reach out.

Alan Ballard, Front End Developer, ProWorks

Umbraco MCP as a Platform Intoduction

Thu, 25 Jun 2026 10:11:03 Z

Phil Whittaker and Bolette Kern introduce the "Umbraco in AI" framework, showcasing how the Umbraco Management API exposes content, media, document types, and search configurations to modern AI models. This session highlights how to bridge the CMS with artificial intelligence using the Model Context Protocol (MCP) and dedicated command-line tools. Learn how to move beyond local environments using Hosted MCP servers with secure OAuth authentication, connect terminal environments directly via the new CLI tool, and use the Base MCP SDK to make custom Umbraco packages agent-ready. The talk also explores advanced architectural patterns like MCP chaining and an automated five-phase Software Factory. This video is for Umbraco package authors, digital agencies, and platform developers looking for a structured path to implement AI agents. By leveraging these official tools, development teams can eliminate manual integration plumbing and focus entirely on building custom logic, strategy, and creative experiences for clients. Key Takeaways: - Management API Core: Serves as the central translation engine, transforming structured CMS capabilities into discoverable data points that LLMs can read, reason about, and automate. - Multi-Channel Architecture: Support for Local MCP (on-machine agents), Hosted MCP (cloud remote agent access via secure user authentication), and a developer-centric CLI tool. - Marketplace Readiness: The official Base MCP SDK enables package authors to instantly convert existing OpenAPI schemas into functional MCP servers with minimal overhead. - The Five-Phase Software Factory: A command-line toolkit that handles boilerplate scaffolding, project configuration, API schema discovery, tool generation, and automated integration/evaluation testing. - Advanced MCP Chaining: Eliminates redundant manual configurations through structural orchestration patterns like proxying, delegation, and composite multi-step tools. Timeline Chapters: 00:00 - Introduction to the Umbraco in AI Strategy 00:59 - Interactive Integration Diagram Overview 01:07 - The Central Role of the Umbraco Management API 01:29 - Stage 1: The Local Developer MCP Foundation 02:10 - Stage 2: Hosted MCP and Custom ChatGPT App Setup Demo 03:24 - Native Connections via the CLI Tool and Claude Code Integration 05:08 - Unpacking the Differences: Local MCP vs. Hosted MCP vs. CLI 06:49 - Stage 3: Making Umbraco Packages Agent-Ready with the Base SDK 07:43 - Stage 4: Scaffolding a Server Using the Five-Phase Software Factory 09:57 - Stage 5: Advanced MCP Chaining (Proxying, Delegation, and Composite Tools) 11:07 - Composing Shared Capabilities Across Custom MCP Servers 11:51 - Stage 6: The New Umbraco in AI Documentation Section 12:12 - Summary: Lowering Barriers and Reducing Friction for Digital Agencies Resources and Links: Official Umbraco in AI Documentation: https://docs.umbraco.com/umbraco-in-ai Model Context Protocol (MCP) Core Concepts: https://docs.umbraco.com/umbraco-in-ai/concepts/model-context-protocol Base MCP Package Guide & Repository Info: https://docs.umbraco.com/umbraco-in-ai/mcp/base-mcp Developer MCP Server Configurations: https://docs.umbraco.com/umbraco-in-ai/mcp/cms-developer-mcp Umbraco AI strategy: www.umbraco.com/ai Umbraco Official CMS Resources: www.umbraco.com

Unboxing Umbraco 18

Thu, 25 Jun 2026 10:10:54 Z

Join us for a developer's perspective on Umbraco 18, the new Standard-Term Support release of the CMS. We discuss the new Elements feature, typed OpenAPI schemas for the Delivery API, and the move from Swashbuckle to Microsoft.AspNetCore.OpenApi. We also look at features you may have missed in recent Umbraco 17 minors, and explain the plan for Umbraco 17 - the current Long-Term Support release. Chapters: 00:00 Introduction 00:51 Releases review 02:50 A look at Elements 14:06 Typed OpenAPI schemas for the Delivery API 18:29 Moving from Swashbuckle to Microsoft.AspNetCore.OpenApi 21:10 The new login screen! 23:30 Umbraco 17 minors review 23:51 Umbraco 17.4 changes for AI 27:36 Upgrade considerations 29:21 Finding more information Related resources: Dive into the Umbraco 18 final release blog post: [URL] Visit our Umbraco 18 product page: https://umbraco.com/products/umbraco-cms/umbraco-18/ Ready to learn more? Explore the Umbraco 18 documentation: https://docs.umbraco.com/umbraco-cms Specific documentation links: Version-specific upgrade instructions: https://docs.umbraco.com/umbraco-cms/18.latest/get-started/upgrading-and-migrating/version-specific Umbraco 18 Release Candidate blog post: https://umbraco.com/blog/umbraco-18-release-candidate/ Laura's blog post on migrating away from Swashbuckle: https://dev.to/lauraneto/umbraco-18-and-openapi-a-heads-up-for-extension-developers-1k7 Filip's product update from Codegarden: https://umbraco.com/blog/umbraco-product-updatecodegarden-keynote-highlights-q2-2026/ Andy Butland's CMS Roadmap talk from Codegarden: https://www.youtube.com/watch?v=HO0BsEebTys

Clean Starter Kit v8 Released

Thu, 25 Jun 2026 08:07:26 Z

Clean Starter Kit v8 released for Umbraco 18. Explore the new element library features, block list labels workaround, and runtime migration solution for categories.

Krebil.UmbracoAzureSearch

Thu, 25 Jun 2026 00:00:00 Z

Plug Azure AI Search into Umbraco Search as a fully-featured provider: filtering, faceting, sorting, culture/segment variants, and protected content out of the box.

Umbraco 18 Release

Thu, 25 Jun 2026 00:00:00 Z

The latest Major Release of Umbraco is here: Umbraco 18. Including Phase One of Elements for reusable content management, and typed OpenAPI schemas for the Delivery API. Upgrade today

Umbraco.Community.MemberLogin

Thu, 25 Jun 2026 00:00:00 Z

Sign in to the front-end as a member from the Umbraco backoffice, with optional culture and redirect page, opening in a new tab.

I'm an Umbraco MVP for the fifth year running!

Wed, 24 Jun 2026 14:04:05 Z

Every year, Umbraco recognises the people who have gone above and beyond with their contributions to Umbraco projects and community, and I am pleased to announce that I am honoured to be renewed as an Umbraco MVP for the fifth consecutive year. To celebrate this achievement, I also wrote an article which you can read here. Thank you, Umbraco, and the Umbraco community, for their fantastic support in making this happen once more! #h5yr

Phil Whittaker, Umbraco in AI

Wed, 24 Jun 2026 11:15:38 Z

In this session from Codegarden, Phil Whittaker explores the strategic vision and practical application of Umbraco in an AI-first world. The discussion details how AI agents and Large Language Models (LLMs) interact with the CMS outside of the traditional backoffice environment using shared best practices. The presentation covers the architectural shift from a base Model Context Protocol (MCP) server to a chained MCP architecture. By reducing technical friction, developers can enable AI agents to assist directly with content modeling, site deployment, and day-to-day management tasks. This video is designed for Umbraco developers, digital agencies, and content editors looking to integrate AI orchestration into modern web development. As agentic workflows become standard, learning how to build composable AI skills and deploy deterministic workflows ensures your digital experiences remain maintainable and future-proof. Key Takeaways: - Augmentation over Automation: Focusing on how developers and AI can collaborate effectively rather than replacing human expertise. - The Open-Source Advantage: Why Umbraco's transparent architecture makes it uniquely positioned for efficient AI model training and context comprehension. - Streamlining the Pitch Phase: Using the Umbraco UI library within design tools to prototype backoffice extensions rapidly. - The MCP Software Factory: Combining deterministic CLI phases and probabilistic AI phases to scaffold, build, and test custom MCP servers. - Chained and Remote MCPs: Establishing cross-connector collaboration between external tools (like Google Drive) and Umbraco to manage content at scale. Timeline Chapters: 00:00 - Introduction to Umbraco in AI 01:40 - The Evolution of AI and Agentic Products 03:03 - Strategy for Reducing Friction with AI Agents 04:56 - Open Source as an AI Advantage 06:59 - Leveraging AI in the Product Pitch Phase 11:56 - Implementing Backoffice Extension Skills 14:33 - AI in Production: Content Modeling and Implementation 21:32 - The Role of the Community AI Team 22:23 - Building Umbraco MCP Servers via Software Factories 27:07 - Architecture of Chained MCPs 29:03 - The AI-Accelerated Editor Experience 33:14 - Practical Prompts and Cross-Connector Collaboration 36:22 - Hosting Options: Umbraco Cloud and Cloudflare Workers 38:00 - Custom Editor Workflows and Deterministic Processes 42:46 - Building for Future Capabilities and Conclusion Resources and Links Umbraco AI Initiatives & Product Pages: https://umbraco.com/products/ai/ Latest Umbraco Product Update: https://umbraco.com/blog/umbraco-product-updatecodegarden-keynote-highlights-q2-2026/ Umbraco in AI documentation: https://docs.umbraco.com/umbraco-in-ai Codegarden: https://codegarden.umbraco.com/

Validating an Umbraco 13 to 17 Upgrade with a Sitemap Audit

Wed, 24 Jun 2026 10:54:04 Z

How I used a small .NET console tool to crawl a sitemap, compare Umbraco 13 and 17 environments, and quickly find broken pages after an upgrade....

You Never Know What'll Stick

Wed, 24 Jun 2026 00:00:00 Z

On unconventional career paths, accidental dev tools, and great people. There

Lait.Umbraco.Content.DragAndDrop

Wed, 24 Jun 2026 00:00:00 Z

Drag-and-drop and keyboard reordering for the Umbraco backoffice Content tree, plus the ability to drag an item out of a collection (list view) and drop it anywhere in the content tree. Three-zone drop targets, cross-parent moves, a move-in-progress spinner and WCAG-compliant keyboard grab & place.

SA.Automate.WeatherApi

Wed, 24 Jun 2026 00:00:00 Z

WeatherAPI.com connection types and actions for Umbraco Automate. Get the current weather for a location as part of an automation workflow.

Boost Your Workflow with Umbraco 17: Developer Productivity Hacks

Tue, 23 Jun 2026 22:00:00 Z

As developers, we’re always searching for ways to get our work done faster. New frameworks roll out and promise to make us blazing fast, AI tools keep booming with talk about writing half our code, and if you’ve ever sat through a developer conference lately, you know there’s always a session on “How to be More Productive.” But after working with Umbraco since version 4, I have to be honest: those massive productivity leaps don’t really come from the shiny, new, revolutionary tools. It all comes down to friction. And not the dramatic, show-stopping kind. I mean those hundreds of tiny speed bumps scattered all over your day. A few extra clicks in the Umbraco backoffice. Rebuilding the same component again and again. Always double-checking a property alias. Waiting for your solution to spin up. Poring over a monster Razor file, desperately trying to recall where you put that chunk of markup. None of these feel like deal-breakers on their own, but stacked together? Suddenly, you’re delivering features at a crawl. What’s won me over with the latest Umbraco versions, especially Umbraco 17, is just how much more aligned the platform is with standard .NET development. It feels less like you’re wrestling with a quirky CMS and more like you’re just building .NET applications. There’s a real payoff: less fighting the system means more time solving real business problems.Over the years I’ve picked up quite a few habits that speed up Umbraco development and make it less painful—some are tied directly to Umbraco 17, while others are just hard-earned lessons from a decade of building websites. Here’s what’s helped the most for me.

Kenn Jacobsen, It's Elemental; reuse your content!

Tue, 23 Jun 2026 12:44:00 Z

Discover how upcoming updates to the Umbraco CMS introduce a dedicated, native framework for managing reusable components. This session details the architectural transition away from traditional content tree workarounds toward a structured, centralized approach that optimizes backend performance and editorial control. Learn about the native Library section and Elements feature launching with Umbraco 18, alongside an early look at the comprehensive block editor integrations scheduled for Umbraco 19. The presentation highlights how these framework changes resolve historical challenges regarding schema inflation, content routing security, and context-switching during development. Who This Video Is For: This session is designed for Umbraco developers, solution architects, and technical content editors managing complex, multi-site, or multi-tenant environments. Understanding these architectural changes ensures teams can design leaner schemas and build intuitive, decoupled component libraries for future projects. Key Takeaways: - Built on Existing Frameworks: Elements utilize familiar native systems like Models Builder and IPublishedElement, ensuring a minimal learning curve for developers. - Leaner Database Schemas: Eliminates the necessity of duplicating document types for local and global contexts, maintaining uniform rendering pipelines regardless of data origin. - Native Security and Non-Routable Architecture: Centralized elements do not generate independent URLs or templates, removing template-sniffing risks and Delivery API exposure. - Segmented Permissions: Dedicated configuration layers separate content tree permissions from library access, reducing administration overhead in tenant environments. - Strict Control Mechanisms: Content libraries remain strictly opt-in on a per-element-type basis, preventing structural clutter from baseline utility compositions. Video Chapters: 00:00 - Introduction and Welcome 00:22 - Traditional Workarounds for Reusable Content 01:29 - Editor Friction and Content Tree Workflows 02:32 - Block Structure and JSON Serialization Challenges 05:32 - Technical Friction: Routing, Delivery API, and Security 07:04 - Schema Growth and Component Rendering Complexities 08:42 - Centralizing Content: Arriving in the New Library Section 09:44 - Architectural Overview: Sourcing Elements vs Local Blocks 11:55 - Cross-Context Tracking with the Out-of-Context Link Icon 14:26 - Element Characteristics: Lifecycles, Permissions, and Multi-Tenancy 16:52 - Managing Library Control via Opt-In Configurations 17:29 - Future Scope: Consolidating Editorial Features into the Library 18:16 - Implementation Roadmap: Umbraco 18 and Umbraco 19 Updates 18:44 - Live Demo: Implementing and Configuring the Element Picker 21:48 - Managing Lifecycles, Single-Sourced Editing, and Preview Mode 28:44 - Technical Preview: Future Block Editor Integrations 34:12 - Advanced Editorial Control: Disconnecting and Transferring Sourced Elements 40:59 - Strategic Takeaways and Presentation Wrap-Up Key Resources and Links: Umbraco 18 Release Candidate: https://umbraco.com/blog/umbraco-18-release-candidate/ Umbraco CMS: https://umbraco.com/products/umbraco-cms/

Matt Brailsford, AI in Umbraco

Tue, 23 Jun 2026 09:19:15 Z

Umbraco AI Staff Engineer and Lead Developer, Matt Brailsford, goes beneath the surface of out-of-the-box copilot packages to show how developers can extend the core platform. Using a real-world podcast management system as a blueprint, this technical deep dive demonstrates how to leverage native framework architecture to build tailored client solutions. The presentation walks through practical implementations of programmatic speech-to-text execution, custom LLM profile isolation, and context layering. Matt illustrates how to inject dynamic data from background systems and empower models to run custom execution tools rather than relying on manual, hard-coded prompt strings. This video is for Umbraco backend developers, solution architects, and engineering leads looking to solve complex business requirements with generative AI. It details how to move away from rigid chat interfaces and toward resilient, goal-oriented AI agents integrated into back-office event handlers and automation pipelines. What You Will Learn: - How to orchestrate background queuing for long-running LLM tasks without blocking the content-saving process. - The method for building custom context resource types that auto-generate Umbraco back-office UI elements using C# code attributes. - How to implement custom AI Tools that give LLMs secure access to external data registries like the HubSpot API. - The architectural benefits of shifting from step-by-step prompting to goal-oriented AI Agent reasoning. - Techniques for marrying Umbraco AI with Umbraco Automate to manage custom event triggers, workflow conditioning, and token management. Chapters: 00:00 - Introduction & The Core Philosophy of Umbraco AI 01:52 - Demo Overview: Podcast Management Requirements 03:49 - Setting up a Background Queue & Loop Prevention 06:41 - Configuring Connections, LLM Profiles, and Brand Context 08:02 - Step 1: Programmatic Audio Transcription Implementation 09:47 - Step 2: Generating Episode Summaries & Show Notes 12:12 - Debugging LLM Behavior via AI Back Office Logs 14:04 - Extending Context: Building Custom Resource Types 18:16 - Always Inject vs. On-Demand Context Configurations 21:48 - Empowering LLMs via Custom AI Tools & HubSpot API 29:27 - Shifting to AI Agents for Goal-Oriented Reasoning 34:54 - Analyzing Agent Decision-Making & Conversation Logs 37:16 - Integrating Umbraco AI with Umbraco Automate 41:40 - Custom Triggers, Actions, and Automated Notifications 44:18 - Summary of Extension Points & Closing Remarks Links & Resources: Umbraco, the agent-ready CMS: https://umbraco.com/products/ai/ Umbraco AI Framework Documentation & Developer Guides: https://docs.umbraco.com/ai-in-umbraco Umbraco Automate product page: https://umbraco.com/products/add-ons/automate/ Codegarden 2026 Session Schedule & Announcements: https://codegarden.umbraco.com/

Bolette Kern, Umbraco CMS in the Age of AI

Tue, 23 Jun 2026 08:19:07 Z

Umbraco CMS Product Manager, Bolette Kern, outlines the strategic evolution of content management systems in the era of generative artificial intelligence. Rather than hard-coding trendy, rigid AI features directly into the core platform, Umbraco's architecture focuses on establishing an extensible framework built on choice, governance, and structural flexibility. This session breaks down how organizations can implement AI workflows on their own terms, utilizing localized control profiles, pre-generation data screening, and automated performance testing. It also highlights how the platform is preparing for an ecosystem where external AI agents read, write, and manage content alongside human creators. This video is for digital agency architects, enterprise development teams, content strategists, and product owners who need to design future-proof content platforms. It provides a technical blueprint for maintaining data privacy, evaluating non-deterministic LLM outputs, and managing concurrent multi-author content changes safely. What You Will Learn: - The structural risks of vendor-locked AI strategies and why platform flexibility acts as a long-term competitive advantage. - How to configure pre-generation PII guardrails using regular expressions to protect sensitive user data before it reaches external LLMs. - Methods for quality-checking non-deterministic prompt outputs using automated grading criteria and side-by-side model comparisons. - The architecture of Model Context Protocol (MCP) servers and open-source agent skills designed to guide AI assistants in writing idiomatic Umbraco code. - A first look at upcoming core CMS features for real-time editor collaboration, property-level merge resolution, and visual text differentiation within block editors. Chapters 00:00 - The Role of a CMS in an Unpredictable Future 02:04 - Umbraco's Two-Track AI Strategy Overview 03:02 - The Risks of Hard-Coding AI into the CMS Core 05:15 - Demo: Managing LLM Connections, Profiles, and Contexts 06:14 - Enforcing PII Guardrails and Content Integrity Rules 08:36 - Testing and Grading Non-Deterministic AI Prompt Performance 13:32 - Leveraging the Umbraco AI Foundation for Custom Packages 15:30 - Track 2: Interfacing with External AI Agents 17:43 - Open-Source Agent Skills for Best-Practice Code Generation 22:46 - Model Context Protocol (MCP) Platform Architecture 26:48 - Demo: Content Orchestration via the Hosted CMS Editor MCP 31:43 - Automating Content Audits with Global Updates 35:18 - Core Platform Advantages in a Code-Generation Ecosystem 38:41 - Roadmap: Property-Level Editor Collaboration & Conflict Resolution 41:44 - Integrating Visual Diff Views into the Publishing Flow Links & Resources Umbraco, the agent-ready CMS: https://umbraco.com/products/ai/the-agent-ready-cms/ Codegarden: https://codegarden.umbraco.com/

Extending Tiptap in Umbraco – a real world list example

Tue, 23 Jun 2026 07:37:36 Z

If you've spent any time migrating editors or building rich-text features, you'll know Tiptap looks great on paper but sometimes feels a little... minimal compared to what TinyMCE shipped out of the box. At ilionx we've been moving a few large sites to Umbraco 17 and bumped into the same feedback: list style options. Nothing dramatic, just the ability to pick Roman numerals, different bullet shapes, that sort of thing, but enough to make editors ask for the old behavior back.

So we wrote a small TypeScript extension that adds back list-style variants. It gets built to App_Plugins with Vite, plugs into the UmbTiptapExtensionApiBase and wires up extra toolbar menu items. The actual extension is tiny, it just adds a listStyleType attribute to the list nodes and renders it as inline CSS, but the surrounding bits (icons, toolbar menus, wiring) make the UX feel polished.

Tiptap has solid docs on extending and creating extensions, and Umbraco documents how to register a Tiptap extension, but stitching everything together took a little trial and error. Below is the extension configuration we used. It looks like a lot for a simple feature, but a fair chunk of the files are just icons and small glue code.

Let’s start with the actual extension definitions in Umbraco-package.json, where we define 4 extensions:

"extensions": [
  {
    "type": "icons",
    "alias": "My.Icons.TiptapListStyle",
    "js": "/App_Plugins/My.TiptapListStyle/list-style-icons.js"
  },
  {
    "type": "tiptapExtension",
    "alias": "My.Tiptap.ListStyle",
    "api": "/App_Plugins/My.TiptapListStyle/list-style.tiptap-api.js",
    "meta": {
      "icon": "icon-ordered-list",
      "label": "List style type",
      "group": "#tiptap_extGroup_formatting"
    }
  },
  {
    "type": "tiptapToolbarExtension",
    "kind": "menu",
    "alias": "My.Tiptap.Toolbar.OrderedList",
    "overwrites": "Umb.Tiptap.Toolbar.OrderedList",
    "api": "/App_Plugins/ My.TiptapListStyle/ordered-list-menu.tiptap-toolbar-api.js",
    "forExtensions": ["My.Tiptap.ListStyle", " My.Tiptap.OrderedList"],
    "items": [
      {
        "label": "Numbered list",
        "data": null,
        "appearance": { "icon": "icon-ordered-list" }
      },
      {
        "label": "Numbered list: i, ii, iii",
        "data": "lower-roman",
        "appearance": { "icon": "icon-list-style-lower-roman" }
      },
      // add other style definitions here
    ] 
  },
  {
    "type": "tiptapToolbarExtension",
    "kind": "menu",
    "alias": " My.Tiptap.Toolbar.BulletList",
    "overwrites": "Umb.Tiptap.Toolbar.BulletList",
    "api": "/App_Plugins/My.TiptapListStyle/bullet-list-menu.tiptap-toolbar-api.js",
    "forExtensions": ["My.Tiptap.ListStyle", "Umb.Tiptap.BulletList"],
    "items": [
      {
        "label": "Bullet list",
        "data": null,
        "appearance": { "icon": "icon-bulleted-list" }
      },
      {
        "label": "Bullet list: circle",
        "data": "circle",
        "appearance": { "icon": "icon-list-style-bullet-circle" }
      },
      // add other style definitions here
    ]
  }
]

Here’s what we register:

an icon set (a bunch of tiny SVGs showing what each list style looks like)
one Tiptap extension which carries the list-style attribute
two toolbar extensions that replace the ordered/bulleted list buttons with menus that expose the variants.

The icon set

The icons are trivial: I asked an AI to generate SVGs for different list markers and put each one in a tiny TypeScript file that exports the SVG string.

/** Ordered list with lower-roman markers (i, ii, iii). */
export default `<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-linecap="round" stroke-linejoin="round" stroke-width="1.75"><text x="1" y="7.5" font-size="4.5" fill="currentColor" stroke="none" font-family="serif" font-style="italic">i.</text><path d="M9 6h12"/><text x="1" y="13.5" font-size="4.5" fill="currentColor" stroke="none" font-family="serif" font-style="italic">ii.</text><path d="M9 12h12"/><text x="1" y="19.5" font-size="4.5" fill="currentColor" stroke="none" font-family="serif" font-style="italic">iii.</text><path d="M9 18h12"/></svg>`;

And a small registry file maps the icon names to those files:

export default [
  {
    name: 'icon-list-style-lower-roman',
    path: () => import('./icons/svg-ordered-list-lower-roman.js'),
  },
    //...
];

These images are purely to make the toolbar menus readable — a little UX polish so editors instantly recognise the option they’re picking.

The Tiptap extension

The extension itself is surprisingly compact. It adds a listStyleType attribute to the built-in orderedList and bulletList nodes and serialises it as inline list-style-type style so the HTML stays portable and renders the same in the backoffice and on the front end.

import { Extension, UmbTiptapExtensionApiBase } from '@umbraco-cms/backoffice/tiptap';

/**
 * Extends the built-in orderedList and bulletList nodes with a `listStyleType`
 * attribute that maps to the CSS `list-style-type` property.
 *
 * The attribute is serialised as an inline style so the stored HTML is portable
 * and renders correctly both in the backoffice editor and on the front end.
 */
const ListStyleExtension = Extension.create({
  name: 'listStyle',

  addGlobalAttributes() {
    return [
      {
        types: ['orderedList', 'bulletList'],
        attributes: {
          listStyleType: {
            default: null,
            parseHTML: (element) => element.style.listStyleType || null,
            renderHTML: (attributes) => {
              if (!attributes['listStyleType']) return {};
              return { style: `list-style-type: ${attributes['listStyleType']}` };
            },
          },
        },
      },
    ];
  },
});

export default class ListStyleTiptapExtensionApi extends UmbTiptapExtensionApiBase {
  constructor(...args: ConstructorParameters<typeof UmbTiptapExtensionApiBase>) {
    super(...args);
    this.getTiptapExtensions = () => [ListStyleExtension];
  }
}

That’s it, the extension maps an attribute to CSS and makes sure works in both front- and backoffice. Nothing scary.

The toolbar extensions

Because ordered and unordered lists are separate toolbar buttons, we overwrite each one with a menu that exposes the style variants. To avoid duplicating logic we put the toolbar behaviour into a single helper and import it from the two small extension files.

Each toolbar menu has to do a few things:

create a list if the selection isn’t in one
switch between ordered and bullet lists
toggle or set a specific list-style-type and reflect the active state in the menu UI.

That last bit is where the logic concentrates, the UI needs to show which style is active and allow toggling back to the default behaviour.

The per-list-type extension files look like this:

import { createListStyleMenuToolbarApi } from './list-style-menu-toolbar-api.js';

export default createListStyleMenuToolbarApi('bulletList');

And the shared toolbar helper contains the actual implementation and state logic:

import type { Editor } from '@umbraco-cms/backoffice/tiptap';
import { UmbTiptapToolbarElementApiBase } from '@umbraco-cms/backoffice/tiptap';

type ListStyleMenuItem = { data?: string | null };

function getStyleType(item?: ListStyleMenuItem): string | null | undefined {
  return item?.data;
}

function applyListStyle(
  editor: Editor,
  listType: 'orderedList' | 'bulletList',
  styleType: string,
): void {
  if (editor.isActive(listType)) {
    const currentStyle = editor.getAttributes(listType)['listStyleType'] as string | null;
    const newStyle = currentStyle === styleType ? null : styleType;
    editor.chain().focus().updateAttributes(listType, { listStyleType: newStyle }).run();
    return;
  }

  if (listType === 'orderedList') {
    editor
      .chain()
      .focus()
      .toggleOrderedList()
      .updateAttributes('orderedList', { listStyleType: styleType })
      .run();
  } else {
    editor
      .chain()
      .focus()
      .toggleBulletList()
      .updateAttributes('bulletList', { listStyleType: styleType })
      .run();
  }
}

function applyDefaultList(editor: Editor, listType: 'orderedList' | 'bulletList'): void {
  if (editor.isActive(listType)) {
    const currentStyle = editor.getAttributes(listType)['listStyleType'] as string | null;
    if (currentStyle) {
      editor.chain().focus().updateAttributes(listType, { listStyleType: null }).run();
      return;
    }
    if (listType === 'orderedList') {
      editor.chain().focus().toggleOrderedList().run();
    } else {
      editor.chain().focus().toggleBulletList().run();
    }
    return;
  }

  if (listType === 'orderedList') {
    editor.chain().focus().toggleOrderedList().run();
  } else {
    editor.chain().focus().toggleBulletList().run();
  }
}

/**
 * Toolbar menu API for ordered/bullet list buttons with list-style-type variants.
 */
export function createListStyleMenuToolbarApi(listType: 'orderedList' | 'bulletList') {
  return class extends UmbTiptapToolbarElementApiBase {
    override isActive(editor?: Editor, item?: ListStyleMenuItem): boolean {
      if (!editor) return false;

      const styleType = getStyleType(item);
      if (styleType === undefined) {
        return editor.isActive(listType);
      }

      if (styleType === null) {
        const currentStyle = editor.getAttributes(listType)['listStyleType'] as string | null;
        return editor.isActive(listType) && currentStyle === null;
      }

      return editor.isActive(listType, { listStyleType: styleType });
    }

    override execute(editor?: Editor, item?: ListStyleMenuItem): void {
      if (!editor) return;

      const styleType = getStyleType(item);
      if (styleType === undefined || styleType === null) {
        applyDefaultList(editor, listType);
        return;
      }

      applyListStyle(editor, listType, styleType);
    }
  };
}

TODO / caveats

I’m still getting comfortable with TypeScript, so this isn't a 100%-polished extension. One known quirk: clicking a custom style button after setting a style will clear the style but not fully remove the list node the way the stock ordered/bullet button does. It's a small UX edge-case and likely fixable by tweaking the toggle logic, but I haven't had time for it yet.

If you want to copy this approach, the important bits are:

expose a listStyleType attribute on the list nodes,
serialize it in a way that works in both editor and front end (inline style is the simplest)
replace the toolbar buttons with menus that set/update that attribute.

Hopefully this saves you a few hours of experimentation. The overall idea is small, but the payoff for editors is surprisingly nice.

Mon, 22 Jun 2026 00:00:00 Z

Fri, 19 Jun 2026 00:00:00 Z

AI, automation, community - Umbraco MVP Ian Grieve talks about his key takeaways from Copenhagen.

Copenhagen, Codegarden, and My First Year as an Umbraco MVP

Thu, 18 Jun 2026 17:53:16 Z

Copenhagen, Codegarden, and My First Year as an Umbraco MVP

Thu, 18 Jun 2026 11:30:00 Z

My first year as an Umbraco MVP: receiving the award at Codegarden 2026 in Copenhagen, the MVP Summit, the sessions, the people, and the moments between.

Codegarden Aftermovie 2026

Thu, 18 Jun 2026 10:39:22 Z

🐰 The Rabbit faced traffic jams, train delays, and several moments of “you’ve got to be kidding me” on the way to Codegarden. Then: Codegarden. 🍿 Hit play to see how quickly travel stress turned into community vibes, new friendships, and a reminder that Codegarden isn’t just an event. It’s a family reunion that keeps growing 🫶 And before your grandma out-plans you and claims that prime summer weekend for her 90th birthday, lock your calendar for 2027: 👵🥊 📍 Øksnehallen, Copenhagen 🏰 📅 June 9–10, 2027 🦆🇩🇰

Codegarden 2026 recap

Thu, 18 Jun 2026 00:00:00 Z

Tilbake fra København og Umbraco Codegarden 2026! 🇩🇰

Thu, 18 Jun 2026 00:00:00 Z

Noen dager fylt med faglig påfyll, gode samtaler og sterke relasjoner — det er alltid noe eget med Codegarden. Umbraco-communityet er ikke en kult, men… det er kanskje det nærmeste vi kommer …

My First Umbraco Codegarden: More Than Stickers and T-Shirts

TipTap is not broken. Your expectations are.

Mon, 15 Jun 2026 12:47:24 Z

Since the Umbraco 16 release, Umbraco ships only with the TipTap Rich Text Editor. This was unfortunately something that Umbraco was forced to do. TinyMce 7 has a license that is incompatible with the open source license of Umbraco and TinyMce 6 was going out of support. So an alternative had to be found.

Umbraco did a pretty good job at abstracting the rich text data. In Umbraco 15 both TinyMCE and TipTap were still present and exchangeable because of this abstraction. And arguably, the way you can set up your toolbars for the TipTap editor is superior to TinyMCE. But still, a new Rich Text Editor is a big change that presents real challenges.

These challenges are most obvious when looking at the Umbraco forum's tip-tap tag. Topics vary, but a few come up again and again:

Additional HTML tags getting added to the markup, like a <p> tag inside a <li>
The inability to add certain tags to TipTap, like <script> tags
The inability to add styling to an element, for instance to create a link that looks like a button

These are valid challenges, especially if you're upgrading from an existing TinyMCE setup. But this is also a good moment to ask two questions:

Why do I want the same behaviour?
And was the old behaviour actually any good to begin with?

You don't have to migrate everything at once

Before getting into that, it's worth knowing that TinyMCE is still available as a community package for Umbraco 16+. If you're in the middle of a project, dealing with a large codebase, or just not ready to rethink your Rich Text Editor setup right now, that's a valid escape hatch. Swap in the package, keep things running, and give yourself time to migrate properly.

But "later" should still be on the roadmap. The package is community maintained, not an official Umbraco product, so there are no guarantees around long-term support or compatibility with future Umbraco versions. Relying on it indefinitely carries the same risk as the situation Umbraco just came out of with TinyMCE 6.

So use it if you need to. Just don't treat it as a permanent solution.

The RTE is not a page builder

I'm not a big fan of giving editors too much freedom in a Rich Text Editor. Don't get me wrong, RTEs are great and help editors a lot. But give too much rope and things go wrong fast. My preference is for RTEs to handle the basics: adding a link, making text bold or italic, maybe a table if the frontend deals with it gracefully on mobile.

What I don't like is image placement and scaling inside an RTE. Without proper processing this is a problem for performance and mobile layouts. I also don't like HTML snippets or trying to add CSS classes to elements from within an editor. It's error prone, and if something breaks, you need HTML knowledge to fix it. That's not a realistic expectation for most editors.

So when people ask how to replicate that kind of behaviour in TipTap, I'd rather ask why they need it at all.

Stop fighting the editor, start working with Umbraco

Instead of trying to make TipTap behave like TinyMCE did, consider using the tools Umbraco already gives you.

Need a link that looks like a button? Use a block inside the Rich Text Editor. TipTap has solid block support, and Umbraco exposes this well. You get a structured piece of content with its own view, its own properties, fully typed, fully renderable. An editor picks a "Button" block, fills in the label and the link and that's it. No CSS classes, no raw HTML, no risk of someone pasting style="color:red" into a script tag three months later.

Need a pull quote, a callout, a code snippet with syntax highlighting? Same answer. Model it as a block. Render it properly. Keep the RTE itself lean.

The argument I keep hearing is that recreating all of this takes more time than just making the old thing work again. That's sometimes true in the short term. But you're building something more maintainable, more predictable and more editor-friendly.

There's another reason to think twice before pouring effort into recreating editor-specific behaviour: Umbraco has already switched its default Rich Text Editor once. It could happen again. If your implementation leans heavily on workarounds and editor-specific quirks, you're setting yourself up for the same migration pain all over again. If instead your RTE is kept lean and the complex bits live in blocks with their own models and views, a future editor switch becomes much less of an event. The RTE just renders text. Everything interesting is already abstracted away.

What about the extra markup?

The <p> inside <li> is worth addressing separately, because it looks like a bug but it isn't. TipTap is built on ProseMirror, which uses a strict document schema where every node needs to contain the right type of child node. For list items, that child is a block node and a paragraph is that block node. This is what makes editing reliable: without it, you can end up in situations where the cursor can't be placed inside a list item at all, or where deleting an item breaks unexpectedly.

This behaviour is not unique to TipTap. Any editor built on ProseMirror does the same thing, and that includes quite a few well-known ones. TinyMCE handled lists differently, but that doesn't make TinyMCE's approach the correct one.

If your frontend CSS breaks because of this, that's a one-time fix, typically just adjusting margin or display rules on li p. Once it's done, you're working with markup that is actually more structurally consistent than what TinyMCE produced.

Closing thought

A new editor is disruptive. But disruption is also a chance to reconsider decisions that were made years ago under different constraints, maybe with less knowledge of what Umbraco could do, or just because TinyMCE made it easy and easy felt like good enough.

TipTap is not TinyMCE. It's not trying to be. And once you stop expecting it to be, you might find it pushes you toward solutions that are cleaner, better structured and easier to hand off to an editor who has no idea what a DOM is.

Work with the grain of the tool, not against it.

How I Hacked the Sticker Printers at Codegarden 2026

Mon, 15 Jun 2026 10:29:21 Z

Discover how constraints sparked innovation at Codegarden 2026. I bypassed printer limitations using only my phone and creative problem-solving techniques.

New release for umbPublisher 1.5.1

Mon, 15 Jun 2026 08:43:36 Z

New release for umbPublisher 1.5.1Tags that are set in #obsidian can now be mapped to #umbraco property editor. Available on https://community.obsidian.md/plugins/umbpublisher

I attended Umbraco Codegarden 2026!

Mon, 15 Jun 2026 07:00:00 Z

Codegarden was last week in Copenhagen! I was there this time and here are my thoughts about the event. Previous time I attended was in 2023, so I will draw some comparisons to that year. It was a great experience and I left feeling generally excited and inspired.

Organization

Just like previous time, the event was very well-organized. At Codegarden, you're always well taken care of with lunch and dinner, great instructions, a little kick-off at the start of every day and a lot of spatial diversity. You always know what to expect.

I was very happy to see that the quiet area was easy to find and it was mentioned at the beginning of the event. The previous time I didn't know that such a quiet area existed and I spoke out about that. It gave me comfort that I knew where to retreat to when I needed to. Additionally, there were many places to stand or sit outside and inside. The event was also a little shorter, which made it more manageable for me.

The location was absolutely ideal for the amount of people that attended. There were many attendees (about 700 they said, if I remember correctly), but at no point did the venue feel crowded. I could always easily get to where I wanted to go, there were no long queues and there was always enough seats for all the talks at every stage.

Talks

I'll admit that, on the previous Codegarden, I had the wrong expectations for the talks. Talks are obviously aimed at specific target audiences and I don't belong to all of them. Some talks aim to inform, while others aim to inspire. Stories are not tutorials. Also, sometimes a talk doesn't teach you something new, but simply validates what you were already doing.

So it was this time too. My focus is currently shifting slightly away from coding and more towards collaboration and I am looking for inspiration on how to deliver better software faster. I specifically wanted to attend Debugging Teams: What High-Performing Developer Teams Do Differently, because it seemed relevant to me. Although I was hoping for a deep analysis in development process and teamwork strategies, I ended up learning about the importance of trust and of sharing the "what", "how" and "why" of what we do. It surely gave me something to think about.

I listened to Building Resilient Umbraco Integrations. A more tutorial-style demonstration with insightful information about what you need to think about when integrating with external services. The presentation included concrete code examples that gave concrete solutions to the presented problems. I personally already knew all of it, but it was nice to see anyway, because it confirms that I'm already doing it right.

A special mention goes to Semira Allen and Jason Wodicka with their talks Drowning in Details: Turning TechTalk Into Everyday Language and How (not) to mess up everything. Their talks were incredibly engaging and they were a joy to listen to. I had a good laugh and they were each inspiring in their own ways.

Some additional thoughts

Copenhagen: The fact that it was in Copenhagen was what made me consider it again. I am not big on traveling abroad and the trip to Odense and back was seriously daunting. Being able to get there with just the airplane made the whole trip so much better!
AI: I haven't mentioned AI in this blog. That's because I find the ethics of the application of AI at the moment very questionable. I am still working on forming a well-informed opinion. Umbraco and the community have showcased some very impressive work with AI.
Umbraco awards: In case you didn't know it yet: we were nominated for an Umbraco award for "Accessibility and Security"! Even though we didn't win the award, I believe that our submission was still the best. The winning solution had a more visible approach to accessibility, but we can show off a real certification of accessibility with end-user testimonies to back it up. The nomination is a nice validation of my team's hard work.
Umbraco in the bigger picture? Right now I am learning from people like Dave Farley, Emily Bache and Derek Comartin about better software development practices. Some of it is more about architecture and some of it is about collaboration and process. I feel like these topics deserve more attention in the Umbraco community. I need a talk named How I upgraded my mid-size web agency from feature branch and PR drag to real CI/CD. Maybe I get to give this talk myself one day, who knows.

Conclusion

It was a great event, and I'm very happy that I could be there. If it's like this again next year, then I will be eager to attend. Thank you Umbraco for everything!

Across the Himalayas and Into the Heart of Umbraco

Mon, 15 Jun 2026 00:00:00 Z

Meet Rashmita and Jasper, the founders of One Tech Nepal. Discover how they use their 100% Umbraco agency to fund IT education and libraries in remote Himalayan schools.

Esatto.Umbraco.Backoffice.SharedPreviewLink

Mon, 15 Jun 2026 00:00:00 Z

Shareable preview links for Umbraco 17. Editors mint a tokenized URL via a workspace-action button; recipients open the URL externally and see the current draft (no backoffice login). Tokens are 7-day data-protected; recipient cookie scopes preview to the specific page for 5 minutes.

OC.Automate.Mastodon

Mon, 15 Jun 2026 00:00:00 Z

Mastodon connection type and action for Umbraco Automate. Post statuses to any Mastodon instance as part of an automation workflow.

OC.Automate.Mastodon released

Mon, 15 Jun 2026 00:00:00 Z

OC.Automate.Mastodon released

Mon, 15 Jun 2026 00:00:00 Z

OC.Automate.Mastodon released

Mon, 15 Jun 2026 00:00:00 Z

Codegarden 2026: A Week in Copenhagen I Won't Forget

Sun, 14 Jun 2026 23:00:00 Z

Justin reflects on an unforgettable week at Codegarden 2026 in Copenhagen, where he was recognised as an Umbraco MVP, invited on stage during the keynote to demo his AI Log Analyser package, and won the AI Package Award.

Introducing Larsingerlogue CV-5000

Sun, 14 Jun 2026 21:24:09 Z

Or how I gave Behringer FCV100 the reference power supply it deserves to use for CV-modulation with Korg Minilogue XD

If you're here to solve the problem and don't care for a story, keep scrolling, you'll get to schematics, breadboard pictures and an ingredient list.

There's also a short video montage for the even more impatient.

This is quite a different post than I usually make, if I'm allowed to call it usually anymore at all. In any case, I've been playing the keys in a band for a couple of years and have yearned for a proper synth to supplement my (6) master keyboards. Recently I acquired my first ever analogue synthesizer. It only took 40 years for the dream to come through. I found a 15% cheaper second hand "unused" Korg Minilogue XD. But I only had damper pedals to use with it. Half the fun of synthesizers for me is varying the low pass filter cutoff. It's what gives that cool swiping, buzzing or muffled sound depending on how you "turn" it. For that I needed another type of pedal, and not just a regular one.

The Minilogue has a ton of hand-controlled potentiometer knobs we can use for a multitude of parameters, amongst others the filter cutoff. However it does not have a regular 1/4" jack slot for expression pedals like keyboards usually have. It has a damper slot, but only for CC64 on/off (sustain on and off). What we want is a full, preferably analogue, range from 0 to 100%. Expression pedals are excellent for this since they're basically pot meters you turn with your foot.

What the Minilogue comes with are two 1/8" jack "CV in" ports. So I browsed the interwebz for "CV pedal" and found a bunch of alternatives. Since I'm eyeing a Behringer Poly D come fall I thought the Behringer FCV100 V2 pedal seemed a good deal. It's advertised as a volume pedal with a CV option, including reversing polarity. So I ordered one and excitedly unpacked it while the band leader ran out to buy the last 1/8" to 1/8" cable and a 1/8" to 1/4" adapter. I'd dutifully inserted a 9V battery and optimistically hooked everything up...

Nothing!

I tried both CV inputs, both polarities, tons of options on the minilogue, but still nothing.
When I got home - I plugged a 1/8" into the input port which according to the interwebs should "power it on". Still nothing from the CV output. And yes, I had measured the voltage on the 9V battery.

Note: I have had no ambition doing electronics "right" with this project, nor writing a proper tutorial with a "right" way of doing it. This is a story about fiddling around and getting things to work. It is not a tutorial in proper electronics, in fact almost the opposite. I have not bothered to look up facts or calculated things. This means people who know their way around electronics might find this article revolting. I'm sorry. It was a way for me to brush up on how things work and get something working quickly. DIY by fiddling around until it works. Again, sorry, but hopefully other learners might be inspired to both fiddle around and learn to do the calculations. There's even a gem of an insight in the end that only hit me while writing this post. 😇

The research

According to the interwebz, someone claimed to have gotten CV output when they had plugged an unconnected 1/8" jack into input 2, but showed no proof or measurements. The next answer was someone who had done some due dilligence and measured the output. Apparently it only works with instruments that feed a reference voltage from its control voltage (CV) input in order for the pedal to vary it.

So I dug out my trusty old multimeter and started the process of dusting off the parts of my brain still remembering reading "There are no Electrons: Electronics for Earthlings" ten plus years ago. I learned about what tip, ring and sleeve (TRS) for jack plugs are, and all the other variants. Measuring DC between the tip and sleeve of the unconnected side of the cable when pressing the pedal did absolutely nothing. Measuring resistance though showed a varying impedance of 0 through 50kΩ. If I flipped between TRS and RTS mode on the pedal it seemingly reversed the resistance on the ring, but the tip stayed fixed on 50kΩ in TRS mode. In any case, after some brain clearing with ChatGPT, I could conclude that the pedal in CV mode is only a 50kΩ potmeter and does not provide any of the sweet power from the (now useless) 9V battery I had inserted.

Note: I've left the pedal in RTS mode. In order to use both and reverse polarity there's more research and a V2 to be built. See closer to the end for a short rant about the factory presets in Minilogue XD.

I figured there has to be a way to provide that power even if the synth doesn't. So after a little more chatting with ChatGPT I figured I could dig through all my old cables and adapters to find an USB cable and adapter we're not using. I should be able to "inject" it's 5V DC voltage into the jack cable instead of relying on the synth to provide it. I dug through all my treasure drawers and found an USB mini-B 4-pin (?) to USB A cable and cut off the mini-B plug to reveal the two VCC/GND cables and two data cables. I found a couple of horribly old AC USB adapters and measured the DC from both via the cable's red (VCC) and black (GND) wires. One gave 3.3V and the other gave 5V. I happily threw the overdue 3.3V one in the "to recycling" bin and rubbed my hands together over the other. (Throwing out one old device should score me at least one plus in the wife's accounting system.)

Specifications

Of course it's prudent to actually check the specs of the hardware you're trying to shove a current into. So I dug up the details in the manuals, which to be honest are both quite a tad more than averagely vague about how to connect control voltage hardware.

The Minilogue XD manual has the following gem of a CV mention:

CV IN 1 and 2 jacks (3.5 mm monaural mini-phone jack; input voltage: –5V to 5V in modulation mode, –3V to 5V in CV/gate mode)

So I figured I'm safe proceeding with my 0-5V endeavour. We are going to use it for modulation.

The FCV100 manual has a similarly brief description of it's "CV" output:

1/4" TS - unbalanced Tip: Supply volt. from unit/instr. to be controlled: Impedance: 50kOhm Ring: Slider pick-up (CV dependend on ped. position, impedance: 0-50kOhm)

There's some more specs around 2V and output impedance, but as far as I've understood that's all about the volume control feature of the pedal. I have a hard time interpreting whether that sentence says "bring your own power" or "we'll use the battery you inserted".

Having this information and some support from the [un]trusty LLM though, I pressed on to simulating the imagined setup.

Tinkering

Tinkercad is an awesome tool for budding DYIers wanting to learn or experiment with electronics. Especially if starting to experiment with arduinos or other consumer grade microcontrollers. I could safely experiment with placement of the resistors and different resistance values and until I got the desired voltage output on the simulator's multimeter.

In place of the pedal I added a regular pot meter. It has three pins which is basically a 1:1 representation of the tip, ring and sleeve on a jack plug. The middle pin is the "wiper", which I'd measured on the pedal to output a varying resistance between the ring and sleeve on the opposite end of the jack cable.
Back and forth with GPT and the multimeter for a while made me understand that the CV input on the Minilogue likely has an internal 1MΩ or larger resistor, just like a multimeter has. That's how it's able to read the voltage loss between the sides and thereby also receive the varying "control voltage" input from the pedal.

Tinkercad also sports a USB connector and all the resistors you can dream of. And that's the whole recipe for this "CV adapter". It took some time to remember my URIs (Ohm's law) and how things affect the dance of the electrons (or little green men if you prefer). To be honest I still don't really know, but fiddling and discussing with GPT got me to something that works with a fair understanding. Mr. GPT had suggested a 50 kΩ resistor between the pedal and synth, but the simulations led me to choose a 10 kΩ. Again, the learned and/or dilligent would bother to calculate why.

The ingredients for the simulation ended up as follows:

Name	Value	Description
USB Standard A	-	USB connector. It gives 5V in the simulator as expected.
Resistor A	150 Ω (several tries)	A resistor to limit the circuit current slightly from the USB output. Just to be precaucious.
Resistor B	10 kΩ	A resistor to protect and limit the current going into the synth. (We'd rather not blow it up...)
Fake CV in port	1 MΩ	A resistor representing the internal impedance of the synth's CV sensor and the tip (VCC) and sleeve (GND) of the jack plug.
Multimeter	-	A multimeter in resistance mode measuring the loss over the "fake CV in port" resistor.
Fake pedal	50 kΩ	A potentiometer representing the pedal and the tip (VCC), ring (CV out), and sleeve (GND) of the jack plug.

Here's the breadboard layout:

I'm extremely discontent with how Tinkercad figured to lay out the schematic, but in any case I suppose it is correct. Why couldn't the pot go straight to the 10k resistor? Oh well, here's it is in all it's jumbled glory:

Prototyping and building in real life

Having the simulation show thumbs up I figured I should try it in real life and do some measurements before hooking anything up to my brand new synth. For some reason Tinkercad shows a tiny explosion on the USB connector when the simulation starts, but my adapter stood the test and I suspect there might be a bug with the implementation on Tinkercad. 😇

I have both breadboards and a plethora of resistors lying around from my Arduino adventures last decade. Finding a breadboard and some resistors didn't bide much problem. They're all within arms length to my left. But this is where I started going back and forth between the breadboard and Tinkercad. Turns out real life didn't give the same measurements as the simulation. Even if I used a PSU of 5.5V instead of a USB connector. My adapter gives 5.5V, remember?

Here's a little montage of all the crocodiles holding things together.

After a while I had the right resistors to see 0-5V on the multimeter having hooked up the pedal to my shortest mangled jack-cable. I excitedly hooked up some crocodiles to the other half-jack and the breadboard, wearily shoved the plug into my synth and tried the pedal. Sucess! The LCD-display on the synth showed 0 to ... 97%??? So even if the simulator and my multimeter showed I output 5V from the pedal when 100% down the Minilogue expects more. Anyone knowledgeable with electronics will likely know why, but I merely suspect that it somehow "feels" the max input from the source is 5.5V. So it was out with the jack, out with the GND crocodile and in and out with misc initial resistors until I saw 0-100% CV input on the synth. A 150 Ω resistor turned out to be the sweet spot.

I now had proof I could build this "CV-adapter", so it was time for V1.

Assembling V1

Again from my Arduino-days I found a few circuit boards in my drawers. The smallest ones were 24x18 holes (7x3cm) - a little big. But incidentally I could spot in the corner of my eye something resembling an Arduino-case. The 7x3 board fits perfectly within, and it's a slim one just 1.5cm tall. Perfect!

On to the soldering. Not that I lacked any space, but it's always nice not having to cross wires. Enter a slightly unorthodox tool, my favorite program in the whole world: Excel. Who needs technical drawing software when you have colorable cells? I first drew up the layout on the left, but inspecting the casing I'd found I figured I'd rather flip it around. So I ended up going for the layout on the right.

I'm extremely shaky, so soldering took its time. It's somewhat of a Zen excercise I've never quite mastered. I also realized way too late (of course) that I'd been better off stretching a few more wires, but hey - it's 10 years since last time I did anything like this.

In any case, the first test with the multimeter and pedal showed a semi-constant 5.4V so I had to go back to the soldering board. A few connection tests with the trusty meter showed a lacking connection to ground from the pedal. Even with my new "computer glasses" and a magnifyer on my little helper I couldn't see that the amputated resistor leg I'd connected to ground wasn't connected. But I could find the spot where the connection ended, so I added kind of a highway of tin all the way. Success!

Here's how the circuitboard ended up.

The final stretch was to have the board rest well within the box. I was lucky to find some double sided tape in the kitchen, and since one side of the board already rested slighly on the USB and jack cables I chuckled as I cut off another 2.5cm piece of the now 4cm long USB mini cord. It fit perfectly. Tape on the case, tape on the board, and a short piece of USB mini cord as a pillow.

Here's the final box.

Final fun

Of course my box needed a name and a logo. It didn't take many brain-iterations until I landed on Larsingerlogue CV-5000. It's my [Behr]inger [FCV100 to Mini]logue[ XD] CV-5[V * 1]000[mA adapter]. I turned to my age old friend "Impact" and quickly found a fitting gradient in Photoshop.

Video montage

I'd also shot a couple of videos and pictures during the process, so I amused myself by throwing together a short video of the whole process. It features the first built in patch of Minilogue XD and it's sample sequence with me "playing" the filter cutoff on the now functioning pedal, and the "riser" delay time and depth using my free hand. Farily cool. And then a quite off-beat attempt at the Stranger Things theme as an RL demo of the final product. Check it out.

I hope you've anjoyed following my little story of dipping my toes in electronics for music. There's high potential for a V2 with better polarity support, and who knows what other ideas one might come up with for 100% "DIY" effects to shove into those CV inputs. There's still one unused. 😁

Grief

My only grief, and that's kind of connected to the single polarity of my adapter, is that all of the built-in patches in the Minilogue XD are set to having CV 1 modulating the shape of VCO 1 from 0 to 100%, and CV 2 is set to filter cutoff from 0 to -100%. That means I open the filter by "closing" the pedal and close the filter by "opening" the pedal. Pedal to the floor means almost no audible sound.

Learning while blogging

In hindsight I think I just realized with writing this that 5V on the multimeter means (almost) no power moves through the resistor, which is measured as 0V - while I've been reading 5V (loss) on the multimeter. That would explain the "weird" direction of the pot meter in the simulation that'd been bugging me. 🤣

But hey - adds to a fun story about learning and just jumping into the water.

If you got this far I hope you had a chuckle, nodded or otherwise found this interesting.
Thanks a lot for reading, and have fun whatever endeavor led you to this post.

Esatto.Umbraco.Backoffice.DictionaryFilterValues

Sat, 13 Jun 2026 00:00:00 Z

Extends the Umbraco 17 backoffice Dictionary section filter to also match translation VALUES, not just dictionary-item names. Useful for editors who remember a translated string but not the dictionary key. Adds one authenticated Management API endpoint and a backoffice entry point that re-points the built-in Dictionary collection's data source at it — no window.fetch patching, no anonymous endpoints.

Esatto.Umbraco.Backoffice.CustomEditors

Sat, 13 Jun 2026 00:00:00 Z

A library of reusable property editor UIs for the Umbraco backoffice. Ships an Encrypted Textbox editor (encrypts sensitive values at rest via ASP.NET Core Data Protection, masked on screen) and a Date Range editor (two inline calendars with start/end constraint, optional time and min/max bounds).

My First Umbraco Codegarden: More Than Stickers and T-Shirts

Fri, 12 Jun 2026 22:00:00 Z

After my blog was recently featured on umb.fyi — thanks to Matt Brailsford for that — I felt like I also owed the community a proper write-up about my very first Codegarden experience.Because honestly, after finally attending for the first time, I completely understand why people keep talking about it long after the event is over.I’ve been building with Umbraco since version 4—that takes me back to 2012 or maybe 2013. After all those years, I finally made the pilgrimage: my first Codegarden. And wow, I get it now. I see why people talk about this thing like it’s some annual family reunion you can’t miss, not just a conference. All the stories you hear—about the talks, the people, those late nights that blur into early mornings—they're all real. Still, the heart of it isn’t just scavenging for stickers or filling your suitcase with t-shirts. It’s something deeper.What really struck me—and it hit pretty much as soon as I walked through the doors—is that sense of belonging. Suddenly you realize you’re a piece of something much bigger than just a CMS, a project, or a logo. You’re dropped right into the Umbraco community, and it’s almost impossible not to get swept up in that feeling.

The Umbraco OpenID Connect example has been updated to Umbraco 17.4.2 with support for lightweight external members . This stores members from an external provider as a minimal record instead of a full content entity.

Tue, 02 Jun 2026 00:00:00 Z

SplatDev.Umbraco.Plugins.DictionaryManager

Tue, 02 Jun 2026 00:00:00 Z

Dictionary import/export/CRUD manager for Umbraco — full rewrite of the Umbraco 8 plugin using ILocalizationService. Supports Umbraco 13 (net8.0) and Umbraco 17 (net10.0).

Skrift Issue #128

Tue, 02 Jun 2026 00:00:00 Z

Featuring guest posts by Pasang Tamang on "From Umbraco 8 to Umbraco 17 in One Leap: uSync, Cursor, and the Umbraco MCP" and Aaron Sawyer on "Using Local LLMs wth Umbraco MCP"

SplatDev.Umbraco.Plugins.HiddenContent

Tue, 02 Jun 2026 00:00:00 Z

Umbraco Hidden Content plugin: hide nodes from navigation and sitemaps while keeping them accessible by URL via the umbracoNaviHide property. Supports Umbraco 13 (net8.0) and Umbraco 17 (net10.0).

SplatDev.Umbraco.Plugins.Mailer

Tue, 02 Jun 2026 00:00:00 Z

Umbraco mailer plugin supporting Umbraco 13 (net8.0) and Umbraco 17 (net10.0)

Sat, 30 May 2026 00:00:00 Z

Reframe image media to a new aspect ratio without leaving the Umbraco backoffice. A Reframe view on every Image media item lets editors retarget a picture either by Crop (instant, free, geometric) or by AI Outpaint (OpenAI gpt-image-2 invents the new edges so no content is lost). Preview before/after, then Accept to save the result as a new media item — the original is never changed. Outpaint requires your own OpenAI API key and incurs OpenAI usage cost; Crop is free.

SSO in Umbraco 17: Azure AD Back Office Login with OpenID Connect

Fri, 29 May 2026 18:47:06 Z

SSO in Umbraco 17: Azure AD Back Office Login with OpenID Connect

Fri, 29 May 2026 18:47:06 Z

A step-by-step guide to wiring up Azure Active Directory as an external login provider for the Umbraco back office — with auto-linking…

Continue reading on Medium »

Integrating Amazon S3 Media Storage & HashiCorp Vault Secrets into Umbraco v17

Fri, 29 May 2026 13:45:02 Z

Umbraco MVP 2026!

Fri, 29 May 2026 11:41:10 Z

Woohoo! Proud to receive my seventh Umbraco MVP award in 2026, marking another year of sharing, building, and community-driven progress.

Contentment 7.0.0-alpha001 for Umbraco 18 RC out now

Fri, 29 May 2026 06:23:49 Z

#umbraco #Contentment 7.0.0-alpha001https://github.com/leekelleher/umbraco-contentment/releases/tag/7.0.0-alpha001TL;DR, want to try out Umbraco 18 with Contentment this weekend?Is it stable? Probably!Does it have bugs? Nah!How can you help? Test it out and feedback!

CodeGarden26 : a guide

Thu, 28 May 2026 16:53:23 Z

Umbraco Forums #h5yr now display on HFYR.com

Thu, 28 May 2026 13:00:42 Z

Pleased to announce that now, if you give a #h5yr on the Umbraco Forum, that post will be displayed on H5YR.com Thanks @sebastiaan for helping get this setup. #umbraco

UmbHost launches automated Umbraco upgrades

Thu, 28 May 2026 09:35:45 Z

Automated Umbraco upgrades, sorted. GitHub Dependabot handles the dependency PRs, GreenStack handles the deploy. Here's how you can do it 👇https://umbhost.net/blog/2026/05/building-your-own-umbraco-cloud-style-auto-upgrades-with-github-dependabot#Umbraco #dotnet #DevOps #GreenStack

Umbraco 18 Release Candidate

Thu, 28 May 2026 00:00:00 Z

Discover and test the Umbraco 18 Release Candidate, featuring Elements for reusable content, typed OpenAPI schemas,

Noisy ImageSharp Logs in Umbraco

Wed, 27 May 2026 23:00:00 Z

ImageSharp logs every image request at INFO level, quietly filling your Umbraco logs until the backoffice viewer hits its 100 MB limit and refuses to open them. Here's the one line Serilog fix, plus why a CDN helps.

How I let Cursor build an Azure Search provider for Umbraco Search

Wed, 27 May 2026 09:21:27 Z

I wanted to build an Azure Search provider for Umbraco and let Cursor do the heavy lifting. This is what that looked like from the first prompt to the final commit.

Codegarden 2026 - not long now!

Wed, 27 May 2026 00:00:00 Z

Codegarden 2026 - not long now!

Wed, 27 May 2026 00:00:00 Z

Codegarden 2026 - not long now!

Wed, 27 May 2026 00:00:00 Z

Lantern.Umbraco

Wed, 27 May 2026 00:00:00 Z

Add the Lantern bug-tracking widget to every page of your Umbraco site in seconds. Configure your embed key from the backoffice — no template changes needed.

Umbraco vs WordPress

Tue, 26 May 2026 10:17:32 Z

Die Wahl des richtigen Web-Content-Management-Systems gleicht heute einer strategischen Richtungsentscheidung, die maßgeblichen Einfluss…

Continue reading on Medium »

Browsing Umbraco Logs in Kudu

Tue, 26 May 2026 00:00:00 Z

A new userscript that brings a proper Serilog log viewer into the Kudu interface: file picker, expression search, saved queries, and a momentum graph, all with no build step required.

uPreviewShare

Tue, 26 May 2026 00:00:00 Z

Securely share unpublished draft content with external stakeholders via time-limited, view-capped, and PIN-protected preview links. Renders through actual Umbraco templates.

Skybrud.Umbraco.Redirects.Automate 17.0.0-alpha001

Mon, 25 May 2026 20:37:50 Z

Automate addon for Skybrud Redirects.

Skybrud.Umbraco.Redirects 17.0.5

Mon, 25 May 2026 20:08:42 Z

Award winning redirects manager for Umbraco.

Azure Key Vault Configuration Using RBAC in Azure App Service

Mon, 25 May 2026 11:51:18 Z

Managing secrets securely is one of the most important aspects of modern cloud applications. Instead of storing sensitive values like connection strings, API keys, or passwords directly inside applica

Umbraco Search Explained | Kenn Jacobsen | Umbraco India Meetup

Thu, 21 May 2026 09:52:54 Z

Featuring Kenn Jacobsen Kenn is a 4x Umbraco MVP and a long-time contributor to the Umbraco community, with more than 10 years of experience building solutions with Umbraco and .NET. 📺 Watch the full session recording and learn what’s coming next for search in the Umbraco ecosystem. 🌍 Join us for upcoming Umbraco India User Group events and community updates. 🔗https://www.meetup.com/umbraco-india-user-group 🔗https://www.linkedin.com/groups/14558029

M1sterPl0w.Umbraco.AccessRestriction

Thu, 21 May 2026 00:00:00 Z

An Umbraco package that restricts access to your site (or specific paths) by IP address whitelist. Manage whitelisted IPs and restricted paths from a dashboard in the Umbraco backoffice, with optional hardcoded entries via appsettings.json.

Smarter redirects when editors trash content in Umbraco

Thu, 21 May 2026 00:00:00 Z

A new Umbraco package that replaces the default trash action. It captures the URLs of doomed content first, then suggests redirect targets using Umbraco.AI.Search, with a non-AI fallback for bulk trashes.

UmbHost.Tables for Umbraco has had an update

Wed, 20 May 2026 10:56:20 Z

UmbHost.Tables for #Umbraco has had an update courtesy of Mike Masey!This replaces the custom RTE with the fully featured tiptap RTE with all the configuration options you would expect.View source now opens in a modal windowThere is also a range of accessibility and UX improvementsMany thanks and a huge #h5yr for this PR!Grab it here:https://www.nuget.org/packages/UmbHost.Tables/17.1.0

Start With Markdown

Wed, 20 May 2026 06:00:00 Z

Clean starter kit for Umbraco 18 out in Beta

Wed, 20 May 2026 06:00:00 Z

PragmaticIT.Umbraco.VirtualMembers

Wed, 20 May 2026 00:00:00 Z

Passwordless, database-free member authentication for Umbraco CMS. Protect content nodes with email-only, OTP, or MFA login — members loaded from plain CSV files, no Umbraco Members database records required.

UmbracoTees day May 29th

Tue, 19 May 2026 15:13:52 Z

Can you believe we haven't had an #UmbracoTees day this year yet? Well, let's change that!! Get your Umbraco Swag on, share your photos with #umbracoTees and let's see you all celebrate all things #umbraco May 29th 2026!https://isitumbracoteesday.today/

Start With Markdown

Tue, 19 May 2026 14:17:30 Z

Learn about my new open source content publishing workflow called Start With Markdown It's a simple workflow which triggers when you create or modify a markdown file in the posts folder of your github repo. When it triggers it calls some endpoints on your CMS to create the content and it returns the edit, preview and publish URLs for you. Here is the link to the main project that you fork and setup to call your CMS endpoints https://github.com/prjseal/Start-With-Markdown/ And here is the link to the demo Umbraco project and supporting libraries with the custom resolvers for unsplash and things like that to get it working with the Clean starter kit https://github.com/prjseal/Start-With-Markdown-Umbraco-Libraries

Umbraco 18 and OpenAPI: a heads-up for extension developers

Tue, 19 May 2026 13:37:37 Z

Time to upgrade your extension to Umbraco 18?
A friendly heads up, the OpenAPI generation got an overhaul.

Microsoft.AspNetCore.OpenApi is Umbraco's new library of choice for OpenAPI document generation, replacing Swashbuckle.AspNetCore. It ships with ASP.NET Core and is maintained by Microsoft alongside the framework, which means one fewer third-party dependency to worry about.

The trade-off: if your extension wired up its own OpenAPI document on v17, it won't compile against v18. The Swashbuckle types it relied on are gone.

Two paths forward:

Migrate to Microsoft OpenAPI. Two options:
- Use the AddBackOfficeOpenApiDocument extension method: Umbraco's new helper. What the v18 template uses. Covers most extensions.
- Use Microsoft's AddOpenApi method directly: call Microsoft.AspNetCore.OpenApi yourself. For full control.
Keep using Swashbuckle (not recommended). Install Swashbuckle.AspNetCore in your own extension, wire it up, then plug your document into Umbraco's Swagger UI via AddOpenApiDocumentToUi(...). When rewriting isn't an option right now.

ℹ️ Note: the OpenAPI spec URL also changed from /umbraco/swagger/{documentName}/swagger.json to /umbraco/openapi/{documentName}.json. If you generate a client from the spec (e.g. via the v17 extension template's package.json generate-client script), update the URL before regenerating.

Use the AddBackOfficeOpenApiDocument extension method

We added AddBackOfficeOpenApiDocument() in v18 to take the boilerplate out of registering an OpenAPI document. It's an extension method on IUmbracoBuilder that wires up Umbraco's sensible defaults so you don't have to.

Out of the box, the helper registers your document, scopes it to endpoints decorated with [MapToApi(documentName)], applies Umbraco's naming conventions for schemas and operation IDs, and adds the document to the Swagger UI dropdown at /umbraco/openapi/.

⚠️ Watch out: the first time you call AddBackOfficeOpenApiDocument (or AddOpenApi directly) and build, you'll hit error CS9137: The 'interceptors' feature is not enabled in this namespace. The Microsoft.AspNetCore.OpenApi source generator (which surfaces your XML doc comments as descriptions in the OpenAPI document, among other compile-time enrichments) propagates through Umbraco's project reference, but the property that enables it ships only with the Web SDK. Class-library projects don't get it automatically, so add it to your .csproj:
<PropertyGroup>
  <InterceptorsNamespaces>$(InterceptorsNamespaces);Microsoft.AspNetCore.OpenApi.Generated</InterceptorsNamespaces>
</PropertyGroup>

Minimal usage

public class UmbracoExtensionApiComposer : IComposer
{
    public void Compose(IUmbracoBuilder builder)
    {
        builder.AddBackOfficeOpenApiDocument("my-api");
    }
}

This will add and configure a "my-api" OpenAPI document that will display the controllers/endpoints that have the attribute [MapToApi("my-api")].

Typical usage

public class UmbracoExtensionApiComposer : IComposer
{
    public void Compose(IUmbracoBuilder builder)
    {
        builder.AddBackOfficeOpenApiDocument("my-api", document => document
            .WithTitle("My API")
            .WithBackOfficeAuthentication());
    }
}

Besides adding a "my-api" OpenAPI document, this will set the document title to "My API" and declare that the document's operations require backoffice authentication (which is what enables the "Authorize" flow in the Swagger UI).

Builder method reference

Method	What it does
`WithTitle(string)`	Sets the document's `Info.Title`. Also used as the UI dropdown label unless `WithUiTitle` is set.
`WithUiTitle(string)`	Overrides only the UI dropdown label, leaving `Info.Title` untouched.
`ExcludeFromUi()`	Suppresses registration in the Swagger UI document dropdown. Document is still reachable at its JSON URL.
`WithBackOfficeAuthentication()`	Registers the backoffice OAuth2 security scheme on the document and marks operations as requiring authentication. Swagger UI uses this to prompt for login; generated clients use it to send the token.
`ConfigureOpenApiOptions(Action<OpenApiOptions>)`	Adds a configuration callback for the underlying `OpenApiOptions`. Multiple calls will run in order after Umbraco's defaults.
`WithJsonOptions(...)`	Sets the `JsonOptions` used when generating the document's schema. See Aligning schema serialization below.

Aligning schema serialization

Schema generation needs to use the same JsonOptions your API uses at runtime, otherwise the generated SDKs and the actual payloads will not match. By default, Microsoft.AspNetCore.OpenApi generates schemas using the global HTTP JsonOptions, which means whoever hosts your extension can change them and that affects your schema.

For most backoffice extensions you want the BackOffice named JsonOptions (the same ones Umbraco's Management API uses). Point the document at them with WithJsonOptions:

public class UmbracoExtensionApiComposer : IComposer
{
    public void Compose(IUmbracoBuilder builder)
    {
        builder.AddBackOfficeOpenApiDocument("my-api", document => document
            .WithJsonOptions(Constants.JsonOptionsNames.BackOffice));
    }
}

For this to be meaningful at runtime, your controllers also need to serialize with those same options. The v17 extension template inherits from a plain ControllerBase, which uses the default options instead. Fix that by adding [JsonOptionsName(Constants.JsonOptionsNames.BackOffice)] to your own base controller or to each controller directly.

Without it, the schema reflects backoffice serialization but the actual responses are serialized with the default options, and you're back to the schema-vs-runtime mismatch.

Going beyond the defaults

The helper is not a closed box. Anything you'd normally do on OpenApiOptions (custom operation/schema/document transformers, your own CreateSchemaReferenceId, a replacement operation ID transformer, etc.) is still available through ConfigureOpenApiOptions. It just runs after Umbraco's defaults, so you compose on top of them rather than starting from scratch.

For example, registering your own schema transformer:

public class UmbracoExtensionApiComposer : IComposer
{
    public void Compose(IUmbracoBuilder builder)
    {
        builder.AddBackOfficeOpenApiDocument("my-api", document => document
            .WithTitle("My API")
            .ConfigureOpenApiOptions(options =>
                options.AddSchemaTransformer<MyExtensionSchemaTransformer>()));
    }
}

Migrating an existing composer

If your extension followed the shape of the v17 dotnet template, the migration is: delete the old composer body and write the AddBackOfficeOpenApiDocument(...) call. Below is the same extension's composer before and after.

v17 (Swashbuckle)

public class UmbracoExtensionApiComposer : IComposer
{
    public void Compose(IUmbracoBuilder builder)
    {
        builder.Services.AddSingleton<IOperationIdHandler, CustomOperationHandler>();

        builder.Services.Configure<SwaggerGenOptions>(opt =>
        {
            opt.SwaggerDoc(Constants.ApiName, new OpenApiInfo
            {
                Title = "My Test Extension Backoffice API",
            });

            opt.OperationFilter<UmbracoExtensionOperationSecurityFilter>();
        });
    }

    public class UmbracoExtensionOperationSecurityFilter : BackOfficeSecurityRequirementsOperationFilterBase
    {
        protected override string ApiName => Constants.ApiName;
    }

    public class CustomOperationHandler : OperationIdHandler
    {
        // ...
    }
}

v18 (Microsoft OpenAPI + new builder)

public class UmbracoExtensionApiComposer : IComposer
{
    public void Compose(IUmbracoBuilder builder) =>
        builder.AddBackOfficeOpenApiDocument(
            Constants.ApiName,
            document => document
                .WithTitle("My Test Extension Backoffice API")
                .WithBackOfficeAuthentication());
}

The helper registers UmbracoOperationIdTransformer by default, so the old IOperationIdHandler is no longer needed. If you want custom operation ID logic, register your own through ConfigureOpenApiOptions:

public class UmbracoExtensionApiComposer : IComposer
{
    public void Compose(IUmbracoBuilder builder)
    {
        builder.AddBackOfficeOpenApiDocument("my-api", document => document
            .ConfigureOpenApiOptions(options =>
                options.AddOperationTransformer((operation, context, _) =>
                {
                    operation.OperationId = $"{context.Description.ActionDescriptor.RouteValues["action"]}";
                    return Task.CompletedTask;
                })));
    }
}

Use Microsoft's AddOpenApi method directly

If you want to register a document that isn't a backoffice document, or you want to start from a clean slate without Umbraco's defaults, call AddOpenApi yourself. The helper is just a thin wrapper around that method. Umbraco already wires the OpenAPI routing and Swagger UI hosting, so you don't need to call MapOpenApi or configure endpoints. You only need to register your documents.

For the transformer model itself (how operation/schema/document transformers work), see Microsoft's Customize OpenAPI documents docs.

For Umbraco's specifics ([MapToApi] filtering via options.ShouldInclude, schema/operation ID conventions, the public UmbracoSchemaIdGenerator.Generate(type) helper), see the API versioning and OpenAPI docs.

A few things worth remembering:

Backoffice authentication: call options.AddBackofficeSecurityRequirements() (from Umbraco.Cms.Api.Management.OpenApi) instead of subclassing BackOfficeSecurityRequirementsOperationFilterBase.
Swagger UI registration: documents are no longer auto-listed. Call services.AddOpenApiDocumentToUi(documentName, uiTitle) to surface yours in the dropdown.
InterceptorsNamespaces opt-in: same as the helper path. See the Watch out callout at the top of the helper section.

Keep using Swashbuckle

Not recommended. Consider this only if rewriting a complex Swashbuckle setup isn't feasible right now. Trade-offs:

Extra dependency on Swashbuckle.AspNetCore.
OpenAPI 3.0 output, whereas the rest of Umbraco's documents emit 3.1.
Extra wiring you maintain yourself.
Both libraries depend on Microsoft.OpenApi. A breaking change there that Swashbuckle doesn't follow leaves your extension incompatible with the rest of the stack.

If you still want to go this route, see the Swashbuckle.AspNetCore README for general setup. The rest of this section is the Umbraco-specific wiring.

1. Install the NuGet package

Add a PackageReference to Swashbuckle.AspNetCore in your extension's .csproj (or dotnet add package Swashbuckle.AspNetCore).

2. Register Swashbuckle and your document in a composer

In v17, Umbraco called AddSwaggerGen for you and your extension only configured SwaggerGenOptions. In v18 you have to call it yourself:

public class UmbracoExtensionApiComposer : IComposer
{
    public void Compose(IUmbracoBuilder builder)
    {
        builder.Services.AddSwaggerGen(opt =>
        {
            opt.SwaggerDoc(Constants.ApiName, new OpenApiInfo
            {
                Title = "My Test Extension Backoffice API",
                Version = "1.0",
            });

            var previousDocInclusion = opt.SwaggerGeneratorOptions.DocInclusionPredicate;
            opt.DocInclusionPredicate((docName, apiDesc) =>
                docName == Constants.ApiName
                    ? apiDesc.ActionDescriptor.HasMapToApiAttribute(docName)
                    : previousDocInclusion?.Invoke(docName, apiDesc) ?? true);

            // any operation filters, schema filters, or other v17 setup you had...
        });
    }
}

3. Host the Swagger JSON middleware via an IUmbracoPipelineFilter

Umbraco no longer calls app.UseSwagger(), so the middleware that serves the Swagger JSON isn't running. Add it through Umbraco's pipeline filter, and set the RouteTemplate to match UmbracoOpenApiOptions.RouteTemplate (default umbraco/openapi/{documentName}.json) so the dropdown link resolves.

public class UmbracoExtensionApiComposer : IComposer
{
    public void Compose(IUmbracoBuilder builder)
    {
        builder.Services.Configure<UmbracoPipelineOptions>(options =>
        {
            options.AddFilter(new UmbracoPipelineFilter("Swashbuckle")
            {
                PostPipeline = app =>
                {
                    var openApiOptions = app.ApplicationServices.GetRequiredService<IOptions<UmbracoOpenApiOptions>>().Value;
                    if (!openApiOptions.Enabled)
                    {
                        return;
                    }

                    var routeTemplate = openApiOptions.RouteTemplate;
                    app.UseWhen(
                        ctx => ctx.Request.Path == routeTemplate.Replace("{documentName}", Constants.ApiName).EnsureStartsWith('/'),
                        branch => branch.UseSwagger(c => c.RouteTemplate = routeTemplate));
                },
            });
        });
    }
}

Scope the middleware to your own document's URL. Otherwise Swashbuckle intercepts requests for Umbraco's own documents (Management, Delivery) and returns 404 because they aren't registered with AddSwaggerGen.

4. Register the document in the Swagger UI dropdown

public class UmbracoExtensionApiComposer : IComposer
{
    public void Compose(IUmbracoBuilder builder)
    {
        builder.Services.AddOpenApiDocumentToUi(Constants.ApiName, "My API");
    }
}

TL;DR

The helper is the simplest option for most extensions. AddBackOfficeOpenApiDocument() is what the v18 template uses, gives you Umbraco's sensible defaults out of the box (naming conventions, Swagger UI registration, JsonOptions alignment), and lets you register an OpenAPI document in a single call.

Calling AddOpenApi yourself is the standard ASP.NET Core approach and works fine. It means more wiring and code to maintain, so reach for it when you need full control (non-backoffice documents, or skipping the Umbraco defaults).

If rewriting really isn't an option right now, keeping Swashbuckle as your own dependency and plugging into the dropdown via AddOpenApiDocumentToUi(...) will get you through, but plan to revisit when you can.

Building a Passwordless Authentication Library for Umbraco - Part 1: Why?

Tue, 19 May 2026 12:36:58 Z

Limbo.Umbraco.FilterList 13.0.0-alpha004

Tue, 19 May 2026 10:55:08 Z

Fri, 15 May 2026 14:03:31 Z

📣 Introducing 🥁 uSkinned Site Builder for Umbraco 17 🤩 Full support for Umbraco 17 is now available for uSkinned Site Builder. Install or upgrade today.

From zero to working product in two hours

Fri, 15 May 2026 07:58:10 Z

Umbraco.AI.Agent.UI

Fri, 15 May 2026 00:00:00 Z

Shared chat UI components for Umbraco AI Agent surfaces

Umbraco.AI.Agent.Copilot

Fri, 15 May 2026 00:00:00 Z

Copilot chat UI for Umbraco AI Agent

Modgift.Umbraco.Breakable

Fri, 15 May 2026 00:00:00 Z

A Breakable property editor for Umbraco CMS that lets editors mark soft-hyphen break points inside text values using | as a delimiter.

Our.Umbraco.PropertyToolTip

Fri, 15 May 2026 00:00:00 Z

Property ToolTip keeps Umbraco property descriptions available, but shows them as small tooltip help text beside each property label.

SwiftUI is a Disaster

Thu, 14 May 2026 17:24:48 Z

I’ll admit it. I’m still programming for Apple platforms using Objective-C, AppKit and UIKit.

Continue reading on Medium »

The Umbicosaurus De-Extinction: The Community Effort that Brought a Better Icon Picker to Umbraco 17.4

Thu, 14 May 2026 09:58:00 Z

In 2021, I dreamed of improving the icon picker in the Umbraco backoffice and today, in Umbraco 17.4, the package I started is making a splash as part of Core! This is the story of Umbicosaurus.

Fri, 08 May 2026 08:28:41 Z

Diplo Translator | Umbraco Marketplace

Umbraco.Community.AI.Chatbot

Fri, 08 May 2026 00:00:00 Z

Drops a public-facing, AI-powered chat widget on a website's frontend. End users on the public site type a question; the package runs a semantic search over the site's Umbraco content (Umbraco.AI.Search), feeds the matched pages into an Umbraco.AI.Agent, and streams a grounded answer back with cited source pages and follow-up suggestions. The official Umbraco.AI.* packages expose chat only inside the backoffice. There is no path for an anonymous site visitor to ask questions of the site's content. This community package fills that gap. Key features: - Public-facing widget (drop in one