May 2026: Umbraco 18 went from beta1 to release candidate in fifteen days

· JD + AI · Umbraco

May 2026: Umbraco 18 went from beta1 to release candidate in fifteen days

Umbraco 18 beta1 landed on 13 May, beta2 the following day, and the release candidate on 28 May. Fifteen days from first beta to RC. The beta1 notes carry thirty-five entries under the "Breaking Changes" heading, and if you maintain a package, an extension, or a solution with anything custom bolted onto the backoffice, that list is your May.

The cadence is the thing worth reading, not any single feature. A vendor that compresses beta to RC into two weeks is telling you the shape of the release is already settled and the window for finding problems in your own code is short.

Fifteen days, and where the breaking changes actually are

Umbraco 18.0.0-beta1 — lauraneto, Umbraco CMS releases Umbraco 18.0.0-beta2 — AndyButland, Umbraco CMS releases These are Umbraco's own release notes on Umbraco's own repository, so treat them as the vendor speaking about its own product. beta2 changed two things against beta1, a backoffice prerelease-tag fix and a SignalR handler registration, and otherwise restates the same cumulative list. The thirty-five breaking entries are almost all one of two kinds: obsoleted code finally removed on the v18 boundary, or nullability tightened to match actual behaviour.

Four are the ones we would check first on a real solution. Webhooks now default to the "minimal" payload type, which silently changes what your subscribers receive. MigrationBase and every migration between v13 and v17 are gone, which matters if your upgrade path assumed it could hop from an old LTS in one move. "Master Template" is renamed to "Layout Template", which is cosmetic until it is in your documentation and your onboarding deck. And name is now non-nullable on content, element, media and member constructors, which is the kind of change that compiles fine until the one place it does not.

Elements, typed schemas, and the end of Swashbuckle

Umbraco 18 Release Candidate — Andy Butland, Umbraco official blog Butland writes for the vendor, so this is a launch post rather than analysis, but it is a detailed one and it is honest about scope. Three things land in 18.

Elements is the headline, and it is explicitly phase one: a Library section in the backoffice for reusable content outside the document tree, with reference tracking, scheduled publishing, rollback, permissions and a configurable element picker. The payoff most people actually want, mixing elements with standalone blocks in the Block Editor and converting a block into a library element, is targeted for Umbraco 19 later in 2026 per the same post. If you have been modelling site settings and footer data as unroutable pages, 18 gives them a better home and 19 gives you the rest.

Typed OpenAPI schemas for the Delivery API are opt-in and change only the OpenAPI document; the responses are unchanged. That distinction decides whether this is useful to you. Consuming the Delivery API directly gains nothing. Generating clients from the spec gains real typed models per document type. Butland flags the caveat himself: the schemas use OpenAPI 3.1 oneOf with discriminators, generator support for that is uneven, so verify the output against your tooling before you depend on it.

Swashbuckle is replaced by Microsoft.AspNetCore.OpenApi. This is the one that breaks package authors. Any extension that wired up its own OpenAPI document on 17 will not compile on 18, because the Swashbuckle types are gone. There is a new AddBackOfficeOpenApiDocument() helper that covers most of the migration in one call, and the OpenAPI endpoint moves. Budget an afternoon per package, not a sprint, but budget it now — the RC post asks for testing against real projects between 28 May and 25 June.

Two positions on AI, and neither of them ships as a button

AI on Your Terms: How Umbraco Reimagines AI — Jeppe Birkebæk Truelsen, Technical Enablement Specialist at Umbraco, on the Umbraco blog Umbraco writing about Umbraco's own AI strategy, so read it as positioning. The position itself is unusual enough to be worth knowing: the CMS core is kept deliberately free of AI features, and AI arrives through a separate layer with the customer choosing the model. Truelsen frames it as introducing AI "without forcing organizations to surrender control in exchange for convenience". Whether the products deliver that is a 2026 question, but as a stated stance it is the opposite of what most of this market shipped last year.

Designing an AI Agent skill for adding a page type to Umbraco — Paul Seal, Codeshare The community version of the same question, and the more useful document. Seal, with Andy Eva-Dale and Callum Whyte, spent two meetings of the Umbraco AI community team arguing about naming conventions, tabs, compositions and what "add a page" even means before writing any skill. That argument is the artefact. Anyone standardising agent-assisted scaffolding on their own team will have the same argument, and this is a head start on it.

How I let Cursor build an Azure Search provider for Umbraco Search — no byline on the page Our harvest records no author for this post; it runs on jeroenbreuer.nl, whose site description names Jeroen Breuer, but the article itself credits nobody and we are not going to assume. We also have no declared commercial interest for the source, so read it as a practitioner write-up of unknown affiliation. The method is the transferable part: before asking the agent to build anything, it was pointed at four existing codebases (the Elasticsearch and Typesense providers, an Azure Search playground, the demo project) with the same instruction each time, and made to produce a strategy before a line of provider code. Research phase first, generation second.

The field notes worth an afternoon

What a slow Chrome trace told us about a 2,000-product catalogue page — Josh Wood, TSD Digital The best technical writing in the Umbraco orbit this month, and it is not about Umbraco. A category page with 1,948 listings had a 14,117 ms worst blocking task, a 10,471 ms second-worst, and 318 style recalculations inside a single task. The fixes are unglamorous: throttle the sticky filter's scroll handler and batch its reads before its writes, debounce the IntersectionObserver callback by 250 ms so scrolling past 200 cards stops firing 200 requests. The conclusion that generalises: a mobile tab dying is a renderer-memory story, not a JavaScript-heap story, and content-visibility: auto with contain-intrinsic-size is the single largest lever on any long listing page. TSD Digital implement commercially, and this is also the month's second item from their blog, so weigh the marketing function accordingly — the numbers are still numbers.

Building a Personalisation Roadmap on a Realistic Budget — Tim Gaunt, TSD Digital The other TSD post, and Gaunt sells personalisation work, which he is open about — the piece opens on a sales-call objection. Discount the framing and the argument holds: personalisation projects fail on sequencing rather than budget, and a twelve-month three-phase plan starting with an analytics audit costs nothing in phase one. Useful the next time a client asks for personalisation and means "buy us a platform".

A weekend without internet access — Owain Williams, Owain Codes A cabin with no wifi turned into the sharpest operational finding of the month: you cannot log into a local Umbraco Cloud backoffice without reaching Umbraco Cloud authentication, and you cannot create a local user account until you have signed in through the cloud once, signed out, and signed back in. Do that while you still have signal. Anyone who works on a train knows why this matters.

Why Accessibility on the Web is Mission-Critical — Dave Jonker, Dynamic Dave The argument for treating accessibility as content modelling rather than a pre-launch audit, written against Umbraco 17. Nothing here will surprise anyone who already believes it, which is exactly why it is the piece to forward to the people who do not.

Underneath, and around

uSync v17.3.2 "SingleBlock" — Kevin Jump A small patch with a specific reason to care: it fixes double-encoding of non-string JSON values inside nested blocks and adds a SingleBlock mapper. If your uSync diffs on v17 have been noisy around block values, this is the explanation. The fix came from a first-time contributor.

.NET 11 Preview 4 (EF Core) — rbhanda, dotnet/efcore releases Mostly dependency bumps and bot commits, plus Cosmos complex-property binding. It appears here only because Umbraco's data layer sits on EF Core and preview cadence is worth tracking, not because May's preview changes anything for you. It is thin, and we would rather say so than inflate it.

The people, briefly

uProfile May 2026 — Bernadet Goey — Bernadet Goey, on the Umbraco blog Goey writes her own profile for the vendor's community series: a decade as a PHP specialist, three years into Umbraco, now a software engineer at ilionx in the Netherlands. The honest part is the middle — moving to .NET made a senior developer feel junior again. Worth handing to anyone in your team currently in that gap.

Codegarden 2026 — not long now — Owain Williams, Owain Codes Codegarden moves from Odense back to Copenhagen, with the MVP Summit running the Monday and Tuesday before. Williams is speaking for twenty minutes on the Management API, which he argues is underused. On that, he is right.

What we would actually do about this month

Fifteen days from beta1 to RC is not a rushed release; it is a release whose risk has been moved onto you. The compressed window works because the breaking changes are concentrated in removal of code marked obsolete releases ago, which is fair, and because Umbraco is betting that the ecosystem tests during the RC rather than after it. That bet only pays off if package authors and agencies actually run their code against the RC before 25 June.

So pull the RC into a branch this week, compile your packages, and look hardest at anything that registered its own OpenAPI document or consumed a webhook payload. The rename and the nullability tightening surface at compile time. The webhook default will not. It surfaces in production, on a Tuesday, in someone else's system.

The wider read on May: the interesting Umbraco writing was not about Umbraco. A Chrome trace, a sequencing argument and a cabin with no wifi produced more transferable engineering than the feature list did. That is not a criticism of the release. It is a reminder that a CMS roundup covering only the CMS is missing where the work actually goes.

Sources

umbraco · sitecore-search · umbraco-cms · umbraco-backoffice · umbraco-apis · content-modelling · product · community

2026 © Umbracolombia - All rights reserved.