You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: 16/umbraco-cms/customizing/extending-overview/extension-registry/README.md
+6-8Lines changed: 6 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,17 +5,15 @@ description: >-
5
5
---
6
6
7
7
# Extension Registry
8
+
The Umbraco backoffice is build with extendability in mind. The backoffice without extensions is more or less a blank canvas that is build out using extensions. These extensions dictate how the backoffice functions and looks. All visual elements in an Umbraco installation, like the sections, menu's, trees and buttons, are extensions. But extensions also dictate behaviour and the editing experience. So everything in the backoffice is governed (and extendable) by extensions.
8
9
9
-
The Extensions Registry is your entry to extend or customize the Backoffice. Therefore, it is crucial to understand the abilities of the Extension Registry.
10
+
All extensions are registered in the extension registry. The registry can be manipulated at any time, meaning you can add or remove extensions at runtime. You as a developer have the same possibilities as an Umbraco HQ developer, which means what HQ can do, you can do. This also means that you can change almost everything that is by default present in Umbraco. You can see in the backoffice what extensions are registered by going to Settings > Extensions Insights.
## [Introduction to a Extension Manifest](extension-manifest.md)
13
+
An Extension Manifest is a declaration on what you want to register in the Umbraco backoffice. This handles what an extension manifest looks like and what is required or not.
12
14
15
+
## [Register an extension](extension-registry.md)
13
16
The extension registry is a global registry that can be accessed and changed at any time while Backoffice is running.
14
17
15
-
## [Extension Manifest](extension-manifest.md)
16
-
17
-
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.
18
-
19
-
## [Replace, Exclude, or Unregister](replace-exclude-or-unregister.md)
20
-
18
+
## [Change an existing extension](replace-exclude-or-unregister.md)
21
19
Once you understand how to declare your own, you may want to replace or remove existing ones.
Copy file name to clipboardExpand all lines: 16/umbraco-cms/customizing/extending-overview/extension-registry/extension-manifest.md
+30-23Lines changed: 30 additions & 23 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,45 +3,52 @@ description: Learn about the different methods for declaring an Extension Manife
3
3
---
4
4
5
5
# Extension Manifest
6
+
This page explains how to author Extension Manifests for Umbraco backoffice extensions.
7
+
It outlines the manifest structure, required fields, and optional features used across types.
6
8
7
-
The Extension Manifest is the first step for any extension. It is the declaration of what you want to register.
8
-
9
-
In this section, you will find all the Extension Types provided by the Backoffice. [See all Extension Types here.](../extension-types/)
9
+
## What is an Extension Manifest?
10
+
An Extension Manifest declares a single backoffice extension and its configuration.
11
+
Umbraco reads the manifest to register the extension in the Extension Registry.
12
+
The chosen extension type determines required fields and available capabilities.
13
+
Some extensions need extra assets, like a JavaScript file with a Web Component.
10
14
11
15
## Extension Manifest Format
16
+
An Extension Manifest has a strict format where some properties are required and some depend on the Extension Type. An Extension Manifest can be written as a JavaScript or JSON Object. We'll dive deeper into that when [registering an extension](extension-registry).
12
17
13
-
An Extension Manifest can be written as a JavaScript or JSON Object.
18
+
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, like a section or menu item. Other types require files, like a JavaScript file containing a Web Component, like a custom property editor.
14
19
15
-
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 types require files, like a JavaScript file containing a Web Component.
20
+
### Required Manifest properties
21
+
A minimal Extension Manifest looks like this (in JSON formatting):
16
22
17
-
```typescript
23
+
```json
18
24
{
19
-
type: '...',
20
-
alias: 'my.customization',
21
-
name: 'My customization'
22
-
...
23
-
};
25
+
"type": "...",
26
+
"alias": "my.customization",
27
+
"name": "My customization"
28
+
}
24
29
```
25
30
26
-
The required fields of any Extension Manifest are:
31
+
These fields are all required and have the following meaning:
27
32
28
-
*`type` — The type defines the purpose of the extension. It is used to determine where the extension will be used.
29
-
*`alias` — This is a unique identifier for this manifest. Prefix it with something that makes your extension unique. Example: `mfc.Dashboard.Overview` .
30
-
*`name` — This is a representational name of this manifest; It does not need to be unique, but this can be beneficial when debugging extensions. Example: `My Fictive Company Overview Dashboar` .
31
-
32
-
### Additional Manifest features
33
+
*`type` — The type defines the purpose of the extension. Umbraco has many [extension types](../extension-types) available.
34
+
*`alias` — This is a unique identifier for this manifest. Prefix it with something that makes your extension unique. For example: _FictiveCompany.MyProject.Dashboard.Overview_.
35
+
*`name` — This is a representational name of this manifest; It does not need to be unique, but this can be beneficial when debugging extensions. This name also shows up in the Extensions Insights in the backoffice of Umbraco. For example: _My Fictive Company Overview Dashboard_.
33
36
37
+
### Additional Manifest properties
34
38
Most extension types support the use of the following generic features for their Manifest:
35
39
36
-
*`weight` - Define a weight to determine the importance or visual order of this extension. A higher weight gives a more prominent position.
37
-
*`overwrites` - Define one or more Extension Aliases that this extension should replace. Notice it only omits the listed Extensions when this is rendered in the same spot. [Read more in Replace, Exclude or Unregister](replace-exclude-or-unregister.md).
38
-
*`conditions` - Define one or more conditions that must be permitted for the extension to become available. [Extension Conditions](../extension-conditions.md).
39
-
*`kind` - Define a kind-alias of which this manifest should be based upon. Kind acts like a preset for your manifest. [Extension Kinds](../extension-kind.md).
40
+
*`weight` - Define a weight to determine the importance or visual order of this extension. A higher weight gives a more prominent position. For instance, for a dashboard it determines it's order between other dashboards.
41
+
*`overwrites` - If replacing an existing extension, this define one or more Extension Aliases that this extension should replace. Read more in [Replace, Exclude or Unregister extensions](replace-exclude-or-unregister.md).
42
+
*`conditions` - Define one or more conditions that must pass for the extension to become available. For instance, don't show a section if you don't have the proper rights. Read more in [Extension Conditions](../extension-conditions.md).
43
+
*`kind` - Some extension types can reference a predefined Kind. By specifying a Kind, the manifest inherits the Kind's properties. This allows for reuse of predefined settings. See [Extension Kind](../extension-kind.md).
44
+
*`meta` - Many Extension Types require additional information declared as part of a `meta` field. It depends on the extension what is required. For instance label and icon of a menu item.
40
45
41
-
Many of the Extension Types require additional information declared as part of a `meta` field.
46
+
For more information, see an overview of all possible [Extension Types](../extension-types/) and their requirements.
42
47
43
-
## Type intellisense
44
48
49
+
---- Below should be moved or removed, because it requires too much context for this file -----
50
+
51
+
## Type intellisense
45
52
It is recommended to make use of the Type IntelliSense that we provide.
46
53
47
54
When writing your Manifest in TypeScript, you should use the Type `UmbExtensionManifest`. See the article on [Development Setup](../../development-flow/) to ensure you have Types correctly configured.
Copy file name to clipboardExpand all lines: 16/umbraco-cms/customizing/extending-overview/extension-registry/register-extensions.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ description: >-
4
4
registering an Extension via an Extension Manifest.
5
5
---
6
6
7
-
# Register an Extension
7
+
# Register extensions
8
8
9
9
Whether you're looking to make a single correction or a package, it is done via a file on the server that we call Umbraco Package JSON. This will be your starting point.
0 commit comments