fix(docs): Remove /guides/ prefix from internal documentation links

Links like `](/guides/developer-guide/...)` are now `](/developer-guide/...)`.
Updated JSDoc comments in source TypeScript files and regenerated API
reference documentation.

docs/docs/guides/core-concepts/auth/index.mdx

@@ -86,7 +86,7 @@ mutation {
 ```
 
 :::info
-See the [Managing Sessions guide](/guides/storefront/connect-api/#managing-sessions) for how to manage authenticated sessions in your storefront/client applications.
+See the [Managing Sessions guide](/storefront/connect-api/#managing-sessions) for how to manage authenticated sessions in your storefront/client applications.
 :::
 
 ## External authentication

docs/docs/guides/core-concepts/channels/index.mdx

@@ -47,7 +47,7 @@ Many entities are channel-aware, meaning that they can be associated with a mult
 
 Each channel is also assigned a single [`Seller`](/reference/typescript-api/entities/seller/). This entity is used to represent
 the vendor or seller of the products in the channel. This is useful for implementing a marketplace, where each channel represents
-a distinct vendor. The `Seller` entity can be extended with [custom fields](/guides/developer-guide/custom-fields/) to store additional information about the seller, such as a logo, contact details etc.
+a distinct vendor. The `Seller` entity can be extended with [custom fields](/developer-guide/custom-fields/) to store additional information about the seller, such as a logo, contact details etc.
 
 ## Channels, Currencies & Prices
 
@@ -122,7 +122,7 @@ In this case, you can create the entire inventory in the default Channel and the
 
 ### Multi-vendor marketplace
 
-This is the most advanced use of channels. For a detailed guide to this use-case, see our [Multi-vendor marketplace guide](/guides/how-to/multi-vendor-marketplaces/).
+This is the most advanced use of channels. For a detailed guide to this use-case, see our [Multi-vendor marketplace guide](/how-to/multi-vendor-marketplaces/).
 
 
 ## Specifying channel in the GraphQL API

docs/docs/guides/core-concepts/collections/index.mdx

@@ -53,7 +53,7 @@ in the child collection.
 ### Creating a collection filter
 
 You can create your own custom collection filters with the [`CollectionFilter`](/reference/typescript-api/configuration/collection-filter/) class. This class
-is a [configurable operation](/guides/developer-guide/strategies-configurable-operations/#configurable-operations) where the specific
+is a [configurable operation](/developer-guide/strategies-configurable-operations/#configurable-operations) where the specific
 filtering logic is implemented in the `apply()` method passed to its constructor.
 
 The `apply()` method receives an instance of the [TypeORM SelectQueryBuilder](https://typeorm.io/select-query-builder) which should have filtering logic

docs/docs/guides/core-concepts/customers/index.mdx

@@ -9,7 +9,7 @@ If a customer has registered an account, they will have an associated [`User`](/
 entity is used for authentication and authorization. **Guest checkouts** are also possible, in which case a customer will not have a user.
 
 :::info
-See the [Auth guide](/guides/core-concepts/auth/#customer-auth) for a detailed explanation of the relationship between
+See the [Auth guide](/core-concepts/auth/#customer-auth) for a detailed explanation of the relationship between
 customers and users.
 :::
 

docs/docs/guides/core-concepts/email/index.mdx

@@ -23,7 +23,7 @@ Here's an illustration of the flow of an email being sent:
 
 ![Email plugin flow](./email-plugin-flow.webp)
 
-All emails are triggered by a particular [Event](/guides/developer-guide/events/) - in this case when the state of an
+All emails are triggered by a particular [Event](/developer-guide/events/) - in this case when the state of an
 Order changes. The EmailPlugin ships with a set of [default email handlers](https://github.com/vendurehq/vendure/blob/master/packages/email-plugin/src/default-email-handlers.ts),
 one of which is responsible for sending "order confirmation" emails.
 

docs/docs/guides/core-concepts/images-assets/index.mdx

@@ -3,7 +3,7 @@ title: "Images & Assets"
 ---
 
 [`Assets`](/reference/typescript-api/entities/asset/) are used to store files such as images, videos, PDFs, etc. Assets can be
-assigned to **products**, **variants** and **collections** by default. By using [custom fields](/guides/developer-guide/custom-fields/) it is
+assigned to **products**, **variants** and **collections** by default. By using [custom fields](/developer-guide/custom-fields/) it is
 possible to assign assets to other entities. For example, for implementing customer profile images.
 
 The handling of assets in Vendure is implemented in a modular way, allowing you full control over the way assets

docs/docs/guides/core-concepts/money/index.mdx

@@ -89,7 +89,7 @@ export function MyComponent({ variant }: MyComponentProps) {
 ## Support for multiple currencies
 
 Vendure supports multiple currencies out-of-the-box. The available currencies must first be set at the Channel level
-(see the [Channels, Currencies & Prices section](/guides/core-concepts/channels/#channels-currencies--prices)), and then
+(see the [Channels, Currencies & Prices section](/core-concepts/channels/#channels-currencies--prices)), and then
 a price may be set on a `ProductVariant` in each of the available currencies.
 
 When using multiple currencies, the [ProductVariantPriceSelectionStrategy](/reference/typescript-api/configuration/product-variant-price-selection-strategy/)
@@ -123,13 +123,13 @@ type ShippingLine {
 }
 ```
 
-If you are defining custom GraphQL types, or adding fields to existing types (see the [Extending the GraphQL API doc](/guides/developer-guide/extend-graphql-api/)),
+If you are defining custom GraphQL types, or adding fields to existing types (see the [Extending the GraphQL API doc](/developer-guide/extend-graphql-api/)),
 then you should also use the `Money` scalar for any monetary values.
 
 
 ## The `@Money()` decorator
 
-When [defining new database entities](/guides/developer-guide/database-entity), if you need to store a monetary value, then rather than using the TypeORM `@Column()`
+When [defining new database entities](/developer-guide/database-entity), if you need to store a monetary value, then rather than using the TypeORM `@Column()`
 decorator, you should use Vendure's [`@Money()` decorator](/reference/typescript-api/money/money-decorator).
 
 Using this decorator allows Vendure to correctly store the value in the database according to the configured `MoneyStrategy` (see below).

docs/docs/guides/core-concepts/orders/index.mdx

@@ -142,7 +142,7 @@ Sometimes you might need to extend things beyond what is provided by the default
 
 ### Adding a new state
 
-Let's say your company can only sell to customers with a valid EU tax ID. We'll assume that you've already used a [custom field](/guides/developer-guide/custom-fields/) to store that code on the Customer entity.
+Let's say your company can only sell to customers with a valid EU tax ID. We'll assume that you've already used a [custom field](/developer-guide/custom-fields/) to store that code on the Customer entity.
 
 Now you want to add a step _before_ the customer handles payment, where we can collect and verify the tax ID.
 
@@ -248,7 +248,7 @@ const customerValidationProcess: OrderProcess<'ValidatingCustomer'> = {
 ```
 
 :::info
-For an explanation of the `init()` method and `injector` argument, see the guide on [injecting dependencies in configurable operations](/guides/developer-guide/strategies-configurable-operations/#injecting-dependencies).
+For an explanation of the `init()` method and `injector` argument, see the guide on [injecting dependencies in configurable operations](/developer-guide/strategies-configurable-operations/#injecting-dependencies).
 :::
 
 ### Responding to a state transition

docs/docs/guides/core-concepts/payment/index.mdx

@@ -133,7 +133,7 @@ export const config: VendureConfig = {
 ```
 
 :::info
-If your PaymentMethodHandler needs access to the database or other providers, see the [configurable operation dependency injection guide](/guides/developer-guide/strategies-configurable-operations/#injecting-dependencies).
+If your PaymentMethodHandler needs access to the database or other providers, see the [configurable operation dependency injection guide](/developer-guide/strategies-configurable-operations/#injecting-dependencies).
 :::
 
 ## The PaymentMethod entity
@@ -150,7 +150,7 @@ The payment method also has a **code**, which is a string identifier used to spe
 
 ### Eligible payment methods
 
-Once the active Order has been transitioned to the `ArrangingPayment` state (see the [Order guide](/guides/core-concepts/orders/)), we can query the available payment methods by executing the [`eligiblePaymentMethods` query](/reference/graphql-api/shop/queries#eligiblepaymentmethods).
+Once the active Order has been transitioned to the `ArrangingPayment` state (see the [Order guide](/core-concepts/orders/)), we can query the available payment methods by executing the [`eligiblePaymentMethods` query](/reference/graphql-api/shop/queries#eligiblepaymentmethods).
 
 <Tabs>
 <TabItem value="Request" label="Request" default>

docs/docs/guides/core-concepts/products/index.mdx

@@ -51,7 +51,7 @@ also use facets to add other metadata to products and variants such as "New", "S
 
 These are the typical uses of facets in Vendure:
 
-- As the **basis of [Collections](/guides/core-concepts/collections)**, in order to categorize your catalog.
+- As the **basis of [Collections](/core-concepts/collections)**, in order to categorize your catalog.
 - To **filter products** in the storefront, also known as "faceted search". For example, a customer is on the "hoodies" collection
 page and wants to filter to only show Nike hoodies.
 - For **internal logic**, such as a promotion that applies to all variants with the "Summer Sale" facet value, or a shipping calculation

docs/docs/guides/core-concepts/promotions/index.mdx

@@ -32,7 +32,7 @@ Vendure comes with some built-in actions, but you can also create your own actio
 ## Creating custom conditions
 
 To create a custom condition, you need to define a new [`PromotionCondition` object](/reference/typescript-api/promotions/promotion-condition/).
-A promotion condition is an example of a [configurable operation](/guides/developer-guide/strategies-configurable-operations/#configurable-operations).
+A promotion condition is an example of a [configurable operation](/developer-guide/strategies-configurable-operations/#configurable-operations).
 Here is an annotated example of one of the built-in PromotionConditions.
 
 ```ts
@@ -321,4 +321,4 @@ export const buyXGetYFreeCondition = new PromotionCondition({
 
 ## Injecting providers
 
-If your PromotionCondition or PromotionAction needs access to the database or other providers, they can be injected by defining an `init()` function in your PromotionAction or PromotionCondition. See the [configurable operation guide](/guides/developer-guide/strategies-configurable-operations/#injecting-dependencies) for details.
+If your PromotionCondition or PromotionAction needs access to the database or other providers, they can be injected by defining an `init()` function in your PromotionAction or PromotionCondition. See the [configurable operation guide](/developer-guide/strategies-configurable-operations/#injecting-dependencies) for details.

docs/docs/guides/core-concepts/shipping/index.mdx

@@ -178,7 +178,7 @@ export const config: VendureConfig = {
 ```
 
 :::info
-If your ShippingEligibilityChecker or ShippingCalculator needs access to the database or other providers, see the [configurable operation dependency injection guide](/guides/developer-guide/strategies-configurable-operations/#injecting-dependencies).
+If your ShippingEligibilityChecker or ShippingCalculator needs access to the database or other providers, see the [configurable operation dependency injection guide](/developer-guide/strategies-configurable-operations/#injecting-dependencies).
 :::
 
 ## Fulfillments
@@ -218,5 +218,5 @@ export const config: VendureConfig = {
 ```
 
 :::info
-For a more detailed look at how custom processes are used, see the [custom order processes guide](/guides/core-concepts/orders/#custom-order-processes).
+For a more detailed look at how custom processes are used, see the [custom order processes guide](/core-concepts/orders/#custom-order-processes).
 :::

docs/docs/guides/deployment/deploy-to-digital-ocean-app-platform/index.mdx

@@ -195,7 +195,7 @@ After saving your environment variables you can click through the confirmation s
 
 ## Create the worker resource
 
-Now we need to set up the [Vendure worker](/guides/developer-guide/worker-job-queue/) which will handle background tasks. From the dashboard of your newly-created
+Now we need to set up the [Vendure worker](/developer-guide/worker-job-queue/) which will handle background tasks. From the dashboard of your newly-created
 app, click the "Create" button and then select "Create Resources From Source Code".
 
 You will be prompted to select the repo again, and then you'll need to set up a new single resource with the following 

docs/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.

docs/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)
   

docs/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)
   

docs/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
 

docs/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/).

docs/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
 

docs/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.

docs/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
 

docs/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

docs/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

docs/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
 

docs/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/).
 
 :::
 

docs/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

docs/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.
 

docs/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).

docs/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

docs/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';

docs/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 {

docs/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.

docs/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.

docs/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.

docs/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.

docs/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

docs/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) 
 

docs/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/).

docs/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)
 :::

docs/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.

docs/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/):
 

docs/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
 

docs/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

docs/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/).

docs/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';

docs/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
 

docs/docs/guides/developer-guide/updating/index.mdx

@@ -60,7 +60,7 @@ For any database schema changes, it is advised to:
 
 1. Read the changelog breaking changes entries to see what changes to expect
 2. **Important:** Make a backup of your database!
-3. Create a new database migration as described in the [Migrations guide](/guides/developer-guide/migrations/)
+3. Create a new database migration as described in the [Migrations guide](/developer-guide/migrations/)
 4. Manually check the migration script. In some cases manual action is needed to customize the script in order to correctly migrate your existing data.
 5. Test the migration script against non-production data.
 6. Only when you have verified that the migration works as expected, run it against your production database.

docs/docs/guides/developer-guide/uploading-files/index.mdx

@@ -3,7 +3,7 @@ title: "Uploading Files"
 showtoc: true
 ---
 
-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](/guides/core-concepts/images-assets/). 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](/core-concepts/images-assets/). Assets are typically used for images, but can represent any kind of binary data such as PDF files or videos.
 
 ## Upload clients
 
@@ -55,11 +55,11 @@ function UploadFile() {
 
 ## Custom upload mutations
 
-How about if you want to implement a custom mutation for file uploads? Let's take an example where we want to allow customers to set an avatar image. To do this, we'll add a [custom field](/guides/developer-guide/custom-fields/) to the Customer entity and then define a new mutation in the Shop API.
+How about if you want to implement a custom mutation for file uploads? Let's take an example where we want to allow customers to set an avatar image. To do this, we'll add a [custom field](/developer-guide/custom-fields/) to the Customer entity and then define a new mutation in the Shop API.
 
 ### Configuration
 
-Let's define a custom field to associate the avatar `Asset` with the `Customer` entity. To keep everything encapsulated, we'll do all of this in a [plugin](/guides/developer-guide/plugins/)
+Let's define a custom field to associate the avatar `Asset` with the `Customer` entity. To keep everything encapsulated, we'll do all of this in a [plugin](/developer-guide/plugins/)
 
 ```ts title="src/plugins/customer-avatar/customer-avatar.plugin.ts"
 import { Asset, LanguageCode, PluginCommonModule, VendurePlugin } from '@vendure/core';

docs/docs/guides/extending-the-admin-ui/creating-detail-views/index.mdx

@@ -13,14 +13,14 @@ in that case you won't be able to use the built-in Angular-specific components.
 
 ## Example: Creating a Product Detail View
 
-Let's say you have a plugin which adds a new entity to the database called `ProductReview`. You have already created a [list view](/guides/extending-the-admin-ui/creating-list-views/), and
+Let's say you have a plugin which adds a new entity to the database called `ProductReview`. You have already created a [list view](/extending-the-admin-ui/creating-list-views/), and
 now you need a detail view which can be used to view and edit individual reviews.
 
 ### Extend the TypedBaseDetailComponent class
 
 The detail component itself is an Angular component which extends the [BaseDetailComponent](/reference/admin-ui-api/list-detail-views/base-detail-component/) or [TypedBaseDetailComponent](/reference/admin-ui-api/list-detail-views/typed-base-detail-component) class.
 
-This example assumes you have set up your project to use code generation as described in the [GraphQL code generation guide](/guides/how-to/codegen/#codegen-for-admin-ui-extensions).
+This example assumes you have set up your project to use code generation as described in the [GraphQL code generation guide](/how-to/codegen/#codegen-for-admin-ui-extensions).
 
 ```ts title="src/plugins/reviews/ui/components/review-detail/review-detail.component.ts"
 import { ResultOf } from '@graphql-typed-document-node/core';
@@ -236,7 +236,7 @@ export default [
 
 ## Supporting custom fields
 
-From Vendure v2.2, it is possible for your [custom entities to support custom fields](/guides/developer-guide/database-entity/#supporting-custom-fields).
+From Vendure v2.2, it is possible for your [custom entities to support custom fields](/developer-guide/database-entity/#supporting-custom-fields).
 
 If you have set up your entity to support custom fields, and you want custom fields to be available in the Admin UI detail view,
 you need to add the following to your detail component:

docs/docs/guides/extending-the-admin-ui/creating-list-views/index.mdx

@@ -39,14 +39,14 @@ type ProductReviewList implements PaginatedList {
 ```
 
 :::info
-See the [Paginated Lists guide](/guides/how-to/paginated-list/) for details on how to implement this in your server plugin code.
+See the [Paginated Lists guide](/how-to/paginated-list/) for details on how to implement this in your server plugin code.
 :::
 
 ### Create the list component
 
 The list component itself is an Angular component which extends the [BaseListComponent](/reference/admin-ui-api/list-detail-views/base-list-component/) or [TypedBaseListComponent](/reference/admin-ui-api/list-detail-views/typed-base-list-component) class.
 
-This example assumes you have set up your project to use code generation as described in the [GraphQL code generation guide](/guides/how-to/codegen/#codegen-for-admin-ui-extensions).
+This example assumes you have set up your project to use code generation as described in the [GraphQL code generation guide](/how-to/codegen/#codegen-for-admin-ui-extensions).
 
 ```ts title="src/plugins/reviews/ui/components/review-list/review-list.component.ts"
 import { ChangeDetectionStrategy, Component } from '@angular/core';
@@ -247,7 +247,7 @@ export default [
 
 ## Supporting custom fields
 
-From Vendure v2.2, it is possible for your [custom entities to support custom fields](/guides/developer-guide/database-entity/#supporting-custom-fields).
+From Vendure v2.2, it is possible for your [custom entities to support custom fields](/developer-guide/database-entity/#supporting-custom-fields).
 
 If you have set up your entity to support custom fields, and you want custom fields to be available in the Admin UI list view,
 you need to add the following to your list component:

docs/docs/guides/extending-the-admin-ui/custom-data-table-components/index.mdx

@@ -3,7 +3,7 @@ title: 'Custom DataTable Components'
 weight: 6
 ---
 
-The Admin UI list views are powered by a data table component which features sorting, advanced filtering, pagination and more. It will also give you the option of displaying any configured [custom fields](/guides/developer-guide/custom-fields/) for the entity in question.
+The Admin UI list views are powered by a data table component which features sorting, advanced filtering, pagination and more. It will also give you the option of displaying any configured [custom fields](/developer-guide/custom-fields/) for the entity in question.
 
 With Admin UI extensions, you can specify custom components to use in rendering any column of any data table - both custom fields _and_ built-in fields, using either Angular or React components.
 

docs/docs/guides/extending-the-admin-ui/custom-form-inputs/index.mdx

@@ -2,7 +2,7 @@
 title: 'Custom Form Inputs'
 ---
 
-You can define custom Angular or React components which can be used to render [Custom Fields](/guides/developer-guide/custom-fields/) you have defined on your entities as well as [configurable args](/reference/typescript-api/configurable-operation-def/config-args/) used by custom [Configurable Operations](/guides/developer-guide/strategies-configurable-operations/#configurable-operations).
+You can define custom Angular or React components which can be used to render [Custom Fields](/developer-guide/custom-fields/) you have defined on your entities as well as [configurable args](/reference/typescript-api/configurable-operation-def/config-args/) used by custom [Configurable Operations](/developer-guide/strategies-configurable-operations/#configurable-operations).
 
 ## For Custom Fields
 
@@ -128,7 +128,7 @@ export default [
 
 ### 3. Register the providers
 
-The `providers.ts` is then passed to the `compileUiExtensions()` function as described in the [UI Extensions Getting Started guide](/guides/extending-the-admin-ui/getting-started/):
+The `providers.ts` is then passed to the `compileUiExtensions()` function as described in the [UI Extensions Getting Started guide](/extending-the-admin-ui/getting-started/):
 
 ```ts title="src/vendure-config.ts"
 import * as path from 'path';
@@ -253,7 +253,7 @@ export class RelationReviewInputComponent implements OnInit, FormInputComponent<
 
 ## For ConfigArgs
 
-[ConfigArgs](/reference/typescript-api/configurable-operation-def/config-args/) are used by classes which extend [Configurable Operations](/guides/developer-guide/strategies-configurable-operations/#configurable-operations) (such as ShippingCalculator or PaymentMethodHandler). These ConfigArgs allow user-input values to be passed to the operation's business logic.
+[ConfigArgs](/reference/typescript-api/configurable-operation-def/config-args/) are used by classes which extend [Configurable Operations](/developer-guide/strategies-configurable-operations/#configurable-operations) (such as ShippingCalculator or PaymentMethodHandler). These ConfigArgs allow user-input values to be passed to the operation's business logic.
 
 They are configured in a very similar way to custom fields, and likewise can use custom form inputs by specifying the `ui` property. 
 

docs/docs/guides/extending-the-admin-ui/custom-timeline-components/index.mdx

@@ -75,5 +75,5 @@ export default [
 ];
 ```
 
-Then we need to add the `providers.ts` file to the `uiExtensions` array as described in the [UI Extensions Getting Started guide](/guides/extending-the-admin-ui/getting-started/).
+Then we need to add the `providers.ts` file to the `uiExtensions` array as described in the [UI Extensions Getting Started guide](/extending-the-admin-ui/getting-started/).
 

docs/docs/guides/extending-the-admin-ui/dashboard-widgets/index.mdx

@@ -74,7 +74,7 @@ We also need to define an `NgModule` for this component. This is because we will
 
 ### Register the widget
 
-Our widget now needs to be registered in our [providers file](/guides/extending-the-admin-ui/getting-started/#providers):
+Our widget now needs to be registered in our [providers file](/extending-the-admin-ui/getting-started/#providers):
 
 ```ts title="src/plugins/reviews/ui/providers.ts"
 import { registerDashboardWidget } from '@vendure/admin-ui/core';

docs/docs/guides/extending-the-admin-ui/defining-routes/index.mdx

@@ -6,7 +6,7 @@ Routes allow you to mount entirely custom components at a given URL in the Admin
 
 ![Route area](./route-area.webp)
 
-Routes can be defined natively using either **Angular** or **React**. It is also possible to [use other frameworks](/guides/extending-the-admin-ui/using-other-frameworks/) in a more limited capacity.
+Routes can be defined natively using either **Angular** or **React**. It is also possible to [use other frameworks](/extending-the-admin-ui/using-other-frameworks/) in a more limited capacity.
 
 ## Example: Creating a "Greeter" route
 
@@ -565,7 +565,7 @@ export default [
 ];
 ```
 
-A more powerful way to set the breadcrumbs is by using the `getBreadcrumbs` property. This is a function that receives any resolved detail data and returns an array of link/label pairs. An example of its use can be seen in the [Creating detail views guide](/guides/extending-the-admin-ui/creating-detail-views/#route-config).
+A more powerful way to set the breadcrumbs is by using the `getBreadcrumbs` property. This is a function that receives any resolved detail data and returns an array of link/label pairs. An example of its use can be seen in the [Creating detail views guide](/extending-the-admin-ui/creating-detail-views/#route-config).
 
 ### Dynamically from the component
 

docs/docs/guides/extending-the-admin-ui/getting-started/index.mdx

@@ -3,10 +3,10 @@ title: 'Getting Started'
 ---
 
 :::warning Angular Admin UI Deprecation
-The Angular-based Admin UI has been replaced by the new [React Admin Dashboard](/guides/extending-the-dashboard/getting-started/). The Angular Admin UI will not be maintained after **July 2026**. 
+The Angular-based Admin UI has been replaced by the new [React Admin Dashboard](/extending-the-dashboard/getting-started/). The Angular Admin UI will not be maintained after **July 2026**. 
 Until then, we will continue patching critical bugs and security issues. Community contributions will always be merged and released.
 
-**For new projects, use the [React Admin Dashboard](/guides/extending-the-dashboard/getting-started/) instead.**
+**For new projects, use the [React Admin Dashboard](/extending-the-dashboard/getting-started/) instead.**
 
 If you want to use the Admin UI and the Dashboard together, both plugins can now be used simultaneously without any special configuration.
 :::
@@ -282,7 +282,7 @@ Routes allow you to define completely custom views in the Admin UI.
 
 Your `routes.ts` file exports an array of objects which define new routes in the Admin UI. For example, imagine you have created a plugin which implements a simple content management system. You can define a route for the list of articles, and another for the detail view of an article.
 
-For a detailed instructions, see the [Defining Routes guide](/guides/extending-the-admin-ui/defining-routes/).
+For a detailed instructions, see the [Defining Routes guide](/extending-the-admin-ui/defining-routes/).
 
 ## Dev vs Prod mode
 
@@ -410,7 +410,7 @@ yarn add copyfiles
 
 ## Using other frameworks
 
-While the Admin UI natively supports extensions written with Angular or React, it is still possible to create extensions using other front-end frameworks such as Vue or Solid. Note that creating extensions in this way is much more limited, with only the ability to define new routes, and limited access to internal services such as data fetching and notifications. See [UI extensions in other frameworks](/guides/extending-the-admin-ui/using-other-frameworks/).
+While the Admin UI natively supports extensions written with Angular or React, it is still possible to create extensions using other front-end frameworks such as Vue or Solid. Note that creating extensions in this way is much more limited, with only the ability to define new routes, and limited access to internal services such as data fetching and notifications. See [UI extensions in other frameworks](/extending-the-admin-ui/using-other-frameworks/).
 
 ## IDE Support
 
@@ -461,7 +461,7 @@ Angular uses the concept of modules ([NgModules](https://angular.io/guide/ngmodu
 
 When creating your UI extensions, you can set your module to be either `lazy` or `shared`. Shared modules are loaded _eagerly_, i.e. their code is bundled up with the main app and loaded as soon as the app loads.
 
-As a rule, modules defining new routes should be lazily loaded (so that the code is only loaded once that route is activated), and modules defining [new navigations items](/guides/extending-the-admin-ui/nav-menu/) and [custom form input](/guides/extending-the-admin-ui/custom-form-inputs/) should be set to `shared`.
+As a rule, modules defining new routes should be lazily loaded (so that the code is only loaded once that route is activated), and modules defining [new navigations items](/extending-the-admin-ui/nav-menu/) and [custom form input](/extending-the-admin-ui/custom-form-inputs/) should be set to `shared`.
 
 :::info
 "lazy" modules are equivalent to the new "routes" API, and "shared" modules are equivalent to the new "providers" API. In fact, behind the scenes,

docs/docs/guides/extending-the-admin-ui/nav-menu/index.mdx

@@ -10,7 +10,7 @@ access to routes in the app, and can be extended and modified by UI extensions.
 
 Once you have defined some custom routes, you need some way for the administrator to access them. For this you will use the [addNavMenuItem](/reference/admin-ui-api/nav-menu/add-nav-menu-item/) and [addNavMenuSection](/reference/admin-ui-api/nav-menu/add-nav-menu-section) functions.
 
-Let's add a new section to the Admin UI main nav bar containing a link to the "greeter" module from the [Getting Started guide](/guides/extending-the-admin-ui/getting-started/#routes) example:
+Let's add a new section to the Admin UI main nav bar containing a link to the "greeter" module from the [Getting Started guide](/extending-the-admin-ui/getting-started/#routes) example:
 
 ```ts title="src/plugins/greeter/ui/providers.ts"
 import { addNavMenuSection } from '@vendure/admin-ui/core';

docs/docs/guides/extending-the-admin-ui/using-other-frameworks/index.mdx

@@ -202,4 +202,4 @@ If your extension does not have a build step, you can still include the UiDevkit
 
 ## Next Steps
 
-Now you have created your extension, you need a way for your admin to access it. See [Adding Navigation Items](/guides/extending-the-admin-ui/nav-menu/)
+Now you have created your extension, you need a way for your admin to access it. See [Adding Navigation Items](/extending-the-admin-ui/nav-menu/)

docs/docs/guides/extending-the-dashboard/creating-pages/detail-pages.mdx

@@ -5,7 +5,7 @@ title: 'Creating Detail Pages'
 ## Setup
 
 :::info
-This guide assumes you have a `CmsPlugin` with an `Article` entity, as covered in the [Extending the Dashboard: Plugin Setup](/guides/extending-the-dashboard/extending-overview/#plugin-setup) guide.
+This guide assumes you have a `CmsPlugin` with an `Article` entity, as covered in the [Extending the Dashboard: Plugin Setup](/extending-the-dashboard/extending-overview/#plugin-setup) guide.
 :::
 
 Detail pages can be created for any entity which has been exposed via the Admin API. Following the

docs/docs/guides/extending-the-dashboard/creating-pages/index.mdx

@@ -34,7 +34,7 @@ export function TestPage() {
 Following this structure ensures that:
 - Your pages look consistent with the rest of the Dashboard
 - Your page content is responsive
-- Your page can be further extended using the [pageBlocks API](/guides/extending-the-dashboard/customizing-pages/page-blocks)
+- Your page can be further extended using the [pageBlocks API](/extending-the-dashboard/customizing-pages/page-blocks)
 
 :::info
 Note that the [ListPage](/reference/dashboard/list-views/list-page) and [DetailPage](/reference/dashboard/detail-views/detail-page)
@@ -80,7 +80,7 @@ defineDashboardExtension({
 ```
 
 :::info
-For a complete guide to the navigation options available, see the [Navigation guide](/guides/extending-the-dashboard/navigation/)
+For a complete guide to the navigation options available, see the [Navigation guide](/extending-the-dashboard/navigation/)
 :::
 
 

docs/docs/guides/extending-the-dashboard/creating-pages/list-pages.mdx

@@ -5,10 +5,10 @@ title: 'Creating List Pages'
 ## Setup
 
 :::info
-This guide assumes you have a `CmsPlugin` with an `Article` entity, as covered in the [Extending the Dashboard: Plugin Setup](/guides/extending-the-dashboard/extending-overview/#plugin-setup) guide.
+This guide assumes you have a `CmsPlugin` with an `Article` entity, as covered in the [Extending the Dashboard: Plugin Setup](/extending-the-dashboard/extending-overview/#plugin-setup) guide.
 :::
 
-List pages can be easily created for any query in the Admin API that follows the [PaginatedList pattern](/guides/how-to/paginated-list/).
+List pages can be easily created for any query in the Admin API that follows the [PaginatedList pattern](/how-to/paginated-list/).
 
 For example, the `articles` query of our `CmsPlugin` looks like this:
 

docs/docs/guides/extending-the-dashboard/creating-pages/tabbed-pages.mdx

@@ -5,7 +5,7 @@ title: 'Creating Tabbed Pages'
 ## Setup
 
 :::info
-This guide assumes you have a basic understanding of creating custom pages in the Vendure Dashboard, as covered in the [Creating List Pages](/guides/extending-the-dashboard/creating-pages/list-pages) and [Creating Detail Pages](/guides/extending-the-dashboard/creating-pages/detail-pages) guides.
+This guide assumes you have a basic understanding of creating custom pages in the Vendure Dashboard, as covered in the [Creating List Pages](/extending-the-dashboard/creating-pages/list-pages) and [Creating Detail Pages](/extending-the-dashboard/creating-pages/detail-pages) guides.
 :::
 
 Tabbed pages allow you to organize related content into separate tabs within a single page. This is useful

docs/docs/guides/extending-the-dashboard/custom-form-components/index.mdx

@@ -84,7 +84,7 @@ Here's how this component will look when rendered in your form:
 
 ## Custom Field Components
 
-Let's configure a [custom field](/guides/developer-guide/custom-fields/) which uses the `ColorPickerComponent` as its form component.
+Let's configure a [custom field](/developer-guide/custom-fields/) which uses the `ColorPickerComponent` as its form component.
 
 First we need to register the component with the `defineDashboardExtension` function:
 
@@ -138,7 +138,7 @@ export class MyPlugin {}
 
 ## Configurable Operation Components
 
-The `ColorPickerComponent` can also be used as a [configurable operation argument](/guides/developer-guide/strategies-configurable-operations/#configurable-operations) component. For example, we can add a color code
+The `ColorPickerComponent` can also be used as a [configurable operation argument](/developer-guide/strategies-configurable-operations/#configurable-operations) component. For example, we can add a color code
 to a shipping calculator:
 
 ```tsx title="src/plugins/my-plugin/config/custom-shipping-calculator.ts"

docs/docs/guides/extending-the-dashboard/customizing-pages/action-bar-items.mdx

@@ -266,7 +266,7 @@ The dashboard provides several button variants you can use:
 
 To find the `pageId` for your action bar items:
 
-1. Enable [Dev Mode](/guides/extending-the-dashboard/extending-overview/#dev-mode) in the dashboard
+1. Enable [Dev Mode](/extending-the-dashboard/extending-overview/#dev-mode) in the dashboard
 2. Navigate to the page where you want to add your action
 3. The page ID will be shown in the dev mode overlay
 4. Use this ID in your action bar item configuration

docs/docs/guides/extending-the-dashboard/customizing-pages/customizing-detail-pages.mdx

@@ -32,12 +32,12 @@ defineDashboardExtension({
 });
 ```
 
-To learn how to build custom form components, see the [Custom Form Elements guide](/guides/extending-the-dashboard/custom-form-components/).
+To learn how to build custom form components, see the [Custom Form Elements guide](/extending-the-dashboard/custom-form-components/).
 
 ## Extending the detail query
 
 You might want to extend the GraphQL query used to fetch the data for the detail page. For example, to include new
-fields that your plugin has defined so that you can render them in [custom page blocks](/guides/extending-the-dashboard/customizing-pages/page-blocks).
+fields that your plugin has defined so that you can render them in [custom page blocks](/extending-the-dashboard/customizing-pages/page-blocks).
 
 ```tsx title="index.tsx"
 import { defineDashboardExtension } from '@vendure/dashboard';

docs/docs/guides/extending-the-dashboard/customizing-pages/customizing-login-page.mdx

@@ -44,7 +44,7 @@ This will result in a login page like this:
 ## Fully custom login pages
 
 If you need even more control over the login page, you can also create an
-[unauthenticated route](/guides/extending-the-dashboard/navigation/#unauthenticated-routes) with a completely
+[unauthenticated route](/extending-the-dashboard/navigation/#unauthenticated-routes) with a completely
 custom layout.
 
 ```tsx title="index.tsx"

docs/docs/guides/extending-the-dashboard/customizing-pages/index.mdx

@@ -4,7 +4,7 @@ title: 'Customizing Pages'
 
 Existing pages in the Dashboard can be customized in many ways:
 
-- [Action bar buttons](/guides/extending-the-dashboard/customizing-pages/action-bar-items) can be added to the top of the page
-- [Page blocks](/guides/extending-the-dashboard/customizing-pages/page-blocks) can be added at any position, and existing page blocks can be replaced or removed.
-- [Extend list pages](/guides/extending-the-dashboard/customizing-pages/customizing-list-pages) with custom components, data and bulk actions
-- [Extend detail pages](/guides/extending-the-dashboard/customizing-pages/customizing-detail-pages) with custom components and data
+- [Action bar buttons](/extending-the-dashboard/customizing-pages/action-bar-items) can be added to the top of the page
+- [Page blocks](/extending-the-dashboard/customizing-pages/page-blocks) can be added at any position, and existing page blocks can be replaced or removed.
+- [Extend list pages](/extending-the-dashboard/customizing-pages/customizing-list-pages) with custom components, data and bulk actions
+- [Extend detail pages](/extending-the-dashboard/customizing-pages/customizing-detail-pages) with custom components and data

docs/docs/guides/extending-the-dashboard/customizing-pages/page-blocks.mdx

@@ -3,7 +3,7 @@ title: 'Page Blocks'
 ---
 
 In the Dashboard, all pages are built from blocks. Every block has a `pageId` and a `blockId` which uniquely locates it in the
-app (see [Dev Mode](/guides/extending-the-dashboard/extending-overview/#dev-mode) section).
+app (see [Dev Mode](/extending-the-dashboard/extending-overview/#dev-mode) section).
 
 You can also define your own blocks, which can be added to any page and can even replace the default blocks.
 
@@ -229,7 +229,7 @@ defineDashboardExtension({
 
 To find the `pageId` and `blockId` values for positioning your blocks:
 
-1. Enable [Dev Mode](/guides/extending-the-dashboard/extending-overview/#dev-mode) in the dashboard
+1. Enable [Dev Mode](/extending-the-dashboard/extending-overview/#dev-mode) in the dashboard
 2. Navigate to the page where you want to add your block
 3. Hover over existing blocks to see their IDs
 4. Use these IDs in your block positioning configuration

docs/docs/guides/extending-the-dashboard/data-fetching/index.mdx

@@ -119,7 +119,7 @@ to a file - by default you can find it at `src/gql/graphql-env.d.ts`.
 When you then use the `import { graphql } from '@/gql'` function to define your queries and mutations, you get automatic
 type safety when using the results in your components!
 
-When you have the `@/gql` path mapping correctly [set up as per the getting started guide](/guides/extending-the-dashboard/getting-started/#installation--setup), you should see that
+When you have the `@/gql` path mapping correctly [set up as per the getting started guide](/extending-the-dashboard/getting-started/#installation--setup), you should see that
 your IDE is able to infer the TypeScript type of your queries and mutations, including the correct inputs and return
 types!
 

docs/docs/guides/extending-the-dashboard/extending-overview/index.mdx

@@ -220,6 +220,6 @@ In Dev Mode, hovering any block in the dashboard will allow you to find the corr
 
 Now that you understand the fundamentals of extending the dashboard, explore these specific guides:
 
-- [Creating Pages](/guides/extending-the-dashboard/creating-pages/) 
-- [Customizing Pages](/guides/extending-the-dashboard/customizing-pages/) 
-- [Navigation](/guides/extending-the-dashboard/navigation/) 
+- [Creating Pages](/extending-the-dashboard/creating-pages/) 
+- [Customizing Pages](/extending-the-dashboard/customizing-pages/) 
+- [Navigation](/extending-the-dashboard/navigation/) 

docs/docs/guides/extending-the-dashboard/migration/index.mdx

@@ -16,7 +16,7 @@ Community contributions will always be merged and released.
 A recommended approach to migrating is to run both the Admin UI _and_ the new Dashboard in parallel. This allows you to start building
 new features right away with the new Dashboard while maintaining access to existing features that have not yet been migrated.
 
-To do so, follow the instructions to [set up the Dashboard](/guides/extending-the-dashboard/getting-started/#installation--setup).
+To do so, follow the instructions to [set up the Dashboard](/extending-the-dashboard/getting-started/#installation--setup).
 Both plugins can now be used simultaneously without any special configuration.
 
 ## AI-Assisted Migration
@@ -1589,14 +1589,14 @@ It is very likely you'll still need to do _some_ manual cleanup after an AI-assi
 things like:
 
 - Non-optimum styling choices
-- Issues with the [tsconfig setup](/guides/extending-the-dashboard/getting-started/#installation--setup) not being perfectly implemented.
+- Issues with the [tsconfig setup](/extending-the-dashboard/getting-started/#installation--setup) not being perfectly implemented.
 - For more complex repo structures like a monorepo with plugins as separate libs, you may need to manually implement
   the initial setup of the config files.
 
 ## Manual Migration
 
-If you would rather do a full manual migration, you should first follow the [Dashboard Getting Started guide](/guides/extending-the-dashboard/getting-started/)
-and the [Extending the Dashboard guide](http://localhost:3001/guides/extending-the-dashboard/extending-overview/).
+If you would rather do a full manual migration, you should first follow the [Dashboard Getting Started guide](/extending-the-dashboard/getting-started/)
+and the [Extending the Dashboard guide](http://localhost:3001/extending-the-dashboard/extending-overview/).
 
 The remainder of this document details specific features, and how they are now implemented in the new Dashboard.
 

docs/docs/guides/extending-the-dashboard/navigation/index.mdx

@@ -43,7 +43,7 @@ The dashboard comes with several built-in sections:
 
 ### Finding Section IDs & Ordering
 
-You can find the available IDs & their order value for all navigation sections and items using [Dev mode](/guides/extending-the-dashboard/extending-overview/#dev-mode):
+You can find the available IDs & their order value for all navigation sections and items using [Dev mode](/extending-the-dashboard/extending-overview/#dev-mode):
 
 ![Dev mode navigation ids](./dev-mode-nav.webp)
 

docs/docs/guides/getting-started/graphql-intro/index.mdx

@@ -50,8 +50,8 @@ Both GraphQL and REST are valid approaches to building an API. These are some of
 - **Many resources in a single request**: Very often, a single page in a web app will need to fetch data from multiple resources. For example, a product detail page might need to fetch the product, the product's variants, the product's collections, the product's reviews, and the product's images. With REST, this would require multiple requests. With GraphQL, you can fetch all of this data in a single request.
 - **Static typing**: GraphQL APIs are always defined by a statically typed schema. This means that you can be sure that the data you receive from the API will always be in the format you expect.
 - **Developer tooling**: The schema definition allows for powerful developer tooling. For example, the GraphQL Playground above with auto-complete and full documentation is generated automatically from the schema definition. You can also get auto-complete and type-checking directly in your IDE.
-- **Code generation**: TypeScript types can be generated automatically from the schema definition. This means that you can be sure that your frontend code is always in sync with the API. This end-to-end type safety is extremely valuable, especially when working on large projects or with teams. See the [GraphQL Code Generation guide](/guides/storefront/codegen/)
-- **Extensible**: Vendure is designed with extensibility in mind, and GraphQL is a perfect fit. You can extend the GraphQL API with your own custom queries, mutations, and types. You can also extend the built-in types with your own custom fields, or supply you own custom logic to resolve existing fields. See the [Extend the GraphQL API guide](/guides/developer-guide/extend-graphql-api/)
+- **Code generation**: TypeScript types can be generated automatically from the schema definition. This means that you can be sure that your frontend code is always in sync with the API. This end-to-end type safety is extremely valuable, especially when working on large projects or with teams. See the [GraphQL Code Generation guide](/storefront/codegen/)
+- **Extensible**: Vendure is designed with extensibility in mind, and GraphQL is a perfect fit. You can extend the GraphQL API with your own custom queries, mutations, and types. You can also extend the built-in types with your own custom fields, or supply you own custom logic to resolve existing fields. See the [Extend the GraphQL API guide](/developer-guide/extend-graphql-api/)
 
 ## GraphQL Terminology
 
@@ -398,7 +398,7 @@ type EmailAddressInUseError {
 ```
 
 :::info
-In Vendure, we use this pattern for almost all mutations. You can read more about it in the [Error Handling guide](/guides/developer-guide/error-handling/).
+In Vendure, we use this pattern for almost all mutations. You can read more about it in the [Error Handling guide](/developer-guide/error-handling/).
 :::
 
 Now, when we perform this mutation, we need alter the way we select the fields in the response, since the response could be one of two types:
@@ -484,7 +484,7 @@ A resolver is a function which is responsible for fetching the data for a partic
 would be resolved by a function which fetches the list of customers from the database.
 
 To get started with Vendure's APIs, you don't need to know much about resolvers beyond this basic understanding. However,
-later on you may want to write your own custom resolvers to extend the API. This is covered in the [Extending the GraphQL API guide](/guides/developer-guide/extend-graphql-api/).
+later on you may want to write your own custom resolvers to extend the API. This is covered in the [Extending the GraphQL API guide](/developer-guide/extend-graphql-api/).
 
 ## Querying data
 
@@ -555,7 +555,7 @@ can use to provide autocomplete.
 
 Code generation means the automatic generation of TypeScript types based on your GraphQL schema and your GraphQL operations. This is a very powerful feature that allows you to write your code in a type-safe manner, without you needing to manually write any types for your API calls.
 
-For more information see the [GraphQL Code Generation guide](/guides/storefront/codegen).
+For more information see the [GraphQL Code Generation guide](/storefront/codegen).
 
 ## Further reading
 

docs/docs/guides/getting-started/installation/index.mdx

@@ -76,7 +76,7 @@ If you'd rather have more control over the configuration, you can choose the "Ma
 
 Vendure supports a number of different databases. The `@vendure/create` tool will prompt you to select one.
 
-**To quickly test out Vendure, we recommend using SQLite**, which requires no external dependencies. You can always switch to a different database later [by changing your configuration file](/guides/developer-guide/configuration/#connecting-to-the-database).
+**To quickly test out Vendure, we recommend using SQLite**, which requires no external dependencies. You can always switch to a different database later [by changing your configuration file](/developer-guide/configuration/#connecting-to-the-database).
 
 ```text
 ┌  Let's create a Vendure App ✨
@@ -104,7 +104,7 @@ If you select MySQL, MariaDB, or Postgres, you need to make sure you:
 
 3. **Have database credentials**: You need the username and password for a database user that has full permissions (CREATE, ALTER, DROP, INSERT, UPDATE, DELETE, SELECT) on the database you created.
 
-For detailed database configuration examples, see the [Configuration guide](/guides/developer-guide/configuration/#connecting-to-the-database).
+For detailed database configuration examples, see the [Configuration guide](/developer-guide/configuration/#connecting-to-the-database).
 
 :::
 
@@ -112,7 +112,7 @@ For detailed database configuration examples, see the [Configuration guide](/gui
 
 The final prompt will ask whether to populate your new Vendure server with some sample product data.
 
-**We recommend you do so**, as it will give you a good starting point for exploring the APIs, which we will cover in the [Try the API section](/guides/getting-started/try-the-api/), as well as providing some data to use when building your own storefront.
+**We recommend you do so**, as it will give you a good starting point for exploring the APIs, which we will cover in the [Try the API section](/getting-started/try-the-api/), as well as providing some data to use when building your own storefront.
 
 ```text
 ┌  Let's create a Vendure App ✨
@@ -203,9 +203,9 @@ If you included the Next.js Storefront Starter, you can also access:
 
 Congratulations! 🥳 You now have a fully functional Vendure server running locally.
 
-Now you can explore Vendure by following our [Try the API guide](/guides/getting-started/try-the-api/) to learn how to interact with the server.
+Now you can explore Vendure by following our [Try the API guide](/getting-started/try-the-api/) to learn how to interact with the server.
 
-If you are new to GraphQL, you should also check out our [Introducing GraphQL guide](/guides/getting-started/graphql-intro/).
+If you are new to GraphQL, you should also check out our [Introducing GraphQL guide](/getting-started/graphql-intro/).
 
 :::tip
 Open the Dashboard at [http://localhost:3000/dashboard](http://localhost:3000/dashboard) in your browser and log in with the superadmin credentials you specified, which default to:

docs/docs/guides/getting-started/try-the-api/index.mdx

@@ -2,7 +2,7 @@
 title: 'Try the API'
 ---
 
-Once you have successfully installed Vendure locally following the [installation guide](/guides/getting-started/installation),
+Once you have successfully installed Vendure locally following the [installation guide](/getting-started/installation),
 it's time to try out the API!
 
 :::note
@@ -162,7 +162,7 @@ if the response is an `ErrorResult`, we want to include the `errorCode` and `mes
 Running this mutation a second time should show that the quantity of the product in the order has increased by 1.
 
 :::info
-For more information about `ErrorResult` and the handling of errors in Vendure, see the [Error Handling guide](/guides/developer-guide/error-handling).
+For more information about `ErrorResult` and the handling of errors in Vendure, see the [Error Handling guide](/developer-guide/error-handling).
 :::
 
 ## Admin API

docs/docs/guides/how-to/cms-integration-plugin/index.mdx

@@ -6,9 +6,9 @@ A CMS integration plugin allows you to automatically synchronize your Vendure pr
 
 This is done in a way that establishes Vendure as the source of truth for the ecommerce's data.
 
-This guide demonstrates how to build a production-ready CMS integration plugin. The principles covered here are designed to be CMS-agnostic, however we do have [working examples](/guides/how-to/cms-integration-plugin/#platform-specific-setup) for various platforms.
+This guide demonstrates how to build a production-ready CMS integration plugin. The principles covered here are designed to be CMS-agnostic, however we do have [working examples](/how-to/cms-integration-plugin/#platform-specific-setup) for various platforms.
 
-Platfroms covered in the [guide](/guides/how-to/cms-integration-plugin/#platform-specific-setup):
+Platfroms covered in the [guide](/how-to/cms-integration-plugin/#platform-specific-setup):
 
 - [Payload](https://payloadcms.com/)
 - [Sanity](https://www.sanity.io/)
@@ -27,16 +27,16 @@ The code examples in this guide are simplified for educational purposes. The act
 ## Prerequisites
 
 - Node.js 20+ with npm package manager
-- An existing Vendure project created with the [Vendure create command](/guides/getting-started/installation/)
+- An existing Vendure project created with the [Vendure create command](/getting-started/installation/)
 - An access key to a CMS platform that provides an API
 
 ## Core Concepts
 
-This [plugin](/guides/developer-guide/plugins/) leverages several key Vendure concepts:
+This [plugin](/developer-guide/plugins/) leverages several key Vendure concepts:
 
-- **[EventBus](/guides/developer-guide/events/)**: Provides real-time notifications when entities are created, updated, or deleted.
-- **[Job Queues](/guides/developer-guide/worker-job-queue/)**: Ensures that synchronization tasks are performed reliably and asynchronously, with retries on failure.
-- **[Plugin API](/guides/developer-guide/plugins/)**: The foundation for extending Vendure with custom capabilities.
+- **[EventBus](/developer-guide/events/)**: Provides real-time notifications when entities are created, updated, or deleted.
+- **[Job Queues](/developer-guide/worker-job-queue/)**: Ensures that synchronization tasks are performed reliably and asynchronously, with retries on failure.
+- **[Plugin API](/developer-guide/plugins/)**: The foundation for extending Vendure with custom capabilities.
 
 ## How It Works
 
@@ -92,11 +92,11 @@ npx vendure add -s CmsSpecificService --selected-plugin CmsPlugin
 # Explained later in the Event-Driven Synchronization Section
 ```
 
-Now we start by defining the main [plugin](/guides/developer-guide/plugins/) class, its [services](/guides/developer-guide/the-service-layer/), and the configuration types.
+Now we start by defining the main [plugin](/developer-guide/plugins/) class, its [services](/developer-guide/the-service-layer/), and the configuration types.
 
 ### Plugin Definition
 
-The `CmsPlugin` class registers the necessary [services](/guides/developer-guide/the-service-layer/) (`CmsSyncService`, `CmsSpecificService`) and sets up any Admin API extensions.
+The `CmsPlugin` class registers the necessary [services](/developer-guide/the-service-layer/) (`CmsSyncService`, `CmsSpecificService`) and sets up any Admin API extensions.
 
 ```ts title="src/plugins/cms/cms.plugin.ts"
 import { VendurePlugin, PluginCommonModule, Type, OnModuleInit } from '@vendure/core';
@@ -161,9 +161,9 @@ export interface SyncResponse {
 
 ## Event-Driven Synchronization
 
-The plugin uses Vendure's [EventBus](/guides/developer-guide/events/) to capture changes in real-time.
+The plugin uses Vendure's [EventBus](/developer-guide/events/) to capture changes in real-time.
 
-In the [onModuleInit](/guides/developer-guide/events/#subscribing-to-events) lifecycle hook, we create job queues and subscribe to entity events.
+In the [onModuleInit](/developer-guide/events/#subscribing-to-events) lifecycle hook, we create job queues and subscribe to entity events.
 
 ### Creating Job Queues and Subscribing to Events
 
@@ -280,7 +280,7 @@ The sync service handles several critical functions:
 
 ### Service Structure and Dependencies
 
-The service follows Vendure's [dependency injection pattern](/guides/developer-guide/the-service-layer/) and requires several core Vendure services:
+The service follows Vendure's [dependency injection pattern](/developer-guide/the-service-layer/) and requires several core Vendure services:
 
 ```ts title="src/plugins/cms/services/cms-sync.service.ts"
 @Injectable()

docs/docs/guides/how-to/codegen/index.mdx

@@ -16,7 +16,7 @@ directory.
 :::
 
 :::note
-This guide is for adding codegen to your Vendure plugins. For a guide on adding codegen to your storefront, see the [Storefront Codegen](/guides/storefront/codegen/) guide.
+This guide is for adding codegen to your Vendure plugins. For a guide on adding codegen to your storefront, see the [Storefront Codegen](/storefront/codegen/) guide.
 :::
 
 ## Installation

docs/docs/guides/how-to/configurable-products/index.mdx

@@ -8,7 +8,7 @@ A "configurable product" is one where aspects can be configured by the customer,
 - A gift message inserted with the packaging
 - An uploaded image to be printed on a t-shirt
 
-In Vendure this is done by defining one or more [custom fields](/guides/developer-guide/custom-fields/) on the [OrderLine](/reference/typescript-api/entities/order-line/) entity.
+In Vendure this is done by defining one or more [custom fields](/developer-guide/custom-fields/) on the [OrderLine](/reference/typescript-api/entities/order-line/) entity.
 
 ## Defining custom fields
 

docs/docs/guides/how-to/digital-products/index.mdx

@@ -40,7 +40,7 @@ export class DigitalProductsPlugin {}
 
 :::note
 You will need to **create a migration** after adding this custom field.
-See the [Migrations](/guides/developer-guide/migrations/) guide for more information.
+See the [Migrations](/developer-guide/migrations/) guide for more information.
 :::
 
 We will also define a custom field on the `ShippingMethod` entity to indicate that this shipping method is only available for digital products:

docs/docs/guides/how-to/github-oauth-authentication/index.mdx

@@ -343,7 +343,7 @@ GitHub-authenticated customers are managed like any other Vendure [Customer](/re
 - **External ID**: GitHub username stored for future authentication
 - **Profile**: Name extracted from GitHub profile when available
 
-This means GitHub users work seamlessly with Vendure's [order management](/guides/core-concepts/orders/), [promotions](/guides/core-concepts/promotions/), and customer workflows.
+This means GitHub users work seamlessly with Vendure's [order management](/core-concepts/orders/), [promotions](/core-concepts/promotions/), and customer workflows.
 
 ## Testing the Integration
 

docs/docs/guides/how-to/google-oauth-authentication/index.mdx

@@ -12,7 +12,7 @@ This is particularly valuable for **consumer-facing stores** where users prefer
 
 This guide shows you how to **add Google OAuth support** to your Vendure store using a custom [AuthenticationStrategy](/reference/typescript-api/auth/authentication-strategy/) and Google Identity Services.
 
-An **AuthenticationStrategy** in Vendure defines how users can log in to your store. Learn more about [authentication in Vendure](/guides/core-concepts/auth/).
+An **AuthenticationStrategy** in Vendure defines how users can log in to your store. Learn more about [authentication in Vendure](/core-concepts/auth/).
 
 ## Creating the Plugin
 
@@ -22,7 +22,7 @@ An **AuthenticationStrategy** in Vendure defines how users can log in to your st
 npx vendure add -p GoogleAuthPlugin
 ```
 
-This creates a basic [plugin](/guides/developer-guide/plugins/) structure with the necessary files.
+This creates a basic [plugin](/developer-guide/plugins/) structure with the necessary files.
 
 ## Installing Dependencies
 
@@ -477,7 +477,7 @@ mutation AuthenticateWithGoogle {
 - **Profile**: First and last names from Google profile, with fallbacks
 - **Security**: No password stored - authentication handled entirely by Google
 
-This means **Google users work seamlessly** with Vendure's [order management](/guides/core-concepts/orders/), [promotions](/guides/core-concepts/promotions/), and all customer workflows.
+This means **Google users work seamlessly** with Vendure's [order management](/core-concepts/orders/), [promotions](/core-concepts/promotions/), and all customer workflows.
 
 ## Testing the Integration
 

docs/docs/guides/how-to/multi-vendor-marketplaces/index.mdx

@@ -20,7 +20,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](/guides/core-concepts/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](/core-concepts/channels/) to get a more detailed understanding of how they work.
 
 Each Channel is assigned to a [Seller](/reference/typescript-api/entities/seller/), which is another term for the vendor who is selling things in our marketplace.
 
@@ -60,7 +60,7 @@ Bob can now log in to the Dashboard using the provided credentials and begin cre
 
 In some marketplaces, the same product may be sold by multiple sellers. When this is the case, the product and its variants
 will be assigned not only to the default channel, but to multiple other channels as well - see the 
-[Channels, Currencies & Prices section](/guides/core-concepts/channels/#channels-currencies--prices) for a visual explanation of how this works.
+[Channels, Currencies & Prices section](/core-concepts/channels/#channels-currencies--prices) for a visual explanation of how this works.
 
 This means that there will be multiple ProductVariantPrice entities per variant, one for each channel. 
  

docs/docs/guides/how-to/paginated-list/index.mdx

@@ -7,7 +7,7 @@ to implement your own paginated list queries.
 
 ## API definition
 
-Let's start with defining the GraphQL schema for our query. In this example, we'll image that we have defined a [custom entity](/guides/developer-guide/database-entity/) to
+Let's start with defining the GraphQL schema for our query. In this example, we'll image that we have defined a [custom entity](/developer-guide/database-entity/) to
 represent a `ProductReview`. We want to be able to query a list of reviews in the Admin API. Here's how the schema definition
 would look:
 

docs/docs/guides/how-to/publish-plugin/index.mdx

@@ -2,7 +2,7 @@
 title: "Publishing a Plugin"
 ---
 
-Vendure's [plugin-based architecture](/guides/developer-guide/plugins/) means you'll be writing a lot of plugins.
+Vendure's [plugin-based architecture](/developer-guide/plugins/) means you'll be writing a lot of plugins.
 Some of those plugins may be useful to others, and you may want to share them with the community.
 
 We have created [Vendure Hub](https://vendure.io/hub) as a central listing for high-quality Vendure plugins.
@@ -44,7 +44,7 @@ a must. The same goes for any of the transitive dependencies of Vendure core suc
 that these dependencies will be available in the Vendure project that uses your plugin.
 
 As for version compatibility, you should use the
-[compatibility property](/guides/developer-guide/plugins/#step-7-specify-compatibility) in your plugin definition to ensure that the Vendure project
+[compatibility property](/developer-guide/plugins/#step-7-specify-compatibility) in your plugin definition to ensure that the Vendure project
 is using a compatible version of Vendure.
 
 ### License
@@ -380,7 +380,7 @@ export class LoyaltyPointsTransactionEvent extends VendureEvent {
 Testing is an important part of ensuring the quality of your plugin, as well as preventing regressions when you make
 changes.
 
-For plugins of any complexity, you should aim to have a suite of end-to-end tests as covered in the [testing docs](/guides/developer-guide/testing/).
+For plugins of any complexity, you should aim to have a suite of end-to-end tests as covered in the [testing docs](/developer-guide/testing/).
 
 In future we may use the test results to help determine the quality of a plugin.
 

docs/docs/guides/how-to/s3-asset-storage/index.mdx

@@ -14,7 +14,7 @@ Refer to the complete working code for full implementation details.
 ## Prerequisites
 
 - Node.js 20+ with npm package manager
-- An existing Vendure project created with the [Vendure create command](/guides/getting-started/installation/)
+- An existing Vendure project created with the [Vendure create command](/getting-started/installation/)
 - An account with one of the supported S3-compatible storage providers
 
 ## S3-Compatible Storage Provider Setup

docs/docs/guides/storefront/active-order/index.mdx

@@ -100,7 +100,7 @@ query GetActiveOrder {
 
 ## Add an item
 
-To add an item to the active order, we use the [`addItemToOrder` mutation](/reference/graphql-api/shop/mutations/#additemtoorder), as we have seen in the [Product Detail Page guide](/guides/storefront/product-detail/).
+To add an item to the active order, we use the [`addItemToOrder` mutation](/reference/graphql-api/shop/mutations/#additemtoorder), as we have seen in the [Product Detail Page guide](/storefront/product-detail/).
 
 ```graphql
 mutation AddItemToOrder($productVariantId: ID!, $quantity: Int!) {
@@ -122,7 +122,7 @@ mutation AddItemToOrder($productVariantId: ID!, $quantity: Int!) {
 
 :::info
 If you have defined any custom fields on the `OrderLine` entity, you will be able to pass them as a `customFields` argument to the `addItemToOrder` mutation.
-See the [Configurable Products guide](/guides/how-to/configurable-products/) for more information.
+See the [Configurable Products guide](/how-to/configurable-products/) for more information.
 :::
 
 ## Remove an item
@@ -160,12 +160,12 @@ mutation AdjustOrderLine($orderLineId: ID!, $quantity: Int!) {
 
 :::info
 If you have defined any custom fields on the `OrderLine` entity, you will be able to update their values by passing a `customFields` argument to the `adjustOrderLine` mutation.
-See the [Configurable Products guide](/guides/how-to/configurable-products/) for more information.
+See the [Configurable Products guide](/how-to/configurable-products/) for more information.
 :::
 
 ## Applying a coupon code
 
-If you have defined any [Promotions](/guides/core-concepts/promotions/) which use coupon codes, you can apply the a coupon code to the active order
+If you have defined any [Promotions](/core-concepts/promotions/) which use coupon codes, you can apply the a coupon code to the active order
 using the [`applyCouponCode` mutation](/reference/graphql-api/shop/mutations/#applycouponcode).
 
 ```graphql

docs/docs/guides/storefront/checkout-flow/index.mdx

@@ -4,12 +4,12 @@ title: "Checkout Flow"
 
 Once the customer has added the desired products to the active order, it's time to check out.
 
-This guide assumes that you are using the [default OrderProcess](/guides/core-concepts/orders/#the-order-process), so
+This guide assumes that you are using the [default OrderProcess](/core-concepts/orders/#the-order-process), so
 if you have defined a custom process, some of these steps may be slightly different.
 
 :::note
 In this guide, we will assume that an `ActiveOrder` fragment has been defined, as detailed in the
-[Managing the Active Order guide](/guides/storefront/active-order/#define-an-order-fragment), but for the purposes of
+[Managing the Active Order guide](/storefront/active-order/#define-an-order-fragment), but for the purposes of
 checking out the fragment should also include `customer` `shippingAddress` and `billingAddress` fields.
 :::
 
@@ -388,7 +388,7 @@ Our [`MolliePlugin` docs](/reference/core-plugins/payments-plugin/mollie-plugin/
 
 ### Other payment providers
 
-For more information on how to integrate with a payment provider, see the [Payment](/guides/core-concepts/payment/) guide.
+For more information on how to integrate with a payment provider, see the [Payment](/core-concepts/payment/) guide.
 
 ## Display confirmation
 

docs/docs/guides/storefront/codegen/index.mdx

@@ -9,7 +9,7 @@ write any types for your API calls.
 To do this, we will use [Graphql Code Generator](https://the-guild.dev/graphql/codegen).
 
 :::note
-This guide is for adding codegen to your storefront. For a guide on adding codegen to your backend Vendure plugins or UI extensions, see the [Plugin Codegen](/guides/how-to/codegen/) guide.
+This guide is for adding codegen to your storefront. For a guide on adding codegen to your backend Vendure plugins or UI extensions, see the [Plugin Codegen](/how-to/codegen/) guide.
 :::
 
 ## Installation

docs/docs/guides/storefront/connect-api/index.mdx

@@ -113,7 +113,7 @@ length of time that a session will stay valid since the last API call.
 
 ## Specifying a channel
 
-If your project has multiple [channels](/guides/core-concepts/channels/), you can specify the active channel by setting
+If your project has multiple [channels](/core-concepts/channels/), you can specify the active channel by setting
 the `vendure-token` header on each request to match the `channelToken` for the desired channel.
 
 Let's say you have a channel with the token `uk-channel` and you want to make a request to the Shop API to get the
@@ -161,7 +161,7 @@ POST http://localhost:3000/shop-api?languageCode=de
 If you are building your storefront with TypeScript, we highly recommend you set up code generation to ensure
 that the responses from your queries & mutation are always correctly typed according the fields you request.
 
-See the [GraphQL Code Generation guide](/guides/storefront/codegen/) for more information.
+See the [GraphQL Code Generation guide](/storefront/codegen/) for more information.
 
 ## Examples
 

docs/docs/guides/storefront/customer-accounts/index.mdx

@@ -137,7 +137,7 @@ mutation LogOut {
 The `login` mutation, as well as the following mutations related to registration & password recovery only
 apply when using the built-in [`NativeAuthenticationStrategy`](/reference/typescript-api/auth/native-authentication-strategy/).
 
-If you are using alternative authentication strategies in your storefront, you would use the [`authenticate` mutation](/reference/graphql-api/shop/mutations/#authenticate) as covered in the [External Authentication guide](/guides/core-concepts/auth/#external-authentication).
+If you are using alternative authentication strategies in your storefront, you would use the [`authenticate` mutation](/reference/graphql-api/shop/mutations/#authenticate) as covered in the [External Authentication guide](/core-concepts/auth/#external-authentication).
 :::
 
 ## Registering a customer account

docs/docs/guides/storefront/listing-products/index.mdx

@@ -13,7 +13,7 @@ be used to fetch a list of products, but they need to perform much more complex
 
 ## Listing products in a collection
 
-Following on from the [navigation example](/guides/storefront/navigation-menu/), let's assume that a customer has
+Following on from the [navigation example](/storefront/navigation-menu/), let's assume that a customer has
 clicked on a collection item from the menu, and we want to display the products in that collection.
 
 Typically, we will know the `slug` of the selected collection, so we can use the `collection` query to fetch the

docs/docs/guides/storefront/navigation-menu/index.mdx

@@ -4,7 +4,7 @@ title: "Navigation Menu"
 
 A navigation menu allows your customers to navigate your store and find the products they are looking for.
 
-Typically, navigation is based on a hierarchy of [collections](/guides/core-concepts/collections/). We can get the top-level
+Typically, navigation is based on a hierarchy of [collections](/core-concepts/collections/). We can get the top-level
 collections using the `collections` query with the `topLevelOnly` filter:
 
 

docs/docs/guides/storefront/order-workflow/index.mdx

@@ -10,7 +10,7 @@ An Order is a collection of one or more ProductVariants which can be purchased b
 Every Order has a `state` property of type [`OrderState`](/reference/typescript-api/orders/order-process/#orderstate). The following diagram shows the default states and how an Order transitions from one to the next.
 
 :::note
-Note that this default workflow can be modified to better fit your business processes. See the [Customizing the Order Process guide](/guides/core-concepts/orders/#custom-order-processes).
+Note that this default workflow can be modified to better fit your business processes. See the [Customizing the Order Process guide](/core-concepts/orders/#custom-order-processes).
 :::
 
 ![./order_state_diagram.png](./order_state_diagram.png)
@@ -25,7 +25,7 @@ Here is a simplified diagram illustrating this relationship:
 
 ## Shop client order workflow
 
-The [GraphQL Shop API Guide](/guides/storefront/active-order) lists the GraphQL operations you will need to implement this workflow in your storefront client application.
+The [GraphQL Shop API Guide](/storefront/active-order) lists the GraphQL operations you will need to implement this workflow in your storefront client application.
 
 In this section, we'll cover some examples of how these operations would look in your storefront.
 

docs/docs/guides/storefront/product-detail/index.mdx

@@ -145,11 +145,11 @@ This single query provides all the data we need to display our PDP.
 
 ## Formatting prices
 
-As explained in the [Money & Currency guide](/guides/core-concepts/money/), the prices are returned as integers in the
+As explained in the [Money & Currency guide](/core-concepts/money/), the prices are returned as integers in the
 smallest unit of the currency (e.g. cents for USD). Therefore, when we display the price, we need to divide by 100 and
 format it according to the currency's formatting rules.
 
-In the demo at the end of this guide, we'll use the [`formatCurrency` function](/guides/core-concepts/money/#displaying-monetary-values)
+In the demo at the end of this guide, we'll use the [`formatCurrency` function](/core-concepts/money/#displaying-monetary-values)
 which makes use of the browser's `Intl` API to format the price according to the user's locale.
 
 ## Displaying images
@@ -274,9 +274,9 @@ fragment UpdatedOrder on Order {
 
 There are some important things to note about this mutation:
 
-- Because the `addItemToOrder` mutation returns a union type, we need to use a [fragment](/guides/getting-started/graphql-intro/#fragments) to specify the fields we want to return.
+- Because the `addItemToOrder` mutation returns a union type, we need to use a [fragment](/getting-started/graphql-intro/#fragments) to specify the fields we want to return.
 In this case we have defined a fragment called `UpdatedOrder` which contains the fields we are interested in.
-- If any [expected errors](/guides/developer-guide/error-handling/) occur, the mutation will return an `ErrorResult` object. We'll be able to
+- If any [expected errors](/developer-guide/error-handling/) occur, the mutation will return an `ErrorResult` object. We'll be able to
 see the `errorCode` and `message` fields in the response, so that we can display a meaningful error message to the user.
 - In the special case of the `InsufficientStockError`, in addition to the `errorCode` and `message` fields, we also get the `quantityAvailable` field
 which tells us how many of the requested quantity are available (and have been added to the order). This is useful information to display to the user.

docs/docs/reference/admin-ui-api/ui-devkit/admin-ui-extension.mdx

@@ -8,7 +8,7 @@ Defines extensions to the Admin UI application by specifying additional
 Angular [NgModules](https://angular.io/guide/ngmodules) which are compiled
 into the application.
 
-See [Extending the Admin UI](/guides/extending-the-admin-ui/getting-started/) for
+See [Extending the Admin UI](/extending-the-admin-ui/getting-started/) for
 detailed instructions.
 
 ```ts title="Signature"

docs/docs/reference/core-plugins/admin-ui-plugin/index.mdx

@@ -5,7 +5,7 @@ generated: true
 <GenerationInfo sourceFile="packages/admin-ui-plugin/src/plugin.ts" sourceLine="147" packageName="@vendure/admin-ui-plugin" />
 
 :::warning Deprecated
-From Vendure v3.5.0, the Angular-based Admin UI has been replaced by the new [React Admin Dashboard](/guides/extending-the-dashboard/getting-started/).
+From Vendure v3.5.0, the Angular-based Admin UI has been replaced by the new [React Admin Dashboard](/extending-the-dashboard/getting-started/).
 The Angular Admin UI will not be maintained after **July 2026**. Until then, we will continue patching critical bugs and security issues.
 Community contributions will always be merged and released.
 :::

docs/docs/reference/core-plugins/dashboard-plugin/index.mdx

@@ -14,7 +14,7 @@ GraphQL extensions needed for the order metrics on the dashboard index page.
 ## Usage
 
 First you need to set up compilation of the Dashboard, using the Vite configuration
-described in the [Dashboard Getting Started Guide](/guides/extending-the-dashboard/getting-started/)
+described in the [Dashboard Getting Started Guide](/extending-the-dashboard/getting-started/)
 
 ## Development vs Production
 

docs/docs/reference/core-plugins/telemetry-plugin/index.mdx

@@ -15,7 +15,7 @@ npm install @vendure/telemetry-plugin
 
 :::info
 For a complete guide to setting up and working with Open Telemetry, see
-the [Implementing Open Telemetry guide](/guides/how-to/telemetry/).
+the [Implementing Open Telemetry guide](/how-to/telemetry/).
 :::
 
 ## Configuration

docs/docs/reference/typescript-api/auth/authentication-strategy.mdx

@@ -7,7 +7,7 @@ generated: true
 An AuthenticationStrategy defines how a User (which can be a Customer in the Shop API or
 and Administrator in the Admin API) may be authenticated.
 
-Real-world examples can be found in the [Authentication guide](/guides/core-concepts/auth/).
+Real-world examples can be found in the [Authentication guide](/core-concepts/auth/).
 
 :::info
 

docs/docs/reference/typescript-api/common/admin-ui/admin-ui-config.mdx

@@ -128,7 +128,7 @@ A url of a custom image to be used on the login screen, to override the images p
 
 Allows you to provide default reasons for a refund or cancellation. This will be used in the
 refund/cancel dialog. The values can be literal strings (e.g. "Not in stock") or translation
-tokens (see [Adding Admin UI Translations](/guides/extending-the-admin-ui/adding-ui-translations/)).
+tokens (see [Adding Admin UI Translations](/extending-the-admin-ui/adding-ui-translations/)).
 
 
 </div>