tabshift/payloadcms
1
0
Fork 0
Code Issues Pull Requests Actions 3 Packages Projects Releases Wiki Activity

docs: payload proper nouns (#11792)

Browse Source 
Uses proper nouns in the docs where necessary for "Payload" and "Local
API".
This commit is contained in:
Jacob Fletcher
2025-03-21 09:04:11 -04:00
committed by GitHub
parent 4081953c18
commit 5f7202bbb8
17 changed files with 25 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/admin/customizing-css.mdx
View File

@@ -45,7 +45,7 @@ To override existing styles in a way that the previous rules of specificity woul
```css
@layer payload-default {
// my styles within the payload specificity
// my styles within the Payload specificity
}
```

4
docs/authentication/operations.mdx
View File

@@ -353,7 +353,7 @@ const token = await payload.forgotPassword({
data: {
email: 'dev@payloadcms.com',
},
disableEmail: false, // you can disable the auto-generation of email via local API
disableEmail: false, // you can disable the auto-generation of email via Local API
})
```
@@ -370,7 +370,7 @@ const token = await payload.forgotPassword({
<Banner type="success">
**Tip:**
You can stop the reset-password email from being sent via using the local API. This is helpful if
You can stop the reset-password email from being sent via using the Local API. This is helpful if
you need to create user accounts programmatically, but not set their password for them. This
effectively generates a reset password token which you can then use to send to a page you create,
allowing a user to "complete" their account by setting their password. In the background, you'd

2
docs/configuration/localization.mdx
View File

@@ -107,7 +107,7 @@ _\* An asterisk denotes that a property is required._
In some projects you may want to filter the available locales shown in the admin UI selector. You can do this by providing a `filterAvailableLocales` function in your Payload Config. This is called on the server side and is passed the array of locales. This means that you can determine what locales are visible in the localizer selection menu at the top of the admin panel. You could do this per user, or implement a function that scopes these to tenants and more. Here is an example using request headers in a multi-tenant application:
```ts
// ... rest of payload config
// ... rest of Payload config
localization: {
defaultLocale: 'en',
locales: ['en', 'es'],

2
docs/database/migrations.mdx
View File

@@ -53,7 +53,7 @@ export async function down({ payload, req }: MigrateDownArgs): Promise<void> {
## Using Transactions
When migrations are run, each migration is performed in a new [transaction](/docs/database/transactions) for you. All
you need to do is pass the `req` object to any [local API](/docs/local-api/overview) or direct database calls, such as
you need to do is pass the `req` object to any [Local API](/docs/local-api/overview) or direct database calls, such as
`payload.db.updateMany()`, to make database changes inside the transaction. Assuming no errors were thrown, the transaction is committed
after your `up` or `down` function runs. If the migration errors at any point or fails to commit, it is caught and the
transaction gets aborted. This way no change is made to the database if the migration fails.

8
docs/database/transactions.mdx
View File

@@ -69,7 +69,7 @@ const afterChange: CollectionAfterChangeHook = async ({ req }) => {
## Direct Transaction Access
When writing your own scripts or custom endpoints, you may wish to have direct control over transactions. This is useful for interacting with your database outside of Payload's local API.
When writing your own scripts or custom endpoints, you may wish to have direct control over transactions. This is useful for interacting with your database outside of Payload's Local API.
The following functions can be used for managing transactions:
@@ -77,7 +77,7 @@ The following functions can be used for managing transactions:
- `payload.db.commitTransaction` - Takes the identifier for the transaction, finalizes any changes.
- `payload.db.rollbackTransaction` - Takes the identifier for the transaction, discards any changes.
Payload uses the `req` object to pass the transaction ID through to the database adapter. If you are not using the `req` object, you can make a new object to pass the transaction ID directly to database adapter methods and local API calls.
Payload uses the `req` object to pass the transaction ID through to the database adapter. If you are not using the `req` object, you can make a new object to pass the transaction ID directly to database adapter methods and Local API calls.
Example:
```ts
@@ -91,7 +91,7 @@ const standalonePayloadScript = async () => {
const transactionID = await payload.db.beginTransaction()
try {
// Make an update using the local API
// Make an update using the Local API
await payload.update({
collection: 'posts',
data: {
@@ -123,7 +123,7 @@ standalonePayloadScript()
If you wish to disable transactions entirely, you can do so by passing `false` as the `transactionOptions` in your database adapter configuration. All the official Payload database adapters support this option.
In addition to allowing database transactions to be disabled at the adapter level. You can prevent Payload from using a transaction in direct calls to the local API by adding `disableTransaction: true` to the args. For example:
In addition to allowing database transactions to be disabled at the adapter level. You can prevent Payload from using a transaction in direct calls to the Local API by adding `disableTransaction: true` to the args. For example:
```ts
await payload.update({

6
docs/fields/join.mdx
View File

@@ -236,11 +236,11 @@ The following query options are supported:
| **`sort`** | A string used to order related results |
| **`count`** | Whether include the count of related documents or not. Not included by default |
These can be applied to the local API, GraphQL, and REST API.
These can be applied to the Local API, GraphQL, and REST API.
### Local API
By adding `joins` to the local API you can customize the request for each join field by the `name` of the field.
By adding `joins` to the Local API you can customize the request for each join field by the `name` of the field.
```js
const result = await payload.find({
@@ -287,7 +287,7 @@ const result = await payload.find({
### Rest API
The rest API supports the same query options as the local API. You can use the `joins` query parameter to customize the
The REST API supports the same query options as the Local API. You can use the `joins` query parameter to customize the
request for each join field by the `name` of the field. For example, an API call to get a document with the related
posts limited to 5 and sorted by title:

2
docs/graphql/extending.mdx
View File

@@ -70,7 +70,7 @@ export default buildConfig({
## Resolver function
In your resolver, make sure you set `depth: 0` if you're returning data directly from the local API so that GraphQL can correctly resolve queries to nested values such as relationship data.
In your resolver, make sure you set `depth: 0` if you're returning data directly from the Local API so that GraphQL can correctly resolve queries to nested values such as relationship data.
Your function will receive four arguments you can make use of:

2
docs/graphql/graphql-schema.mdx
View File

@@ -60,7 +60,7 @@ type Collection1 {
}
```
The above example outputs all your definitions to a file relative from your payload config as `./graphql/schema.graphql`. By default, the file will be output to your current working directory as `schema.graphql`.
The above example outputs all your definitions to a file relative from your Payload config as `./graphql/schema.graphql`. By default, the file will be output to your current working directory as `schema.graphql`.
### Adding an npm script

2
docs/hooks/context.mdx
View File

@@ -14,7 +14,7 @@ Context gives you a way forward on otherwise difficult problems such as:
1. **Passing data between Hooks**: Needing data in multiple Hooks from a 3rd party API, it could be retrieved and used in `beforeChange` and later used again in an `afterChange` hook without having to fetch it twice.
2. **Preventing infinite loops**: Calling `payload.update()` on the same document that triggered an `afterChange` hook will create an infinite loop, control the flow by assigning a no-op condition to context
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.
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

2
docs/jobs-queue/queues.mdx
View File

@@ -39,7 +39,7 @@ export default buildConfig({
tasks: [
// your tasks here
],
// autoRun can optionally be a function that receives payload as an argument
// autoRun can optionally be a function that receives `payload` as an argument
autoRun: [
{
cron: '0 * * * *', // every hour at minute 0

6
docs/jobs-queue/tasks.mdx
View File

@@ -15,7 +15,7 @@ You can register Tasks on the Payload config, and then create [Jobs](/docs/jobs-
Payload Tasks can be configured to automatically retried if they fail, which makes them valuable for "durable" workflows like AI applications where LLMs can return non-deterministic results, and might need to be retried.
Tasks can either be defined within the `jobs.tasks` array in your payload config, or they can be defined inline within a workflow.
Tasks can either be defined within the `jobs.tasks` array in your Payload config, or they can be defined inline within a workflow.
### Defining tasks in the config
@@ -25,9 +25,9 @@ Simply add a task to the `jobs.tasks` array in your Payload config. A task consi
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `slug` | Define a slug-based name for this job. This slug needs to be unique among both tasks and workflows. |
| `handler` | The function that should be responsible for running the job. You can either pass a string-based path to the job function file, or the job function itself. If you are using large dependencies within your job, you might prefer to pass the string path because that will avoid bundling large dependencies in your Next.js app. Passing a string path is an advanced feature that may require a sophisticated build pipeline in order to work. |
| `inputSchema` | Define the input field schema - payload will generate a type for this schema. |
| `inputSchema` | Define the input field schema - Payload will generate a type for this schema. |
| `interfaceName` | You can use interfaceName to change the name of the interface that is generated for this task. By default, this is "Task" + the capitalized task slug. |
| `outputSchema` | Define the output field schema - payload will generate a type for this schema. |
| `outputSchema` | Define the output field schema - Payload will generate a type for this schema. |
| `label` | Define a human-friendly label for this task. |
| `onFail` | Function to be executed if the task fails. |
| `onSuccess` | Function to be executed if the task succeeds. |

2
docs/jobs-queue/workflows.mdx
View File

@@ -27,7 +27,7 @@ To define a JS-based workflow, simply add a workflow to the `jobs.workflows` arr
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `slug` | Define a slug-based name for this workflow. This slug needs to be unique among both tasks and workflows. |
| `handler` | The function that should be responsible for running the workflow. You can either pass a string-based path to the workflow function file, or workflow job function itself. If you are using large dependencies within your workflow, you might prefer to pass the string path because that will avoid bundling large dependencies in your Next.js app. Passing a string path is an advanced feature that may require a sophisticated build pipeline in order to work. |
| `inputSchema` | Define the input field schema - payload will generate a type for this schema. |
| `inputSchema` | Define the input field schema - Payload will generate a type for this schema. |
| `interfaceName` | You can use interfaceName to change the name of the interface that is generated for this workflow. By default, this is "Workflow" + the capitalized workflow slug. |
| `label` | Define a human-friendly label for this workflow. |
| `queue` | Optionally, define the queue name that this workflow should be tied to. Defaults to "default". |

2
docs/local-api/outside-nextjs.mdx
View File

@@ -76,7 +76,7 @@ Note: Install @swc-node/register in your project first. While swc mode is faster
#### Option 2: use an alternative runtime like bun
While we do not guarantee support for alternative runtimes, you are free to use them and disable payloads own transpilation by appending the `--disable-transpile` flag to the `payload` command:
While we do not guarantee support for alternative runtimes, you are free to use them and disable Payload's own transpilation by appending the `--disable-transpile` flag to the `payload` command:
```sh
bunx --bun payload run src/seed.ts --disable-transpile

2
docs/local-api/overview.mdx
View File

@@ -320,7 +320,7 @@ available:
// you'll also have to await headers inside your function, or component, like so:
// const headers = await nextHeaders()
// If you're using payload outside of Next.js, you'll have to provide headers accordingly.
// If you're using Payload outside of Next.js, you'll have to provide headers accordingly.
// result will be formatted as follows:
// {

2
docs/migration-guide/overview.mdx
View File

@@ -42,7 +42,7 @@ For more details, see the [Documentation](https://payloadcms.com/docs/getting-st
1. **Install new dependencies of Payload, Next.js and React**:
Refer to the package.json file made in the create-payload-app, including peerDependencies, devDependencies, and dependencies. The core package and plugins require all versions to be synced. Previously, on 2.x it was possible to be running the latest version of payload 2.x with an older version of db-mongodb for example. This is no longer the case.
Refer to the package.json file made in the create-payload-app, including peerDependencies, devDependencies, and dependencies. The core package and plugins require all versions to be synced. Previously, on 2.x it was possible to be running the latest version of Payload 2.x with an older version of db-mongodb for example. This is no longer the case.
```bash
pnpm i next react react-dom payload @payloadcms/ui @payloadcms/next

2
docs/plugins/form-builder.mdx
View File

@@ -423,7 +423,7 @@ formBuilderPlugin({
## Email
This plugin relies on the [email configuration](../email/overview) defined in your payload configuration. It will read from your config and attempt to send your emails using the credentials provided.
This plugin relies on the [email configuration](../email/overview) defined in your Payload configuration. It will read from your config and attempt to send your emails using the credentials provided.
### Email formatting

2
docs/typescript/generating-types.mdx
View File

@@ -212,7 +212,7 @@ appending the field type to the end, i.e. `MetaGroup` or similar.
## Using your types
Now that your types have been generated, payloads local API will now be typed. It is common for users to want to use this in their frontend code, we recommend generating them with Payload and then copying the file over to your frontend codebase. This is the simplest way to get your types into your frontend codebase.
Now that your types have been generated, Payload's Local API will now be typed. It is common for users to want to use this in their frontend code, we recommend generating them with Payload and then copying the file over to your frontend codebase. This is the simplest way to get your types into your frontend codebase.
### Adding an npm script