docs: Add temp todo page

docs/docs/TODO.md

@@ -0,0 +1,8 @@
+---
+title: TODO
+---
+This part still needs to be written! 
+
+```
+( ° ᴗ°)~ð (/❛o❛\)
+```

docs/docs/guides/concepts/custom-fields/index.md

@@ -38,7 +38,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](TODO).
+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](/TODO).
 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/typescript-api/core-plugins/admin-ui-plugin/), the Admin UI detail pages will now contain form inputs to allow the custom field data to be added or edited, and the list view data tables will allow custom field columns to be added, sorted and filtered.
 
@@ -909,7 +909,7 @@ This table shows the default form input component used for each custom field typ
 
 The Admin UI 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](TODO)
+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](/TODO)
 :::
 
 ### Specifying the input component
@@ -995,7 +995,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](TODO) 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](/TODO) guide.
 
 
 ## Tabbed custom fields

docs/docs/guides/concepts/data-model/index.mdx

@@ -78,7 +78,7 @@ includes a number of collection filters:
 ![Collection filters](./collection-filters.webp)
 
 It is also possible to create your own custom collection filters, which can be used to implement more complex logic. This is
-covered in the [custom collection filters](TODO) guide.
+covered in the [custom collection filters](/TODO) guide.
 
 Collections are not _only_ used as the basis of storefront navigation. They are a general-purpose organization tool which can be used
 for many purposes, such as:

docs/docs/guides/concepts/worker-job-queue/index.mdx

@@ -167,7 +167,7 @@ which uses an efficient push-based strategy built on Redis.
 
 ### Using Job Queues in a plugin
 
-If you create a [Vendure plugin](/guides/concepts/plugins/) which involves some long-running tasks, you can also make use of the job queue. See the [JobQueue plugin example](TODO)
+If you create a [Vendure plugin](/guides/concepts/plugins/) which involves some long-running tasks, you can also make use of the job queue. See the [JobQueue plugin example](/TODO)
 for a detailed annotated example.
 
 :::info

docs/docs/guides/getting-started/configuration.md

@@ -68,7 +68,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](TODO).
+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]((/(/TODO))).
 
 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).
 

docs/docs/guides/getting-started/overview/index.md

@@ -24,7 +24,7 @@ Vendure is built on the following open-source technologies:
 
 - **SQL Database**: Vendure requires an SQL database compatible with [TypeORM](https://typeorm.io/). Officially we support **PostgreSQL**, **MySQL/MariaDB** and **SQLite** but Vendure can also be used with API-compatible variants such [Amazon Aurora](https://aws.amazon.com/rds/aurora/), [CockroachDB](https://www.cockroachlabs.com/), or [PlanetScale](https://planetscale.com/).
 - **TypeScript & Node.js**: Vendure is written in [TypeScript](https://www.typescriptlang.org/) and runs on [Node.js](https://nodejs.org).
-- **NestJS**: The underlying framework is [NestJS](https://nestjs.com/), which is a full-featured application development framework for Node.js. Building on NestJS means that Vendure from the well-defined structure and rich feature-set and ecosystem that NestJS provides. If you are unfamiliar with NestJS, see our [NestJS for Vendure Developers guide](TODO).
+- **NestJS**: The underlying framework is [NestJS](https://nestjs.com/), which is a full-featured application development framework for Node.js. Building on NestJS means that Vendure from the well-defined structure and rich feature-set and ecosystem that NestJS provides. If you are unfamiliar with NestJS, see our [NestJS for Vendure Developers guide](/TODO).
 - **GraphQL**: The Shop and Admin APIs use [GraphQL](https://graphql.org/), which is a modern API technology which allows you to specify the exact data that your client application needs in a convenient and type-safe way. Internally we use [Apollo Server](https://www.apollographql.com/docs/apollo-server/) to power our GraphQL APIs.
 - **Angular**: The Admin UI is built with [Angular](https://angular.io/), a popular, stable application framework from Google. Note that you do not need to know Angular to use Vendure, and UI extensions can even be written in the front-end framework of your choice, such as React or Vue.