This follows the release of a beta two weeks ago. Since then, we've spent the time looking into reported issues, bringing in some additional bug fixes, and generally polishing to get to the point of releasing the RC today. That'll continue over the next period, but we'll be limiting change now to only the resolution of issues found or reported in regression testing.
Along with the beta release a fortnight ago came an introductory blog post, which, if you haven't read it already, I'd recommend doing so before proceeding with this one. It sets the scene a little more broadly for those following Umbraco's Long-term Support (LTS) release cycle. Umbraco 17 will be the next LTS, so for those of you looking to move up from Umbraco 13, there's a fair bit to review and consider when planning your upgrade.
With this blog post, I want to dive into more detail on those aspects of Umbraco 17 that are new, even for those who have kept up with the short-term support (STS) releases and are already running on Umbraco 16.
However, let's first address the usual topics related to a major Umbraco release. Umbraco 17 runs on .NET 10, the latest release of .NET and available at the time of publication as a release candidate itself. You can download the latest version from here, and you will need to do that in the environment where you want to install Umbraco 17.
There are some breaking changes involved in the new release, which you can find detailed here. It's worth particularly calling out the changes related to Microsoft's decision to deprecate Razor runtime compilation. In order to work toward better support of the replacement for this - hot reload - in the future, we've broken out the components necessary for InMemoryAuto models builder and razor runtime compilation into their own package. So you'll need to make sure to reference this if installing or upgrading and wanting to retain these features.
Other documentation updates as they relate to new features are linked along with the discussion on the feature below.
We've taken the opportunity to upgrade all Umbraco dependencies to their latest compatible versions, including major version updates to the NPoco, OpenIddict, Serilog and Swashbuckle libraries. Further details are available in the breaking changes documentation.
A project over the last six months has been to solve what's been a long-term question of why we can't load balance the backoffice. Load balancing of Umbraco for the front-end website has been possible for a long time, but it's always come with this caveat of only having a single server for the backoffice.
We wanted to remove that. Partly, as we know, Umbraco is increasingly being used for larger editorial teams, where providing resilience and resources only via scaling up a single server is too limited. We also wanted to simplify the process of load balancing Umbraco, such that it's possible to more straightforwardly scale the whole Umbraco application, without the complication of splitting into backoffice and front-end web servers.
The first part of the project was to analyse and find the areas where we were currently limited to a single server setup, which led to the following set of concerns we had to address.
Also known as "isolated caches", these are held within Umbraco to improve performance at the data layer. Requests to retrieve a given entity even outside of the front-end caches don't necessarily always hit the database. Rather, we maintain repository-level caches that are invalidated only when the entity is updated.
This presented a problem for load balancing the backoffice, as we could easily have a scenario where, after one server receives a request to save a content item, a different server receives the request to publish it. The publishing server would have an outdated version of the item in its repository cache because the refreshers that invalidate these caches haven't run yet.
To address this issue, we have introduced a cache version mechanism that allows servers to detect when their isolated caches are out of sync. When an out-of-sync cache is detected, we automatically roll the cache forward to bring it up to date.
As these changes are only relevant for sites with load-balanced backoffice environments, we've made this an opt-in feature.
Umbraco has several periodic background jobs that can be divided into "per-server" and "distributed" tasks. The former we want to run on every server in a load balanced setup, but the latter should only run once on each occasion for the entire cluster.
The firing of webhooks is an example of a distributed task - if that were to run on every load balanced server we'd at best have unnecessary processing and at worst cause issues downstream by sending duplicate messages.
We've moved the tracking of distributed jobs now to the database, with each server querying and this to pick up and run jobs.
Long-running operations that use a "submit and poll" technique were bound to a single server, as the status of the ongoing task was held in memory. We've addressed and improved this by introducing a dedicated service for these operations, and storing the state of them in the database.
As well as state stored in memory, another thing to avoid with load balanced setups is using files on local server disks to persist information. Umbraco had one of these we needed to address, a small and innocuous file used for tracking cache and search index status, which in turn controls whether Umbraco will boot hot or cold. Again a database backed service was introduced for this.
We make use of the SignalR library to allow server code to send asynchronous notifications to the client-side backoffice. The main use case of this currently is for cache invalidation. When requesting the details of entities such as data and document types, the backoffice application will cache these client-side until such time as a message is received from the server indicating that they have changed. This is a big performance improvement from having to retrieve the details from the server every time they are required.
To support load balancing these features it is necessary to introduce an infrastructure component to distribute notifications to all the servers, using standard techniques for scale-out of SignalR.
To read more about the topics introduced above and in particular how we advise configuring your Umbraco setup for load balancing, please see the documentation website.
We're now added a specific article on the topics related to load balancing the backoffice.
Clearly, this has been a large undertaking, but having completed the development work, we've been testing for several weeks and have confidence in the setup. It'll be a continued focus for us over the release candidate period, and of course, we highly welcome external validation and input on this.
Umbraco stores quite a number of system dates within its database, including creation and update dates for entities, dates related to user actions, and for the setup of scheduled publishing. There is currently an inconsistency here, though, as we sometimes use server time and in others coordinated universal time (UTC). Storage is also of an unspecified datetime, without timezone information, meaning it's difficult to be sure as to exactly what date and time is represented - particularly if an application has moved between servers running different clocks.
For Umbraco 17, we have addressed this so that we consistently persist UTC dates and expose these from the management API, delivery API, and in Razor template rendering.
We've also provided a migration that will run on an upgrade to Umbraco 17, which will take all dates currently stored in server time and update them so that they are now persisted as UTC.
You have control over this migration via configuration, so it's worth reading the documentation to understand what will happen on the upgrade and whether you need to adjust the default behaviour. You'll find this on the documentation page detailing breaking changes for Umbraco 17, under the heading "System dates are updated to UTC".
It's important to note that the changes and migration described above only apply to system dates. Dates defined for content and managed by editors - using the datetime picker - are not touched. This is deliberate, as of course we can't know what a particular date used on a document type in a given project represents in terms of timezone.
However we still had a similar problem we wanted to address: to allow more options when designing document types to better represent the content that editors will be managing.
To do this we've introduced four new date time property editors, for explicit representation of date only, time only, unspecified dates and timezone associated dates. You can read more about these in the Umbraco documentation on date time property editors, and see them in action below.
Much of the focus over the past months, and really all releases since Umbraco 14, has been ensuring we get to a point where we have feature parity with the previous LTS and any new ways to do things are established and polished. You'll have seen this if you've been following along with the various STS and minor releases since.
As such, there's not too much on this topic completely new in Umbraco 17 itself, but there are a few things I'd like to mention.
Firstly, we feel that with collection views, we've found a happy medium between not showing items in the tree at all (Umbraco 13 behaviour) and always showing all items (as in Umbraco 16). You'll now not see the items in the tree when loading a collection, but the surrounding siblings will be shown when you edit an item. Editing will always be in full workspace view. In this way, the context of the item in the tree is available when selected, which can be useful, but we don't clutter the view.
Entity signs are available in the tree, with tooltips and the option for multiple signs per item. Out of the box, we show signs for core features such as protected items and when changes are pending for publishing. Importantly, though, these are available for extension, and we expect HQ products such as Engage and Workflow to be able to use these to provide additional context to editors.
You can read more on using this extension in the documentation about backoffice signs.
We've restored the Umbraco news dashboard that was available in Umbraco 13, and refreshed it with the latest stories and more permanent handy links to the various sources of HQ and community support and documentation.
Finally, of course, there's a new photo for the login screen. Who is on it? Well, that would be telling… you'll have to download the release candidate to find out!
More seriously, we are always extremely grateful for those who take the time to try out new versions of Umbraco within the release candidate period, as really, this is the best time to catch any issues we've missed and address remaining concerns.
If you’re upgrading a project, make sure to review the version-specific upgrade guides from Umbraco 16. If passing through other major versions, it's worth also reading back over the equivalent pages for these other updates (they are all listed in the beta blog post).
If you do find anything, after a quick look to see if the problem is already reported, please provide details in the CMS tracker, indicating which version you've discovered an issue in.
You'll find the release candidate on NuGet and details of the release on both GitHub and releases.umbraco.com.
Today, we release the Beta of Umbraco 17!
Wait… what? A beta version…? Yes! From the release of Umbraco 17 onwards, every major version of Umbraco will include a beta six weeks before launch.