Community Blogs

My First Umbraco UK Conference 2026: AI, Great Conversations, and the Umbraco Community ❤️

Umbraco Upgrade Decisions: Upgrade or Rewrite

If a site genuinely needs to change, the next decision is whether to upgrade it or rewrite it. In this post, I look at what a major version upgrade actually involves, when upgrading or rewriting makes more sense, and what each option costs in practice. Continue reading

Giving AI agents tools for the Umbraco backoffice with WebMCP

Chrome's new WebMCP API lets a page hand an AI agent a list of named tools, so I tried it on the Umbraco 18 backoffice to see whether an agent could get around it, Umbraco Forms included, without reading a single screenshot.

The Umbraco MCP Benchmark, part 2: Haiku 5.5 and the budget models

Haiku went from 47 to 93 on my Umbraco MCP benchmark when 4.5 became 5.5. Then I ran the budget and open models, with and without a verified recipe, and tracked grade, cost and whether they told the truth.

Three Years of UMB.FYI, and a Second Pulse Check

UMB.FYI turns three, and the second Pulse Check looks back at how the Umbraco ecosystem moved over the past year.

Chicago: What a Wonderful Town

Examine 3.10.1 and 4.0.1 released

Examine 3.10.1 and 4.0.1 are out on NuGet now. Both are patch releases and the main reason for them is a fix for an analyzer issue that could cause queries to be parsed with the wrong analyzer. The analyzer fix This was reported in #613 and it's been lurking for a long time, but it's an edge case that only shows up if something uses the index's analyzer before the index's field value types have been resolved on startup. With a normal startup that doesn't happen, which is why it hasn't come up before. LuceneIndex.FieldAnalyzer is lazily created and cached, but the per-field analyzer mappings were populated lazily too, so if the analyzer was used first, the PerFieldAnalyzerWrapper would cache the default analyzer for those fields. That stuck around for the life of the index, so any searcher created from it kept using the default analyzer for fields that were configured to use something else. So if you had a field configured with a KeywordAnalyzer, a native query like this: someField:"contentPage" could end up parsed as: someField:contentpage which is the StandardAnalyzer lower casing it, and then you get no results and a bit of head scratching. The fix in #621 is quite small: the field value types are now resolved before the analyzer wrapper is constructed, so it can't cache a fallback analyzer for a configured field. There's a regression test for it too. Other changes A few small allocation improvements in OrderedDictionary.Values, LuceneIndex.GetFieldNames and LuceneSearchQueryBase. These came from the agentic perf workflows I have running on the repo, which open PRs for this sort of thing that I then review. The docs site is updated for v4 and the v1/v2 docs are now marked as unsupported. A new release process These are also the first releases shipped with the new release process. Previously I'd tag a release, wait for the build, download the zip of packages, unzip them and push them to NuGet from my terminal. Now pushing a tag builds the packages and then waits for me to approve the deployment in GitHub. Once approved, it publishes to NuGet with trusted publishing (so no API keys sitting around) and creates the GitHub release with the packages attached. I also switched versioning from GitVersion to MinVer, which just uses the tag, which is all I wanted anyway. That's mostly only interesting to me, but it does mean releases should happen a bit more often now that there's less toil involved :) Release notes for each are on GitHub: v3.10.1 and v4.0.1. Happy Searching!

Examine 3.10.1 and 4.0.1 released

Examine 3.10.1 and 4.0.1 are out on NuGet now. Both are patch releases and the main reason for them is a fix for an analyzer issue that could cause queries to be parsed with the wrong analyzer. The analyzer fix This was reported in #613 and it's been lurking for a long time, but it's an edge case that only shows up if something uses the index's analyzer before the index's field value types have been resolved on startup. With a normal startup that doesn't happen, which is why it hasn't come up before. LuceneIndex.FieldAnalyzer is lazily created and cached, but the per-field analyzer mappings were populated lazily too, so if the analyzer was used first, the PerFieldAnalyzerWrapper would cache the default analyzer for those fields. That stuck around for the life of the index, so any searcher created from it kept using the default analyzer for fields that were configured to use something else. So if you had a field configured with a KeywordAnalyzer, a native query like this: someField:"contentPage" could end up parsed as: someField:contentpage which is the StandardAnalyzer lower casing it, and then you get no results and a bit of head scratching. The fix in #621 is quite small: the field value types are now resolved before the analyzer wrapper is constructed, so it can't cache a fallback analyzer for a configured field. There's a regression test for it too. Other changes A few small allocation improvements in OrderedDictionary.Values, LuceneIndex.GetFieldNames and LuceneSearchQueryBase. These came from the agentic perf workflows I have running on the repo, which open PRs for this sort of thing that I then review. The docs site is updated for v4 and the v1/v2 docs are now marked as unsupported. A new release process These are also the first releases shipped with the new release process. Previously I'd tag a release, wait for the build, download the zip of packages, unzip them and push them to NuGet from my terminal. Now pushing a tag builds the packages and then waits for me to approve the deployment in GitHub. Once approved, it publishes to NuGet with trusted publishing (so no API keys sitting around) and creates the GitHub release with the packages attached. I also switched versioning from GitVersion to MinVer, which just uses the tag, which is all I wanted anyway. That's mostly only interesting to me, but it does mean releases should happen a bit more often now that there's less toil involved :) Release notes for each are on GitHub: v3.10.1 and v4.0.1. Happy Searching!

Estimating the CO2 of your Umbraco AI usage

A new community package adds a CO2 tab to Umbraco AI Analytics, estimating the energy and CO2e of your AI chat usage with the EcoLogits method.

AI is changing how I approach Umbraco development

Building a PDF metadata dashboard with AI made me reconsider when I reach for Umbraco's standard tools and when a custom extension is worth the maintenance.

My Umbraco India Festival 2026 Experience

Looking back at Umbraco India Festival 2026 in Kochi: a hackathon on the Water Metro, recording the sessions, great people, and the next edition in Goa.

Umbraco Management API Wonders

You may have heard me talk about Rick Dangerous, a 1989 game I reversed-engineered long ago, which can now be played directly on the web, thanks to WebAssembly. All it takes is one .wasm file, and a couple of .js files. Now, because rick-dangerous.org is running Umbraco, and because it is simpler to have everything in the same place, those files are managed as Umbraco media. So each time I rebuild the game, I need to update those media files. But browsing in the media section is a manual and tedious process. Can we do better? Umbraco Management API The Umbraco Management API is the API that was introduced in order to support the revamped back-office in a clean and independent way. And straight from the beginning, it was meant to be. First create a dedicated API user. Second, authenticate: CLIENT_ID=umbraco-back-office-rick-dangerous-api CLIENT_SECRET=***** API_URL=https://www.zpqrtbnk.net/umbraco/management/api/v1 TOKEN=$( \ curl -s $API_URL/security/back-office/token \ -d "client_id=$CLIENT_ID" \ -d "client_secret=$CLIENT_SECRET" \ -d 'grant_type=client_credentials' \ | jq -r .access_token ) If all goes well, the $TOKEN shell variable now contains your authentication token. We are going to define a simple helper method for invoking the API: curl_api() { METHOD=$1 shift API=$1 shift curl -s \ -H "Authorization: Bearer $TOKEN" \ -X $METHOD \ $API_URL/$API "$@" fi } Let us test it by retrieving the authenticated user name: curl_api GET user/current | jq -r .name Now let's assume that the media item containing the WASM file has a given UUID that we have retrieved from the UI, and we want to update its file with the recently built file xrick/build/web/xrick.wasm. This is what it takes: MEDIA_WASM="11467372-23fb-4d45-818b-fc78edf889a6" FILE_WASM=xrick/build/web/xrick.wasm # get the media name (required for updates?) MEDIA_NAME=$( \ curl_api GET media/$MEDIA_WASM | jq -r .variants[0].name ) # create a UUID for the temporary file UUID=$(uuidgen) # upload the file as a temporary file curl_api POST temporary-file -F "Id=$UUID" -F "File=@./$FILE_WASM" # edit the media to remove the current file curl_api PUT media/$MEDIA_WASM \ -H "Content-Type: application/json" \ -d "{\"id\":\"$MEDIA_WASM\",\"values\":[{\"alias\":\"umbracoFile\",\"culture\":null,\"segment\":null,\"value\":{}}],\"variants\":[{\"culture\":null,\"segment\":null,\"name\":\"$MEDIA_NAME\"}]}" # edit the media again, with the temporary file curl_api PUT media/$MEDIA_WASM \ -H "Content-Type: application/json" \ -d "{\"id\":\"$MEDIA_WASM\",\"values\":[{\"alias\":\"umbracoFile\",\"culture\":null,\"segment\":null,\"value\":{\"src\":\"\",\"temporaryFileId\":\"$UUID\"}}],\"variants\":[{\"culture\":null,\"segment\":null,\"name\":\"$MEDIA_NAME\"}]}" And... that is all. You will want to add some error checking here and there, but basically, this is all it takes to fully script the update of a media file. The list of things that can be done this easily is huge—pretty much anything in fact. Which is absolutely impressive. Loving it, would recommend.