Community Blogs

TipTap is not broken. Your expectations are.

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.

I attended Umbraco Codegarden 2026!

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!

OC.Automate.Mastodon released

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

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.

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

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.

Diagram and NATP Win Best Enterprise Solution at the 2026 Umbraco Awards

We’re excited to share that the National Association of Tax Professionals (NATP) website, designed and developed by Diagram, has been named Best Enterprise Solution at the 2026 Umbraco Awards.

Nominated for an Umbraco Solution Award

Feeling incredibly proud to have been nominated for an Umbraco Solution Award this year!

CodeGarden-talk: Hybrid Cache changes everything

I recently spent some time looking closer at the new HybridCache implementation in Umbraco to prepare for my presentation at CodeGarden 2026, and the short version is this: it changes more than just the cache layer. Historically, Umbraco has been very good at keeping published content available in memory. That has made many common developer patterns feel cheap and convenient. Things like traversing content trees, using `.Children()`, `.Descendants()` and resolving references have often just worked without us thinking too much about the cost. With HybridCache, that mental model changes. The cache is still there, but not everything necessarily lives in memory all the time. The big win is scalability The reason for this change is very easy to understand when looking at large Umbraco installations. Keeping everything in memory can work beautifully for small and medium-sized sites, but it becomes painful when a site has hundreds of thousands of pages, many languages, or very large content structures. Startup time, memory usage and hosting constraints can become real problems. HybridCache helps by reducing the memory footprint and making startup faster. Instead of loading everything into memory, Umbraco can seed important content and load other content when needed. That is a big architectural improvement. The cost did not disappear The interesting part, at least for me as a developer, is that the cost did not vanish. It moved. Some operations that used to feel almost free can now become more expensive, especially on larger sites. Traversing a large tree, filtering over many children, or resolving many references may trigger more cache lookups or database access than before. That does not mean HybridCache is bad. Quite the opposite. But it does mean we need to be more intentional about how we build things like menus, listings, sitemaps and search-driven pages. Use the right tool for the job One of my main takeaways is that we should stop treating the published content cache as the answer to everything. For search and filtering, Examine is often a much better fit. For menus, footers and repeated structures, runtime cache or prebuilt DTOs can be a good option. For sitemaps, adding the right data to the index (e.g. URLs) can be much more scalable than traversing the whole content tree. So the practical message is simple: measure, observe, and choose the right approach based on what the page actually needs to do. HybridCache gives Umbraco a better foundation for large sites, but it also makes performance patterns more visible. And honestly, that is probably a good thing. Download the slides I’ve shared the full slide deck from the presentation if you want to dig into the examples, benchmarks and diagrams in more detail. Download the slides

Codegarden: What to bring (2026 edition!)

Wow, hasn't time flown?! This weekend I'll be boarding my plane to Denmark ahead of Codegarden 2026 so it's about time we thought about packing our bags! But what to bring? If you've not been before, or if you're forgetful like I am, I've written you a packing list...

Umbraco OpenID Connect example with lightweight external members

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.

Speed up slow deployments to Umbraco Cloud

Why 2026 Is Finally the Year I'm Going to Codegarden

Some things just hang around on your bucket list forever. You tell yourself, “maybe next year,” but you never actually get around to it. For me, that’s always been Codegarden.I’ve been working with Umbraco since version 4—so, we’re talking 2012 or 2013. That’s over a decade of projects, bug fixes, and late-night “why is this still broken?” moments. But I’ve never packed a bag and headed to Copenhagen for the biggest Umbraco event on the planet. Not once. Until now.