Personalisation Groups for Umbraco 14

Nearly a year ago now, I started a series of blog posts looking to migrate a package to Umbraco 14. In hindsight, that was a little premature... both in terms of stability (platform) and ability (my skills with modern front-end). So whilst I made some progress, it was slow going and led to a few occasions of getting stuck.

Then the day job called, and priority needed to be getting Umbraco's commercial products ready for Umbraco 14, for which we are almost there.

I took a recent "cycle hack" at work to see if I could go back to the personal package, and, based on what I've learnt, get that released for Umbraco 14. Which I've now done. You can find the release candidate for the "Personalisation Groups" package here on NuGet.

Am pleased to say it was a lot quicker and easier to make progress coming back to it now.

Whilst the package isn't particularly complicated compared to some others in the Umbraco community, it's probably at a useful size for review if you are interested in building packages on Umbraco 14. Not too big, but contains a few different concepts that are likely needed in other packages.

You can find the source code here on GitHub if you checkout the develop branch.

Some concepts and features on the front-end to note, all of which can be found in the PersonalisationGroups/Client folder.:

• The core of the package is a property editor, so you'll see how to create and register one.
• The property editor uses a modal window for the provision of different criteria settings, using Umbraco's modal context.
• The package is extensible with different criteria, several of which ship with the package. Partly this is defined in C#, which hasn't changed, but the front-end aspects have.
• Firstly, the user interface for providing the details of a given criteria uses a property editor. So each criteria - "days of week", "country" etc. - has it's own property editor registered using a manifest.
• And secondly, each criteria also has a "translator" - used to display something human-readable parsed from the JSON definition of the criteria. So this is a good example of a custom extension point - where I've defined an interface for an API and registered the various implementations via a custom manifest type.

Server-side changes were more minimal, but you will find an example of a management API, created to surface the necessary data we need in the backoffice. You'll find the controllers and other classes for this in the PersonalisationGroups/Api folder, and can browse the definition for the API at under the main Umbraco Swagger UI at: /umbraco/swagger/index.html?urls.primaryName=Personalisation+Groups+Management+API

In terms of project structure I've gone back to a single project now, which is created as a Razor Class Library. That way there's one .dll and the client-side files are no longer written to disk. The contents of the .csproj file, the Build folder and the front-end configuration in the Client folder should also be useful reference as to how the package is built.