chore: Update docs structure

docs/content/deployment/deploying-admin-ui.md → docs/content/guides/deployment/deploying-admin-ui.md

@@ -5,7 +5,7 @@ showtoc: true
 
 ## Deploying the Admin UI
 
-If you have customized the Admin UI with extensions, you should [compile your extensions ahead of time as part of the deployment process]({{< relref "/plugins/extending-the-admin-ui" >}}#compiling-as-a-deployment-step).
+If you have customized the Admin UI with extensions, you should [compile your extensions ahead of time as part of the deployment process]({{< relref "/guides/plugins/extending-the-admin-ui" >}}#compiling-as-a-deployment-step).
 
 ### Deploying a stand-alone Admin UI
 

docs/content/deployment/production-configuration/index.md → docs/content/guides/deployment/production-configuration/index.md

@@ -45,7 +45,7 @@ export const config: VendureConfig = {
 
 ## API hardening
 
-It is recommended that you install and configure the [HardenPlugin]({{< relref "typescript-api/core-plugins/harden-plugin" >}}) for all production deployments. This plugin locks down your schema (disabling introspection and field suggestions) and protects your Shop API against malicious queries that could otherwise overwhelm your server.
+It is recommended that you install and configure the [HardenPlugin]({{< relref "/reference/typescript-api/core-plugins/harden-plugin" >}}) for all production deployments. This plugin locks down your schema (disabling introspection and field suggestions) and protects your Shop API against malicious queries that could otherwise overwhelm your server.
 
 Install the plugin: 
 
@@ -78,7 +78,7 @@ export const config: VendureConfig = {
 ```
 
 {{< alert primary >}}
-For a detailed explanation of how to best configure this plugin, see the [HardenPlugin docs]({{< relref "typescript-api/core-plugins/harden-plugin" >}}).
+For a detailed explanation of how to best configure this plugin, see the [HardenPlugin docs]({{< relref "/reference/typescript-api/core-plugins/harden-plugin" >}}).
 {{< /alert >}}
 
 ## ID Strategy

docs/content/developer-guide/customizing-models/index.md → docs/content/guides/developer-guide/customizing-models/index.md

@@ -5,7 +5,7 @@ showtoc: true
 
 # Customizing Models with custom fields
 
-Custom fields allow you to add your own custom data properties to many of the Vendure entities. The entities which may have custom fields defined are listed in the [CustomFields documentation]({{< relref "/typescript-api/custom-fields" >}})
+Custom fields allow you to add your own custom data properties to many of the Vendure entities. The entities which may have custom fields defined are listed in the [CustomFields documentation]({{< relref "/reference/typescript-api/custom-fields" >}})
 
 They are specified in the VendureConfig:
 
@@ -29,7 +29,7 @@ With the example config above, the following will occur:
 
 1. The database schema will be altered, and a column will be added for each custom field. **Note: changes to custom fields require a database migration**. See the [Migrations guide]({{< relref "migrations" >}}).
 2. The GraphQL APIs will be modified to add the custom fields to the `Product` and `User` types respectively.
-3. If you are using the [admin-ui-plugin]({{< relref "/typescript-api/core-plugins/admin-ui-plugin" >}}), the Admin UI detail pages will now contain form inputs to allow the custom field data to be added or edited, and the list view data tables will allow custom field columns to be added, sorted and filtered. 
+3. If you are using the [admin-ui-plugin]({{< relref "/reference/typescript-api/core-plugins/admin-ui-plugin" >}}), the Admin UI detail pages will now contain form inputs to allow the custom field data to be added or edited, and the list view data tables will allow custom field columns to be added, sorted and filtered. 
 
 
 {{< figure src="custom-fields-data-table.webp" >}}
@@ -196,7 +196,7 @@ OrderLine: [
 ]
 ```
 
-Once defined, the [addItemToOrder mutation]({{< relref "/graphql-api/shop/mutations" >}}#additemtoorder) will have a third argument available, which accepts values for the custom field defined above:
+Once defined, the [addItemToOrder mutation]({{< relref "/reference/graphql-api/shop/mutations" >}}#additemtoorder) will have a third argument available, which accepts values for the custom field defined above:
 
 ```GraphQL
 mutation {
@@ -250,7 +250,7 @@ export class EngravingPriceStrategy implements OrderItemPriceCalculationStrategy
 ## TypeScript Typings
 
 Because custom fields are generated at run-time, TypeScript has no way of knowing about them based on your
-VendureConfig. Consider the example above - let's say we have a [plugin]({{< relref "/plugins" >}}) which needs to
+VendureConfig. Consider the example above - let's say we have a [plugin]({{< relref "/guides/plugins" >}}) which needs to
 access the custom field values on a Product entity.
 
 Attempting to access the custom field will result in a TS compiler error:

docs/content/developer-guide/error-handling.md → docs/content/guides/developer-guide/error-handling.md

@@ -125,4 +125,4 @@ mutation ApplyCoupon($code: String!) {
 
 This ensures that your client code is aware of and handles all the usual error cases.
 
-You can see all the ErrorResult types returned by the Shop API mutations in the [Shop API Mutations docs]({{< relref "/graphql-api/shop/mutations" >}}). 
+You can see all the ErrorResult types returned by the Shop API mutations in the [Shop API Mutations docs]({{< relref "/reference/graphql-api/shop/mutations" >}}). 

docs/content/developer-guide/importing-product-data.md → docs/content/guides/developer-guide/importing-product-data.md

@@ -35,7 +35,7 @@ Here's an explanation of each column:
 * `name`: The name of the product. Rows with an empty "name" are interpreted as variants of the preceeding product row.
 * `slug`: The product's slug. Can be omitted, in which case will be generated from the name.
 * `description`: The product description.
-* `assets`: One or more asset file names separated by the pipe (`|`) character. The files can be located on the local file system, in which case the path is interpreted as being relative to the [`importAssetsDir`]({{< relref "/typescript-api/import-export/import-export-options" >}}#importassetsdir) as defined in the VendureConfig. Files can also be urls which will be fetched from a remote http/https url. If you need more control over how assets are imported, you can implement a custom [AssetImportStrategy]({{< relref "asset-import-strategy" >}}). The first asset will be set as the featuredAsset.
+* `assets`: One or more asset file names separated by the pipe (`|`) character. The files can be located on the local file system, in which case the path is interpreted as being relative to the [`importAssetsDir`]({{< relref "/reference/typescript-api/import-export/import-export-options" >}}#importassetsdir) as defined in the VendureConfig. Files can also be urls which will be fetched from a remote http/https url. If you need more control over how assets are imported, you can implement a custom [AssetImportStrategy]({{< relref "asset-import-strategy" >}}). The first asset will be set as the featuredAsset.
 * `facets`: One or more facets to apply to the product separated by the pipe (`|`) character. A facet has the format `<facet-name>:<facet-value>`.
 * `optionGroups`: OptionGroups define what variants make up the product. Applies only to products with more than one variant. 
 * `optionValues`: For each optionGroup defined, a corresponding value must be specified for each variant. Applies only to products with more than one variant.
@@ -84,7 +84,7 @@ Use of language codes has to be consistent throughout the file. You don't have t
 
 ## Initial Data
 
-As well as product data, other initialization data can be populated using the [`InitialData` object]({{< relref "initial-data" >}}). **This format is intentionally limited**; more advanced requirements (e.g. setting up ShippingMethods that use custom checkers & calculators) should be carried out via scripts which interact with the [Admin GraphQL API]({{< relref "/graphql-api/admin" >}}).
+As well as product data, other initialization data can be populated using the [`InitialData` object]({{< relref "initial-data" >}}). **This format is intentionally limited**; more advanced requirements (e.g. setting up ShippingMethods that use custom checkers & calculators) should be carried out via scripts which interact with the [Admin GraphQL API]({{< relref "/reference/graphql-api/admin" >}}).
 
 ```TypeScript
 import { InitialData, LanguageCode } from '@vendure/core';

docs/content/developer-guide/job-queue/index.md → docs/content/guides/developer-guide/job-queue/index.md

@@ -52,7 +52,7 @@ In this case it is recommended to try the [BullMQJobQueuePlugin]({{< relref "bul
 
 ## Using Job Queues in a plugin
 
-If you create a [Vendure plugin]({{< relref "/plugins" >}}) which involves some long-running tasks, you can also make use of the job queue. See the [JobQueue plugin example]({{< relref "using-job-queue-service" >}}) for a detailed annotated example.
+If you create a [Vendure plugin]({{< relref "/guides/plugins" >}}) which involves some long-running tasks, you can also make use of the job queue. See the [JobQueue plugin example]({{< relref "using-job-queue-service" >}}) for a detailed annotated example.
 
 {{< alert "primary" >}}
 A real example of this can be seen in the [EmailPlugin source](https://github.com/vendure-ecommerce/vendure/blob/master/packages/email-plugin/src/plugin.ts)

docs/content/developer-guide/multi-vendor-marketplaces/_index.md → docs/content/guides/developer-guide/multi-vendor-marketplaces/_index.md

@@ -23,7 +23,7 @@ All the concepts presented here have been implemented in our [example multi-vend
 
 ## Sellers, Channels & Roles
 
-The core of Vendure's multi-vendor support is Channels. Read the [Channels guide]({{< relref "/developer-guide/channels" >}}) to get a more detailed understanding of how they work.
+The core of Vendure's multi-vendor support is Channels. Read the [Channels guide]({{< relref "/guides/developer-guide/channels" >}}) to get a more detailed understanding of how they work.
 
 Each Channel is assigned to a [Seller]({{< relref "seller" >}}), which is another term for the vendor who is selling things in our marketplace.
 

docs/content/developer-guide/overview/_index.md → docs/content/guides/developer-guide/overview/_index.md

@@ -13,7 +13,7 @@ Here is a simplified diagram of the Vendure application architecture:
 
 ## Entry Points
 
-As you can see in the diagram, there are two entry points into the application: [`bootstrap()`]({{< relref "bootstrap" >}}) and [`bootstrapWorker()`]({{< relref "bootstrap-worker" >}}), which start the main server and the [worker]({{< relref "/developer-guide/vendure-worker" >}}) respectively. Communication between server and worker(s) is done via the [Job Queue]({{< relref "/developer-guide/job-queue" >}}).
+As you can see in the diagram, there are two entry points into the application: [`bootstrap()`]({{< relref "bootstrap" >}}) and [`bootstrapWorker()`]({{< relref "bootstrap-worker" >}}), which start the main server and the [worker]({{< relref "/guides/developer-guide/vendure-worker" >}}) respectively. Communication between server and worker(s) is done via the [Job Queue]({{< relref "/guides/developer-guide/job-queue" >}}).
 
 ## GraphQL APIs
 
@@ -21,10 +21,10 @@ There are 2 separate GraphQL APIs: shop and admin.
 
 * The **Shop API** is used by public-facing client applications (web shops, e-commerce apps, mobile apps etc.) to allow customers to find products and place orders. 
     
-    [Shop API Documentation]({{< relref "/graphql-api/shop" >}}).
+    [Shop API Documentation]({{< relref "/reference/graphql-api/shop" >}}).
 * The **Admin API** is used by administrators to manage products, customers and orders. 
 
-    [Admin API Documentation]({{< relref "/graphql-api/admin" >}}).
+    [Admin API Documentation]({{< relref "/reference/graphql-api/admin" >}}).
 
 ## Database
 
@@ -32,4 +32,4 @@ Vendure officially supports multiple databases: MySQL/MariaDB, PostgreSQL, SQLit
 
 ## Custom Business Logic (Plugins)
 
-Not shown on the diagram (for the sake of simplicity) are plugins. Plugins are the mechanism by which you extend Vendure with your own business logic and functionality. See [the Plugins docs]({{< relref "/plugins" >}})
+Not shown on the diagram (for the sake of simplicity) are plugins. Plugins are the mechanism by which you extend Vendure with your own business logic and functionality. See [the Plugins docs]({{< relref "/guides/plugins" >}})

docs/content/developer-guide/payment-integrations/index.md → docs/content/guides/developer-guide/payment-integrations/index.md

@@ -144,7 +144,7 @@ Once the PaymentMethodHandler is defined as above, you can use it to create a ne
 
 ## Payment flow
 
-1. Once the active Order has been transitioned to the ArrangingPayment state (see the [Order Workflow guide]({{< relref "order-workflow" >}})), one or more Payments are created by executing the [`addPaymentToOrder` mutation]({{< relref "/graphql-api/shop/mutations#addpaymenttoorder" >}}). This mutation has a required `method` input field, which _must_ match the `code` of one of the configured PaymentMethodHandlers. In the case above, this would be set to `"my-payment-method"`.
+1. Once the active Order has been transitioned to the ArrangingPayment state (see the [Order Workflow guide]({{< relref "order-workflow" >}})), one or more Payments are created by executing the [`addPaymentToOrder` mutation]({{< relref "/reference/graphql-api/shop/mutations#addpaymenttoorder" >}}). This mutation has a required `method` input field, which _must_ match the `code` of one of the configured PaymentMethodHandlers. In the case above, this would be set to `"my-payment-method"`.
     ```GraphQL
     mutation {
         addPaymentToOrder(input: {
@@ -155,7 +155,7 @@ Once the PaymentMethodHandler is defined as above, you can use it to create a ne
     }
     ```
     The `metadata` field is used to store the specific data required by the payment provider. E.g. some providers have a client-side part which begins the transaction and returns a token which must then be verified on the server side.
-2. This mutation internally invokes the [PaymentMethodHandler's `createPayment()` function]({{< relref "payment-method-config-options" >}}#createpayment). This function returns a [CreatePaymentResult object]({{< relref "payment-method-types" >}}#payment-method-types) which is used to create a new [Payment]({{< relref "/typescript-api/entities/payment" >}}). If the Payment amount equals the order total, then the Order is transitioned to either the "PaymentAuthorized" or "PaymentSettled" state and the customer checkout flow is complete.
+2. This mutation internally invokes the [PaymentMethodHandler's `createPayment()` function]({{< relref "payment-method-config-options" >}}#createpayment). This function returns a [CreatePaymentResult object]({{< relref "payment-method-types" >}}#payment-method-types) which is used to create a new [Payment]({{< relref "/reference/typescript-api/entities/payment" >}}). If the Payment amount equals the order total, then the Order is transitioned to either the "PaymentAuthorized" or "PaymentSettled" state and the customer checkout flow is complete.
 
 ### Single-step
 

docs/content/developer-guide/promotions.md → docs/content/guides/developer-guide/promotions.md

@@ -17,7 +17,7 @@ Promotions are a means of offering discounts on an order based on various criter
 All Promotions can have the following constraints applied to them:
 
 -   **Date range** Using the "starts at" and "ends at" fields, the Promotion can be scheduled to only be active during the given date range.
--   **Coupon code** A Promotion can require a coupon code first be activated using the [`applyCouponCode` mutation]({{< relref "/graphql-api/shop/mutations" >}}#applycouponcode) in the Shop API.
+-   **Coupon code** A Promotion can require a coupon code first be activated using the [`applyCouponCode` mutation]({{< relref "/reference/graphql-api/shop/mutations" >}}#applycouponcode) in the Shop API.
 -   **Per-customer limit** A Promotion coupon may be limited to a given number of uses per Customer.
 
 ### Conditions

docs/content/developer-guide/shipping.md → docs/content/guides/developer-guide/shipping.md

@@ -4,7 +4,7 @@ showtoc: true
 ---
 # Shipping & Fulfillment
 
-Shipping in Vendure is handled by [ShippingMethods]({{< relref "shipping-method" >}}). Multiple ShippingMethods can be set up and then your storefront can query [`eligibleShippingMethods`]({{< relref "/graphql-api/shop/queries" >}}#eligibleshippingmethods) to find out which ones can be applied to the active order.
+Shipping in Vendure is handled by [ShippingMethods]({{< relref "shipping-method" >}}). Multiple ShippingMethods can be set up and then your storefront can query [`eligibleShippingMethods`]({{< relref "/reference/graphql-api/shop/queries" >}}#eligibleshippingmethods) to find out which ones can be applied to the active order.
 
 A ShippingMethod is composed of a **checker** and a **calculator**. When querying `eligibleShippingMethods`, each of the defined ShippingMethods' checker functions is executed to find out whether the order is eligible for that method, and if so, the calculator is executed to determine the shipping cost.
 

docs/content/developer-guide/stock-control/index.md → docs/content/guides/developer-guide/stock-control/index.md

@@ -32,7 +32,7 @@ Stock on hand | Allocated | Out-of-stock threshold | Saleable
 10            | 10        | 0                      | 0
 10            | 10        | -5                     | 5
 
-The saleable value is what determines whether the customer is able to add a variant to an order. If there is 0 saleable stock, then any attempt to add to the order will result in an [`InsufficientStockError`]({{< relref "/graphql-api/shop/object-types" >}}#insufficientstockerror).
+The saleable value is what determines whether the customer is able to add a variant to an order. If there is 0 saleable stock, then any attempt to add to the order will result in an [`InsufficientStockError`]({{< relref "/reference/graphql-api/shop/object-types" >}}#insufficientstockerror).
 
 ```JSON
 {

docs/content/developer-guide/taxes.md → docs/content/guides/developer-guide/taxes.md

@@ -44,7 +44,7 @@ When a customer adds an item to the Order, the following logic takes place:
 1. The price of the OrderItem, and whether or not that price is inclusive of tax, is determined according to the configured [OrderItemPriceCalculationStrategy]({{< relref "order-item-price-calculation-strategy" >}}).
 2. The active tax Zone is determined based on the configured [TaxZoneStrategy]({{< relref "tax-zone-strategy" >}}).
 3. The applicable TaxRate is fetched based on the ProductVariant's TaxCategory and the active tax Zone determined in step 1.
-4. The `TaxLineCalculationStrategy.calculate()` of the configured [TaxLineCalculationStrategy]({{< relref "tax-line-calculation-strategy" >}}) is called, which will return one or more [TaxLines]({{< relref "/graphql-api/shop/object-types" >}}#taxline).
+4. The `TaxLineCalculationStrategy.calculate()` of the configured [TaxLineCalculationStrategy]({{< relref "tax-line-calculation-strategy" >}}) is called, which will return one or more [TaxLines]({{< relref "/reference/graphql-api/shop/object-types" >}}#taxline).
 5. The final `priceWithTax` of the OrderItem is calculated based on all the above.
 
 ## Calculating taxes on shipping

docs/content/developer-guide/uploading-files.md → docs/content/guides/developer-guide/uploading-files.md

@@ -5,7 +5,7 @@ showtoc: true
 
 # Uploading Files 
 
-Vendure handles file uploads with the [GraphQL multipart request specification](https://github.com/jaydenseric/graphql-multipart-request-spec). Internally, we use the [graphql-upload package](https://github.com/jaydenseric/graphql-upload). Once uploaded, a file is known as an [Asset]({{< relref "/typescript-api/entities/asset" >}}). Assets are typically used for images, but can represent any kind of binary data such as PDF files or videos.
+Vendure handles file uploads with the [GraphQL multipart request specification](https://github.com/jaydenseric/graphql-multipart-request-spec). Internally, we use the [graphql-upload package](https://github.com/jaydenseric/graphql-upload). Once uploaded, a file is known as an [Asset]({{< relref "/reference/typescript-api/entities/asset" >}}). Assets are typically used for images, but can represent any kind of binary data such as PDF files or videos.
 
 ## Upload clients
 
@@ -15,7 +15,7 @@ For testing, it is even possible to use a [plain curl request](https://github.co
 
 ## The `createAssets` mutation
 
-The [createAssets mutation]({{< relref "/graphql-api/admin/mutations" >}}#createassets) in the Admin API is the only means of uploading files by default. 
+The [createAssets mutation]({{< relref "/reference/graphql-api/admin/mutations" >}}#createassets) in the Admin API is the only means of uploading files by default. 
 
 Here's an example of how a file upload would look using the `apollo-upload-client` package:
 

docs/content/developer-guide/vendure-worker.md → docs/content/guides/developer-guide/vendure-worker.md

@@ -70,7 +70,7 @@ bootstrap(config)
 
 ## Running custom code on the worker
 
-If you are authoring a [Vendure plugin]({{< relref "/plugins" >}}) to implement custom functionality, you can also make use of the worker process in order to handle long-running or computationally-demanding tasks. See the [Plugin Examples]({{< relref "plugin-examples" >}}#running-processes-on-the-worker) page for an example of this.
+If you are authoring a [Vendure plugin]({{< relref "/guides/plugins" >}}) to implement custom functionality, you can also make use of the worker process in order to handle long-running or computationally-demanding tasks. See the [Plugin Examples]({{< relref "plugin-examples" >}}#running-processes-on-the-worker) page for an example of this.
 
 ## ProcessContext
 

docs/content/getting-started.md → docs/content/guides/getting-started.md

@@ -70,7 +70,7 @@ Log in with the superadmin credentials you specified, which default to:
 
 ## Next Steps
 
-* Learn more about [Configuration]({{< relref "/developer-guide/configuration" >}}) of your Vendure server.
-* Get a better understanding of how Vendure works by reading the [Architecture Overview]({{< relref "/developer-guide/overview" >}})
-* Start writing custom plugins with the [Plugin guide]({{< relref "/plugins" >}})
-* Learn how to implement a storefront with the [GraphQL API Guide]({{< relref "/storefront/shop-api-guide" >}})
+* Learn more about [Configuration]({{< relref "/guides/developer-guide/configuration" >}}) of your Vendure server.
+* Get a better understanding of how Vendure works by reading the [Architecture Overview]({{< relref "/guides/developer-guide/overview" >}})
+* Start writing custom plugins with the [Plugin guide]({{< relref "/guides/plugins" >}})
+* Learn how to implement a storefront with the [GraphQL API Guide]({{< relref "/guides/storefront/shop-api-guide" >}})

docs/content/plugins/_index.md → docs/content/guides/plugins/_index.md

@@ -9,7 +9,7 @@ The heart of Vendure is its plugin system. Plugins not only allow you to instant
 
 Plugins in Vendure allow one to:
 
-* Modify the [VendureConfig]({{< ref "/typescript-api/configuration" >}}#vendureconfig) object, such as defining [custom fields]({{< relref "customizing-models" >}}) on existing entities.
+* Modify the [VendureConfig]({{< ref "/reference/typescript-api/configuration" >}}#vendureconfig) object, such as defining [custom fields]({{< relref "customizing-models" >}}) on existing entities.
 * Extend the GraphQL APIs, including modifying existing types and adding completely new queries and mutations.
 * Define new database entities and interact directly with the database.
 * Interact with external systems that you need to integrate with.

docs/content/plugins/extending-the-admin-ui/custom-form-inputs/_index.md → docs/content/guides/plugins/extending-the-admin-ui/custom-form-inputs/_index.md

@@ -5,7 +5,7 @@ weight: 5
 
 # Custom Form Inputs
 
-Another way to extend the Admin UI app is to define custom form input components for manipulating any [Custom Fields]({{< ref "/typescript-api/custom-fields" >}}) you have defined on your entities as well as [configurable args]({{< relref "config-args" >}}) used by custom [ConfigurableOperationDefs]({{< relref "configurable-operation-def" >}}).
+Another way to extend the Admin UI app is to define custom form input components for manipulating any [Custom Fields]({{< ref "/reference/typescript-api/custom-fields" >}}) you have defined on your entities as well as [configurable args]({{< relref "config-args" >}}) used by custom [ConfigurableOperationDefs]({{< relref "configurable-operation-def" >}}).
 
 ## For Custom Fields
 

docs/content/plugins/plugin-architecture/_index.md → docs/content/guides/plugins/plugin-architecture/_index.md

@@ -10,7 +10,7 @@ showtoc: true
 
 A plugin in Vendure is a specialized Nestjs Module that is decorated with the [`VendurePlugin` class decorator]({{< relref "vendure-plugin" >}}). This diagram illustrates how a plugin can integrate with and extend Vendure.
  
-1. A Plugin may define logic to be run by the [Vendure Worker]({{< relref "/developer-guide/vendure-worker" >}}). This is suitable for long-running or resource-intensive tasks.
+1. A Plugin may define logic to be run by the [Vendure Worker]({{< relref "/guides/developer-guide/vendure-worker" >}}). This is suitable for long-running or resource-intensive tasks.
 2. A Plugin can modify any aspect of server configuration via the [`configuration` metadata property]({{< relref "vendure-plugin-metadata" >}}#configuration).
 3. A Plugin can extend the GraphQL APIs via the [`shopApiExtensions` metadata property]({{< relref "vendure-plugin-metadata" >}}#shopapiextensions) and the [`adminApiExtensions` metadata property]({{< relref "vendure-plugin-metadata" >}}#adminapiextensions).
 4. A Plugin can interact with Vendure by importing the [`PluginCommonModule`]({{< relref "plugin-common-module" >}}), by which it may inject any of the core Vendure services (which are responsible for all interaction with the database as well as business logic). Additionally, a plugin may define new database entities via the [`entities` metadata property]({{< relref "vendure-plugin-metadata" >}}#entities) and otherwise define any other providers and controllers just like any [Nestjs module](https://docs.nestjs.com/modules).

docs/content/plugins/plugin-examples/using-job-queue-service.md → docs/content/guides/plugins/plugin-examples/using-job-queue-service.md

@@ -6,7 +6,7 @@ showtoc: true
 
 # Using the Job Queue
 
-If your plugin involves long-running tasks, you can take advantage of the [job queue system]({{< relref "/developer-guide/job-queue" >}}) that comes with Vendure. This example defines a mutation that can be used to transcode and link a video to a Product's customFields.
+If your plugin involves long-running tasks, you can take advantage of the [job queue system]({{< relref "/guides/developer-guide/job-queue" >}}) that comes with Vendure. This example defines a mutation that can be used to transcode and link a video to a Product's customFields.
 
 ```TypeScript
 // product-video.resolver.ts

docs/content/plugins/writing-a-vendure-plugin.md → docs/content/guides/plugins/writing-a-vendure-plugin.md

@@ -121,7 +121,7 @@ Some explanations of this code are in order:
 * We are able to use Nest's dependency injection to inject an instance of our `CatFetcher` class into the constructor of the resolver. We are also injecting an instance of the built-in [ProductService class]({{< relref "product-service" >}}), which is responsible for operations on Products.
 * We use the `@Transaction()` decorator to ensure that all database operations in this resolver are run within a transaction. This ensures that if any part of it fails, all changes will be rolled back, keeping our data in a consistent state. For more on this, see the [Transaction Decorator docs]({{< relref "transaction-decorator" >}}).
 * We use the `@Mutation()` decorator to mark this method as a resolver for the GraphQL mutation with the corresponding name.
-* The `@Allow()` decorator enables us to define permissions restrictions on the mutation. Only those users whose permissions include `UpdateCatalog` may perform this operation. For a full list of available permissions, see the [Permission enum]({{< relref "/graphql-api/admin/enums" >}}#permission). Plugins may also define custom permissions, see [Defining custom permissions]({{< relref "defining-custom-permissions" >}}).
+* The `@Allow()` decorator enables us to define permissions restrictions on the mutation. Only those users whose permissions include `UpdateCatalog` may perform this operation. For a full list of available permissions, see the [Permission enum]({{< relref "/reference/graphql-api/admin/enums" >}}#permission). Plugins may also define custom permissions, see [Defining custom permissions]({{< relref "defining-custom-permissions" >}}).
 * The `@Ctx()` decorator injects the current [RequestContext]({{< relref "request-context" >}}) into the resolver. This provides information about the current request such as the current Session, User and Channel. It is required by most of the internal service methods.
 * The `@Args()` decorator injects the arguments passed to the mutation as an object.