docs: misc improvements to high-level docs (#7177)

docs/admin/collections.mdx

@@ -30,14 +30,14 @@ The following options are available:
 | **`group`**                      | Text used as a label for grouping Collection and Global links together in the navigation.                                                                                                             |
 | **`hidden`**                     | Set to true or a function, called with the current user, returning true to exclude this Collection from navigation and admin routing.                                                                 |
 | **`hooks`**                      | Admin-specific hooks for this Collection. [More details](../hooks/collections).                                                                                                                                        |
-| **`useAsTitle`**                 | Specify a top-level field to use for a document title throughout the [Admin Panel](./overview). If no field is defined, the ID of the document is used as the title.                                                |
+| **`useAsTitle`**                 | Specify a top-level field to use for a document title throughout the Admin Panel. If no field is defined, the ID of the document is used as the title.                                                |
 | **`description`**                | Text or React component to display below the Collection label in the List View to give editors more information.                                                                                      |
 | **`defaultColumns`**             | Array of field names that correspond to which columns to show by default in this Collection's List View.                                                                                              |
 | **`hideAPIURL`**                 | Hides the "API URL" meta field while editing documents within this Collection.                                                                                                                        |
 | **`enableRichTextLink`**         | The [Rich Text](../fields/rich-text) field features a `Link` element which allows for users to automatically reference related documents within their rich text. Set to `true` by default.         |
 | **`enableRichTextRelationship`** | The [Rich Text](../fields/rich-text) field features a `Relationship` element which allows for users to automatically reference related documents within their rich text. Set to `true` by default. |
-| **`meta`**                       | Metadata overrides to apply to the [Admin Panel](./overview). Included properties are `description` and `openGraph`.                                                                           |
+| **`meta`**                       | Metadata overrides to apply to the Admin Panel. Included properties are `description` and `openGraph`.                                                                           |
-| **`preview`**                    | Function to generate preview URLs within the [Admin Panel](./overview) that can point to your app. [More details](#preview).                                                                                                |
+| **`preview`**                    | Function to generate preview URLs within the Admin Panel that can point to your app. [More details](#preview).                                                                                                |
 | **`livePreview`**                | Enable real-time editing for instant visual feedback of your front-end application. [More details](../live-preview/overview).                                                                              |
 | **`components`**                 | Swap in your own React components to be used within this Collection. [More details](#components).                                                                                       |
 | **`listSearchableFields`**       | Specify which fields should be searched in the List search view. [More details](#list-searchable-fields).                                                                                                      |
@@ -71,11 +71,11 @@ The following options are available:
 | **`beforeListTable`**      | An array of components to inject _before_ the built-in List View's table                                                  |
 | **`afterList`**            | An array of components to inject _after_ the built-in List View                                                           |
 | **`afterListTable`**       | An array of components to inject _after_ the built-in List View's table                                                   |
-| **`edit.SaveButton`**      | Replace the default `Save` button with a Custom Component. Drafts must be disabled                                     |
+| **`edit.SaveButton`**      | Replace the default Save Button with a Custom Component. [Drafts](../versions/drafts) must be disabled.                                     |
-| **`edit.SaveDraftButton`** | Replace the default `Save Draft` button with a Custom Component. Drafts must be enabled and autosave must be disabled. |
+| **`edit.SaveDraftButton`** | Replace the default Save Draft Button with a Custom Component. [Drafts](../versions/drafts) must be enabled and autosave must be disabled. |
-| **`edit.PublishButton`**   | Replace the default `Publish` button with a Custom Component. Drafts must be enabled.                                  |
+| **`edit.PublishButton`**   | Replace the default Publish Button with a Custom Component. [Drafts](../versions/drafts) must be enabled.                                  |
-| **`edit.PreviewButton`**   | Replace the default `Preview` button with a Custom Component.                                                          |
+| **`edit.PreviewButton`**   | Replace the default Preview Button with a Custom Component. [Preview](#preview) must be enabled.                                         |
-| **`views`**                | Override or create new views within the [Admin Panel](./overview). [More details](./views).                                     |
+| **`views`**                | Override or create new views within the Admin Panel. [More details](./views).                                     |
 
 <Banner type="success">
   <strong>Note:</strong>
@@ -111,7 +111,7 @@ The preview function receives two arguments:
 
 | Argument | Description |
 | --- | --- |
-| **`doc`** | The document being edited |
+| **`doc`** | The Document being edited. |
 | **`ctx`** | An object containing `locale` and `token` properties. The `token` is the currently logged-in user's JWT. |
 
 <Banner type="success">
@@ -121,7 +121,7 @@ The preview function receives two arguments:
 
 ### Pagination
 
-All Collections receive their own List View which displays a paginated list of documents that can be sorted and filtered. The pagination behavior of the List View can be customized on a per-Collection basis.
+All Collections receive their own List View which displays a paginated list of documents that can be sorted and filtered. The pagination behavior of the List View can be customized on a per-Collection basis, and uses the same [Pagination](../queries/pagination) API that Payload provides.
 
 To configure pagination options, use the `admin.pagination` property in your [Collection Config](../configuration/collections):
 

docs/admin/components.mdx

@@ -38,11 +38,11 @@ import { MyCustomLogo } from './MyCustomLogo'
 export default buildConfig({
   // ...
   admin: {
+    // highlight-start
     components: {
-      graphics: {
+      // ...
-        Logo: MyCustomLogo, // highlight-line
-      },
     },
+    // highlight-end
   },
 })
 ```

docs/admin/globals.mdx

@@ -30,10 +30,10 @@ The following options are available:
 | **`group`**       | Text used as a label for grouping Collection and Global links together in the navigation.                                         |
 | **`hidden`**      | Set to true or a function, called with the current user, returning true to exclude this Global from navigation and admin routing. |
 | **`components`**  | Swap in your own React components to be used within this Global. [More details](#components).                           |
-| **`preview`**     | Function to generate a preview URL within the [Admin Panel](./overview) for this Global that can point to your app. [More details](#preview).           |
+| **`preview`**     | Function to generate a preview URL within the Admin Panel for this Global that can point to your app. [More details](#preview).           |
 | **`livePreview`** | Enable real-time editing for instant visual feedback of your front-end application. [More details](../live-preview/overview).          |
 | **`hideAPIURL`**  | Hides the "API URL" meta field while editing documents within this collection.                                                    |
-| **`meta`**        | Metadata overrides to apply to the [Admin Panel](./overview). Included properties are `description` and `openGraph`.       |
+| **`meta`**        | Metadata overrides to apply to the Admin Panel. Included properties are `description` and `openGraph`.       |
 
 ### Components
 
@@ -59,11 +59,11 @@ The following options are available:
 
 | Path                           | Description                                                                                                            |
 | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------- |
-| **`elements.SaveButton`**      | Replace the default `Save` button with a Custom Component. Drafts must be disabled.                                    |
+| **`elements.SaveButton`**      | Replace the default Save Button with a Custom Component. [Drafts](../versions/drafts) must be disabled.                                    |
-| **`elements.SaveDraftButton`** | Replace the default `Save Draft` button with a Custom Component. Drafts must be enabled and autosave must be disabled. |
+| **`elements.SaveDraftButton`** | Replace the default Save Draft Button with a Custom Component. [Drafts](../versions/drafts) must be enabled and autosave must be disabled. |
-| **`elements.PublishButton`**   | Replace the default `Publish` button with a Custom Component. Drafts must be enabled.                                  |
+| **`elements.PublishButton`**   | Replace the default Publish Button with a Custom Component. [Drafts](../versions/drafts) must be enabled.                                  |
-| **`elements.PreviewButton`**   | Replace the default `Preview` button with a Custom Component.                                                          |
+| **`elements.PreviewButton`**   | Replace the default Preview Button with a Custom Component. [Preview](#preview) must be enabled.                                         |
-| **`views`**                    | Override or create new views within the [Admin Panel](./overview). [More details](./views).                                     |
+| **`views`**                    | Override or create new views within the Admin Panel. [More details](./views).                                     |
 
 <Banner type="success">
   <strong>Note:</strong>
@@ -99,7 +99,7 @@ The preview function receives two arguments:
 
 | Argument | Description |
 | --- | --- |
-| **`doc`** | The document being edited |
+| **`doc`** | The Document being edited. |
 | **`ctx`** | An object containing `locale` and `token` properties. The `token` is the currently logged-in user's JWT. |
 
 <Banner type="success">

docs/admin/preferences.mdx

@@ -22,7 +22,7 @@ Out of the box, Payload handles the persistence of your users' preferences in a
   that is reading or setting a preference via all provided authentication methods.
 </Banner>
 
-## Use cases
+## Use Cases
 
 This API is used significantly for internal operations of the Admin Panel, as mentioned above. But, if you're building your own React components for use in the Admin Panel, you can allow users to set their own preferences in correspondence to their usage of your components. For example:
 

docs/admin/views.mdx

@@ -278,7 +278,7 @@ export const MyCollectionConfig: SanitizedCollectionConfig = {
 Your Custom Views will be provided with the following props:
 
 | Prop                      | Description                                                                                                                            |
-| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |                                                                                            |
+| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
 | **`user`**                    | The currently logged in user.                                                                                                          |
 | **`locale`**                  | The current [Locale](../configuration/localization) of the [Admin Panel](./overview).                                                  |
 | **`navGroups`**               | The grouped navigation items according to `admin.group` in your [Collection Config](../collections/overview) or [Global Config](../globals/overview). |

docs/configuration/collections.mdx

@@ -6,9 +6,9 @@ desc: Structure your Collections for your needs by defining fields, adding slugs
 keywords: collections, config, configuration, documentation, Content Management System, cms, headless, javascript, node, react, nextjs
 ---
 
-A Collection is a group of records, called Documents, that all share a common schema. You can define as many Collections as your application needs. Each Collection saves to the [Database](../database/overview) based on the [Fields](../fields/overview) that you define, and automatically generates the [Local API](../local-api/overview), [REST API](../rest-api/overview), and [GraphQL API](../graphql/overview) to manage your Documents.
+A Collection is a group of records, called Documents, that all share a common schema. You can define as many Collections as your application needs. Each Document in a Collection is stored in the [Database](../database/overview) based on the [Fields](../fields/overview) that you define, and automatically generates a [Local API](../local-api/overview), [REST API](../rest-api/overview), and [GraphQL API](../graphql/overview) used to manage your Documents.
 
-Collections are also the primary way to achieve [Authentication](../authentication/overview) in Payload. By defining a Collection with `auth` options, that Collection receives additional operations to support user authentication.
+Collections are also used to achieve [Authentication](../authentication/overview) in Payload. By defining a Collection with `auth` options, that Collection receives additional operations to support user authentication.
 
 Collections are the primary way to structure recurring data in your application, such as users, products, pages, posts, and other types of content that you might want to manage. Each Collection can have its own unique [Access Control](../access-control/overview), [Hooks](../hooks/overview), [Admin Options](#admin-options), and more.
 
@@ -97,18 +97,10 @@ You can customize the way that the [Admin Panel](../admin/overview) behaves on a
 
 ## TypeScript
 
-You can import Collection types as follows:
+You can import types from Payload to help make writing your Collection configs easier and type-safe. There are two main types that represent the Collection Config, `CollectionConfig` and `SanitizeCollectionConfig`.
+
+The `CollectionConfig` type represents a raw Collection Config in its full form, where only the bare minimum properties are marked as required. The `SanitizedCollectionConfig` type represents a Collection Config after it has been fully sanitized. Generally, this is only used internally by Payload.
 
 ```ts
-import { CollectionConfig } from 'payload'
+import { CollectionConfig, SanitizedCollectionConfig } from 'payload'
-
-// This is the type used for incoming Collection configs.
-// Only the bare minimum properties are marked as required.
-```
-
-```ts
-import { SanitizedCollectionConfig } from 'payload'
-
-// This is the type used after an incoming Collection config is fully sanitized.
-// Generally, this is only used internally by Payload.
 ```

docs/configuration/globals.mdx

@@ -6,7 +6,7 @@ desc: Set up your Global config for your needs by defining fields, adding slugs
 keywords: globals, config, configuration, documentation, Content Management System, cms, headless, javascript, node, react, nextjs
 ---
 
-Globals are in many ways similar to [Collections](../configuration/collections), except they correspond to only a single Document. You can define as many Globals as your application needs. Each Global saves to the [Database](../database/overview) based on the [Fields](../fields/overview) that you define, and automatically generates the [Local API](../local-api/overview), [REST API](../rest-api/overview), and [GraphQL API](../graphql/overview) to manage your Documents.
+Globals are in many ways similar to [Collections](../configuration/collections), except they correspond to only a single Document. You can define as many Globals as your application needs. Each Global Document is stored in the [Database](../database/overview) based on the [Fields](../fields/overview) that you define, and automatically generates a [Local API](../local-api/overview), [REST API](../rest-api/overview), and [GraphQL API](../graphql/overview) used to manage your Documents.
 
 Globals are the primary way to structure singletons in Payload, such as a header navigation, site-wide banner alerts, or app-wide localized strings. Each Global can have its own unique [Access Control](../access-control/overview), [Hooks](../hooks/overview), [Admin Options](#admin-options), and more.
 
@@ -101,18 +101,10 @@ You can customize the way that the [Admin Panel](../admin/overview) behaves on a
 
 ## TypeScript
 
-You can import Global types as follows:
+You can import types from Payload to help make writing your Global configs easier and type-safe. There are two main types that represent the Global Config, `GlobalConfig` and `SanitizeGlobalConfig`.
+
+The `GlobalConfig` type represents a raw Global Config in its full form, where only the bare minimum properties are marked as required. The `SanitizedGlobalConfig` type represents a Global Config after it has been fully sanitized. Generally, this is only used internally by Payload.
 
 ```ts
-import { GlobalConfig } from 'payload'
+import { GlobalConfig, SanitizedGlobalConfig } from 'payload'
-
-// This is the type used for incoming Global configs.
-// Only the bare minimum properties are marked as required.
-```
-
-```ts
-import { SanitizedGlobalConfig } from 'payload'
-
-// This is the type used after an incoming Global config is fully sanitized.
-// Generally, this is only used internally by Payload.
 ```

docs/configuration/overview.mdx

@@ -58,7 +58,7 @@ export default buildConfig({
 ```
 
 <Banner type="success">
-  <strong>Reminder:</strong>
+  <strong>Note:</strong>
   For a more complex example, see the [Public Demo](https://github.com/payloadcms/public-demo) source code on GitHub, or the [Templates](https://github.com/payloadcms/payload/tree/main/templates) and [Examples](https://github.com/payloadcms/payload/tree/main/examples) directories in the Payload repository.
 </Banner>
 
@@ -100,14 +100,14 @@ The following options are available:
 _\* An asterisk denotes that a property is required._
 
 <Banner type="warning">
-  <strong>Reminder:</strong>
+  <strong>Note:</strong>
   Some properties are removed from the client-side bundle. [More details](../admin/components#accessing-the-payload-config).
 </Banner>
 
 
-### TypeScript
+### Typescript Config
 
-Payload exposes a variety of TypeScript settings that you can leverage. These settings are used to auto-generate TypeScript interfaces for your Collections and Globals, and to ensure that Payload uses your [Generated Types](../typescript/overview) for all Local API methods.
+Payload exposes a variety of TypeScript settings that you can leverage. These settings are used to auto-generate TypeScript interfaces for your [Collections](../configuration/collections) and [Globals](../configuration/globals), and to ensure that Payload uses your [Generated Types](../typescript/overview) for all [Local API](../local-api/overview) methods.
 
 To customize the TypeScript settings, use the `typescript` property in your Payload Config:
 
@@ -130,39 +130,59 @@ The following options are available:
 | **`declare`**     | By default, Payload adds a `declare` block to your generated types, which makes sure that Payload uses your generated types for all Local API methods. Opt out by setting `typescript.declare: false`. |
 | **`outputFile`**  | Control the output path and filename of Payload's auto-generated types by defining the `typescript.outputFile` property to a full, absolute path. |
 
-#### Importing Payload Config types
-
-You can import config types as follows:
-
-```ts
-import { Config } from 'payload'
-
-// This is the type used for an incoming Payload Config.
-// Only the bare minimum properties are marked as required.
-```
-
-```ts
-import { SanitizedConfig } from 'payload'
-
-// This is the type used after an incoming Payload Config is fully sanitized.
-// Generally, this is only used internally by Payload.
-```
-
 ## Config Location
 
-For Payload command-line scripts, we need to be able to locate your Payload Config. We'll check a variety of locations for the presence of `payload.config.ts` by default, including the root current working directory, your `tsconfig`'s `rootDir`, and your `tsconfig`'s `outDir`.
+For Payload command-line scripts, we need to be able to locate your Payload Config. We'll check a variety of locations for the presence of `payload.config.ts` by default, including:
 
-In development mode, if the configuration file is not found at the root, Payload will attempt to read your `tsconfig.json`, and search in the directory specified in `compilerOptions.rootDir` (typically "src").
+1. The root current working directory
+1. The `compilerOptions` in your `tsconfig`*
+1. The `dist` directory*
 
-In production mode, Payload will first attempt to find the config file in the output directory specified in `compilerOptions.outDir` of your `tsconfig.json`, then fallback to the source directory (`compilerOptions.rootDir`), and finally will check the 'dist' directory.
+_\* Config location detection is different between development and production environments. See below for more details._
 
-Please ensure your `tsconfig.json` is properly configured if you want Payload to accurately auto-detect your configuration file location. If `tsconfig.json` does not exist or doesn't specify `rootDir` or `outDir`, Payload will default to the current working directory.
+<Banner type="warning">
+  <strong>Important:</strong>
+  Ensure your `tsconfig.json` is properly configured for Payload to auto-detect your config location. If if does not exist, or does not specify the proper `compilerOptions`, Payload will default to the current working directory.
+</Banner>
+
+**Development Mode**
+
+In development mode, if the configuration file is not found at the root, Payload will attempt to read your `tsconfig.json`, and attempt to find the config file specified in the `rootDir`:
+
+```json
+{
+  // ...
+  // highlight-start
+  "compilerOptions": {
+    "rootDir": "src"
+  }
+  // highlight-end
+}
+```
+
+**Production Mode**
+
+In production mode, Payload will first attempt to find the config file in the `outDir` of your `tsconfig.json`, and if not found, will fallback to the `rootDor` directory:
+
+```json
+{
+  // ...
+  // highlight-start
+  "compilerOptions": {
+    "outDir": "dist",
+    "rootDir": "src"
+  }
+  // highlight-end
+}
+```
+
+If none was in either location, Payload will finally check the `dist` directory.
 
 ### Customizing the Config Location
 
-In addition to the above automated detection, you can specify your own location for the Payload Config. This is done by using the environment variable `PAYLOAD_CONFIG_PATH`. The path you provide via this environment variable can either be absolute or relative to your current working directory. This can be useful in situations where your Payload Config is not in a standard location, or you wish to switch between multiple configurations.
+In addition to the above automated detection, you can specify your own location for the Payload Config. This can be useful in situations where your config is not in a standard location, or you wish to switch between multiple configurations. To do this, Payload exposes an [Environment Variable](..environment-variables) to bypass all automatic config detection.
 
-**Example in package.json:**
+To use a custom config location, set the `PAYLOAD_CONFIG_PATH` environment variable:
 
 ```json
 {
@@ -172,7 +192,10 @@ In addition to the above automated detection, you can specify your own location
 }
 ```
 
-When `PAYLOAD_CONFIG_PATH` is set, Payload will use this path to load the configuration, bypassing all automated detection.
+<Banner type="info">
+  <strong>Tip:</strong>
+  `PAYLOAD_CONFIG_PATH` can be either an absolute path, or path relative to your current working directory.
+</Banner>
 
 ## Telemetry
 
@@ -186,8 +209,8 @@ Cross-origin resource sharing (CORS) can be configured with either a whitelist a
 
 | Option    | Description                                                                                                                                                                        |
 | --------- | --------------------------------------------------------------------------------------------------------------------------------------- |
-| `origins` | Either a whitelist array of URLS to allow CORS requests from, or a wildcard string (`'*'`) to accept incoming requests from any domain. |
+| **`origins`** | Either a whitelist array of URLS to allow CORS requests from, or a wildcard string (`'*'`) to accept incoming requests from any domain. |
-| `headers  | A list of allowed headers that will be appended in `Access-Control-Allow-Headers`. |
+| **`headers`**  | A list of allowed headers that will be appended in `Access-Control-Allow-Headers`. |
 
 Here's an example showing how to allow incoming requests from any domain:
 
@@ -196,7 +219,7 @@ import { buildConfig } from 'payload/config'
 
 export default buildConfig({
   // ...
-  cors: '*'
+  cors: '*' // highlight-line
 })
 ```
 
@@ -207,9 +230,21 @@ import { buildConfig } from 'payload/config'
 
 export default buildConfig({
   // ...
+  // highlight-start
   cors: {
     origins: ['http://localhost:3000']
     headers: ['x-custom-header']
   }
+  // highlight-end
 })
 ```
+
+## TypeScript
+
+You can import types from Payload to help make writing your config easier and type-safe. There are two main types that represent the Payload Config, `Config` and `SanitizedConfig`.
+
+The `Config` type represents a raw Payload Config in its full form. Only the bare minimum properties are marked as required. The `SanitizedConfig` type represents a Payload Config after it has been fully sanitized. Generally, this is only used internally by Payload.
+
+```ts
+import { Config, SanitizedConfig } from 'payload'
+```

docs/getting-started/concepts.mdx

@@ -42,7 +42,7 @@ Payload dynamically generates a beautiful, fully type-safe interface to manage y
 
 ## Plugins
 
-Plugins allow for developers to easily inject custom—sometimes complex—functionality into Payload apps from a very small touch-point. [More details](../plugins/overview).
+Plugins allow for developers to easily inject custom—sometimes complex—functionality into Payload apps from a very small touch-point. This is especially useful in sharing your work across multiple projects or with the greater Payload community. [More details](../plugins/overview).
 
 ## Retrieving Data
 
@@ -102,7 +102,7 @@ const MyServerComponent: React.FC = () => {
 
 By default, the Payload [REST API](../rest-api/overview) is mounted automatically for you at the `/api` path of your app.
 
-For example, if you have a [Collection](../configuration/collections) called `pages`:
+For example, if you have a Collection called `pages`:
 
 ```ts
 fetch('https://localhost:3000/api/pages') // highlight-line
@@ -127,10 +127,6 @@ You can use any GraphQL client with Payload's GraphQL endpoint. Here are a few p
   For more information about the GraphQL API, [click here](../graphql/overview).
 </Banner>
 
-### Depth
-
-Documents can be related to other Documents through a concept called "relationships". When you query a Document, you can specify these relationships are populated. [More details](../queries/depth).
-
 ## Package Structure
 
 Payload is abstracted into a set of dedicated packages to keep the core `payload` package as lightweight as possible. This allows you to only install the parts of Payload based on your unique project requirements.
@@ -174,4 +170,7 @@ You can choose which Database Adapter you'd like to use for your project, and no
 
 Payload's Rich Text functionality is abstracted into separate packages and if you want to enable Rich Text in your project, you'll need to install one of these packages. We recommend Lexical for all new projects, and this is where Payload will focus its efforts on from this point, but Slate is still supported if you have already built with it.
 
-Rich Text is entirely optional and you may not need it for your project.
+<Banner type="info">
+  <strong>Note:</strong>
+  Rich Text is entirely optional and you may not need it for your project.
+</Banner>

docs/getting-started/installation.mdx

@@ -63,7 +63,7 @@ To install a Database Adapter, you can run **one** of the following commands:
     ```
 
 <Banner type="success">
-  <strong>Reminder:</strong>
+  <strong>Note:</strong>
   New [Database Adapters](/docs/database/overview) are becoming available every day. Check the docs for the most up-to-date list of what's available.
 </Banner>
 

docs/getting-started/what-is-payload.mdx

@@ -15,7 +15,7 @@ keywords: documentation, getting started, guide, Content Management System, cms,
 
 - A full Admin Panel using React server / client components, matching the shape of your data and completely extensible with your own React components
 - Automatic database schema, including direct DB access and ownership, with migrations, transactions, proper indexing, and more
-- Instant REST, GraphQL, and straight-to-DB Node APIs
+- Instant REST, GraphQL, and straight-to-DB Node.js APIs
 - Authentication which can be used in your own apps
 - A deeply customizable access control pattern
 - File storage and image management tools like cropping / focal point selection
@@ -30,12 +30,14 @@ No matter what you're building, Payload will give you backend superpowers. It ca
 
 It's fully open source with an MIT license and you can self-host anywhere that you can run a Node app. You can also deploy serverless to hosts like Vercel, right inside your existing Next.js app folder.
 
+### Code-first and version controlled
+
+In Payload, there are no "click ops" - as in clicking around in an Admin Panel to define your schema. In Payload, everything is done the right way—code-first and version controlled like a proper backend. But once developers define how Payload should work, non-technical users can independently make use of its Admin Panel to manage whatever they need to without having to know code whatsoever.
+
 ### Fully extensible
 
 Even in spite of how much you get out of the box, you still have full control over every aspect of your app - be it database, admin UI, or anything else. Every part of Payload has been designed to be extensible and customizable with modern TypeScript / React. And you'll fully understand the code that you write.
 
-In Payload, there are no "click ops" - as in clicking around in an Admin Panel to define your schema. In Payload, everything is done the right way—code-first and version controlled like a proper backend. But once developers define how Payload should work, non-technical users can independently make use of its Admin Panel to manage whatever they need to without having to know code whatsoever.
-
 ## Use Cases
 
 Payload started as a headless Content Management System (CMS), but since, we've seen our community leverage Payload in ways far outside of simply managing pages and blog posts. It's grown into a full-stack TypeScript app framework.

docs/hooks/collections.mdx

@@ -89,9 +89,9 @@ Available Collection operations include `create`, `read`, `update`, `delete`, `l
 import type { CollectionBeforeOperationHook } from 'payload'
 
 const beforeOperationHook: CollectionBeforeOperationHook = async ({
-  args, // original arguments passed into the operation
+  args,
-  operation, // name of the operation
+  operation,
-  req, // full Request object
+  req,
 }) => {
   return args // return modified operation arguments as necessary
 }

docs/hooks/context.mdx

@@ -8,7 +8,7 @@ keywords: hooks, context, payload context, payloadcontext, data, extra data, sha
 
 The `context` object is used to share data across different Hooks. This persists throughout the entire lifecycle of a request and is available within every Hook. By setting properties to `req.context`, you can effectively logic across multiple Hooks.
 
-## When to use Context
+## When To Use Context
 
 Context gives you a way forward on otherwise difficult problems such as:
 
@@ -17,11 +17,11 @@ Context gives you a way forward on otherwise difficult problems such as:
 3. **Passing data to local API**: Setting values on the `req.context` and pass it to `payload.create()` you can provide additional data to hooks without adding extraneous fields.
 4. **Passing data between hooks and middleware or custom endpoints**: Hooks could set context across multiple collections and then be used in a final `postMiddleware`.
 
-## How to Use Context
+## How To Use Context
 
 Let's see examples on how context can be used in the first two scenarios mentioned above:
 
-### Passing data between hooks
+### Passing Data Between Hooks
 
 To pass data between hooks, you can assign values to context in an earlier hook in the lifecycle of a request and expect it the context in a later hook.
 
@@ -58,7 +58,7 @@ const Customer: CollectionConfig = {
 }
 ```
 
-### Preventing infinite loops
+### Preventing Infinite Loops
 
 Let's say you have an `afterChange` hook, and you want to do a calculation inside the hook (as the document ID needed for the calculation is available in the `afterChange` hook, but not in the `beforeChange` hook). Once that's done, you want to update the document with the result of the calculation.
 

docs/hooks/globals.mdx

@@ -58,11 +58,11 @@ Runs before the `update` operation. This hook allows you to add or format data b
 import type { GlobalBeforeValidateHook } from 'payload'
 
 const beforeValidateHook: GlobalBeforeValidateHook = async ({
-  data, // incoming data to update or create with
+  data,
-  req, // full Request object
+  req,
-  originalDoc, // original document
+  originalDoc,
 }) => {
-  return data // Return data to update the document with
+  return data
 }
 ```
 
@@ -84,11 +84,11 @@ Immediately following validation, `beforeChange` hooks will run within the `upda
 import type { GlobalBeforeChangeHook } from 'payload'
 
 const beforeChangeHook: GlobalBeforeChangeHook = async ({
-  data, // incoming data to update or create with
+  data,
-  req, // full Request object
+  req,
-  originalDoc, // original document
+  originalDoc,
 }) => {
-  return data // Return data to update the document with
+  return data
 }
 ```
 
@@ -110,9 +110,9 @@ After a global is updated, the `afterChange` hook runs. Use this hook to purge c
 import type { GlobalAfterChangeHook } from 'payload'
 
 const afterChangeHook: GlobalAfterChangeHook = async ({
-  doc, // full document data
+  doc,
-  previousDoc, // document data before updating the collection
+  previousDoc,
-  req, // full Request object
+  req,
 }) => {
   return data
 }
@@ -136,8 +136,8 @@ Runs before `findOne` global operation is transformed for output by `afterRead`.
 import type { GlobalBeforeReadHook } from 'payload'
 
 const beforeReadHook: GlobalBeforeReadHook = async ({
-  doc, // full document data
+  doc,
-  req, // full Request object
+  req,
 }) => {...}
 ```
 
@@ -158,9 +158,9 @@ Runs as the last step before a global is returned. Flattens locales, hides prote
 import type { GlobalAfterReadHook } from 'payload'
 
 const afterReadHook: GlobalAfterReadHook = async ({
-  doc, // full document data
+  doc,
-  req, // full Request object
+  req,
-  findMany, // boolean to denote if this hook is running against finding one, or finding many (useful in versions)
+  findMany,
 }) => {...}
 ```
 

docs/hooks/overview.mdx

@@ -2,13 +2,13 @@
 title: Hooks Overview
 label: Overview
 order: 10
-desc: Hooks allow you to add your own logic to Payload, including integrating with third-party APIs, adding auto-generated data, or modifing Payload's base functionality.
+desc: Hooks allow you to add your own logic to Payload, including integrating with third-party APIs, adding auto-generated data, or modifying Payload's base functionality.
 keywords: hooks, overview, config, configuration, documentation, Content Management System, cms, headless, javascript, node, react, nextjs
 ---
 
-Hooks allow you to execute your own side effects during specific events of the Document lifecycle. With Hooks, you can transform Payload from a traditional CMS into a fully-fledged application framework. They allow you to perform business logic, third-party integrations, etc. during precise moments within the data lifecycle.
+Hooks allow you to execute your own side effects during specific events of the Document lifecycle. They allow you to do things like mutate data, perform business logic, integrate with third-parties, or anything else, all during precise moments within your application.
 
-There are many use cases for Hooks, including:
+With Hooks, you can transform Payload from a traditional CMS into a fully-fledged application framework. There are many use cases for Hooks, including:
 
 - Modify data before it is read or updated
 - Encrypt and decrypt sensitive data

docs/live-preview/overview.mdx

@@ -8,7 +8,7 @@ keywords: live preview, preview, live, iframe, iframe preview, visual editing, d
 
 With Live Preview you can render your front-end application directly within the [Admin Panel](../admin/overview). As you type, your changes take effect in real-time. No need to save a draft or publish your changes. This works in both [Server-side](./server) as well as [Client-side](./client) environments.
 
-Live Preview works by rendering an iframe on the page that loads your front-end application. The Admin Panel communicates with your app through [`window.postMessage`](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) events. These events are emitted every time a change is made to the document. Your app then listens for these events and re-renders itself with the data it receives.
+Live Preview works by rendering an iframe on the page that loads your front-end application. The Admin Panel communicates with your app through [`window.postMessage`](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) events. These events are emitted every time a change is made to the Document. Your app then listens for these events and re-renders itself with the data it receives.
 
 To add Live Preview, use the `admin.livePreview` property in your [Payload Config](../configuration/overview):
 
@@ -28,12 +28,16 @@ const config = buildConfig({
   }
 })
 ```
+<Banner type="warning">
+  <strong>Reminder:</strong>
+  Alternatively, you can define the <code>admin.livePreview</code> property on individual [Collection Admin Configs](../admin/collections) and [Global Admin Configs](../admin/globals). Settings defined here will be merged into the top-level as overrides.
+</Banner>
 
 {/* IMAGE OF LIVE PREVIEW HERE */}
 
 ## Options
 
-Setting up Live Preview is easy. This can be done either globally through the [Root Config](../configuration/overview), or on individual [Collection](../configuration/collections) and [Global](../configuration/globals) configs. Once configured, a new "Live Preview" tab will appear at the top of enabled documents. Navigating to this tab opens the preview window and loads your front-end application.
+Setting up Live Preview is easy. This can be done either globally through the [Root Admin Config](../admin/overview), or on individual [Collection Admin Configs](../admin/collections) and [Global Admin Configs](../admin/globals). Once configured, a new "Live Preview" tab will appear at the top of enabled Documents. Navigating to this tab opens the preview window and loads your front-end application.
 
 The following options are available:
 
@@ -46,11 +50,6 @@ The following options are available:
 
 _\* An asterisk denotes that a property is required._
 
-<Banner type="warning">
-  <strong>Reminder:</strong>
-  Alternatively, you can define the <code>admin.livePreview</code> property on individual [Collection](../configuration/collections) and [Global](../configuration/globals) configs. Settings defined here will be merged into the top-level as overrides.
-</Banner>
-
 ### URL
 
 The `url` property is a string that points to your front-end application. This value is used as the `src` attribute of the iframe rendering your front-end. Once loaded, the Admin Panel will communicate directly with your app through `window.postMessage` events.
@@ -74,7 +73,7 @@ const config = buildConfig({
 
 #### Dynamic URLs
 
-You can also pass a function in order to dynamically format URLs. This is useful for multi-tenant applications, localization, or any other scenario where the URL needs to be generated based on the document being edited.
+You can also pass a function in order to dynamically format URLs. This is useful for multi-tenant applications, localization, or any other scenario where the URL needs to be generated based on the Document being edited.
 
 To set dynamic URLs, set the `admin.livePreview.url` property in your [Payload Config](../configuration/overview) to a function:
 
@@ -105,8 +104,8 @@ The following arguments are provided to the `url` function:
 
 | Path               | Description                                                                                                       |
 | ------------------ | ----------------------------------------------------------------------------------------------------------------- |
-| **`data`**         | The data of the document being edited. This includes changes that have not yet been saved.                        |
+| **`data`**         | The data of the Document being edited. This includes changes that have not yet been saved.                        |
-| **`documentInfo`** | Information about the document being edited like collection slug. [More details](../admin/hooks#usedocumentinfo). |
+| **`documentInfo`** | Information about the Document being edited like collection slug. [More details](../admin/hooks#usedocumentinfo). |
 | **`locale`**       | The locale currently being edited (if applicable). [More details](../configuration/localization).                 |
 
 ### Breakpoints

docs/plugins/overview.mdx

@@ -6,7 +6,7 @@ desc: Plugins provide a great way to modularize Payload functionalities into eas
 keywords: plugins, config, configuration, extensions, custom, documentation, Content Management System, cms, headless, javascript, node, react, nextjs
 ---
 
-Payload Plugins take full advantage of the modularity of the [Payload Config](../configuration/overview), allowing developers to extend Payload's core functionality in a precise and granular way. This pattern allows developers to easily inject custom—sometimes complex—functionality into Payload apps from a very small touch-point.
+Payload Plugins take full advantage of the modularity of the [Payload Config](../configuration/overview), allowing developers developers to easily inject custom—sometimes complex—functionality into Payload apps from a very small touch-point. This is especially useful is sharing your work across multiple projects or with the greater Payload community.
 
 There are many [Official Plugins](#official-plugins) available that solve for some of the most common uses cases, such as the [Form Builder Plugin](./seo) or [SEO Plugin](./seo). There are also [Community Plugins](#community-plugins) available, maintained entirely by contributing members. To extend Payload's functionality in some other way, you can easily [build your own plugin](./build-your-own).
 

docs/queries/overview.mdx

@@ -6,7 +6,7 @@ desc: Payload provides a querying language through all APIs, allowing you to fil
 keywords: query, documents, overview, documentation, Content Management System, cms, headless, javascript, node, react, nextjs
 ---
 
-In Payload, "querying" means filtering or searching through Documents within a [Collection](../configuration/collections). The querying language in Payload is designed to be simple and powerful, allowing you to filter documents with extreme precision.
+In Payload, "querying" means filtering or searching through Documents within a [Collection](../configuration/collections). The querying language in Payload is designed to be simple and powerful, allowing you to filter Documents with extreme precision through an intuitive and standardized structure.
 
 Payload provides three common APIs for querying your data: