Community blogs

Automate All the Things - my Codegarden 2026 talk is up

My Codegarden 2026 talk, Automate All the Things: Building & Evolving Umbraco Sites with AI Agents, is now up on YouTube: ▶️ Watch it here And everything I ran on stage - the prompts, the rules, the skills, the agents, the whole workflow - is open source here: 📦 github.com/Shazwazza/UmbracoAI So what actually happens in it? The whole talk is a live demo. I point GitHub Copilot CLI at a completely empty Umbraco install - no content types, no templates, no content, nothing but an API user I'd set up beforehand - and it designs, scaffolds, styles, populates, validates and commits an entire blogging website. Nobody opens the back office. Nobody writes a line of code. It builds the document types, the templates, the CSS, the navigation, ten blog posts, goes and finds matching images for all of them, adds a tag cloud, generates a sitemap, runs accessibility checks, and commits after every single step. The content isn't generic filler, either. The agent is told to write about the presentation it's currently part of, and about what it's learning as it goes. So it writes blog posts about its own experience of being built, live, while a room full of people watches. It knows it's on stage, and it will happily tell you so. The bit I'm most excited about The thing driving all of it is Conductor - a YAML-based multi-agent workflow runner. If you've used LangChain or LangGraph, it's a bit like that, except you don't write code, you write YAML. Each step is an agent with strongly typed inputs and outputs, so you can wire the output of one step into the input of another. Steps can run in parallel, they can fan out and fan back in, they can loop, they can each use a different model, and the whole thing can be templated. The best part is you don't even have to write the YAML. Installing Conductor installs a skill that writes Conductor workflows, so you can just ask for what you want. That's exactly what I did - I told it I wanted a blog engine with a tag cloud and git commits along the way, and deliberately never told it how to use Umbraco. It figured that out entirely from the Umbraco MCP tool metadata. The funny bits Because it's writing about itself as it goes, the titles are a delight. Some actual ones it came up with: Hello Codegarden, an AI agent walks into a CMS The first keystroke is always the hardest Publishing nine posts in parallel Giving the tag cloud a job Building navigation that feels obvious My first accessibility pass, out loud The day HMAC-signed images humbled me That last one got a proper laugh out of the room, because of course everybody has had that problem. And "the first keystroke is always the hardest" opened with something about the particular quiet that lives in the moment you create your very first document type, which is honestly more introspection than I manage before coffee. One run decided to put a live counter on the home page showing how long it had been building and how many document types it had created, credited to "one very caffeinated agent". Nobody asked it to do that. The other consistent surprise: if you tell a model to be creative and invent its own visual identity, it will make it neon. Over and over. I never once said the word "neon". Several runs independently decided the site should be called Aurora, which I also never mentioned. Something out there in training data really wants your blog to glow. Go have a play Clone the repo, install Conductor, point it at an empty Umbraco and watch it go. The README covers the setup. If you build something interesting with it, I'd genuinely love to hear about it. 🙂

12 August 2026 by Shanon Thompson (Deminick)

I've used Umbraco for more than a decade. An unexpected reflection.

I just got back from vacation, and, for the first time in ages, I managed to ditch my laptop. So no Visual Studio, no migrations and no coding whatsoever. No people asking me “can you just…?”. It felt pretty good to unplug for a bit. I wasn’t mentally writing code the whole time, and I definitely didn’t set out to think about Umbraco over my morning coffee.And I was planning on reading blog posts, listen to a few podcasts, reading the docs, etc. But the terrible mobile connection in France prevented that. So I kicked back, soaked up some sun, and enjoyed the joy of doing nothing productive (and a beer here of there), my mind wandered back to it anyway. Because this holiday made me look back and reflect at the last couple of years somehow. Maybe it was the lack of a laptop that made me a look back…I’ve been working with Umbraco for 10+ years now. I started somewhere around 2012 or 2013, with Umbraco 4. In that time, I’ve watched versions come and go, seen the platform shift in big ways, and watched the community explode to what it is today. And I’ve wrangled my way through more projects and upgrades than I care to count.Thinking about that is weird. I never expected, back when I started, that I’d still be talking about Umbraco a decade later. It became part of my career, a source of major learning, and eventually even something I started writing about.So while I was taking a break, I found myself reflecting on this whole adventure. Not just on the version numbers, but on how the platform changed—and, honestly, how I changed right alongside it.

10 August 2026 by Dave Jonker

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

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 This is one of those things that’s probably obvious once you’ve worked with it before, but until then, it’s easy to assume backoffice search is less flexible than it actually is. If you’ve got editors relying on custom fields it’s worth checking whether those fields are included in backoffice search. If they’re already indexed, you may only need to extend UmbracoTreeSearcherFields to make them searchable. A small change, but a very useful one for editors.

7 August 2026 by Bernadet Goey

Umbraco Codegarden 2026 Day 1: AI, Elements & Community News | manifesto

Explore key takeaways from Day 1 of Umbraco Codegarden 2026, including major product keynotes, AI governance, new Elements features, and the Umbraco Awards.

7 August 2026 by Rich Howell

Setting up Windows Server 2025 for Umbraco

Every time I build a new server I go through the same sequence, and every time I find myself trying to remember what I did last time. So this is my reference for turning a clean Windows Server 2025 instance into something that will happily host Umbraco on IIS and SQL Express, in the order I actually do things.

6 August 2026 by Justin Neville