Skip to main content


Programmatically Creating a Record With Umbraco Forms

Umbraco Forms is a commercial add-on for Umbraco providing an editor interface for creating and managing forms. These forms can then be hosted on the website for completion by site visitors, with the entries available for view in the Umbraco backoffice. That describes the usual use-case, but it is also possible to create form submissions - known as records - for a form programatically. Posting for future reference, this illustrative example for Forms 10 shows how this is done:
Recent posts

Use PostConfigure For Default Configuration of Collections in ASP.NET

This post contains a couple of topics that came together in a recent update I was making - one a gotcha, and one a solution, that as well as addressing this issue has wider application. In my web application there was some configuration that consisted of a list of elements. This was represented in code with a POCO like this: Which can then be injected using IOptions<MySettings> into the classes that need it. And in configuration, via the appSettings.json file, you can provide the values: So far so good, but now I wanted to set some default values for this configuration. If nothing is provided, I wanted a non-empty list to be used as the default. But if the user has configured something for the setting, then that should be used. I figured I could just do the following, setting an initial collection on the class, which would be use unless overridden by a value provided in configuration: Unfortunately this doesn't work as I expected as was pointed out to me

Handling Umbraco Events After Deploy Operations

I had a question from an partner Umbraco raised for me this week, that's available at this forum topic . They had some code running in a notification handler running when dictionary items were saved, and found this wasn't firing when the item was saved following an Umbraco Deploy operation. I responded that this is actually expected behaviour - as Deploy supresses events being fired on individual save and publish events when transferring items. This implementation decision was made I understand for performance reasons. In the back-office, the usual case for a save of an item is one-at-a-time, but with a deployment, there could be hundreds of updates within an operation. However, what if you do want to run some code on the save of some Umbraco data, even if this is happening as part of a Deploy operation? There's an option here using cache refresher notifications. Not all events are suppressed by Umbraco Deploy - some that are batched up and fired after the deploy o

What Content Broke My Restore?

Just something I want to keep track of... From a support issue with Umbraco Deploy on Umbraco 8, a customer was getting a failure when restoring, which stemmed from a JSON serialization failure when generating the Umbraco Deploy artifact. It was a bulk restore though, so tricky to figure out which content was causing the problem. And as this serialization is happening in the upstream environment being restored from, a local instance and debugging doesn't help. This hacky code dumped in a view was useful to find out:

Cache Busting Back-Office Client-Side Assets With Umbraco 9+

Since I started at Umbraco the link I've shared the most when helping with support issues has been a blog post article by Dennis Adofi titled "Bumping The Client Dependency Version" . It describes the method used to ensure caches are cleared for client-side assets in the back-office for Umbraco versions up to 8. There's a similar setting for Umbraco 9+ which I've recently had to look up a few times. The configuration setting is at: Umbraco : CMS : RuntimeMinification: Version and is set to a numeric value. It's documented here and, as described, uses a similar version number that can be increment manually or via a build process to ensure the same cache busting behaviour. When upgrading Umbraco to a new version of the CMS you don't need to worry about this, as the version running is already used in the hash that is generated for the cache key. But this doesn't take into account package installs, or your own custom extensions to the back-office.