Ctrlk

Breaking Changes Overview

Breaking changes introduced in each major version of Umbraco CMS, with notes on what to update when upgrading.

Use the information below to learn about any potential breaking changes and common pitfalls when upgrading your Umbraco CMS project.

If any specific steps are involved with upgrading to a specific version they will be listed below.

Use the general upgrade guide to complete the upgrade of your project.

Breaking changes

Umbraco 17

System dates are updated to UTC

In earlier versions of Umbraco, system dates have been primarily persisted as server time without time zone information, with some stored as UTC. With Umbraco 17, system dates are now always stored in UTC.

To ensure that existing stored system dates align, a migration will run when upgrading to Umbraco 17.

The migration consists of:

  • Determining the current time zone for the server.

  • If a time zone is detected and it is not already UTC, database queries will update all system dates previously stored as server time to UTC.

There is configuration available to customize this migration.

Adding the following configuration setting will disable the migration from running.

  "Umbraco": {
    "CMS": {
      "SystemDateMigration": {
        "Enabled": false
      }
    }
  }

You can also explicitly define the time zone for your server. If this is provided as the standard English name of the time zone, it will be used over the detected one.

  "Umbraco": {
    "CMS": {
      "SystemDateMigration": {
        "LocalServerTimeZone": "Eastern Standard Time"
      }
    }
  }

Progress of the migration is written to the Umbraco log file.

For more details on this update see the following PRs: #19705, #19798, and #20112.

InMemoryAuto models builder and Razor runtime compilation have moved into their own package

The InMemoryAuto models builder and the Umbraco feature that uses Razor runtime compilation (Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation) have been moved to a separate package: Umbraco.Cms.DevelopmentMode.Backoffice.

Why was this change made?

Razor runtime compilation is obsolete in .NET and prevents Hot Reload from working. Since InMemoryAuto depends on Razor runtime compilation, keeping it in the core would prevent Hot Reload from working.

By moving InMemoryAuto to its own package, Umbraco can enable Hot Reload by default for a better development experience.

When you need to reference Umbraco.Cms.DevelopmentMode.Backoffice?

Add the package if any of the following apply:

  1. You use the InMemoryAuto models builder:

    • By explicitly selecting InMemoryAuto.

    • By starting a new project with the default --models-mode (which is InMemoryAuto, adding the package automatically).

  2. You rely on Razor runtime compilation to edit templates via the backoffice.

  3. You use the RoslynCompiler class (you'll also need to update your namespace usings).

The choice to include Umbraco.Cms.DevelopmentMode.Backoffice depends on how you work with models and templates. It is not based in the hosting environment, and using it enables Razor runtime compilation and disables Hot Reload.

When you do not need the package?

You don’t need to reference it if you use Models Builder in a source-code mode, such as:

  • AppData

  • SourceCodeAuto

  • SourceCodeManual

Important! These modes do not rely on Razor runtime compilation. However, ensure the following settings are removed from your .csproj file.

<RazorCompileOnBuild>false</RazorCompileOnBuild>
<RazorCompileOnPublish>false</RazorCompileOnPublish>

Additional notes

If you use the ModelsMode enum or its extension methods, use the string constants in Constants.ModelsBuilder.ModelsModes instead.

For more details on this update, see PR #20187.

Date Picker Property Editor Kind

The existing date picker that returns a DateTime object has been updated to provide one with a Kind of Unspecified. Previously, it was UTc, but this was incorrect because Umbraco cannot determine the intended use of a particular date picker. This update makes that explicit.

For more details on this update see the following PR: #19727.

Color Picker Property Editor

The color picker property editor used for the built-in approved color Data Type will now always make available a PickedColor object. Previously, this was only output when labels were configured on the Data Type. Without labels the previous behavior was to expose a string.

For more details on this update see the following PR: #19430.

Segmented Content Fallback

The Template and Delivery API output for segmented properties will perform an explicit fallback to the default segment, if they do not have a value.

In earlier versions, if you created a segmented version of a document, you had to complete every property. This made segments an editorial burden unless the behavior was customized. With the new behavior, segmented content now only needs to have the properties that require a segmented value completed.

For more details on this update see the following PR: #20309.

Removal of Extension Methods

Extension and public helper methods, unused in Umbraco and obsolete in previous versions, have been removed.

These are:

  • GetAssemblyFile

  • ToSingleItemCollection

  • GenerateDataTable, CreateTableData, AddRowData, ChildrenAsTable, ChildrenAsTable all related to DataTable

  • RetryUntilSuccessOrTimeout

  • RetryUntilSuccessOrMaxAttempts

  • HasFlagAny

  • Deconstruct

  • AsEnumerable, ContainsKey and GetValue extending NameValueCollection

  • DisposeIfDisposable

  • SafeCast

  • ToDictionary on object

  • SanitizeThreadCulture

For more details on this update see the following PR: #17051.

Tiptap external extensions package

The import namespace @umbraco-cms/backoffice/external/tiptap has been removed, replaced with @umbraco-cms/backoffice/tiptap.

This means backoffice extension code must be updated from:

import { Editor } from '@umbraco-cms/backoffice/external/tiptap';

To:

import { Editor } from '@umbraco-cms/backoffice/tiptap';

For more details on this update see the following PR: #20256.

Client-side user related entities

The following components have been moved from user to current-user and exported.

  • UmbCurrentUserAllowMfaActionCondition

  • UmbCurrentUserConfigRepository

  • UmbCurrentUserConfigStore

  • UMB_CURRENT_USER_CONFIG_STORE_CONTEXT

They should now be imported from @umbraco-cms/backoffice/current-user.

For more details on this update see the following PR: #20125.

URL provider updates

URL providers are now responsible for generating content preview URLs. To achieve this, the IUrlProvider interface has been extended with the GetPreviewUrlAsync() method.

The IUrlProvider interface must also provide a unique system-wide Alias.

Lastly, the UrlInfo class has been revamped to support this setup.

For more details on this update see the following PR: #20021.

See also this announcement: #27.

HTTPS is enabled by default

The default value of the UseHttps configuration in Global Settings has been changed from false to true.

If you need to run Umbraco without HTTPS, make sure to update appsettings.json accordingly.

Authentication for the backoffice client

Following the draft Request for Comments (RFC) from the Internet Engineering Task Force (IETF), the backoffice client authentication has been changed to tighten security.

This change affects only the backoffice client authentication against the Management API. API user authentication against the Management API remains unaffected, as does the Delivery API.

This change might affect custom backoffice extensions that interact with the Management API. All fetch requests to the Management API must include credentials by declaring credentials: 'include'.

By default, backoffice extensions built using the HQ package starter template are not affected.

For more details on this update, see the following PRs: #20779 and #20820.

Updated dependencies

As is usual for a major upgrade, Umbraco’s dependencies have been updated to their latest compatible versions.

NPoco was updated by a major version from 5.7.1 to 6.1.0. There were some changes to Umbraco code necessary after this update, so customer projects or packages that use NPoco directly may also require some changes.

Swashbuckle was updated to a new major version 10.0.1. If you are using this library to provide a Swagger document in your package or project, changes around namespaces, nullability, and types will be encountered.

The other specific dependency updates made for Umbraco 17 for server and client-side libraries can be found in these PRs:

Sections

In UmbSectionContext, the setManifest() method has been replaced with a manifest. This is done to align with most other extension types. The ManifestSection interface has been modified to extend ManifestElementAndApi instead of ManifestElement. The UmbSectionElement that a section extends from now extends UmbControllerHostElement instead of HTMLElement.

For more details on these updates, see the following PRs: #20305

Other breaking changes

The full details of breaking changes can be found from this list of labelled PRs.

Umbraco 16

TinyMCE is removed

In Umbraco 15, two property editors were available for a rich text editor: TinyMCE and TipTap.

With Umbraco 16, only TipTap is available as an option out of the box. TinyMCE's change of license precludes us from shipping it with the MIT-licensed Umbraco CMS.

When upgrading to Umbraco 16, any data types using TinyMCE will be migrated to use TipTap.

To continue to use TinyMCE, a third-party package must be installed prior to the upgrade. This will disable the migration and allow you to continue with TinyMCE.

Package migrations are asynchronous

Umbraco 16 adds support for asynchronous migrations and part of this work involved creating a new base class for package migrations. This leads to a source-compatible but binary-incompatible breaking change. In practice, this means that package code using migrations and calling base class helper methods such as TableExists can be recompiled without change. But if built against 15 and run on 16, a "method missing" exception will be thrown. For more details on the feature and the changes implemented, see the PR.

Examine is now registered via a composer

A new abstraction and implementation for search is being worked on in an external package. To support this, a method has been implemented to disable the default Examine-based search in Umbraco. This has required moving the Examine component registration to a composer.

There is no effect on the default search experience in Umbraco, but it may affect search customizations. As Examine is now registered in a composer, any custom code registered the same way is not guaranteed to run after the core setup. You should ensure to use a [ComposeAfter(typeof(Umbraco.Cms.Infrastructure.Examine.AddExamineComposer))] attribute to make sure custom code runs after Umbraco's default setup of Examine.

Read more in the article on custom indexing and see PR #18988 for reference.

Updated dependencies

As is usual for a major upgrade, the dependencies Umbraco takes have been updated to their latest, compatible versions. This had little impact on the code of Umbraco itself, so we don't expect this to affect upgraded customer projects.

The specific dependency updates made for Umbraco 16 can be found in these PRs: for server-side and client-side libraries.

Other breaking changes

Other than the above, breaking changes are minimal in Umbraco 16. On the server side, changes are limited to removing already obsolete constructors and methods.

Client-side there are a few things to look out for if you've built extensions to the backoffice:

  • When consuming contexts, an undefined response will be resolved when the context can't be provided or the host is disconnected. See PR 19113 for more information.

  • Similarly, consuming a context as a promise can result in a promise rejection and getting a context can result in an undefined response. See PR 18611 for more information.

  • When making calls to retrieve data from the server, if you used either of Umbraco's helper methods tryExecute or tryExecuteAndNotify, then you need to adjust your code slightly. tryExecuteAndNotify is obsolete, and tryExecute takes the 'host' as the first argument. See PR 18939 for more information.

  • The urls property is no longer populated on the document and media detail response models. This was removed to alleviate performance concerns. Dedicated repositories and management API endpoints exist for retrieving URLs for documents and media. See PR #19030 and PR 19130.

The full details of breaking changes can be found from this list of labelled PRs.

Umbraco 15

Snapshots are removed

Snapshots have been removed, meaning any code using IPublishedSnapshot, and by extension IPublishedSnapshotAccessor, must be updated. Inject IPublishedContentCache or IPublishedMediaCache and use those directly instead.

Modelsbuilder models needs to be rebuilt

Models generated by ModelsBuilder used the IPublishedSnapshot interface, which has been removed. This means that the models need to be rebuilt. The approach to this will differ depending on the mode chosen:

InMemoryAuto

Remove the umbraco\Data\TEMP\InMemoryAuto folder to trigger a rebuild of the models.

SourceCodeAuto and SourceCodeManual

Remove the old models located in the \umbraco\models folder by default. This will cause your views to no longer be able to build due to missing types. To get around this you can disable the precompiled view temporarily by adding the following to your .csproj file:

<PropertyGroup>
  <RazorCompileOnBuild>false</RazorCompileOnBuild>
  <RazorCompileOnPublish>false</RazorCompileOnPublish>
</PropertyGroup>

This will allow your site to start up, but you will still see an error page when loading a page.

  1. Disregard the error.

  2. Enter the backoffice.

  3. Rebuild the models from the ModelsBuilder dashboard.

You can now re-enable precompiled views and rebuild your site.

If you have custom C# code that references the models this will also not build. You can either comment out your custom code temporarily until the models have been rebuilt or fix the models manually. To fix the models manually you need to find and replace IPublishedSnapshotAccessor with IPublishedContentTypeCache.

Handling Precompressed Files

When upgrading from Umbraco 14 to 15, you might notice that JavaScript and CSS files are automatically precompressed, adding additional .br and .gz files. This behavior is introduced in ASP.NET Core version 9, where static files are fingerprinted and precompressed by default at build and publish time.

To disable this feature, set <CompressionEnabled>false</CompressionEnabled> in your project file. If you are using Umbraco's templates: dotnet new umbraco, this setting is already included.

In the project containing the /umbraco folder, set <CompressionEnabled>false</CompressionEnabled> in the .csproj file. This ensures the CMS can manage its own system files correctly. If you have separate Class Library projects for your custom frontend assets (CSS, JS), you may set this to true for performance benefits.

For more details, see the ASP.NET Core Documentation.

Umbraco 14

Read more about the release of Umbraco 14 in the Blog Post.

Below you can find the list of breaking changes introduced in Umbraco 14 CMS.

This is by far the most impactful update of Umbraco in years. We’ve fundamentally changed the way you extend Umbraco. If you are experienced in developing Web Components you can now use your preferred framework for this. If you are unsure how to proceed, you can implement it with TypeScript and the Lit library like we’ve done. In this case, start with this article on how to customize the Backoffice.

The new Backoffice (Bellissima) is entirely built on the Umbraco UI Library. This means that you might experience some of your components not being rendered on the page because the name has been changed. You should be able to find equivalents to what you were used to. For example, the umb-button is now called uui-button, and umb-box is now uui-box. When extending the Backoffice, we encourage you to use our Umbraco UI Library to ensure the same look and feel in your extensions. The UI Library is Open Source and hosted on GitHub, so feel free to contribute with new components or raise issues or discussions.

  • Icons are based on Lucide.

Umbraco 13 and earlier used sets of icons ranging from custom SVGs to Font Awesome. This has all been converged into the Lucide icon pack with icon names mapped from Umbraco 13.

  • Custom icons

To add custom icons to the Backoffice, you must add an extension type called “icons”, which can provide icons given a Name and a File. The file can reside anywhere on disk or in RCLs the only requirements being that it must be routable and it must be an SVG.

  • User provided translations

Translations used in the UI (which are most of them) have been migrated from XML to JavaScript modules. This means that if you wish to override any of the built-in translation keys for the UI, you have to add an extension type called “localization”. It is still possible to add XML translations, but they can no longer be used in the Backoffice UI. However, you may still find usage for them in server-to-server scenarios. Umbraco also keeps its e-mail templates as XML translations. Package and extension developers working with localization will find many benefits from this change seeing that you can add logic to JavaScript modules making your localization files more dynamic and even making them able to react to input parameters.

You can read more about localization on the Umbraco Documentation.

  • BackOffice controllers have been replaced with the Management API

Following the implementation of the new Backoffice (Bellissima), Umbraco has now internally upgraded Headless to a first-class citizen. This means that all controllers previously available under the /umbraco/api route have been removed and replaced with controllers in the Management API. You can read more about the Management API on the Management API article. You can also check out the Swagger UI in your local Umbraco instance available under /umbraco/swagger.

  • A new way of writing authorized controllers

If you have implemented API controllers in Umbraco before, we recommend you update or rewrite these. Follow the Documenting your Controllers article, as you’ll then ensure the same cool documentation of your APIs. Notice, that we’ve made a much better separation of concern between controllers and services so that there is no more business logic in controllers.

Although this sounds like it's not a big change, it’s one of the most breaking changes on the backend. Whereas Newtonsoft.Json was flexible and error-tolerant by default, System.Text.Json is strict but more secure by default. You can therefore run into things that will not be serialized. You can read more about the differences between Newtonsoft.Json and System.Text.Json here.

  • Nested Content and Grid Layout have been removed

These two property editors have been deprecated in Umbraco for some time as you can read in our breaking change announcements for Nested Content and Grid Layout. The recommended action is to use blocks instead - Block Grid for the grid layout and either Block Grid or Block List for Nested Content.

We have for some time encouraged to not use the legacy Media Picker, and now it’s fully removed. You should use the default Media Picker instead.

  • Macros and Partial View Macros have been removed. Use partial views and/or blocks in the Rich Text Editor (RTE)

Depending on the usage of macros, you’ll be able to use either partial views or blocks in the Rich Text Editor. They are not the same kind of functionality, but they cover all the identified use cases in a more consistent and supportable way.

For more information on migrating from macros to using blocks in the Rich Text Editor, see the Migrating Macros article.

  • XPath has been removed

An alternative is using the Dynamic Roots in the Multinode Treepicker and for ContentXPath the alternative is IContentLastChanceFinder.

The package.manifest file is no longer supported and has been replaced with the umbraco-package.json file. The format is similar and after building your Umbraco solution, you have access to a JSON schema file which you can reference and thereby have type-safety in the file. You can read more about the new format on the Package Manifest article.

  • Smidge is no longer a default dependency

Smidge has been removed from the default installation along with the RuntimeMinification setting and related classes. Smidge used to bundle up Backoffice and package assets before, however, with the Bellissima, we have migrated entirely to ESModules. This means we can no longer predict how modules work in automated bundles.

It's recommended that you bundle up your Backoffice static assets for instance by a tool called Vite. You can read more about this on the Vite Package Setup article. You can still use libraries like Smidge for frontend static assets by manually installing the package from NuGet.

You can read the Smidge documentation on how to set up a similar setting to RuntimeMinification. For sites being upgraded from V13 or below, remove these two lines from the _ViewImports.cshtml file.

  • Base classes for Backoffice controllers have been removed

The UmbracoAuthorizedApiController and UmbracoAuthorizedJsonController classes have been removed. We recommend basing your Backoffice APIs on the ManagementApiControllerBase class from the Umbraco.Cms.Api.Management project.

Read the Creating a Backoffice API article for a comprehensive guide to writing APIs for the Management API.

  • Removal of certain AppSettings

Some AppSettings have been removed or found a new place. In general, any UI-related app settings will now have to be configured as extensions through the manifest system.

  • RichTextEditor

The global configuration of TinyMCE has been removed in order to support more rich text editors in the future. Instead, a new extension type called “tinyMcePlugin” has been added. This extension type gives you access to each instance of TinyMCE allowing you to configure it exactly as you see fit. You can even make it dependent on more factors such as Document Type, user group, environment, and much more. You have access to the full array of contexts in the Backoffice.

  • ShowDeprecatedPropertyEditors

There are no deprecated property editors in Bellissima and this configuration will no longer have an effect.

  • HideBackOfficeLogo

This configuration will no longer have an effect. Instead, you can add a CSS file where you can modify the default CSS variables in the Backoffice. The Backoffice loads a CSS file which can be overwritten by placing a similar file in your project at /umbraco/backoffice/css/user-defined.css with the following content:

:root {
  --umb-header-logo-display: none;
}

  • IconsPath

This configuration will no longer have an effect. Instead, you should add icons through the “icons” extension type.

  • AllowedMediaHosts

This configuration will no longer have an effect.

  • Notifications

Notifications have changed their behavior to an extent. You can still implement notifications such as ContentSavingNotification to react to changes for related systems or add messages to be shown in the Backoffice. You can no longer modify the models being transferred through the API.

If you wish to modify the Backoffice UI, register the extensions through the manifest system that hook on to the desired areas of the Backoffice UI. If you used to modify the models because you needed more data on the models, it's recommended that you build your own API controller to achieve this. You can read more about building custom API controllers on the Umbraco Documentation and even learn how to register your controllers in the Swagger UI.

  • Property editors have been split in two

The new Backoffice and the Management API ushers in a shift in responsibility. Traditionally, a lot of UI responsibility has been misplaced on the server.

For example, it is hardly a server concern how many rows a text area should span by default.

To this end, property editors have been split into two, individually reusable parts; the server implementation and the client implementation.

This change will likely impact custom Property Editors. See the Migrate custom Property Editors to Umbraco version 14 and later article for details.

  • Property value converters for package.manifest based property editors

The package.manifest file format is no longer known on the server side. It has been changed to be a purely client-side responsibility (and it has adopted a new format and a new name). If you have implemented a property value converter for a property editor defined in a package.manifest file, you will likely need to make a small change to the property value converter.

The property value converter must implement IsConverter() to determine if it can handle a given property. In this implementation, it is common to use the EditorAlias of the passed in IPublishedPropertyType. However, in Umbraco 14 you should use the EditorUiAlias instead.

More details can be found in this article.

  • UmbracoApiController breakage

Due to the shift from Newtonsoft.Json to the System.Text.Json, the UmbracoApiController will yield camel-cased output in Umbraco 14, where it was pascal-cased in the previous versions.

Make sure to perform thorough testing of all usages of UmbracoApiController. As the class has now been marked as obsolete, we recommend these controllers to be based on the Controller class from ASP.NET Core moving forward.

  • Two-Factor Authentication requires a client registration

The C# models for Two-Factor Authentication previously supported setting a custom AngularJS view to setup the QR code. This has been moved to the Backoffice client and requires a registration through the new extension type mfaLoginProvider:

    {
      "type": "mfaLoginProvider",
      "alias": "my.2fa.provider",
      "name": "My 2fa Provider",
      "forProviderName": "UmbracoUserAppAuthenticator",
      "meta": {
        "label": "Authenticate with a 2FA code"
      }
    }

This will use Umbraco’s default configuration of the two-factor provider. The user scans a QR code using an app such as Google Authenticator or Authy by Twilio.

It is additionally possible to register your own configurator similar to Umbraco 13. You can achieve this by providing a custom JavaScript element through the elementJs property.

More details and code examples can be found in the Two-Factor Authentication article.

  • External Login Providers require a client registration

The C# models for External Login Providers have changed and no longer hold configuration options for the “Sign in with XYZ” button. To show a button in the Backoffice to sign in with an external provider, you need to register this through the extension type called authProvider :

   {
      "type": "authProvider",
      "alias": "My.AuthProvider.Google",
      "name": "Google Auth Provider",
      "forProviderName": "Umbraco.Google",
      "meta": {
        "label": "Google",
        "defaultView": {
          "icon": "icon-google"
        },
        "linking": {
          "allowManualLinking": true
        }
      }
    }

This will use Umbraco’s default button to sign in with the provider. You can also choose to provide your own element to show in the login form. You can achieve this by adding the elementJs property.

Additionally, on the backend side, there is an additional helper available to do proper error handling. You can utilize this by using the options pattern to configure the provider.

More details and code examples can be found in the External Login Providers article.

  • Deprecated SQLite provider name removed

In previous versions of Umbraco the umbracoDbDSN_ProviderName (and umbracoCommerceDbDSN_ProviderName) value could be Microsoft.Data.SQLite or Microsoft.Data.Sqlite with the former being deprecated in Umbraco 12.

The deprecated version, Microsoft.Data.SQlite, has been removed and will require the value to be updated to Microsoft.Data.Sqlite for installations using an SQLite database.

{
    ...
    "ConnectionStrings": {
        "umbracoDbDSN": "Data Source=|DataDirectory|/Umbraco.sqlite.db;Cache=Shared;Foreign Keys=True;Pooling=True",
        "umbracoDbDSN_ProviderName": "Microsoft.Data.Sqlite",
        "umbracoCommerceDbDSN": "Data Source=|DataDirectory|/Umbraco.Commerce.sqlite.db;Mode=ReadWrite;Foreign Keys=True;Pooling=True;Cache=Shared",
        "umbracoCommerceDbDSN_ProviderName": "Microsoft.Data.Sqlite"
    },
    ...
}

  • Webhook payload property casing has changed

Following changes to serialization, property names in the payload now use camelCase instead of PascalCase. For example, the 'CreateDate' property is now 'createDate'.

In-depth and further breaking changes for Umbraco 14 can be found on the CMS GitHub repository and on Our Website.

Umbraco 14 RC Versions

Below you can find the list of breaking changes introduced in Umbraco 14 RC release versions.

RC 5

RC 4

RC 3

RC 2

RC 1 First RC release - 17th of April. Breaking changes since Beta 3:

Umbraco 14 Beta Versions

Below you can find the list of breaking changes introduced in Umbraco 14 Beta release versions.

Beta 3

Beta 2

There are a few breaking changes since Beta 1. Most of the changes concern property editors and getting them to work with migrations as well as new values.

Beta 1 Official release of Beta, 6th March 2023.

Umbraco 13

Below you can find the list of breaking changes introduced in Umbraco 13.

You can find more information about all breaking changes for v13.0.0 on Our Umbraco website.

You need to be aware of some things if you are using EF Core, and have installed the Microsoft.EntityFrameworkCore.Design 8.0.0 package:

  • This package has a transient dependency to Microsoft.CodeAnalysis.Common which clashes with the same transient dependency from Umbraco.Cms 13.0.0. This happens because Microsoft.EntityFrameworkCore.Design 8.0.0 requires Microsoft.CodeAnalysis.CSharp.Workspaces in v4.5.0 or higher.

  • If there are no other dependencies that need that package then it installs it in the lowest allowed version (4.5.0). That package then has a strict dependency on Microsoft.CodeAnalysis.Common version 4.5.0. The problem is Umbraco.Cms through its own transient dependencies that require the version of Microsoft.CodeAnalysis.Common to be >= 4.8.0.

  • This can be fixed by installing Microsoft.CodeAnalysis.CSharp.Workspaces version 4.8.0 as a specific package instead of leaving it as a transient dependency. This is because it will then have a strict transient dependency on Microsoft.CodeAnalysis.Common version 4.8.0, which is the same that Umbraco has.

lightbulb-message

Community Insight: Watch this video walkthrough for a deep dive into the major changes from Umbraco 13 through 17.

Umbraco 12

Umbraco 12 does not include many binary breaking changes, but there are some.

Most notable is a functional breaking change in Migrations, that from Umbraco 12. Each translation will be executed in its own transactions instead of all migrations in one big transaction. This change has been made to ease the support for Sqlite.

A type, enum, record, or struct visible outside the assembly is missing in the compared assembly when required to be present.

  • PagedModel has moved namespace from Umbraco.New.Cms.Core.Models to Umbraco.Cms.Core.Models

  • Umbraco.Cms.Infrastructure.Migrations.PostMigrations.ClearCsrfCookies is removed. The functionality can be archived by implementing a notification handler for the new UmbracoPlanExecutedNotification.

  • Umbraco.Cms.Core.Cache.DistributedCacheBinder is now divided into separate files for each notification handler

  • Umbraco.Cms.Infrastructure.Migrations.PostMigrations.DeleteLogViewerQueryFile was a no-op method removed.

  • Umbraco.Cms.Infrastructure.Migrations.PostMigrations.RebuildPublishedSnapshot replaced with a RebuildCache flag on the MigrationBase

A member that is visible outside of the assembly is missing in the compared assembly when required to be present.

  • Umbraco.Cms.Core.Migrations.IMigrationPlanExecutor.Execute(Umbraco.Cms.Infrastructure.Migrations.MigrationPlan,System.String) replaced with Umbraco.Cms.Core.Migrations.IMigrationPlanExecutor.ExecutePlan(Umbraco.Cms.Infrastructure.* * Migrations.MigrationPlan,System.String) that returns an rich object instead of a string

  • Umbraco.Cms.Infrastructure.Migrations.IMigrationContext.AddPostMigration``1 Removed and replaced with notification

  • Umbraco.Cms.Infrastructure.Migrations.MigrationPlan.AddPostMigration``1

  • Removed and replaced with notification

  • Umbraco.Cms.Infrastructure.Migrations.MigrationPlan.get_PostMigrationTypes removed.

  • Umbraco.Cms.Infrastructure.Migrations.Upgrade.Upgrader.Execute(Umbraco.Cms.Core.Migrations.IMigrationPlanExecutor,Umbraco.Cms.Core.Scoping.IScopeProvider,Umbraco.Cms.Core.Services.IKeyValueService) was obsolete and is replaced by method taking a ICoreScopeProvider instead of a IScopeProvider

An abstract member was added to the right side of the comparison to an unsealed type.

  • PublishedPropertyBase now requires inheritors to implement GetDeliveryApiValue(System.Boolean,System.String,System.String)

A member was added to an interface without a default implementation.

  • Umbraco.Cms.Core.Events.IEventAggregator.Publish2(System.Collections.Generic.IEnumerable{0})

  • Umbraco.Cms.Core.Events.IEventAggregator.PublishAsync2(System.Collections.Generic.IEnumerable{0},System.Threading.CancellationToken)

  • Umbraco.Cms.Core.Models.PublishedContent.IPublishedProperty.GetDeliveryApiValue(System.Boolean,System.String,System.String)

  • Umbraco.Cms.Core.Models.PublishedContent.IPublishedPropertyType.ConvertInterToDeliveryApiObject(Umbraco.Cms.Core.Models.PublishedContent.IPublishedElement,Umbraco.Cms.Core.PropertyEditors.PropertyCacheLevel,System.Object,System.Boolean,System.Boolean)

  • Umbraco.Cms.Core.Models.PublishedContent.IPublishedPropertyType.ConvertInterToDeliveryApiObject(Umbraco.Cms.Core.Models.PublishedContent.IPublishedElement,Umbraco.Cms.Core.PropertyEditors.PropertyCacheLevel,System.Object,System.Boolean)

  • Umbraco.Cms.Core.Models.PublishedContent.IPublishedPropertyType.DeliveryApiCacheLevel

  • Umbraco.Cms.Core.Scoping.ICoreScope.Locks

  • Umbraco.Cms.Core.Migrations.IMigrationPlanExecutor.ExecutePlan(Umbraco.Cms.Infrastructure.Migrations.MigrationPlan,System.String)

  • Umbraco.Cms.Infrastructure.Search.IUmbracoIndexingHandler.RemoveProtectedContent

  • Umbraco.Cms.Infrastructure.Examine.IUmbracoIndex.SupportProtectedContent

Umbraco 11

Most breaking changes are introduced due to updated dependencies. The breaking changes in .NET 7 and ASP.NET Core 7 are documented by Microsoft.

Besides the documented changes, we have also seen a few method signatures that are changed to support Nullable-Reference-Types.

If you are using TinyMCE plugins or custom TinyMCE configuration you need to migrate to the latest version. Learn more about this in the Rich Text Editor documentation.

The breaking changes in TinyMCE are also documented in the official migration guides for version 4 to 5 and from version 5 to 6.

The breaking changes in Umbraco 11 are mainly the removal of classes, methods, and so on, marked as obsolete in Umbraco 9.

A few methods and classes have also been moved and changed namespace. Decoupled dependencies are documented on the Umbraco Announcements repository.

The full list of API-breaking changes can be found below.

Obsolete code removed

The following have been removed after having been obsoleted since Umbraco 9.

Umbraco.Extensions

Umbraco.Cms.Core

Umbraco.Cms.Infrastructure

Umbraco.Cms.Web

Umbraco.Cms.Tests

Code moved to new assemblies and namespaces

The following have been moved to new assemblies and their namespaces have been updated accordingly.

Umbraco.Extensions

Umbraco.Cms.Web

Umbraco.Cms.Infrastructure

New interface methods

A few interfaces have been merged, adding new members to the original interfaces.

Umbraco.Cms.Core

No-Operation methods removed

A method not doing anything for the last couple of major releases have been removed.

Umbraco.Cms.Core

Changes due to models made immutable

A single model have been made immutable, so the default constructor and the setters are not available anymore.

Umbraco.Cms.Infrastructure

Classes that does not inherit from base type anymore

The following classes now directly inherit from OEmbedProviderBase instead of EmbedProviderBase.

Umbraco.Cms.Core

Umbraco 10

Update 'diff' from 3.5.0 to 5.0.0

The diff library used in the Backoffice client has been updated and introduces a breaking change since the exposed global object has been renamed from JsDiff to Diff.

Content Schedule performance

Removes mutable ContentSchedule property from IContent/Content to read/write content schedules.

Use IContentService.GetContentScheduleByContentId && IContentService.PersistContentSchedule or the optional contentSchedule parameter on IContentService.Save instead.

Removed redundant event handling code

  • Removed public methods: PublishedSnapshotServiceEventHandler.Dispose, PublishedSnapshotServiceEventHandler.Dispose(bool), and .PublishedSnapshotServiceEventHandler.Initialize.

  • Removed public ctor.

Scope provider cleanup

  • Some public classes in the Cms.Core.Services namespace have moved assembly from Umbraco.Cms.Infrastructure to Umbraco.Cms.Core.

  • These same public classes have changed namespace from Umbraco.Cms.Core.Services.Implement to Umbraco.Cms.Core.Services.

Update to NPoco5

NPoco types and interfaces are part of our public interface which means that this upgrade imposes breaking changes.

SQLite support

  • Removed support for Microsoft SQL Server Compact (SQL CE).

  • Removed ReadLock and WriteLock methods from ISqlSyntaxProvider interface. Use IDistributedLockingMechanism (or IScope which delegates to IDistributedLockingMechanism) instead.

  • Constants for SQL Server provider name moved+consolidated from Core.Constants.DatabaseProviders and Core.Constants.-DbProviderNames to Umbraco.Cms.Persistence.SqlServer.Constants

  • Some SQL Server related services moved from the Umbraco.Infrastructure project to the new Umbraco.Cms.Persistence.

  • SqlServer project with altered namespaces e.g. SqlServerSyntaxProvider, SqlServerBulkSqlInsertProvider, SqlServerDatabaseCreator.

Added the following methods/properties to ISqlSyntaxProvider. These must be implemented in any downstream implementation e.g:

  • ISqlSyntaxProvider.HandleCreateTable(IDatabase,TableDefinition,Boolean)

  • ISqlSyntaxProvider.GetFieldNameForUpdate()

  • ISqlSyntaxProvider.GetColumn(DatabaseType,String,String,String,String,Boolean)

  • ISqlSyntaxProvider.InsertForUpdateHint(Sql)

  • ISqlSyntaxProvider.AppendForUpdateHint(Sql)

  • ISqlSyntaxProvider.LeftJoinWithNestedJoin(Sql,Func<Sql,Sql>,String)

Update to ImageSharp v2

Update dependency versions:

  • SixLabors.ImageSharp from 1.0.4 to 2.1.1

  • SixLabors.ImageSharp.Web from 1.0.5 to 2.0.0

Renamed the CachedNameLength property to CacheHashLength on ImagingCacheSettings.

Moved ImageSharpImageUrlGenerator from project Umbraco.Infrastructure to Umbraco.Web.Common and updated the corresponding namespace and DI registration (from AddCoreInitialServices() to AddUmbracoImageSharp());

Moved ImageSharp configuration from the AddUmbracoImageSharp() extension method into separate IConfigureOptions<> implementations:

  • The middleware is configured in ConfigureImageSharpMiddlewareOptions (which also replaces ImageSharpConfigurationOptions that previously only set the default ImageSharp configuration);

  • The default physical cache is configured in ConfigurePhysicalFileSystemCacheOptions.

Migrate Member properties to columns on the Member table

This is breaking because it is no longer possible to access the properties listed below through the IMember.Properties collection. You must now access them through their specific properties that is IMember.IsLockedOut.

  • umbracoMemberFailedPasswordAttempts

  • umbracoMemberApproved

  • umbracoMemberLockedOut

  • umbracoMemberLastLockoutDate

  • umbracoMemberLastLogin

  • umbracoMemberLastPasswordChangeDate

Additionally, when previously you resolved a Member as published content, all the default properties would be there twice. For instance, IsLockedOut would be there both as a property with the alias umbracoMemberLockedOut and with the alias IsLockedOut. Now it'll only be there once, with the alias being the name of the property, so IsLockedOut in this instance.

Lastly the nullable dates on a user, i.e. LastLoginLate will now be null instead of DateTime.MinValue when getting a user with the UserService.

Update examine to version 3

Examine 3 breaking changes:

  • ValueSet immutable.

  • ValueSetValidationResult is renamed to ValueSetValidationStatus and ValueSetValidationResult is now a type.

Async support for content finders

Has changed to:

Improve redirect Content finder scalability

  • Added more methods to IRedirectUrlRepository and IRedirectUrlService.cs.

Fix Block List settings exception and optimize PVCs

  • Added a new method on IPublishedModelFactory: Type GetModelType(string? alias);

  • The generic types of a BlockListItem<TContent, TSettings>instance in theBlockListModelreturned byBlockListPropertyValueConverteris now determined by calling this new method, which can be different and cause aModelBindingException` in your views.

Async tree search

Has changed to:

Moved StackQueue to correct namespace

StackQueue has been moved from Umbraco.Core.Collections to the Umbraco.Cms.Core.Collections namespace.

Globalsetting SqlWriteLockTimeOut has been removed

This setting has been superseded by DistributedLockingWriteLockDefaultTimeout.

GlobalSetting UmbracoPath cannot be configured

It is no longer possible to rename the /Umbraco folder path using configuration. The property still exists but is hardcoded to /Umbraco and will be removed in Umbraco 12, planned for release in June 2023.

Release notes

You can find a list of all the released Umbraco versions on Our Umbraco website. When you visit Our Umbraco website, click on the version number to view the changes made in that specific version.

PreviousUpgrade Your ProjectNextFind Your Upgrade Path

Last updated

Was this helpful?