Revert changes made to 14 docs

umbraco · Jan 8, 2025 · 2bff02c · 2bff02c
1 parent cf9bc5b
commit 2bff02c
Show file tree

Hide file tree

Showing 8 changed files with 39 additions and 43 deletions.
diff --git a/14/umbraco-cms/customizing/extending-overview/extension-types/condition.md b/14/umbraco-cms/customizing/extending-overview/extension-types/condition.md
@@ -37,15 +37,16 @@ You can make your own Conditions by creating a class that implements the `UmbExt
 
 ```typescript
 import {
+  ManifestCondition,
   UmbConditionConfigBase,
   UmbConditionControllerArguments,
   UmbExtensionCondition
 } from '@umbraco-cms/backoffice/extension-api';
 import { UmbConditionBase } from '@umbraco-cms/backoffice/extension-registry';
 import { UmbControllerHost } from '@umbraco-cms/backoffice/controller-api';
 
-export type MyExtensionConditionConfig = UmbConditionConfigBase<'My.Condition.CustomName'> & {
-  match?: string;
+export type MyExtensionConditionConfig = UmbConditionConfigBase & {
+  match: string;
 };
 
 export class MyExtensionCondition extends UmbConditionBase<MyExtensionConditionConfig> implements UmbExtensionCondition {
@@ -63,28 +64,26 @@ export class MyExtensionCondition extends UmbConditionBase<MyExtensionConditionC
 // Declare the Condition Configuration Type in the global UmbExtensionConditionConfigMap interface:
 declare global {
     interface UmbExtensionConditionConfigMap {
-        MyExtensionConditionConfig: MyExtensionConditionConfig;
+        MyExtensionConditionConfig: MyExtensionCondition;
     }
 }
 ```
 
-The global declaration on the last five lines makes your Condition appear valid for manifests using the type `UmbExtensionManifest`. Also, the Condition Config Type alias should match the alias given when registering the condition below.
-
-The Condition then needs to be registered in the Extension Registry:
+This has to be registered in the extension registry, shown below:
 
 ```typescript
-export const manifest: UmbExtensionManifest = {
+export const manifest: ManifestCondition = {
  type: 'condition',
  name: 'My Condition',
  alias: 'My.Condition.CustomName',
  api: MyExtensionCondition,
 };
 ```
 
-Finally, you can make use of your condition in any manifests:
+Finally, you can make use of the condition in your configuration. See an example of this below:
 
 ```typescript
-export const manifest: UmbExtensionManifest = {
+{
  type: 'workspaceAction',
  name: 'example-workspace-action',
  alias: 'My.Example.WorkspaceAction',
@@ -101,7 +100,7 @@ export const manifest: UmbExtensionManifest = {
 }
 ```
 
-As shown in the code above, the configuration property `match` isn't used for our condition. We can do this by replacing the timeout with some other check:
+As can be seen in the code above, we never make use of `match`. We can do this by replacing the timeout with some other check.
 
 ```typescript
 // ...

diff --git a/14/umbraco-cms/customizing/extending-overview/extension-types/header-apps.md b/14/umbraco-cms/customizing/extending-overview/extension-types/header-apps.md
@@ -93,9 +93,9 @@ This is a continuation of the above steps from the **Button Header App with Mani
 
 {% code title="my-element.ts" lineNumbers="true" %}
 ```typescript
-import { umbExtensionsRegistry } from '@umbraco-cms/backoffice/extension-registry';
+import { ManifestHeaderAppButtonKind, umbExtensionsRegistry } from '@umbraco-cms/backoffice/extension-registry';
 
-const manifest: UmbExtensionManifest = {
+const manifest: ManifestHeaderAppButtonKind = {
   type: "headerApp",
   alias: "My.HeaderApp.Documentation",
   name: "My Header App Documentation",

diff --git a/14/umbraco-cms/customizing/extending-overview/extension-types/kind.md b/14/umbraco-cms/customizing/extending-overview/extension-types/kind.md
@@ -8,8 +8,6 @@ description: A kind extension provides the preset for other extensions to use
 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.
 {% endhint %}
 
-## Kind
-
 A kind is matched with a specific type. When another extension uses that type and kind it will inherit the preset manifest of the kind extension.
 
 The registration of Kinds is done in the same manner as the registration of other extensions. But the format of it is different. Let's take a look at an example of how to implement the `Kind registration` for a [**Header App**](../extension-types/header-apps.md) **Button Kind**.
@@ -18,10 +16,10 @@ The registration of Kinds is done in the same manner as the registration of othe
 
 The root properties of this object define the `Kind registration`. Then the manifest property holds the preset for the extension using this kind to be based upon. This object can hold the property values that make sense for the Kind.
 
-```ts
+```typescript
 ...
 
-const manifest: UmbExtensionManifestKind = {
+const manifest: ManifestKind = {
 	type: 'kind',
 	alias: 'Umb.Kind.MyButtonKind',
 	matchType: 'headerApp',
@@ -36,7 +34,7 @@ const manifest: UmbExtensionManifestKind = {
 
 For the kind to be used, it needs to match up with the registration of the extension using it. This happens when the extension uses a type, which matches the value of `matchType` of the Kind. As well the extension has to utilize that kind, by setting the value of `kind` to the value of `matchKind` the Kind.
 
-```ts
+```typescript
 ...
 
 const manifest = {
@@ -52,10 +50,11 @@ const manifest = {
 
 In the following example, a kind is registered. This kind provides a default element for extensions utilizing this kind.
 
-```ts
-import { umbExtensionsRegistry } from '@umbraco-cms/backoffice/extension-registry';
+```typescript
+import { ManifestHeaderAppButtonKind, umbExtensionsRegistry } from '@umbraco-cms/backoffice/extension-registry';
+import { ManifestKind } from '@umbraco-cms/backoffice/extension-api';
 
-const manifest: UmbExtensionManifest = {
+const manifest: ManifestKind<ManifestHeaderAppButtonKind> = {
   type: 'kind',
   alias: 'Umb.Kind.MyButtonKind',
   matchType: 'headerApp',
@@ -72,7 +71,7 @@ This enables other extensions to use this kind and inherit the manifest properti
 
 In this example a **Header App** is registered without defining an element, this is possible because the registration inherits the elementName from the kind.
 
-```ts
+```typescript
 import { extensionRegistry } from '@umbraco-cms/extension-registry';
 
 const manifest = {

diff --git a/14/umbraco-cms/customizing/extending-overview/extension-types/section.md b/14/umbraco-cms/customizing/extending-overview/extension-types/section.md
@@ -61,7 +61,7 @@ This is not recommended as it limits the content of your section to this element
 If you like to have full control, you can define an element like this:
 
 ```typescript
-const section : UmbExtensionManifest = {
+const section : ManifestSection = {
     type: "section",
     alias: "Empty.Section",
     name : 'Empty Section',

diff --git a/14/umbraco-commerce/key-concepts/ui-extensions/store-menu-items.md b/14/umbraco-commerce/key-concepts/ui-extensions/store-menu-items.md
@@ -63,7 +63,9 @@ Here:
 To handle requests to this endpoint, you should define a workspace manifest for the given entity type.
 
 ```typescript
-const manifests: UmbExtensionManifest[] = [
+import { ManifestWorkspace } from '@umbraco-cms/backoffice/extension-registry';
+
+const manifests: ManifestWorkspace[] = [
     {
         type: 'workspace',
         kind: 'routable',

diff --git a/15/umbraco-cms/customizing/extending-overview/extension-types/condition.md b/15/umbraco-cms/customizing/extending-overview/extension-types/condition.md
@@ -20,16 +20,15 @@ You can make your own Conditions by creating a class that implements the `UmbExt
 
 ```typescript
 import {
-  ManifestCondition,
   UmbConditionConfigBase,
   UmbConditionControllerArguments,
   UmbExtensionCondition
 } from '@umbraco-cms/backoffice/extension-api';
 import { UmbConditionBase } from '@umbraco-cms/backoffice/extension-registry';
 import { UmbControllerHost } from '@umbraco-cms/backoffice/controller-api';
 
-export type MyExtensionConditionConfig = UmbConditionConfigBase & {
-  match: string;
+export type MyExtensionConditionConfig = UmbConditionConfigBase<'My.Condition.CustomName'> & {
+  match?: string;
 };
 
 export class MyExtensionCondition extends UmbConditionBase<MyExtensionConditionConfig> implements UmbExtensionCondition {
@@ -47,12 +46,14 @@ export class MyExtensionCondition extends UmbConditionBase<MyExtensionConditionC
 // Declare the Condition Configuration Type in the global UmbExtensionConditionConfigMap interface:
 declare global {
     interface UmbExtensionConditionConfigMap {
-        MyExtensionConditionConfig: MyExtensionCondition;
+        MyExtensionConditionConfig: MyExtensionConditionConfig;
     }
 }
 ```
 
-This has to be registered in the extension registry, shown below:
+The global declaration on the last five lines makes your Condition appear valid for manifests using the type `UmbExtensionManifest`. Also, the Condition Config Type alias should match the alias given when registering the condition below.
+
+The Condition then needs to be registered in the Extension Registry:
 
 ```typescript
 export const manifest: UmbExtensionManifest = {
@@ -63,10 +64,10 @@ export const manifest: UmbExtensionManifest = {
 };
 ```
 
-Finally, you can make use of the condition in your configuration. See an example of this below:
+Finally, you can make use of your condition in any manifests:
 
 ```typescript
-{
+export const manifest: UmbExtensionManifest = {
  type: 'workspaceAction',
  name: 'example-workspace-action',
  alias: 'My.Example.WorkspaceAction',
@@ -83,7 +84,7 @@ Finally, you can make use of the condition in your configuration. See an example
 }
 ```
 
-As can be seen in the code above, we never make use of `match`. We can do this by replacing the timeout with some other check.
+As shown in the code above, the configuration property `match` isn't used for our condition. We can do this by replacing the timeout with some other check:
 
 ```typescript
 // ...

diff --git a/15/umbraco-cms/customizing/extending-overview/extension-types/kind.md b/15/umbraco-cms/customizing/extending-overview/extension-types/kind.md
@@ -8,8 +8,6 @@ description: A kind extension provides the preset for other extensions to use
 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.
 {% endhint %}
 
-## Kind
-
 A kind is matched with a specific type. When another extension uses that type and kind it will inherit the preset manifest of the kind extension.
 
 The registration of Kinds is done in the same manner as the registration of other extensions. But the format of it is different. Let's take a look at an example of how to implement the `Kind registration` for a [**Header App**](../extension-types/header-apps.md) **Button Kind**.
@@ -18,7 +16,7 @@ The registration of Kinds is done in the same manner as the registration of othe
 
 The root properties of this object define the `Kind registration`. Then the manifest property holds the preset for the extension using this kind to be based upon. This object can hold the property values that make sense for the Kind.
 
-```ts
+```typescript
 ...
 
 const manifest: ManifestKind = {
@@ -36,7 +34,7 @@ const manifest: ManifestKind = {
 
 For the kind to be used, it needs to match up with the registration of the extension using it. This happens when the extension uses a type, which matches the value of `matchType` of the Kind. As well the extension has to utilize that kind, by setting the value of `kind` to the value of `matchKind` the Kind.
 
-```ts
+```typescript
 ...
 
 const manifest = {
@@ -52,11 +50,10 @@ const manifest = {
 
 In the following example, a kind is registered. This kind provides a default element for extensions utilizing this kind.
 
-```ts
-import { ManifestHeaderAppButtonKind, umbExtensionsRegistry } from '@umbraco-cms/backoffice/extension-registry';
-import { ManifestKind } from '@umbraco-cms/backoffice/extension-api';
+```typescript
+import { umbExtensionsRegistry } from '@umbraco-cms/backoffice/extension-registry';
 
-const manifest: ManifestKind<ManifestHeaderAppButtonKind> = {
+const manifest: UmbExtensionManifest = {
   type: 'kind',
   alias: 'Umb.Kind.MyButtonKind',
   matchType: 'headerApp',
@@ -73,7 +70,7 @@ This enables other extensions to use this kind and inherit the manifest properti
 
 In this example a **Header App** is registered without defining an element, this is possible because the registration inherits the elementName from the kind.
 
-```ts
+```typescript
 import { extensionRegistry } from '@umbraco-cms/extension-registry';
 
 const manifest = {

diff --git a/15/umbraco-commerce/key-concepts/ui-extensions/store-menu-items.md b/15/umbraco-commerce/key-concepts/ui-extensions/store-menu-items.md
@@ -63,9 +63,7 @@ Here:
 To handle requests to this endpoint, you should define a workspace manifest for the given entity type.
 
 ```typescript
-import { ManifestWorkspace } from '@umbraco-cms/backoffice/extension-registry';
-
-const manifests: ManifestWorkspace[] = [
+const manifests: UmbExtensionManifest[] = [
     {
         type: 'workspace',
         kind: 'routable',