Community Blogs

What Umbraco Codegarden 2026 Left on Me—Permanently | Marathon Consulting

Marathon's Scott Clevenger reflects on Umbraco Codegarden 2026 — an MVP, a tattoo, and a platform that's ready for whatever comes next.

Is AI signalling the end of the CMS as we know it? Or is it simply becoming something much bigger?

Gibe goes to Codegarden (2026 edition)

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!

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

Introducing ImageSharp TrimCache for Umbraco

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

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 <remarks> 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. 🙂

Umbraco London July Meetup .. the write- up

Creating A Safe Space for Editors to Be Wrong

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...

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

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

PostgreSQL provider for Umbraco Search

Introducing a PostgreSQL powered search provider for Umbraco Search.

Using Umbraco.Automate to populate content from an API

Learn how to automatically populate Umbraco content from an external API using Umbraco.Automate, with a hands-on PokéAPI example and video demo.

Advanced Permissions meets Umbraco 18!

A few days ago, the final version of Umbraco 18 was released! So it was time to update my Advanced Permissions package to support Umbraco 18. This was not just a simple case of updating a few namespaces and dependencies and calling it done. The main new feature in Umbraco 18 was a perfect candidate for Advanced Permissions support, so that is exactly what I added! 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