Andy Butland

This is one of a series of posts looking at migrating Umbraco packages to Umbraco 14 and the new backoffice. Other posts in this series: Introduction Upgrading to Umbraco 14 Preview Creating a Property Editor With Umbraco 14 Adding and Deleting Criteria As of last time I posted in this series, I had a partially working property editor for Personalisation Groups. It could display the information stored against the property, and I'd solved a couple of challenges around retrieving external data and injecting scripts dynaically at runtime. There's not been too much progress since, but I've picked up a few more things along the way that I'll include as a bit of a "grab-bag" in this post. First step to make the data editable was wiring up some button clicks. In angularjs we are used to: <button type="button" ng-click="delete($index)">Delete</button> With Lit, the syntax is: <button type="b

This is one of a series of posts looking at migrating Umbraco packages to Umbraco 14 and the new backoffice. Other posts in this series: Introduction Upgrading to Umbraco 14 Preview Creating a Property Editor With Umbraco 14 Adding and Deleting Criteria A "Hello World" Property Editor The Umbraco documentation is a good guide for getting started, with details on creating an extension and creating a property editor . Using the scripts provided I created an extension within a folder created in my main package project that I called client-src . npm create vite@latest -- --template lit-ts personalisation-groups cd personalisation-groups npm install npm install -D @umbraco-cms/backoffice@next This sets up some files that make up an extension to the backoffice, using the latest preview release from the Umbraco prereleases feed. Next step as described in the docs is to add a vite.config.ts file. I set mine up to export the built files rather than to t

This is one of a series of posts looking at migrating Umbraco packages to Umbraco 14 and the new backoffice. Other posts in this series: Introduction Upgrading to Umbraco 14 Preview Creating a Property Editor With Umbraco 14 Adding and Deleting Criteria Prerequisites As indicated in the official documentation , to work with Umbraco 14 it's likely your development machine needs some updates, which was the case for me. You'll need: To be running .NET 8, which is available at the time of writing in a first release candidate . To be on at least the v17.8 latest preview version of Visual Studio. To download and install this you may need to change the channel used by the installer . To install a minimum version of Node.js 18.16. I have Node Version Manager for Windows installed, which is handy tool both for installing new versions and also switching between versions that you may need for different projects. Package Update The package I'm worki

Probably the largest change coming in the Umbraco ecosystem is the development of a new backoffice , removing the dependency on the legacy angularjs and moving to a modern front-end stack based on web components and Typescript. Not just for HQ in the work needed to update the CMS itself and associated commercial products. But also for the community, whether that be package developers or custom solution implementors looking to extend the backoffice. It reminds me a little of the time coming up to Umbraco 9, the first version running on modern .NET. There was a lot of collbarative effort and information sharing then, as many people were learning new technology and ways of doing things. I'm hoping the next nine months or so leading up to Umbraco 14 will be a similar experience. Although I'm now working at HQ, I'm in a similar position to many in finding a lot of the change new and something I'm going to need to get up to speed with. Like, I suspect, a number of Umbraco

In some recent work with Umbraco I’ve been looking to migrate an API from using the Newtonsoft.Json serialization library to the newer, Microsoft one, System.Text.Json . The reason for doing this was to align the API we created for Umbraco Forms with the content delivery API available in Umbraco 12. We’re keen to ensure these APIs across Umbraco products are similar both in terms of behaviour but also behind the scenes when it comes to the libraries we are using. As such I had a few updates to make – mostly straightforward, and some that needed a bit more research and development. Deserialization via a Model Binder When a form is submitted, a model binder is referenced in the controller’s action method to deserialize the incoming request to a strongly typed model: Within the model binder we had the following code to deserialize the request into the appropriate type: To convert this it was just necessary to change JsonConvert.DeserializeObject to JsonSerializer.Deser

Cross-posting a couple of articles written for the Umbraco blog on the introduction of Redis Distributed Cache and Azure Cognitive Search to the Umbraco Marketplace , in order to improve performance and functionality: Introducing Redis Distributed Cache to the Umbraco Marketplace Populating and Querying Azure Cognitive Search in the Umbraco Marketplace

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:

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