@vendure/docs 0.0.0-202601221213 → 0.0.0-202601271334

package/docs/guides/deployment/deploy-to-northflank/index.mdx

@@ -596,7 +596,7 @@ Now that you have a basic Vendure server up and running, you can explore some of
 that you might need for a full production setup:
 
 - Configure [health checks](https://northflank.com/docs/v1/application/observe/configure-health-checks) to ensure any container crashes are rapidly detected and restarted. Also see the
-[Vendure health check docs](/guides/deployment/using-docker#healthreadiness-checks).
+[Vendure health check docs](/deployment/using-docker#healthreadiness-checks).
 - [Set up a Redis instance](https://northflank.com/docs/v1/application/databases-and-persistence/deploy-databases-on-northflank/deploy-redis-on-northflank) so that you can take advantage of our highly performant [BullMQJobQueuePlugin](/reference/core-plugins/job-queue-plugin/bull-mqjob-queue-plugin) and set up [Redis-based session caching](/reference/typescript-api/auth/session-cache-strategy/) to handle multi-instance deployments.
 - With the above in place, you can safely start to [scale your server instances](https://northflank.com/docs/v1/application/scale/scaling-replicas) to handle more traffic. 
 - [Add a custom domain](https://northflank.com/docs/v1/application/domains/add-a-domain-to-your-account) using Northflank's powerful DNS management system.

package/docs/guides/deployment/deploy-to-railway/index.mdx

@@ -198,5 +198,5 @@ want to consider the following:
 - Use Redis to power the job queue and session cache. This is not only more performant, but will enable horizontal scaling of your
 server and worker instances.
   - [Railway Redis docs](https://docs.railway.app/guides/redis)
-  - [Vendure horizontal scaling docs](/guides/deployment/horizontal-scaling)
+  - [Vendure horizontal scaling docs](/deployment/horizontal-scaling)
   

package/docs/guides/deployment/deploy-to-render/index.mdx

@@ -217,5 +217,5 @@ want to consider the following:
 - Use Redis to power the job queue and session cache. This is not only more performant, but will enable horizontal scaling of your
   server and worker instances.
   - [Render Redis docs](https://docs.render.com/redis#creating-a-redis-instance)
-  - [Vendure horizontal scaling docs](/guides/deployment/horizontal-scaling)
+  - [Vendure horizontal scaling docs](/deployment/horizontal-scaling)
   

package/docs/guides/deployment/deploying-admin-ui.mdx

@@ -8,7 +8,7 @@ showtoc: true
 If you have customized the Admin UI with extensions, you should compile your custom Admin UI app ahead of time
 before deploying it. This will bundle the app into a set of static files which are then served by the AdminUiPlugin.
 
-- [Guide: Compiling the Admin UI as a deployment step](/guides/extending-the-admin-ui/getting-started/#compiling-as-a-deployment-step).
+- [Guide: Compiling the Admin UI as a deployment step](/extending-the-admin-ui/getting-started/#compiling-as-a-deployment-step).
 
 :::warning
 

package/docs/guides/deployment/getting-data-into-production.mdx

@@ -41,8 +41,8 @@ Set the `DB_SYNCHRONIZE` variable to `true` on first start, and then after the s
 
 ## Importing initial & catalog data
 
-Importing initial and catalog data can be handled by Vendure `populate()` helper function - see the [Importing Product Data guide](/guides/developer-guide/importing-data/).
+Importing initial and catalog data can be handled by Vendure `populate()` helper function - see the [Importing Product Data guide](/developer-guide/importing-data/).
 
 ## Importing other data
 
-Any kinds of data not covered by the `populate()` function can be imported using a custom script, which can use any Vendure service or service defined by your custom plugins to populate data in any way you like. See the [Stand-alone scripts guide](/guides/developer-guide/stand-alone-scripts/).
+Any kinds of data not covered by the `populate()` function can be imported using a custom script, which can use any Vendure service or service defined by your custom plugins to populate data in any way you like. See the [Stand-alone scripts guide](/developer-guide/stand-alone-scripts/).

package/docs/guides/deployment/horizontal-scaling.mdx

@@ -11,7 +11,7 @@ This type of scaling has two main advantages:
 1. It can enable increased throughput (requests/second) by distributing the incoming requests between multiple instances.
 2. It can increase resilience because if a single instance fails, the other instances will still be able to service requests.
 
-As discussed in the [Server resource requirements guide](/guides/deployment/server-resource-requirements), horizontal scaling can be the most cost-effective way of deploying your Vendure server due to the single-threaded nature of Node.js.
+As discussed in the [Server resource requirements guide](/deployment/server-resource-requirements), horizontal scaling can be the most cost-effective way of deploying your Vendure server due to the single-threaded nature of Node.js.
 
 In Vendure, both the server and the worker can be scaled horizontally. Scaling the server will increase the throughput of the GraphQL APIs, whereas scaling the worker can increase the speed with which the job queue is processed by allowing more jobs to be run in parallel.
 
@@ -43,7 +43,7 @@ One way of implementing horizontal scaling is to use Docker to wrap your Vendure
 Some hosting providers allow you to provide a Docker image and will then run multiple instances of that image. Kubernetes can also be used to manage multiple instances
 of a Docker image.
 
-For a more complete guide, see the [Using Docker guide](/guides/deployment/using-docker).
+For a more complete guide, see the [Using Docker guide](/deployment/using-docker).
 
 ## Using PM2
 

package/docs/guides/deployment/production-configuration/index.mdx

@@ -20,7 +20,7 @@ The `APP_ENV` environment variable can then be set using the admin dashboard of
 
 ![A typical UI for setting env vars](./env-var-ui.webp)
 
-If you are using [Docker or Kubernetes](/guides/deployment/using-docker), they include their own methods of setting environment variables.
+If you are using [Docker or Kubernetes](/deployment/using-docker), they include their own methods of setting environment variables.
 
 ## Superadmin credentials
 
@@ -135,4 +135,4 @@ For more details on configuring `trust proxy`, refer to the [Express documentati
 
 ## Security Considerations
 
-Please read over the [Security](/guides/developer-guide/security) section of the Developer Guide for more information on how to secure your Vendure application.
+Please read over the [Security](/developer-guide/security) section of the Developer Guide for more information on how to secure your Vendure application.

package/docs/guides/deployment/server-resource-requirements.mdx

@@ -18,7 +18,7 @@ CPU resources are generally measured in "cores" or "vCPUs" (virtual CPUs) depend
 
 Because Node.js is single-threaded, a single instance of the Vendure server or worker will not be able to take advantage of multiple CPUs. For example, if you set up a server instance running with 4 CPUs, the server will only use 1 of those CPUs and the other 3 will be wasted.
 
-Therefore, when looking to optimize performance (for example, the number of requests that can be serviced per second), it makes sense to scale horizontally by running multiple instances of the Vendure server. See the [Horizontal Scaling guide](/guides/deployment/horizontal-scaling).
+Therefore, when looking to optimize performance (for example, the number of requests that can be serviced per second), it makes sense to scale horizontally by running multiple instances of the Vendure server. See the [Horizontal Scaling guide](/deployment/horizontal-scaling).
 
 ## Load testing
 

package/docs/guides/developer-guide/cache/index.mdx

@@ -38,7 +38,7 @@ export const config: VendureConfig = {
 };
 ```
 
-After enabling the `DefaultCachePlugin`, you will need to [generate a migration](/guides/developer-guide/migrations/) to add the necessary
+After enabling the `DefaultCachePlugin`, you will need to [generate a migration](/developer-guide/migrations/) to add the necessary
 tables to the database.
 
 ### RedisCachePlugin

package/docs/guides/developer-guide/channel-aware/index.mdx

@@ -7,7 +7,7 @@ showtoc: true
 
 Making an entity channel-aware means that it can be associated with a specific [Channel](/reference/typescript-api/entities/channel).
 This is useful when you want to have different data or features for different channels. First you will have to create
-an entity ([Define a database entity](/guides/developer-guide/database-entity/)) that implements the `ChannelAware` interface.
+an entity ([Define a database entity](/developer-guide/database-entity/)) that implements the `ChannelAware` interface.
 This interface requires the entity to provide a `channels` property
 
 ```ts title="src/plugins/requests/entities/product-request.entity.ts"
@@ -64,7 +64,7 @@ export class RequestService {
     }
 }
 ```
-For [Translatable entities](/guides/developer-guide/translations/), the best place to assign the channels is inside the `beforeSave` input of the [TranslatableSaver](/reference/typescript-api/service-helpers/translatable-saver/) helper class.
+For [Translatable entities](/developer-guide/translations/), the best place to assign the channels is inside the `beforeSave` input of the [TranslatableSaver](/reference/typescript-api/service-helpers/translatable-saver/) helper class.
 
 
 ## Querying channel-aware entities

package/docs/guides/developer-guide/cli/index.mdx

@@ -191,7 +191,7 @@ yarn vendure add -p MyPlugin --config ./custom-vendure.config.ts
 
 ## The Migrate Command
 
-The `migrate` command is used to generate and manage [database migrations](/guides/developer-guide/migrations) for your Vendure project.
+The `migrate` command is used to generate and manage [database migrations](/developer-guide/migrations) for your Vendure project.
 
 ### Interactive Mode
 
@@ -275,7 +275,7 @@ The `schema` command was added in Vendure v3.5
 The `schema` command allows you to generate a schema file for your Admin or Shop APIs, in either the GraphQL schema definition language (SDL)
 or as JSON.
 
-This is useful when integrating with GraphQL tooling such as your [IDE's GraphQL plugin](/guides/getting-started/graphql-intro/#ide-plugins).
+This is useful when integrating with GraphQL tooling such as your [IDE's GraphQL plugin](/getting-started/graphql-intro/#ide-plugins).
 
 ### Interactive Mode
 

package/docs/guides/developer-guide/configuration/index.mdx

@@ -66,7 +66,7 @@ export const config: VendureConfig = {
 
 ### Configuring authentication
 
-Authentication settings are configured with [`VendureConfig.authOptions`](/reference/typescript-api/auth/auth-options/). The most important setting here is whether the storefront client will use cookies or bearer tokens to manage user sessions. For more detail on this topic, see [the Managing Sessions guide](/guides/storefront/connect-api/#managing-sessions).
+Authentication settings are configured with [`VendureConfig.authOptions`](/reference/typescript-api/auth/auth-options/). The most important setting here is whether the storefront client will use cookies or bearer tokens to manage user sessions. For more detail on this topic, see [the Managing Sessions guide](/storefront/connect-api/#managing-sessions).
 
 The username and default password of the superadmin user can also be specified here. In production, it is advisable to use environment variables for these settings (see the following section on usage of environment variables).
 
@@ -179,7 +179,7 @@ export const config: VendureConfig = {
 
 :::info
 
-In production, the way you manage environment variables will depend on your hosting provider. Read more about this in our [Production Configuration guide](/guides/deployment/production-configuration/).
+In production, the way you manage environment variables will depend on your hosting provider. Read more about this in our [Production Configuration guide](/deployment/production-configuration/).
 
 :::
 

package/docs/guides/developer-guide/custom-fields/index.mdx

@@ -14,7 +14,7 @@ Some use-cases for custom fields include:
 * Adding a longitude and latitude to the `StockLocation` for use in selecting the closest location to a customer.
 
 :::note
-Custom fields are not solely restricted to Vendure's native entities though, it's also possible to add support for custom fields to your own custom entities. See: [Supporting custom fields](/guides/developer-guide/database-entity/#supporting-custom-fields)
+Custom fields are not solely restricted to Vendure's native entities though, it's also possible to add support for custom fields to your own custom entities. See: [Supporting custom fields](/developer-guide/database-entity/#supporting-custom-fields)
 :::
 
 ## Defining custom fields
@@ -39,7 +39,7 @@ const config = {
 
 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](/guides/developer-guide/migrations/).
+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](/developer-guide/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 [AdminUiPlugin](/reference/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.
 
@@ -643,7 +643,7 @@ const config = {
 The `requiresPermission` property only affects the _Admin API_. Access to a custom field via the _Shop API_ is controlled by the `public` property.
 
 If you need special logic to control access to a custom field in the Shop API, you can set `public: false` and then implement
-a custom [field resolver](/guides/developer-guide/extend-graphql-api/#add-fields-to-existing-types) which contains the necessary logic, and returns
+a custom [field resolver](/developer-guide/extend-graphql-api/#add-fields-to-existing-types) which contains the necessary logic, and returns
 the entity's custom field value if the current customer meets the requirements.
 
 :::
@@ -1195,7 +1195,7 @@ This table shows the default form input component used for each custom field typ
 
 The Dashboard app has built-in selection components for "relation" custom fields that reference certain common entity types, such as Asset, Product, ProductVariant and Customer. If you are relating to an entity not covered by the built-in selection components, you will see a generic relation component which allows you to manually enter the ID of the entity you wish to select.
 
-If the generic selector is not suitable, or is you wish to replace one of the built-in selector components, you can create a UI extension that defines a custom field control for that custom field. You can read more about this in the [custom form input guide](/guides/extending-the-admin-ui/custom-form-inputs/)
+If the generic selector is not suitable, or is you wish to replace one of the built-in selector components, you can create a UI extension that defines a custom field control for that custom field. You can read more about this in the [custom form input guide](/extending-the-admin-ui/custom-form-inputs/)
 :::
 
 ### Specifying the input component
@@ -1281,7 +1281,7 @@ The various configuration options for each of the built-in form input  (e.g. `su
 
 ### Custom form input components
 
-If none of the built-in form input components are suitable, you can create your own. This is a more advanced topic which is covered in detail in the [Custom Form Input Components](/guides/extending-the-admin-ui/custom-form-inputs/) guide.
+If none of the built-in form input components are suitable, you can create your own. This is a more advanced topic which is covered in detail in the [Custom Form Input Components](/extending-the-admin-ui/custom-form-inputs/) guide.
 
 ## Tabbed custom fields
 
@@ -1312,7 +1312,7 @@ const config = {
 ## 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](/guides/developer-guide/plugins/) which needs to
+VendureConfig. Consider the example above - let's say we have a [plugin](/developer-guide/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:
@@ -1389,7 +1389,7 @@ When you define custom fields on the `OrderLine` entity, the following API chang
 - Admin API: the equivalent mutations for manipulating draft orders and for modifying and order will also have inputs to allow custom field values to be set.
 
 :::info
-To see an example of this in practice, see the [Configurable Product guide](/guides/how-to/configurable-products/)
+To see an example of this in practice, see the [Configurable Product guide](/how-to/configurable-products/)
 :::
 
 ### Order custom fields

package/docs/guides/developer-guide/custom-permissions/index.mdx

@@ -3,7 +3,7 @@ title: "Define custom permissions"
 showtoc: true
 ---
 
-Vendure uses a fine-grained access control system based on roles & permissions. This is described in detail in the [Auth guide](/guides/core-concepts/auth/). The built-in [`Permission` enum](/reference/typescript-api/common/permission/) includes a range of permissions to control create, read, update, and delete access to the built-in entities.
+Vendure uses a fine-grained access control system based on roles & permissions. This is described in detail in the [Auth guide](/core-concepts/auth/). The built-in [`Permission` enum](/reference/typescript-api/common/permission/) includes a range of permissions to control create, read, update, and delete access to the built-in entities.
 
 When building plugins, you may need to define new permissions to control access to new functionality. This guide explains how to do so.
 

package/docs/guides/developer-guide/database-entity/index.mdx

@@ -69,7 +69,7 @@ export class ReviewsPlugin {}
 ```
 
 :::note
-Once you have added a new entity to your plugin, and the plugin has been added to your VendureConfig plugins array, you must create a [database migration](/guides/developer-guide/migrations/) to create the new table in the database.
+Once you have added a new entity to your plugin, and the plugin has been added to your VendureConfig plugins array, you must create a [database migration](/developer-guide/migrations/) to create the new table in the database.
 :::
 
 ## Using the entity
@@ -112,7 +112,7 @@ In addition to the decorators described above, there are many other decorators p
 
 There is also another Vendure-specific decorator for representing monetary values specifically:
 
-- [`@Money()`](/reference/typescript-api/money/money-decorator): This works together with the [`MoneyStrategy`](/reference/typescript-api/money/money-strategy) to allow configurable control over how monetary values are stored in the database. For more information see the [Money & Currency guide](/guides/core-concepts/money/#the-money-decorator).
+- [`@Money()`](/reference/typescript-api/money/money-decorator): This works together with the [`MoneyStrategy`](/reference/typescript-api/money/money-strategy) to allow configurable control over how monetary values are stored in the database. For more information see the [Money & Currency guide](/core-concepts/money/#the-money-decorator).
 
 :::info
 The full list of TypeORM decorators can be found in the [TypeORM decorator reference](https://typeorm.io/decorator-reference)
@@ -121,16 +121,16 @@ The full list of TypeORM decorators can be found in the [TypeORM decorator refer
 
 ## Corresponding GraphQL type
 
-Once you have defined a new DB entity, it is likely that you want to expose it in your GraphQL API. Here's how to [define a new type in your GraphQL API](/guides/developer-guide/extend-graphql-api/#defining-a-new-type).
+Once you have defined a new DB entity, it is likely that you want to expose it in your GraphQL API. Here's how to [define a new type in your GraphQL API](/developer-guide/extend-graphql-api/#defining-a-new-type).
 
 ## Supporting translations
 
-In case you'd like to make the `ProductReview` entity support content in multiple languages, here's how to [implement the `Translatable` Interface](/guides/developer-guide/translatable).
+In case you'd like to make the `ProductReview` entity support content in multiple languages, here's how to [implement the `Translatable` Interface](/developer-guide/translatable).
 
 ## Supporting channels
 
-In case you'd like to support separate `ProductReview` entities per Channel, here's how to [implement the `ChannelAware` Interface](/guides/developer-guide/channel-aware).
+In case you'd like to support separate `ProductReview` entities per Channel, here's how to [implement the `ChannelAware` Interface](/developer-guide/channel-aware).
 
 ## Supporting custom fields
 
-Just like you can extend Vendures native entities like `Product` to support your custom needs, you may enable other developers to extend your custom entities too! Here's how to [implement the `HasCustomFields` Interface](/guides/developer-guide/has-custom-fields).
+Just like you can extend Vendures native entities like `Product` to support your custom needs, you may enable other developers to extend your custom entities too! Here's how to [implement the `HasCustomFields` Interface](/developer-guide/has-custom-fields).

package/docs/guides/developer-guide/error-handling/index.mdx

@@ -281,7 +281,7 @@ switch (result.applyCouponCode.__typename) {
 }
 ```
 
-If we combine this approach with [GraphQL code generation](/guides/storefront/codegen/), then TypeScript will even be able to
+If we combine this approach with [GraphQL code generation](/storefront/codegen/), then TypeScript will even be able to
 help us ensure that we have handled all possible ErrorResults:
 
 ```ts

package/docs/guides/developer-guide/events/index.mdx

@@ -242,7 +242,7 @@ export class ProductReviewService {
 
 ### Entity events
 
-There is a special event class [`VendureEntityEvent`](/reference/typescript-api/events/vendure-entity-event) for events relating to the creation, update or deletion of entities. Let's say you have a custom entity (see [defining a database entity](/guides/developer-guide/database-entity)) `BlogPost` and you want to trigger an event whenever a new `BlogPost` is created, updated or deleted:
+There is a special event class [`VendureEntityEvent`](/reference/typescript-api/events/vendure-entity-event) for events relating to the creation, update or deletion of entities. Let's say you have a custom entity (see [defining a database entity](/developer-guide/database-entity)) `BlogPost` and you want to trigger an event whenever a new `BlogPost` is created, updated or deleted:
 
 ```ts title="src/plugins/blog/events/blog-post-event.ts"
 import { ID, RequestContext, VendureEntityEvent } from '@vendure/core';

package/docs/guides/developer-guide/extend-graphql-api/index.mdx

@@ -157,7 +157,7 @@ class BannerAdminResolver {
 Note that we have used the `@Allow()` decorator to ensure that only users with the `UpdateSettings` permission can call this mutation. We have also wrapped the resolver in a transaction using `@Transaction()`, which is a good idea for any mutation which modifies the database.
 
 :::info
-For more information on the available decorators, see the [API Layer "decorators" guide](/guides/developer-guide/the-api-layer/#api-decorators).
+For more information on the available decorators, see the [API Layer "decorators" guide](/developer-guide/the-api-layer/#api-decorators).
 :::
 
 Finally, we add the resolver to the plugin metadata:
@@ -191,7 +191,7 @@ export class BannerPlugin {}
 
 If you have defined a new database entity, it is likely that you'll want to expose this entity in your GraphQL API. To do so, you'll need to define a corresponding GraphQL type.
 
-Using the `ProductReview` entity from the [Define a database entity guide](/guides/developer-guide/database-entity), let's see how we can expose it as a new type in the API.
+Using the `ProductReview` entity from the [Define a database entity guide](/developer-guide/database-entity), let's see how we can expose it as a new type in the API.
 
 As a reminder, here is the `ProductReview` entity:
 
@@ -384,7 +384,7 @@ export class FieldOverrideExampleResolver {
 
 When dealing with operations that return a GraphQL union type, there is an extra step needed.
 
-Union types are commonly returned from mutations in the Vendure APIs. For more detail on this see the section on [ErrorResults](/guides/developer-guide/error-handling#expected-errors-errorresults). For example: 
+Union types are commonly returned from mutations in the Vendure APIs. For more detail on this see the section on [ErrorResults](/developer-guide/error-handling#expected-errors-errorresults). For example: 
 
 ```graphql
 type MyCustomErrorResult implements ErrorResult {

package/docs/guides/developer-guide/has-custom-fields/index.mdx

@@ -3,7 +3,7 @@ title: "Implementing HasCustomFields"
 showtoc: true
 ---
 
-From Vendure v2.2, it is possible to add support for [custom fields](/guides/developer-guide/custom-fields/) to your custom entities. This is useful when you are defining a custom entity as part of a plugin which is intended to be used by other developers. For example, a plugin which defines a new entity for storing product reviews might want to allow the developer to add custom fields to the review entity.
+From Vendure v2.2, it is possible to add support for [custom fields](/developer-guide/custom-fields/) to your custom entities. This is useful when you are defining a custom entity as part of a plugin which is intended to be used by other developers. For example, a plugin which defines a new entity for storing product reviews might want to allow the developer to add custom fields to the review entity.
 
 ## Defining entities that support custom fields
 
@@ -52,7 +52,7 @@ export class ProductReview extends VendureEntity implements HasCustomFields {
 
 ### Type generation
 
-Given the above entity your [API extension](/guides/developer-guide/extend-graphql-api/) might look like this:
+Given the above entity your [API extension](/developer-guide/extend-graphql-api/) might look like this:
 
 ```graphql
 type ProductReview implements Node {
@@ -88,7 +88,7 @@ In order for Vendure to find the correct input types to extend to, they must con
 - `Create<EntityName>Input`
 - `Update<EntityName>Input`
 
-And if your entity is [supporting translations](/guides/developer-guide/translatable):
+And if your entity is [supporting translations](/developer-guide/translatable):
 
 - `<EntityName>Translation`
 - `<EntityName>TranslationInput`
@@ -120,7 +120,7 @@ export type UpdateProductReviewInput = {
 
 ## Supporting custom fields in your services
 
-Creating and updating your entity works now by setting the fields like usual, with one important addition being, you mustn't forget to update relations via the `CustomFieldRelationService`. This is needed because a consumer of your plugin may extend the entity with custom fields of type [`relation`](/guides/developer-guide/custom-fields/#properties-for-relation-fields) which need to get saved separately.
+Creating and updating your entity works now by setting the fields like usual, with one important addition being, you mustn't forget to update relations via the `CustomFieldRelationService`. This is needed because a consumer of your plugin may extend the entity with custom fields of type [`relation`](/developer-guide/custom-fields/#properties-for-relation-fields) which need to get saved separately.
 
 ```ts title="src/plugins/reviews/services/review.service.ts"
 import { Injectable } from '@nestjs/common';
@@ -171,4 +171,4 @@ export const config: VendureConfig = {
 
 ## Migrations
 
-Extending entities will alter the database schema requiring a migration. See the [migrations guide](/guides/developer-guide/migrations/) for further details.
+Extending entities will alter the database schema requiring a migration. See the [migrations guide](/developer-guide/migrations/) for further details.

package/docs/guides/developer-guide/importing-data/index.mdx

@@ -47,7 +47,7 @@ Here's an explanation of each column:
 
 ### Importing Custom Field Data
 
-If you have [CustomFields](/guides/developer-guide/custom-fields/) defined on your Product or ProductVariant entities, this data can also be encoded in the import csv:
+If you have [CustomFields](/developer-guide/custom-fields/) defined on your Product or ProductVariant entities, this data can also be encoded in the import csv:
 
 * `product:<customFieldName>`: The value of this column will populate `Product.customFields[customFieldName]`. 
 * `variant:<customFieldName>`: The value of this column will populate `ProductVariant.customFields[customFieldName]`. 
@@ -264,9 +264,9 @@ Running this script will populate the database with the test data like when you
 
 ### Custom populate scripts
 
-If you require more control over how your data is being imported - for example if you also need to import data into custom entities, or import customer or order information - you can create your own CLI script to do this: see [Stand-Alone CLI Scripts](/guides/developer-guide/stand-alone-scripts/).
+If you require more control over how your data is being imported - for example if you also need to import data into custom entities, or import customer or order information - you can create your own CLI script to do this: see [Stand-Alone CLI Scripts](/developer-guide/stand-alone-scripts/).
 
-In addition to all the services available in the [Service Layer](/guides/developer-guide/the-service-layer/), the following specialized import services are available:
+In addition to all the services available in the [Service Layer](/developer-guide/the-service-layer/), the following specialized import services are available:
 
 * [`ImportParser`](/reference/typescript-api/import-export/import-parser): Used to parse the CSV file into an array of objects.
 * [`FastImporterService`](/reference/typescript-api/import-export/fast-importer-service): Used to create new products & variants in bulk, optimized for speed.

package/docs/guides/developer-guide/migrating-from-v1/breaking-api-changes.mdx

@@ -164,7 +164,7 @@ If you are using the `@vendure/ui-devkit` package to generate custom ui extensio
 - The Admin UI component `vdr-product-selector` has been renamed to `vdr-product-variant-selector` to more accurately represent what it does. If you are using `vdr-product-selector` if any ui extensions code, update it to use the new selector.
 
 ### Other breaking API changes
-- **End-to-end tests using Jest** will likely run into issues due to our move towards using some dependencies that make use of ES modules. We have found the best solution to be to migrate tests over to [Vitest](https://vitest.dev), which can handle this and is also significantly faster than Jest. See the updated [Testing guide](/guides/developer-guide/testing) for instructions on getting started with Vitest.
+- **End-to-end tests using Jest** will likely run into issues due to our move towards using some dependencies that make use of ES modules. We have found the best solution to be to migrate tests over to [Vitest](https://vitest.dev), which can handle this and is also significantly faster than Jest. See the updated [Testing guide](/developer-guide/testing) for instructions on getting started with Vitest.
 - Internal `ErrorResult` classes now take a single object argument rather than multiple args.
 - All monetary values are now represented in the GraphQL APIs with a new `Money` scalar type. If you use [graphql-code-generator](https://the-guild.dev/graphql/codegen), you'll want to tell it to treat this scalar as a number:
     ```ts
@@ -208,4 +208,4 @@ If you are using the `@vendure/ui-devkit` package to generate custom ui extensio
 - If you are using the **BullMQJobQueuePlugin**, the minimum Redis recommended version is 6.2.0.
 - The `WorkerHealthIndicator` which was deprecated in v1.3.0 has been removed, as well as the `jobQueueOptions.enableWorkerHealthCheck` config option.
 - The `CustomerGroupEntityEvent` (fired on creation, update or deletion of a CustomerGroup) has been renamed to `CustomerGroupEvent`, and the former `CustomerGroupEvent` (fired when Customers are added to or removed from a group) has been renamed to `CustomerGroupChangeEvent`.
-- We introduced the [plugin compatibility API](/guides/developer-guide/plugins/#step-7-specify-compatibility) to allow plugins to indicate what version of Vendure they are compatible with. To avoid bootstrap messages you should add this property to your plugins.
+- We introduced the [plugin compatibility API](/developer-guide/plugins/#step-7-specify-compatibility) to allow plugins to indicate what version of Vendure they are compatible with. To avoid bootstrap messages you should add this property to your plugins.

package/docs/guides/developer-guide/migrating-from-v1/index.mdx

@@ -34,6 +34,6 @@ Migration will consist of these main steps:
      }
    }
    ```
-2. **Migrate your database**. This is covered in detail in the [database migration section](/guides/developer-guide/migrating-from-v1/database-migration).
-3. **Update your custom code** (configuration, plugins, admin ui extensions) to handle the breaking changes. Details of these changes are covered in the [breaking API changes section](/guides/developer-guide/migrating-from-v1/breaking-api-changes).
-4. **Update your storefront** to handle some small breaking changes in the Shop GraphQL API. See the [storefront migration section](/guides/developer-guide/migrating-from-v1/storefront-migration) for details.
+2. **Migrate your database**. This is covered in detail in the [database migration section](/developer-guide/migrating-from-v1/database-migration).
+3. **Update your custom code** (configuration, plugins, admin ui extensions) to handle the breaking changes. Details of these changes are covered in the [breaking API changes section](/developer-guide/migrating-from-v1/breaking-api-changes).
+4. **Update your storefront** to handle some small breaking changes in the Shop GraphQL API. See the [storefront migration section](/developer-guide/migrating-from-v1/storefront-migration) for details.

package/docs/guides/developer-guide/migrations/index.mdx

@@ -4,8 +4,8 @@ title: "Migrations"
 
 Database migrations are needed whenever the database schema changes. This can be caused by:
 
-* changes to the [custom fields](/guides/developer-guide/custom-fields/) configuration
-* new [database entities defined by plugins](/guides/developer-guide/database-entity/)
+* changes to the [custom fields](/developer-guide/custom-fields/) configuration
+* new [database entities defined by plugins](/developer-guide/database-entity/)
 * occasional changes to the core Vendure database schema when updating to newer versions
 
 ## Synchronize vs migrate

package/docs/guides/developer-guide/overview/index.mdx

@@ -13,8 +13,8 @@ These are the major parts of a Vendure application:
 
 * **Server**: The Vendure server is the part that handles requests coming in to the GraphQL APIs. It serves both the [Shop API](/reference/graphql-api/shop/queries) and [Admin API](/reference/graphql-api/admin/queries), and can send jobs to the Job Queue to be processed by the Worker.
 * **Worker**: The Worker runs in the background and deals with tasks such as updating the search index, sending emails, and other tasks which may be long-running, resource-intensive or require retries.
-* **Dashboard**: The Dashboard is how shop administrators manage orders, customers, products, settings and so on. The Dashboard can be further extended to support custom functionality, as detailed in the [Extending the Dashboard](/guides/extending-the-dashboard/extending-overview/) section
-* **Storefront**: With headless commerce, you are free to implement your storefront exactly as you see fit, unconstrained by the back-end, using any technologies that you like. To make this process easier, we have created a number of [storefront starter kits](/guides/storefront/storefront-starters/), as well as [guides on building a storefront](/guides/storefront/connect-api/).
+* **Dashboard**: The Dashboard is how shop administrators manage orders, customers, products, settings and so on. The Dashboard can be further extended to support custom functionality, as detailed in the [Extending the Dashboard](/extending-the-dashboard/extending-overview/) section
+* **Storefront**: With headless commerce, you are free to implement your storefront exactly as you see fit, unconstrained by the back-end, using any technologies that you like. To make this process easier, we have created a number of [storefront starter kits](/storefront/storefront-starters/), as well as [guides on building a storefront](/storefront/connect-api/).
 
 ![./Vendure_docs-architecture.webp](./Vendure_docs-architecture.webp) 
 

package/docs/guides/developer-guide/plugins/index.mdx

@@ -143,7 +143,7 @@ This is the recommended way of creating a new plugin.
 
 ## Writing a plugin from scratch
 
-Although the [Vendure CLI](/guides/developer-guide/cli/) is the recommended way to create a new plugin, it can be useful to understand the process of creating
+Although the [Vendure CLI](/developer-guide/cli/) is the recommended way to create a new plugin, it can be useful to understand the process of creating
 a plugin manually.
 
 Vendure **plugins** are used to extend the core functionality of the server. Plugins can be pre-made functionality that you can install via npm, or they can be custom plugins that you write yourself.
@@ -164,7 +164,7 @@ For any unit of functionality that you need to add to your project, you'll be cr
 :::info
 For a complete working example of a Vendure plugin, see the [real-world-vendure Reviews plugin](https://github.com/vendurehq/real-world-vendure/tree/master/src/plugins/reviews)
 
-You can also use the [Vendure CLI](/guides/developer-guide/cli) to quickly scaffold a new plugin.
+You can also use the [Vendure CLI](/developer-guide/cli) to quickly scaffold a new plugin.
 :::
 
 In this guide, we will implement a simple but fully-functional **wishlist plugin** step-by-step. The goal of this plugin is to allow signed-in customers to add products to a wishlist, and to view and manage their wishlist.
@@ -306,7 +306,7 @@ import './types';
 ```
 
 :::note
-Custom fields are not solely restricted to Vendure's native entities though, it's also possible to add support for custom fields to your own custom entities. This way other plugins would be able to extend our example `WishlistItem`. See: [Supporting custom fields](/guides/developer-guide/database-entity/#supporting-custom-fields)
+Custom fields are not solely restricted to Vendure's native entities though, it's also possible to add support for custom fields to your own custom entities. This way other plugins would be able to extend our example `WishlistItem`. See: [Supporting custom fields](/developer-guide/database-entity/#supporting-custom-fields)
 :::
 
 ### Step 4: Create a service
@@ -800,4 +800,4 @@ mutation RemoveFromWishlist {
 If you have created a plugin that you would like to share with the community, you can publish it to npm, and even
 have it listed on the [Vendure Hub](https://vendure.io/hub).
 
-For a full guide to publishing plugins, see the [Publishing a Plugin how-to guide](/guides/how-to/publish-plugin/).
+For a full guide to publishing plugins, see the [Publishing a Plugin how-to guide](/how-to/publish-plugin/).

package/docs/guides/developer-guide/rest-endpoint/index.mdx

@@ -3,7 +3,7 @@ title: "Add a REST endpoint"
 showtoc: true
 ---
 
-REST-style endpoints can be defined as part of a [plugin](/guides/developer-guide/plugins/).
+REST-style endpoints can be defined as part of a [plugin](/developer-guide/plugins/).
 
 :::info
 REST endpoints are implemented as NestJS Controllers. For comprehensive documentation, see the [NestJS controllers documentation](https://docs.nestjs.com/controllers).
@@ -93,7 +93,7 @@ export class ProductsController {
 ```
 
 :::tip
-The following Vendure [API decorators](/guides/developer-guide/the-api-layer/#api-decorators) can also be used with NestJS controllers: `@Allow()`, `@Transaction()`, `@Ctx()`.
+The following Vendure [API decorators](/developer-guide/the-api-layer/#api-decorators) can also be used with NestJS controllers: `@Allow()`, `@Transaction()`, `@Ctx()`.
 
 Additionally, NestJS supports a number of other REST decorators detailed in the [NestJS controllers guide](https://docs.nestjs.com/controllers#request-object)
 :::

package/docs/guides/developer-guide/scheduled-tasks/index.mdx

@@ -17,7 +17,7 @@ Since Vendure v3.3, there is a built-in mechanism which allows you to define sch
 All the information on page applies to Vendure v3.3+
 
 For older versions, there is no built-in support for scheduled tasks, but you can
-instead use a [stand-alone script](/guides/developer-guide/stand-alone-scripts/) triggered by a cron job.
+instead use a [stand-alone script](/developer-guide/stand-alone-scripts/) triggered by a cron job.
 :::
 
 ## Setting up the DefaultSchedulerPlugin
@@ -34,7 +34,7 @@ export const config: VendureConfig = {
 };
 ```
 
-When you first add this plugin to your config, you'll need to [generate a migration](/guides/developer-guide/migrations/) because the
+When you first add this plugin to your config, you'll need to [generate a migration](/developer-guide/migrations/) because the
 plugin will make use of a new database table in order to guarantee only-once execution of tasks.
 
 You can then start adding tasks. Vendure ships with a task that will clean up old sessions from the database.
@@ -239,7 +239,7 @@ The second problem is handled by having tasks only executed on worker processes.
 
 ## Scheduled tasks vs job queue
 
-There is some overlap between the use of a scheduled task and a [job queue job](/guides/developer-guide/worker-job-queue/). They both perform some
+There is some overlap between the use of a scheduled task and a [job queue job](/developer-guide/worker-job-queue/). They both perform some
 task on the worker, independent of requests coming in to the server.
 
 The first difference is that jobs must be triggered explicitly, whereas scheduled tasks are triggered automatically according to the schedule.

package/docs/guides/developer-guide/stand-alone-scripts/index.mdx

@@ -94,7 +94,7 @@ async function importCustomerData() {
 
 ## Creating a RequestContext
 
-Almost all the methods exposed by Vendure's core services take a `RequestContext` object as the first argument. Usually, this object is created in the [API Layer](/guides/developer-guide/the-api-layer/#resolvers) by the `@Ctx()` decorator, and contains information related to the current API request.
+Almost all the methods exposed by Vendure's core services take a `RequestContext` object as the first argument. Usually, this object is created in the [API Layer](/developer-guide/the-api-layer/#resolvers) by the `@Ctx()` decorator, and contains information related to the current API request.
 
 When running a stand-alone script, we aren't making any API requests, so we need to create a `RequestContext` object manually. This can be done using the [`RequestContextService`](/reference/typescript-api/request/request-context-service/):
 

package/docs/guides/developer-guide/strategies-configurable-operations/index.mdx

@@ -322,7 +322,7 @@ a `component` property, and optional properties to configure that component.
 }
 ```
 
-A full description of the available UI components can be found in the [Custom Fields guide](/guides/developer-guide/custom-fields/#custom-field-ui).
+A full description of the available UI components can be found in the [Custom Fields guide](/developer-guide/custom-fields/#custom-field-ui).
 
 ### Injecting dependencies
 

package/docs/guides/developer-guide/testing/index.mdx

@@ -155,8 +155,8 @@ afterAll(async () => {
 
 An explanation of the options:
 
-* `productsCsvPath` This is a path to an optional CSV file containing product data. See [Product Import Format](/guides/developer-guide/importing-data/#product-import-format). You can see [an example used in the Vendure e2e tests](https://github.com/vendurehq/vendure/blob/master/packages/core/e2e/fixtures/e2e-products-full.csv) to get an idea of how it works. To start with you can just copy this file directly and use it as-is.
-* `initialData` This is an object which defines how other non-product data (Collections, ShippingMethods, Countries etc.) is populated. See [Initial Data Format](/guides/developer-guide/importing-data/#initial-data). You can [copy this example from the Vendure e2e tests](https://github.com/vendurehq/vendure/blob/master/e2e-common/e2e-initial-data.ts)
+* `productsCsvPath` This is a path to an optional CSV file containing product data. See [Product Import Format](/developer-guide/importing-data/#product-import-format). You can see [an example used in the Vendure e2e tests](https://github.com/vendurehq/vendure/blob/master/packages/core/e2e/fixtures/e2e-products-full.csv) to get an idea of how it works. To start with you can just copy this file directly and use it as-is.
+* `initialData` This is an object which defines how other non-product data (Collections, ShippingMethods, Countries etc.) is populated. See [Initial Data Format](/developer-guide/importing-data/#initial-data). You can [copy this example from the Vendure e2e tests](https://github.com/vendurehq/vendure/blob/master/e2e-common/e2e-initial-data.ts)
 * `customerCount` Specifies the number of fake Customers to create. Defaults to 10 if not specified.
 
 ### Write your tests

package/docs/guides/developer-guide/the-api-layer/index.mdx

@@ -144,7 +144,7 @@ data transformation.
 
 Guards, interceptors, pipes and filters can be added to your own custom resolvers and controllers
 using the NestJS decorators as given in the NestJS docs. However, a common pattern is to register them globally via a
-[Vendure plugin](/guides/developer-guide/plugins/):
+[Vendure plugin](/developer-guide/plugins/):
 
 ```ts title="src/plugins/my-plugin/my-plugin.ts"
 import { VendurePlugin } from '@vendure/core';
@@ -468,4 +468,4 @@ Although Vendure is primarily a GraphQL-based API, it is possible to add REST en
 you need to integrate with a third-party service or client application which only supports REST, for example.
 
 Creating a REST endpoint is covered in detail in the [Add a REST endpoint
-guide](/guides/developer-guide/rest-endpoint/).
+guide](/developer-guide/rest-endpoint/).

package/docs/guides/developer-guide/the-service-layer/index.mdx

@@ -18,7 +18,7 @@ Services are generally scoped to a specific domain or entity. For instance, in t
 and a corresponding [`ProductService`](/reference/typescript-api/services/product-service) which contains all the methods for interacting with products.
 
 Here's a simplified example of a `ProductService`, including an implementation of the `findOne()` method that was
-used in the example in the [previous section](/guides/developer-guide/the-api-layer/#resolvers):
+used in the example in the [previous section](/developer-guide/the-api-layer/#resolvers):
 
 ```ts title="src/services/product.service.ts"
 import { Injectable } from '@nestjs/common';

package/docs/guides/developer-guide/translations/index.mdx

@@ -98,7 +98,7 @@ export class MyService {
 ```
 ## Admin UI translations
 
-See the [Adding Admin UI Translations guide](/guides/extending-the-admin-ui/adding-ui-translations/).
+See the [Adding Admin UI Translations guide](/extending-the-admin-ui/adding-ui-translations/).
 
 ## Server message translations