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.