Merge pull request #6677 from nielslyngsoe/v15/correct-package-manifest

V15: correct package manifest

Author: sofietoft

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

@@ -4,25 +4,30 @@ description: Learn about the different methods for declaring an Extension Manife
 
 # Extension Manifest
 
-{% hint style="warning" %}
-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 %}
+# Extension Manifest
 
 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:
+The content in this section describes all the extension types that the Backoffice supports. Find a list of the most common types in the [Extension Types](../extension-types/) article.
+
+## Extension Manifest Format
+
+An Extension Manifest can be written either as a JavaScript Object or a JSON Object.
 
-{% content-ref url="../../../tutorials/creating-a-custom-dashboard/" %}
-[creating-a-custom-dashboard](../../../tutorials/creating-a-custom-dashboard/)
-{% endcontent-ref %}
+There are a few general properties, the required set of properties consists of the `type`, `alias`, and `name`.
 
-{% content-ref url="../../property-editors/composition/" %}
-[composition](../../property-editors/composition/)
-{% endcontent-ref %}
+```typescript
+const manifest = {
+    type: '...',
+    alias: 'my.customization',
+    name: 'My customization'
+    ...
+};
+```
 
-{% content-ref url="../../../customize-the-backoffice/section-trees.md" %}
-[section-trees.md](../../../customize-the-backoffice/section-trees.md)
-{% endcontent-ref %}
+The `type` defines what it is declaring
+The `alias` is a unique identifier for this manifest. It must be globally unique, so make sure to prefix it with something that makes your extension unique.
+The `name` is a representational name of this manifest, this does not need to be unique but such can be beneficial when debugging extensions.
 
 ## Manifest Data
 
@@ -36,13 +41,13 @@ The required fields of any extension manifest are:
 * `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:
+Additionally, many extensions support 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](../extension-conditions/extension-conditions.md).
+* `conditions` - Define one or more conditions that must be permitted for the extension to become available. [Extension Conditions](../extension-conditions/extension-conditions.md).
 * `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).
 
-Many of the Extension Types requires additional information declared as part of a `meta` field.
+Many of the Extension Types require additional information declared as part of a `meta` field.
 
 ## Registration
 

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

@@ -6,7 +6,7 @@ This page is a work in progress and may undergo further revisions, updates, or a
 
 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.
+To provide new UI to the backoffice, you must register them via an Extension Manifest. This can be initiated via an Umbraco Package JSON file on the server. This will be your starting point.
 
 Declaring a new extension is done by declaring an [extension manifest](extension-manifest.md). This can be done in one of two ways:
 

15/umbraco-cms/customizing/umbraco-package.md

@@ -1,17 +1,17 @@
 ---
-description: An extension begins with a Package Manifest
+description: An extension begins with a Umbraco Package
 ---
 
 # Umbraco Package
 
-A Package is declared via an Umbraco Package Manifest. This describes the Package and declares one or more UI Extensions. The Package Manifest is a JSON file that is stored in the `App_Plugins/{YourPackageName}` folder. The file is named `umbraco-package.json`.
+A Package is declared via an Umbraco Package JSON file. This describes the Package and declares one or more UI Extensions. The Package declaration is a JSON file that is stored in the `App_Plugins/{YourPackageName}` folder. The file is named `umbraco-package.json`.
 
-## Sample Manifest
+## Sample
 
-This is a sample manifest. It is always stored in a folder in `App_Plugins/{YourPackageName}`, with the name `umbraco-package.json`. In this example, the package name is `SirTrevor` and is a text box property Data Type.
+Here is a sample package. It should be stored in a folder in `App_Plugins/{YourPackageName}`, with the name `umbraco-package.json`. In this example, the package name is `SirTrevor` and is a text box property Data Type.
 
 {% hint style="info" %}
-Before Umbraco 14, the manifest was declared in a `package.manifest` file instead of `umbraco-package.json`. The old format is no longer supported, but you can migrate the contents to the new format.
+Before Umbraco 14, a package was declared in a `package.manifest` file instead of `umbraco-package.json`. The old format is no longer supported, but you can migrate the contents to the new format.
 {% endhint %}
 
 {% code title="umbraco-package.json" lineNumbers="true" %}
@@ -41,7 +41,7 @@ Before Umbraco 14, the manifest was declared in a `package.manifest` file instea
 
 ## Root fields
 
-The `umbraco-package` accept these fields:
+The `umbraco-package` accepts these fields:
 
 ```json
 {
@@ -78,13 +78,13 @@ The version of your package, if this is not specified there will be no version-s
 
 With this field, you can control the telemetry of this package, this will provide Umbraco with the knowledge of how many installations use this package.
 
-Default is `false`.
+The default is `false`.
 
 ### Allow Public Access
 
 This field is used to allow public access to the package. If set to `true`, the package will be available for anonymous usage, for example on the login screen. If set to `false`, the package will only be available to logged-in users.
 
-Default is `false`.
+The default is `false`.
 
 ### Importmap
 
@@ -120,13 +120,9 @@ Umbraco supports the current specification of the property as outlined on MDN We
 
 ### Extensions
 
-The `extensions` field is an array of UI Extension objects. Each object describes a single UI Extension.
+The `extensions` field is an array of Extension Manifest objects. Each object describes a single client extension.
 
-There are three generic fields that are common to all UI Extensions:
-
-* `type` - The type of the UI Extension.
-* `alias` - The alias of the UI Extension. This must be unique.
-* `name` - The name of the UI Extension.
+Read more about these in the [Extension Manifests article](./extending-overview/extension-registry/extension-manifest.md).
 
 These are the current types of UI Extensions: