This page is a work in progress and may undergo further revisions, updates, or amendments. The information contained herein is subject to change without notice.
The extension registry is the center piece of the Backoffice UI. It holds information about most of the Backoffice UI, as most are extensions. This includes the built-in UI. The registry can be manipulated at any time, meaning you can add or remove extensions at runtime.
To provide new UI to the backoffice, you must register them via an extension manifest. This has to be initiated via an Umbraco Package JSON file on the server. This will be your starting point, which enables you to register one or more extensions.
Declaring a new extension is done by declaring an extension manifest. This can be done in one of two ways:
Via a manifest JSON file on the server.
In a JavaScript/TypeScript file.
These two options can be combined as you like.
A typical use case of such is achieved by registering a single extension manifest in your Umbraco Package JSON file. This manifest would then load a JS file, that registers the rest of your extensions. Learn more about these abilities in the bundle or backoffice entry point articles.
Learn about the different methods for declaring an Extension Manifest.
This page is a work in progress and may undergo further revisions, updates, or amendments. The information contained herein is subject to change without notice.
The Extension Manifest is the point of entry for any extension. This is the declaration of what you want to register.
The content in this section describes all the extension types that the Backoffice supports. Here is a list of the most common types:
Each Extension Manifest has to declare its type. This is used to determine where it hooks into the system. It also determines what data is required of this manifest.
The abilities of the extensions rely on the specific extension type. The Type sets the scene for what the extension can do and what it needs to be utilized. Some extension types can be made purely via the manifest. Other requires files, like a JavaScript file containing a Web Component.
The required fields of any extension manifest are:
type
- The type defines the type and purpose of the extension. It is used to determine where the extension will be used and defines the data needed for this manifest.
alias
- The alias is used to identify the extension. This has to be unique for each extension.
name
- The name of the extension. This is used to identify the extension in the UI.
Additionally, many extensions supports the use of the following fields:
weight
- Define a weight, to determine the importance or visual order of this extension.
conditions
- Define one or more conditions which must be permitted for the extension to become available. Extension Conditions.
kind
- Define a kind-alias of which this manifest should be based upon. Kinds acts like a preset for your manifest. Extension Kinds.
Many of the Extension Types requires additional information declared as part of a meta
field.
An Extension Manifest can be declared in multiple ways.
The primary way is to declare it as part of the Umbraco Package Manifest.
Additionally, two Extension types can be used to register other extensions.
A typical use case is to declare one main Extension Manifest as part of the Umbraco Package Manifest. Such main Extension Manifest would be using one of the following types:
bundle
extension typeThe Bundle extension type can be used for declaring multiple Extension Manifests with JavaScript in a single file.
The Bundle declares a single JavaScript file that will be loaded at startup. All the Extension Manifests exported of this Module will be registered in the Extension Registry.
Read more about the bundle
extension type in the Bundle article.
backofficeEntryPoint
extension typeThe backofficeEntryPoint
extension type can run any JavaScript code at startup. This can be used as an entry point for a package.
The entry point declares a single JavaScript file that will be loaded and run when the Backoffice starts.
The entryPbackofficeEntryPointoint
extension is also the way to go if you want to load in external libraries such as jQuery, Angular, or React. You can use the backofficeEntryPoint
type to load in the external libraries to be shared by all your extensions. Loading global CSS files can also be used in the backofficeEntryPoint
extension.
Read more about the backofficeEntryPoint
extension type in the Entry Point article.
Alternatively, an Extension Manifest can be declared in JavaScript at any given point.
The following example shows how to register an extension manifest via JavaScript code:
This page is a work in progress and may undergo further revisions, updates, or amendments. The information contained herein is subject to change without notice.
Most of BackOffice is based on Extensions making it crucial to understand how to register your own extensions. This introduction will give you an outline of the abilities of the extension registry.
The extension registry is a global registry that can be accessed and changed at anytime while Backoffice is running.
Each Extension Manifest has to declare its type, this is used to determine where it hooks into the system. It also looks at what data is required to declare within it.
Most extension types support conditions. Defining conditions enables you to control when and where the extension is available.
The kinds feature enables you to base your extension registration on a preset. A kind provides the base manifest that you like to extend.
The Entry Point manifest type is used to register an entry point for the backoffice. An entry point is a single JavaScript file that is loaded when the backoffice is initialized. This file can be used to do anything, this enables more complex logic to take place on startup.
The bundle
extension type enables you to gather many extension manifests into one.