Andy Butland

In working through the development of an Umbraco integration recently, I had a need to setup an OAuth authentication process to secure access to an API. At first glance, not too tricky – the provider had a well documented process to follow. However I ran into a few challenges when considering how this process can work for an Umbraco package – i.e. an integration that’s not for a single website, but for many, and for ones we don’t know the domains for at the time of configuration. All in all it seemed worth a blog post. The integration Specifically, the integration I was working on was one between Umbraco Forms and HubSpot, the CRM platform. We wanted to have a custom workflow that editors could add to a form, map the fields in the form to the fields defined on a “contact” record at HubSpot, and then, when a form is submitted, use the available APIs to map save the form submission data as a HubSpot contact. My colleague Warren worked on the original integration, which we released

Over the past couple of weeks at Umbraco HQ we've been working on the migration of the Forms package to V9 and .NET Core. I've been blogging recently on the topic, where I've shared articles on various aspects of the work needed and changes found in migrating an open-source package. Unsurprisingly though, that didn't cover everything a package developer might encounter, so I thought it was worth an addendum or two on some further topics found in the Forms migration. Source Code and Branching Most developers with a package out for V8 are unlikely to be able to simply call it "done" and start a new repository for V9 - and Forms in no exception. Broadly we expect to align the package with the CMS plans for long-term support , and so we'll still be making bug fixes and, for a while, adding features to the V8 version. I suspect different developers will adopt different approaches here, so whilst your mileage may vary, this is how we've approached

This is one of a series of posts looking at migrating Umbraco packages to V9 and .NET Core. Other posts in this series: Introduction A False Start A Clean Start - Controllers, Services, Configuration and Caching Criteria Providers - Working With HttpContext Leaning on Umbraco Migrating Tests Extension Methods Migrations Wiring It All Up Distributing and Wrapping Up Update 29th March, 2021, 18:15 - I've updated this article to discuss how to properly handle the NuGet distribution of content files, which was a problem I was having and discussed in the first publication of this post. Thanks to Bjarke and Warren for sorting me out! Installing the Package This post should be the last one, as - good news - the package works now in V9, and you can try it out if you like, by doing the following. Create an Umbraco project based on the alpha 4 template . Install Umbraco and check the back-office is up and running. Install the package - eit

This is one of a series of posts looking at migrating Umbraco packages to V9 and .NET Core. Other posts in this series: Introduction A False Start A Clean Start - Controllers, Services, Configuration and Caching Criteria Providers - Working With HttpContext Leaning on Umbraco Migrating Tests Extension Methods Migrations Wiring It All Up Distributing and Wrapping Up Dependency Registration and other Start-up Tasks At this point I've gone some package functionality that compiles and some unit tests that pass, but there's no way to actually run it yet and it won't work if somehow installed into an Umbraco V9 website. In order for that to happen I need to ensure that the services I've created, which are being constructor injected into various classes that need them, are registered with the IoC container. I've also got to make sure the package migration will run and some custom routes are in place for the controllers that the back-

This is one of a series of posts looking at migrating Umbraco packages to V9 and .NET Core. Other posts in this series: Introduction A False Start A Clean Start - Controllers, Services, Configuration and Caching Criteria Providers - Working With HttpContext Leaning on Umbraco Migrating Tests Extension Methods Migrations Wiring It All Up Distributing and Wrapping Up Package Distribution There are at least a couple of ways to distribute Umbraco packages. The original - and still supported in Umbraco V9 - is to create a package through the back-office, selecting the files, schema and content that you wish to include - and saving that into zip file packaged according to a custom format. This file can be uploaded to our.umbraco.com , from where it can be downloaded by other users for install on their projects, or discovered and installed via the back-office. The approach that's more common in the .NET space as a whole, is to distribute via NuGet

This is one of a series of posts looking at migrating Umbraco packages to V9 and .NET Core. Other posts in this series: Introduction A False Start A Clean Start - Controllers, Services, Configuration and Caching Criteria Providers - Working With HttpContext Leaning on Umbraco Migrating Tests Extension Methods Migrations Wiring It All Up Distributing and Wrapping Up Migrating Extension Methods The functionality of the Personalisation Groups package is exposed via some extension methods added to Umbraco's IPublishedElement and UmbracoHelper . For example, given a set of content elements drawn from child nodes, a multi-node tree picker or a nested content property, you can show just the ones relevant to the user using something like this: @foreach (var post in Model.Content.Children .Where(x => x.ShowToVisitor())) { <h2>@post.Name</h2> } Umbraco's rendering APIs haven't changed a great deal, so not much modifi

This is one of a series of posts looking at migrating Umbraco packages to V9 and .NET Core. Other posts in this series: Introduction A False Start A Clean Start - Controllers, Services, Configuration and Caching Criteria Providers - Working With HttpContext Leaning on Umbraco Migrating Tests Extension Methods Migrations Wiring It All Up Distributing and Wrapping Up Adding a Tests Project Having ported a reasonable amount of the functionality from the Personalisation Groups package over to a version for Umbraco V9 running on .NET Core, I've created a tests project and migrated over most of the existing unit tests. There wasn't too much required here that wasn't fixed with some find and replace. I created an NUnit test project, which aligns with what Umbraco use in the CMS core, but that isn't necessary and you can use what you prefer. I'd previously used MSTest which still available in .NET Core. The only changes needed wer

This is one of a series of posts looking at migrating Umbraco packages to V9 and .NET Core. Other posts in this series: Introduction A False Start A Clean Start - Controllers, Services, Configuration and Caching Criteria Providers - Working With HttpContext Leaning on Umbraco Migrating Tests Extension Methods Migrations Wiring It All Up Distributing and Wrapping Up Amends After Review I received some useful pointers on what I've done so far in this package migration from Bjarke Berg, who heads up the .NET Core transition project at Umbraco. All of which I've now applied. The general theme from all of them is that there are more places where I could lean on existing functionality of Umbraco to help out. Umbraco Dependency The first step taken after creating a new project for the package was to reference the Umbraco NuGet package from the nightlies feed. He pointed out that rather than referencing Umbraco.Cms.Core , it would be better

This is one of a series of posts looking at migrating Umbraco packages to V9 and .NET Core. Other posts in this series: Introduction A False Start A Clean Start - Controllers, Services, Configuration and Caching Criteria Providers - Working With HttpContext Leaning on Umbraco Migrating Tests Extension Methods Migrations Wiring It All Up Distributing and Wrapping Up Migrating Criteria Providers Within the package I'm looking to migrate to Umbraco V9 and .NET Core, Personalisation Groups , there are a number of Criteria classes, used as methods of identifying users for the purpose of personalising their website experience. These are things like day of week, time of day, presence of a querystring, a cookie value etc. Most of these rely on something external to the class in order to retrieve a value from the browsing context in order to match against what's configured in the CMS against the content, in order to decide whether there's a

This is one of a series of posts looking at migrating Umbraco packages to V9 and .NET Core. Other posts in this series: Introduction A False Start A Clean Start - Controllers, Services, Configuration and Caching Criteria Providers - Working With HttpContext Leaning on Umbraco Migrating Tests Extension Methods Migrations Wiring It All Up Distributing and Wrapping Up File > New Project Having decided on a new repository for the migration of the Personalisaton Groups package to Umbraco V9 and .NET Core, I started with a brand new solution, containing a single project targetting .NET Standard 2.0. I picked this version mainly just to match the decison made by Umbraco themselves, when updating the class libraries that make up the code for the CMS itself. We can see if there's any reason to change it later. Adding Reference to Umbraco I then added the first external dependency - Umbraco itself. At the time of writing, the release intended fo

This is one of a series of posts looking at migrating Umbraco packages to V9 and .NET Core. Other posts in this series: Introduction A False Start A Clean Start - Controllers, Services, Configuration and Caching Criteria Providers - Working With HttpContext Leaning on Umbraco Migrating Tests Extension Methods Migrations Wiring It All Up Distributing and Wrapping Up One Codebase or Two? The first decision I took on migrating Personalisation Groups to Umbraco V9 running on .NET Core was on whether to attempt to maintain a single code-base for the supported versions. A couple of years ago, I wrote an article for Skrift outlining the approach I took when V8 came out, which was to maintain versions for V7 and V8 in the same source code repository and in the same branch. In summary, the approach I took there was to extract, from what was then a V7 package, the common code that had no dependency on Umbraco at all. There turned out to be quite a bit o