Skip to content

Commit b98a8cb

Browse files
committed
Add 6503
1 parent 7136672 commit b98a8cb

File tree

6 files changed

+223
-79
lines changed

6 files changed

+223
-79
lines changed
Lines changed: 23 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,23 @@
1+
# Custom Extension Types
2+
3+
The extension registry is an open system, which can hold any Extension Manifest Type. This article describes how you can declare your types.
4+
Types can be declared for re-useability/maintainability or to open up for other package extensions.
5+
6+
## Manifest Type Declaration
7+
8+
A Manifest Type is declared via a TypeScript Interface, like shown below:
9+
10+
```typescript
11+
import type { ManifestBase } from '@umbraco-cms/backoffice/extension-api';
12+
13+
export interface ManifestPreviewAppProvider extends ManifestBase {
14+
type: 'myPrefixedExtensionType';
15+
}
16+
17+
// Declare the Manifest Type in the global UmbExtensionManifestMap interface:
18+
declare global {
19+
interface UmbExtensionManifestMap {
20+
MyPrefixedExtensionManifest: MyExtensionManifestType;
21+
}
22+
}
23+
```
Lines changed: 49 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,49 @@
1+
---
2+
description: Learn how to use Extension Conditions when working with the Umbraco backoffice.
3+
---
4+
5+
# Extension Conditions
6+
7+
{% hint style="warning" %}
8+
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.
9+
{% endhint %}
10+
11+
Extension Manifest Conditions enable you to declare requirements for an Extension before it becomes available.
12+
13+
## Utilizing Conditions in your Manifest
14+
15+
Conditions are referenced via their alias. The Declaration of a Condition is shown in the following example:
16+
17+
```typescript
18+
const manifest = {
19+
type: 'workspaceView',
20+
...
21+
conditions: [
22+
{
23+
alias: 'Umb.Condition.WorkspaceAlias',
24+
match: 'Umb.Workspace.Document',
25+
},
26+
],
27+
};
28+
```
29+
30+
By declaring a condition the extension will become available only once the condition is permitted.
31+
32+
The example above requires the nearest Workspaces Alias to be equal to `'Umb.Workspace.Document'`.
33+
34+
When declaring multiple conditions all of them must be permitted for the extension to be available.
35+
36+
## Condition Configuration
37+
38+
The conditions are defined as an array of condition configurations. Each entry can contain the following properties:
39+
40+
* `alias`- The alias of the condition to utilize.
41+
* `...` - The rest of the properties of the object are specific to the condition configuration.
42+
43+
## Learn more
44+
45+
Learn about built-in conditions and how to create your own:
46+
47+
{% content-ref url="extension-types/condition.md" %}
48+
Condition Extension Type
49+
{% endcontent-ref %}
Lines changed: 55 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,55 @@
1+
---
2+
description: Learn how to use the Kind extension in your manifest files when extending the Umbraco CMS backoffice.
3+
---
4+
5+
# Extension Kind
6+
7+
{% hint style="warning" %}
8+
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.
9+
{% endhint %}
10+
11+
Extension Manifest Kind enables declarations to be based upon a preset Manifest.
12+
13+
This is used for maintainability or to inherit existing features.
14+
15+
## Manifest Kind Declaration
16+
17+
A Kind is utilized by declaring it in the `kind` field of a Manifest:
18+
19+
```typescript
20+
const manifest = {
21+
type: 'headerApp',
22+
kind: 'button',
23+
...
24+
};
25+
```
26+
27+
By declaring a kind, the Manifest will inherit fields of the defined Kind.
28+
29+
A typical use case is a Kind that provides an element, but requires additional meta fields, to fulfill the needs of its element.
30+
31+
In the following example, a manifest using the type 'headerApp' utilizes the 'button' kind. This brings an element and requires some additional information as part of the meta object.
32+
33+
Adding the metadata provides the ability to use and configure existing functionality to a specific need.
34+
35+
```typescript
36+
const manifest = {
37+
type: 'headerApp',
38+
kind: 'button',
39+
name: 'My Header App Example',
40+
alias: 'My.HeaderApp.Example',
41+
meta: {
42+
label: 'My Example',
43+
icon: 'icon-home',
44+
href: '/some/path/to/open/when/clicked',
45+
},
46+
};
47+
```
48+
49+
## Learn more
50+
51+
Learn more about Kinds and how to create your own:
52+
53+
{% content-ref url="extension-types/kind.md" %}
54+
Kind Extension Type
55+
{% endcontent-ref %}
Lines changed: 55 additions & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -1,14 +1,16 @@
1+
---
2+
description: Learn about the different methods for declaring an Extension Manifest.
3+
---
4+
15
# Extension Manifest
26

37
{% hint style="warning" %}
48
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.
59
{% endhint %}
610

7-
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.
8-
9-
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 rely on a reference to other extensions.
11+
The Extension Manifest is the point of entry for any extension. This is the declaration of what you want to register.
1012

11-
The pages of this article describe all the extension types that Backoffice supports. Here is a list of the most common types:
13+
The content in this section describes all the extension types that the Backoffice supports. Here is a list of the most common types:
1214

1315
{% content-ref url="../../../tutorials/creating-a-custom-dashboard/" %}
1416
[creating-a-custom-dashboard](../../../tutorials/creating-a-custom-dashboard/)
@@ -18,43 +20,71 @@ The pages of this article describe all the extension types that Backoffice suppo
1820
[composition](../../property-editors/composition/)
1921
{% endcontent-ref %}
2022

21-
{% content-ref url="../../section-trees/" %}
22-
[section-trees](../../section-trees/)
23+
{% content-ref url="../../../customize-the-backoffice/section-trees.md" %}
24+
[section-trees.md](../../../customize-the-backoffice/section-trees.md)
2325
{% endcontent-ref %}
2426

25-
## Declare Extension Manifest
27+
## Manifest Data
2628

27-
Extension Manifest and can be declared in multiple ways. One of these is to declare it as part of the [Umbraco Package Manifest](../../package-manifest.md).
29+
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.
2830

29-
You can declare new Extension Manifests in JavaScript at any given point.
31+
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.
3032

31-
```typescript
32-
import { umbExtensionsRegistry } from "@umbraco-cms/backoffice/extension-registry"
33+
The required fields of any extension manifest are:
3334

34-
const manifest = {
35-
type: '...',
36-
...
37-
};
35+
* `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.
36+
* `alias`- The alias is used to identify the extension. This has to be unique for each extension.
37+
* `name` - The name of the extension. This is used to identify the extension in the UI.
3838

39-
umbExtensionsRegistry.register(extension);
40-
```
39+
Additionally, many extensions supports the use of the following fields:
40+
41+
* `weight` - Define a weight, to determine the importance or visual order of this extension.
42+
* `conditions` - Define one or more conditions which must be permitted for the extension to become available. [Extension Conditions](../extension-conditions/extension-conditions.md).
43+
* `kind` - Define a kind-alias of which this manifest should be based upon. Kinds acts like a preset for your manifest. [Extension Kinds](../extension-kind/extension-kind.md).
44+
45+
Many of the Extension Types requires additional information declared as part of a `meta` field.
46+
47+
## Registration
48+
49+
An Extension Manifest can be declared in multiple ways.
50+
51+
The primary way is to declare it as part of the [Umbraco Package Manifest](../../../customize-the-backoffice/umbraco-package.md).
52+
53+
Additionally, two Extension types can be used to register other extensions.
4154

42-
Backoffice also comes with two Extension types which can be used to register more extensions.
55+
A typical use case is to declare one main Extension Manifest as part of the [Umbraco Package Manifest](../../../customize-the-backoffice/umbraco-package.md). Such main Extension Manifest would be using one of the following types:
4356

44-
### Using `bundle` to declare other Extension Manifest
57+
### The `bundle` extension type
4558

46-
The bundle extension type can be used for declaring multiple Extension Manifests with JavaScript in a single file.
59+
The Bundle extension type can be used for declaring multiple Extension Manifests with JavaScript in a single file.
4760

48-
The bundle declares a single JavaScript file that will be loaded at startup. All the Extension Manifests exported from this Module will be registered in the Extension Registry.
61+
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.
4962

5063
Read more about the `bundle` extension type in the [Bundle](../../../extending/extending-overview/extension-registry/bundle.md) article.
5164

52-
### Using `backofficeEntryPoint` as your foundation
65+
### The `backofficeEntryPoint` extension type
66+
67+
The `backofficeEntryPoint` extension type can run any JavaScript code at startup. This can be used as an entry point for a package.
5368

54-
The `backofficeEntryPoint` extension type is special, it can be used to run any JavaScript code at startup.\
55-
This can be used as an entry point for a package.\
5669
The entry point declares a single JavaScript file that will be loaded and run when the Backoffice starts.
5770

58-
The `entryPbackofficeEntryPointoint` extension is also the way to go if you want to load in external libraries such as jQuery, Angular, React, etc. You can use the `backofficeEntryPoint` 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.
71+
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.
5972

6073
Read more about the `backofficeEntryPoint` extension type in the [Entry Point](../../../extending/extending-overview/extension-registry/entry-point.md) article.
74+
75+
## Registration via any JavaScript code
76+
77+
Alternatively, an Extension Manifest can be declared in JavaScript at any given point.
78+
79+
The following example shows how to register an extension manifest via JavaScript code:
80+
81+
```typescript
82+
import { umbExtensionsRegistry } from "@umbraco-cms/backoffice/extension-registry"
83+
84+
const manifest = {
85+
type: '...',
86+
...
87+
};
88+
89+
umbExtensionsRegistry.register(extension);
90+
```

15/umbraco-cms/customizing/extending-overview/extension-registry/extension-registry.md

Lines changed: 0 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -19,11 +19,3 @@ These two options can be combined as you like.
1919

2020
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.
2121
Learn more about these abilities in the [bundle](../extension-types/bundle.md) or [backoffice entry point](../extension-types/entry-point.md) articles.
22-
23-
## Extension Manifest Data <a href="#extension-manifest" id="extension-manifest"></a>
24-
25-
The necessary properties that any extension manifest needs are:
26-
27-
* `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.
28-
* `alias`- The alias is used to identify the extension. This has to be unique for each extension.
29-
* `name` - The name of the extension. This is used to identify the extension in the UI.

15/umbraco-cms/customizing/extending-overview/extension-types/condition.md

Lines changed: 41 additions & 46 deletions
Original file line numberDiff line numberDiff line change
@@ -1,49 +1,37 @@
1-
# Extension Conditions
2-
3-
Extension conditions are used to determine if an extension should be used or not. Many of the Extension Types support conditions, but not all of them.
4-
5-
{% hint style="warning" %}
6-
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.
7-
{% endhint %}
8-
9-
All given conditions for an extension must be valid for an extension to be utilized.
1+
---
2+
description: Learn how to declare requirements for your extensions using the Extension Conditions.
3+
---
104

11-
## Using conditions <a href="#using-conditions" id="using-conditions"></a>
12-
13-
In the following example we define the manifest for a Workspace Action, this action will only be available in the workspace with the alias `My.Example.Workspace`.
14-
15-
```typescript
16-
{
17-
type: 'workspaceAction',
18-
name: 'example-workspace-action',
19-
alias: 'My.Example.WorkspaceAction',
20-
elementName: 'my-workspace-action-element',
21-
conditions: [
22-
{
23-
alias: 'Umb.Condition.SectionAlias',
24-
match: 'My.Example.Workspace'
25-
}
26-
]
27-
}
28-
```
29-
30-
The conditions are defined as an array of conditions. Each condition is an object with the following properties:
5+
# Extension Conditions
316

32-
* `alias`- The alias of the condition to utilize.
33-
* `...` - The rest of the properties of the object are specific to the condition.
7+
Extension Conditions declare requirements that should be permitted for the extension to be available. Many, but not all, Extension Types support Conditions.
348

35-
In the above example the `Umb.Condition.SectionAlias` condition is used, this condition takes a property `match` which must be set to the alias of the section to match.
9+
[Read about utilizing conditions in Manifests](../extension-conditions/extension-conditions.md).
3610

3711
## Built-in conditions types <a href="#core-conditions-types" id="core-conditions-types"></a>
3812

39-
The following conditions are available out of the box, for all extension types that support conditions.
40-
41-
* `Umb.Condition.SectionAlias` - Checks if the current section alias matches the one specified.
42-
* `Umb.Condition.WorkspaceAlias` - Checks if the current workspace alias matches the one specified.
43-
44-
## Make your own conditions <a href="#make-your-own-conditions" id="make-your-own-conditions"></a>
13+
The following conditions are available out of the box, for all extension types that support Conditions.
14+
15+
* `Umb.Condition.SectionAlias` - Requires the current Section Alias to match the one specified.
16+
* `Umb.Condition.MenuAlias` - Requires the current Menu Alias to match the one specified.
17+
* `Umb.Condition.WorkspaceAlias` - Requires the current Workspace Alias to match the one specified.
18+
* `Umb.Condition.WorkspaceEntityType` - Requires the current workspace to work on the given Entity Type. Examples: 'document', 'block' or 'user'.
19+
* `Umb.Condition.WorkspaceContentTypeAlias` - Requires the current workspace to be based on a Content Type which Alias matches the one specified.
20+
* `Umb.Condition.Workspace.ContentHasProperties` - Requires the Content Type of the current Workspace to have properties.
21+
* `Umb.Condition.WorkspaceHasCollection` - Requires the current Workspace to have a Collection.
22+
* `Umb.Condition.WorkspaceEntityIsNew` - Requires the current Workspace data to be new, not yet persisted on the server.
23+
* `Umb.Condition.EntityIsTrashed` - Requires the current entity to be trashed.
24+
* `Umb.Condition.EntityIsNotTrashed` - Requires the current entity to not be trashed.
25+
* `Umb.Condition.SectionUserPermission` - Requires the current user to have permissions to the given Section Alias.
26+
* `Umb.Condition.UserPermission.Document` - Requires the current user to have specific Document permissions. Example: 'Umb.Document.Save'
27+
28+
## Make your own conditions
29+
30+
```html
31+
<a href="#make-your-own-conditions" id="make-your-own-conditions"></a>
32+
```
4533

46-
You can make your own conditions by creating a class that implements the `UmbExtensionCondition` interface.
34+
You can make your own Conditions by creating a class that implements the `UmbExtensionCondition` interface.
4735

4836
```typescript
4937
import {
@@ -55,12 +43,12 @@ import {
5543
import { UmbConditionBase } from '@umbraco-cms/backoffice/extension-registry';
5644
import { UmbControllerHost } from '@umbraco-cms/backoffice/controller-api';
5745

58-
export type MyConditionConfig = UmbConditionConfigBase & {
46+
export type MyExtensionConditionConfig = UmbConditionConfigBase & {
5947
match: string;
6048
};
6149

62-
export class MyExtensionCondition extends UmbConditionBase<MyConditionConfig> implements UmbExtensionCondition {
63-
constructor(host: UmbControllerHost, args: UmbConditionControllerArguments<MyConditionConfig>) {
50+
export class MyExtensionCondition extends UmbConditionBase<MyExtensionConditionConfig> implements UmbExtensionCondition {
51+
constructor(host: UmbControllerHost, args: UmbConditionControllerArguments<MyExtensionConditionConfig>) {
6452
super(host, args);
6553

6654
// enable extension after 10 seconds
@@ -70,9 +58,16 @@ export class MyExtensionCondition extends UmbConditionBase<MyConditionConfig> im
7058
}, 10000);
7159
}
7260
}
61+
62+
// Declare the Condition Configuration Type in the global UmbExtensionConditionConfigMap interface:
63+
declare global {
64+
interface UmbExtensionConditionConfigMap {
65+
MyExtensionConditionConfig: MyExtensionCondition;
66+
}
67+
}
7368
```
7469

75-
This has to be registered in the extension registry like shown below:
70+
This has to be registered in the extension registry, shown below:
7671

7772
```typescript
7873
export const manifest: ManifestCondition = {
@@ -108,8 +103,8 @@ As can be seen in the code above, we never make use of `match`. We can do this b
108103
```typescript
109104
// ...
110105

111-
export class MyExtensionCondition extends UmbConditionBase<MyConditionConfig> implements UmbExtensionCondition {
112-
constructor(host: UmbControllerHost, args: UmbConditionControllerArguments<MyConditionConfig>) {
106+
export class MyExtensionCondition extends UmbConditionBase<MyExtensionConditionConfig> implements UmbExtensionCondition {
107+
constructor(host: UmbControllerHost, args: UmbConditionControllerArguments<MyExtensionConditionConfig>) {
113108
super(host, args);
114109

115110
if (args.config.match === 'Yes') {
@@ -132,7 +127,7 @@ With all that in place, the configuration can look like shown below:
132127
{
133128
alias: 'My.Condition.CustomName',
134129
match: 'Yes'
135-
} as MyConditionConfig
130+
}
136131
]
137132
}
138133
```

0 commit comments

Comments
 (0)