Umbraco

Umbraco 15 Release Candidate

Get your hands on all the new features

Bjarke Berg
Written by Bjarke Berg

Umbraco 15 delivers key updates to streamline development, especially for larger content-driven sites. With a new rich text editor UI, client credential support, and improvements like hybrid caching and block-level variants, this release is focused on enhancing performance and flexibility. Developers can also expect upgraded dependencies, including .NET 9, and several experimental features worth exploring.

Overview:

What’s new in Umbraco 15

Umbraco 15 introduces some solid improvements and refinements aimed at making development smoother and more efficient, especially for bigger sites with a lot of content to manage. With updates across the board, this release improves flexibility and brings new tools that simplify working with the APIs. There’s plenty to explore in this release, and it’s definitely worth diving into.

Hacktoberfest 2024 🎃

With the release candidate out right at the start of October, we think it makes to include Umbraco 15 in the Hacktoberfest celebrations. This year, providing feedback and submitting bug reports for the Umbraco 15 release candidates will count as a contribution. Check out the Hacktoberfest 2024 blog post for more details.

Alternative UI for the Rich Text Editor

Due to a licensing change, TinyMCE, the rich text editor used in the backoffice, cannot be upgraded to the latest version. The current version of TinyMCE, version 6, is no longer supported.

To mitigate this, we’re taking advantage of the new Umbraco.RichText schema introduced in Umbraco 14, and shipping a new rich text property editor UI. Since we’re using the same schema and data you can update any existing rich text editor’s underlying data types to this new editor. 

The built-in data type known as ‘Rich Text Editor’ will default to the new editor UI from Umbraco 15 onwards, and TinyMCE is officially deprecated.

While TinyMCE is widely regarded as one of the best rich text editors available, this new alternative offers certain advantages, particularly in handling copy-pasting from applications like Microsoft Word or Google Docs.

The new RTE, based on TipTap, requires a bit more work to include in the backoffice but also comes with a lot of flexibility. We’re working on both the user experience and and configuration to ensure you can do what is needed from an RTE in Umbraco.

We greatly appreciate any feedback on this feature and encourage you to update your existing rich text editors to the new alternative to help ensure everything functions as expected.

If you wanna read more, please take a look at the following links:

 

Client Credentials

We have introduced a new user field for Umbraco users, allowing them to be classified as either a standard user or an API user. The API user is a newly developed feature aimed at simplifying the configuration of Client Credentials (ClientId and Secret), enabling seamless use of the Management API in machine-to-machine scenarios.

Unlike standard users, API users do not require passwords and cannot access the Backoffice. However, they can still interact with the Management API and are assigned to user groups, following the same permission structure as regular users.

In addition to users, Client Credentials are also available to members when configured through the AppSettings. The Backoffice UI now reflects the distinction between API Members and regular Members.

Since this feature modifies the user table in the database, we encourage thorough testing. Even if you do not use this feature, the original functionality should remain unaffected.

For more information about this feature, you can review the following pull requests:

 

Extension Manifest Type Architecture

In Umbraco 15, the Extension Manifest Type architecture is transitioning to a global definition, allowing separation and enabling manifests from extensions to be registered as valid types within the extension registry.

Starting with Umbraco15, Extension Manifests (in TypeScript) will be declared using the global type UmbExtensionManifest. As a result, you should discontinue using ManifestTypes imported from @umbraco-cms/backoffice/extension-registry. Here’s how to declare manifests moving forward:

export const manifests: Array<UmbExtensionManifest> = [
   {
      type: '...',
      ...
   },
   ...
];

Declaring Custom Types

For those who declare custom Extension Manifest Types, you can now define them using the following approach. The example below demonstrates the declaration of a Block Editor Custom View. Note that property names must be unique to prevent conflicts, so ensure you use a suitable postfix.

declare global {
   interface UmbExtensionManifestMap {
      umbBlockEditorCustomView: ManifestBlockEditorCustomView;
   }
}

 

Lazy-Loaded Content (Experimental)

This feature is considered experimental and, depending on feedback, may be removed before the final release of Umbraco 15.

A key feature that will significantly benefit large sites with extensive content is the new lazy-loaded content system. Instead of caching all content at all times, only a limited set will be loaded during startup, with the rest being loaded on demand and remaining in cache for a limited period. This should lead to a smaller memory footprint and faster boot scenarios.

Historically, the published content cache contained not only property data but also structural information. Moving forward, structural data will no longer be stored in the published cache.

Navigation

To retrieve structural information, such as parent and child relationships, you will now need to use the new IDocumentNavigationQueryService, IMediaNavigationQueryService or the corresponding versions for the recycle bins. These serviced includes a local cache, allowing for fast lookups when navigating the structure of published content

Routing

Since the standard Umbraco routing previously relied on the full published content cache, we have reimplemented it. Instead of determining routes at request time, routing will now be handled at save and publish time. The routing data is stored and can be quickly retrieved using the new IDocumentUrlService, which provides a document key based on a given route.

Hybrid Caching

Content properties are cached using the new HybridCache introduced in .NET 9. This system caches both published and draft content in memory and can also optionally store data in an out-of-process cache, utilizing Microsoft’s IDistributedCache abstraction.

Cache Seeding

Since the cache no longer contains all documents or media items, you now have the option to customize which items are preloaded during startup. Umbraco provides two seeding providers out of the box: one uses a breadth-first search in the content tree and seeds a configurable number of items, and the other allows you to seed all documents of a specific document type.

To implement custom seeding, you can register your own ISeedKeyProvider implementation, which simply needs to return the keys of the documents that should always remain in the cache.

Testing the new Cache

Feedback and testing of this feature is critically important to ensure that we do not introduce a feature that may necessitate significant changes in the near future. Given that routing and content delivery are core functionalities of Umbraco, we encourage your assistance in ensuring this feature is fully prepared for the final release. 

By migrating your sites to this release candidate and verifying that your website continues to function as expected, you will provide invaluable testing for this feature, and if it does not work as expected let us hear about it.

For more information about this feature, the following links can be interesting:

 

Block-level Variants (Experimental)

This feature is considered experimental and, depending on feedback, may be removed before the final release of Umbraco 15.

Another feature we’ve been exploring for quite some time is block-level variation, which allows editors of multilingual websites to maintain the same structure for subsets of their content - such as block lists or block grids - across all languages, while easily varying a subset of the content. Umbraco 15 RC introduces this capability.

By using a variant content type that includes a shared/invariant block editor, which contains variant blocks, you can now customize content for different languages more efficiently.

The shared/invariant data has always been saved together with the default language, and while this is still the case, the new block format keeps track of what blocks are exposed on which languages. This is an attempt to avoid situations where a new block is introduced and published in the default language, but not handled in other languages. Thereby no empty blocks show up, before the other languages are published.

 

To support this feature, a migration will run on all block-based content during upgrade. This means, depending on the site, the upgrade process can be longer than usual. Testing that this migration runs smoothly, and that the content works as expected afterwards, is highly valuable to ensure all scenarios are accounted for. 

Please note, this feature is still under consideration for removal before the final release of Umbraco 15, so ensure you have a database backup.

For more information about this feature, the following links can be interesting:

 

Updated Dependencies

Umbraco 15 has been updated to support the latest major versions of all its dependencies. The most significant update is the upgrade to .NET 9, which is currently in its release candidate phase - Like Umbraco 15. This version introduces a range of low-level performance improvements and provides access to the latest features in C# 13.

In addition to .NET 9, we have also upgraded the web framework ASP.NET Core to version 9 and the logging framework Serilog to version 4.

For more details, please refer to the following links:

 

Breaking Changes

Umbraco 15 introduces several breaking changes. While most should have low impact, there are a few noteworthy changes to be aware of.

Dependency Updates

Numerous dependencies have been upgraded to their latest major versions, potentially introducing breaking changes. The most significant update is the move to .NET 9, though other dependencies also include changes that may affect your implementation.

Async Method Signatures

Several method signatures have been updated to Async, as part of efforts to future-proof the codebase. While not all of these methods have synchronous counterparts, migrating to the new Async signatures should be straightforward.

Claims Removed from ClaimsIdentity

The following claims have been removed from ClaimsIdentity:

  • startcontentnode 

  • startmedianode

  • allowedapp

This change primarily enables more seamless access control during updates for users of the Management API. Currently, we need to revoke tokens when access changes occur, which is not ideal for logged-in users.

Additionally, this update lays the groundwork for enabling external authorization for specific operations that are presently tied to these ClaimsIdentity claims.

Changes to GetAll Methods in the Service Layer

The behavior of GetAll methods in the service layer has been updated to prevent a common issue where accidentally passing an empty array would return all items.

Now, GetAll methods will no longer accept any input and will return all items by default. For cases where multiple items are needed, a new GetMultiple method has been introduced, allowing you to pass an array of keys and retrieve the corresponding items.

Routing at Publish Time

Routing is now determined at publish time, rather than at request time. Although we don’t anticipate many cases where this would affect custom implementations, it could impact any routing logic that previously relied on request-time determination. This change has also led to a few breaking changes in routing-related signatures.

Variant Block Support

The introduction of variant block support has resulted in some breaking changes to block models and indexing behavior.

IPublishedSnapshot and IPublishedSnapshotAccessor Removed

The work on new lazy loaded content means that the snapshots are no more. Therefore has IPublishedSnapshot and IPublishedSnapshotAccessor been removed.  Instead you can inject the cache directly using IPublishedContentCache.

For more information, refer to:

 

Known issues

The following issues are known and will be resolved before the final release of Umbraco 15:

.NET 9 Final Release

Umbraco 15 RC currently runs on a release candidate of .NET 9. It will be updated to the final version prior to the official release.

Dependencies Not Yet Updated to .NET 9

Some dependencies, including OpenIddict, are still not updated to .NET 9. These will be updated before the final release.

Block-Level Variant Indexing

Search indexing for block-level variants does not fully work. At this time, only invariant values are indexed. This will be resolved before the final release.

Tags in Variant Blocks

Tags within variant blocks will currently either not resolve or resolve as invariant, leading to an undesirable editing experience when using the same tags group in “regular” content. This will be fixed before the final release.

Validation with Variant Blocks

As a whole, validation should be considered non-functional for block editors, and particularly for block-level variations. Do not expect to rely on block-level validation at this time. Both client- and server-side validation will be remedied before the final release.

Pending Changes Displayed on Default Language

When working with variant blocks, the default language may incorrectly show pending changes when no changes are present. Similarly, the non-default languages might fail to show pending changes, despite changes having been made in variant blocks for those languages. This will be addressed before the final release.

Documentation & Release Notes

The new version of documentation for Umbraco 15 is ready and includes a new article on how to extend the help menu in the backoffice.

For full overview of all the features, improvements and fixes included in Umbraco see the release notes:

 

First of all, please note that .NET SDK 9.0.100-rc.1 is a prerequisite.

To use the new release candidate you can install the new Umbraco dotnet template and from there use the RC installation documentation

Template and CMS packages including prerelease versions are available from NuGet:

 

How to provide feedback

If you find issues that are not already reported, please report them on the GitHub tracker by following the link or selecting “🐛 Bug Report” when creating a new issue.

And remember feedback and reports from testing this release candidate count as a contribution to Hacktober 2024. Don’t forget to add it to your Hacktoberfets Activity Log if you want to make it count.

 

What’s next?

We plan to be rolling out additional release candidates to address minor bugs and incorporate feedback from the community. As we progress, these updates will primarily focus on fixing issues identified during testing.

In addition to resolving any bugs, our efforts will include making HQ packages like Umbraco Forms and Deploy available. We’re also prioritizing the availability of Umbraco 15 on Umbraco Cloud upon its release, along with ongoing documentation efforts.

We’re targeting the public release of Umbraco 15 for November 14, 2024.

We’re eager to hear your feedback on the Umbraco 15 Release Candidate - happy testing! 🙌