docs: fix typos, duplicated words, wrong property names etc. (#12480)
### What? fix typos in doc ### Why? because they are typos ### How? checked manually with the help of AI
This commit is contained in:
@@ -39,7 +39,7 @@ const GlobalWithAccessControl: GlobalConfig = {
|
|||||||
update: ({ req: { user } }) => {...},
|
update: ({ req: { user } }) => {...},
|
||||||
|
|
||||||
// Version-enabled Globals only
|
// Version-enabled Globals only
|
||||||
readVersion: () => {...},
|
readVersions: () => {...},
|
||||||
},
|
},
|
||||||
// highlight-end
|
// highlight-end
|
||||||
}
|
}
|
||||||
@@ -64,7 +64,7 @@ If a Global supports [Versions](../versions/overview), the following additional
|
|||||||
|
|
||||||
Returns a boolean result or optionally a [query constraint](../queries/overview) which limits who can read this global based on its current properties.
|
Returns a boolean result or optionally a [query constraint](../queries/overview) which limits who can read this global based on its current properties.
|
||||||
|
|
||||||
To add read Access Control to a [Global](../configuration/globals), use the `read` property in the [Global Config](../configuration/globals):
|
To add read Access Control to a [Global](../configuration/globals), use the `access` property in the [Global Config](../configuration/globals):
|
||||||
|
|
||||||
```ts
|
```ts
|
||||||
import { GlobalConfig } from 'payload'
|
import { GlobalConfig } from 'payload'
|
||||||
@@ -72,7 +72,7 @@ import { GlobalConfig } from 'payload'
|
|||||||
const Header: GlobalConfig = {
|
const Header: GlobalConfig = {
|
||||||
// ...
|
// ...
|
||||||
// highlight-start
|
// highlight-start
|
||||||
read: {
|
access: {
|
||||||
read: ({ req: { user } }) => {
|
read: ({ req: { user } }) => {
|
||||||
return Boolean(user)
|
return Boolean(user)
|
||||||
},
|
},
|
||||||
|
|||||||
@@ -65,7 +65,7 @@ preview: (doc, { req }) => `${req.protocol}//${req.host}/${doc.slug}` // highlig
|
|||||||
|
|
||||||
The Preview feature can be used to achieve "Draft Preview". After clicking the preview button from the Admin Panel, you can enter into "draft mode" within your front-end application. This will allow you to adjust your page queries to include the `draft: true` param. When this param is present on the request, Payload will send back a draft document as opposed to a published one based on the document's `_status` field.
|
The Preview feature can be used to achieve "Draft Preview". After clicking the preview button from the Admin Panel, you can enter into "draft mode" within your front-end application. This will allow you to adjust your page queries to include the `draft: true` param. When this param is present on the request, Payload will send back a draft document as opposed to a published one based on the document's `_status` field.
|
||||||
|
|
||||||
To enter draft mode, the URL provided to the `preview` function can point to a custom endpoint in your front-end application that sets a cookie or session variable to indicate that draft mode is enabled. This is framework specific, so the mechanisms here very from framework to framework although the underlying concept is the same.
|
To enter draft mode, the URL provided to the `preview` function can point to a custom endpoint in your front-end application that sets a cookie or session variable to indicate that draft mode is enabled. This is framework specific, so the mechanisms here vary from framework to framework although the underlying concept is the same.
|
||||||
|
|
||||||
### Next.js
|
### Next.js
|
||||||
|
|
||||||
|
|||||||
@@ -605,7 +605,7 @@ return (
|
|||||||
textField: {
|
textField: {
|
||||||
initialValue: 'Updated text',
|
initialValue: 'Updated text',
|
||||||
valid: true,
|
valid: true,
|
||||||
value: 'Upddated text',
|
value: 'Updated text',
|
||||||
},
|
},
|
||||||
},
|
},
|
||||||
// blockType: "yourBlockSlug",
|
// blockType: "yourBlockSlug",
|
||||||
@@ -875,7 +875,7 @@ Useful to retrieve info about the currently logged in user as well as methods fo
|
|||||||
| **`refreshCookie`** | A method to trigger the silent refreshing of a user's auth token |
|
| **`refreshCookie`** | A method to trigger the silent refreshing of a user's auth token |
|
||||||
| **`setToken`** | Set the token of the user, to be decoded and used to reset the user and token in memory |
|
| **`setToken`** | Set the token of the user, to be decoded and used to reset the user and token in memory |
|
||||||
| **`token`** | The logged in user's token (useful for creating preview links, etc.) |
|
| **`token`** | The logged in user's token (useful for creating preview links, etc.) |
|
||||||
| **`refreshPermissions`** | Load new permissions (useful when content that effects permissions has been changed) |
|
| **`refreshPermissions`** | Load new permissions (useful when content that affects permissions has been changed) |
|
||||||
| **`permissions`** | The permissions of the current user |
|
| **`permissions`** | The permissions of the current user |
|
||||||
|
|
||||||
```tsx
|
```tsx
|
||||||
@@ -1143,7 +1143,7 @@ This is useful for scenarios where you need to trigger another fetch regardless
|
|||||||
|
|
||||||
Route transitions are useful in showing immediate visual feedback to the user when navigating between pages. This is especially useful on slow networks when navigating to data heavy or process intensive pages.
|
Route transitions are useful in showing immediate visual feedback to the user when navigating between pages. This is especially useful on slow networks when navigating to data heavy or process intensive pages.
|
||||||
|
|
||||||
By default, any instances of `Link` from `@payloadcms/ui` will trigger route transitions dy default.
|
By default, any instances of `Link` from `@payloadcms/ui` will trigger route transitions by default.
|
||||||
|
|
||||||
```tsx
|
```tsx
|
||||||
import { Link } from '@payloadcms/ui'
|
import { Link } from '@payloadcms/ui'
|
||||||
|
|||||||
@@ -62,7 +62,7 @@ In this scenario, if your cookie was still valid, malicious-intent.com would be
|
|||||||
|
|
||||||
### CSRF Prevention
|
### CSRF Prevention
|
||||||
|
|
||||||
Define domains that your trust and are willing to accept Payload HTTP-only cookie based requests from. Use the `csrf` option on the base Payload Config to do this:
|
Define domains that you trust and are willing to accept Payload HTTP-only cookie based requests from. Use the `csrf` option on the base Payload Config to do this:
|
||||||
|
|
||||||
```ts
|
```ts
|
||||||
// payload.config.ts
|
// payload.config.ts
|
||||||
@@ -102,8 +102,8 @@ If option 1 isn't possible, then you can get around this limitation by [configur
|
|||||||
|
|
||||||
```
|
```
|
||||||
SameSite: None // allows the cookie to cross domains
|
SameSite: None // allows the cookie to cross domains
|
||||||
Secure: true // ensures its sent over HTTPS only
|
Secure: true // ensures it's sent over HTTPS only
|
||||||
HttpOnly: true // ensures its not accessible via client side JavaScript
|
HttpOnly: true // ensures it's not accessible via client side JavaScript
|
||||||
```
|
```
|
||||||
|
|
||||||
Configuration example:
|
Configuration example:
|
||||||
|
|||||||
@@ -71,7 +71,7 @@ export const Customers: CollectionConfig = {
|
|||||||
|
|
||||||
#### generateEmailSubject
|
#### generateEmailSubject
|
||||||
|
|
||||||
Similarly to the above `generateEmailHTML`, you can also customize the subject of the email. The function argument are the same but you can only return a string - not HTML.
|
Similarly to the above `generateEmailHTML`, you can also customize the subject of the email. The function arguments are the same but you can only return a string - not HTML.
|
||||||
|
|
||||||
```ts
|
```ts
|
||||||
import type { CollectionConfig } from 'payload'
|
import type { CollectionConfig } from 'payload'
|
||||||
@@ -178,7 +178,7 @@ The following arguments are passed to the `generateEmailHTML` function:
|
|||||||
|
|
||||||
#### generateEmailSubject
|
#### generateEmailSubject
|
||||||
|
|
||||||
Similarly to the above `generateEmailHTML`, you can also customize the subject of the email. The function argument are the same but you can only return a string - not HTML.
|
Similarly to the above `generateEmailHTML`, you can also customize the subject of the email. The function arguments are the same but you can only return a string - not HTML.
|
||||||
|
|
||||||
```ts
|
```ts
|
||||||
import type { CollectionConfig } from 'payload'
|
import type { CollectionConfig } from 'payload'
|
||||||
|
|||||||
@@ -38,7 +38,7 @@ const request = await fetch('http://localhost:3000', {
|
|||||||
|
|
||||||
### Omitting The Token
|
### Omitting The Token
|
||||||
|
|
||||||
In some cases you may want to prevent the token from being returned from the auth operations. You can do that by setting `removeTokenFromResponse` to `true` like so:
|
In some cases you may want to prevent the token from being returned from the auth operations. You can do that by setting `removeTokenFromResponses` to `true` like so:
|
||||||
|
|
||||||
```ts
|
```ts
|
||||||
import type { CollectionConfig } from 'payload'
|
import type { CollectionConfig } from 'payload'
|
||||||
@@ -46,7 +46,7 @@ import type { CollectionConfig } from 'payload'
|
|||||||
export const UsersWithoutJWTs: CollectionConfig = {
|
export const UsersWithoutJWTs: CollectionConfig = {
|
||||||
slug: 'users-without-jwts',
|
slug: 'users-without-jwts',
|
||||||
auth: {
|
auth: {
|
||||||
removeTokenFromResponse: true, // highlight-line
|
removeTokenFromResponses: true, // highlight-line
|
||||||
},
|
},
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|||||||
@@ -67,7 +67,7 @@ query {
|
|||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
Document access can also be queried on a collection/global basis. Access on a global can queried like `http://localhost:3000/api/global-slug/access`, Collection document access can be queried like `http://localhost:3000/api/collection-slug/access/:id`.
|
Document access can also be queried on a collection/global basis. Access on a global can be queried like `http://localhost:3000/api/global-slug/access`, Collection document access can be queried like `http://localhost:3000/api/collection-slug/access/:id`.
|
||||||
|
|
||||||
## Me
|
## Me
|
||||||
|
|
||||||
|
|||||||
@@ -71,7 +71,7 @@ export const Admins: CollectionConfig = {
|
|||||||
</Banner>
|
</Banner>
|
||||||
|
|
||||||
<Banner type="warning">
|
<Banner type="warning">
|
||||||
**Note:** Auth-enabled Collections with be automatically injected with the
|
**Note:** Auth-enabled Collections will be automatically injected with the
|
||||||
`hash`, `salt`, and `email` fields. [More
|
`hash`, `salt`, and `email` fields. [More
|
||||||
details](../fields/overview#field-names).
|
details](../fields/overview#field-names).
|
||||||
</Banner>
|
</Banner>
|
||||||
|
|||||||
@@ -8,7 +8,7 @@ keywords: authentication, config, configuration, documentation, Content Manageme
|
|||||||
|
|
||||||
During the lifecycle of a request you will be able to access the data you have configured to be stored in the JWT by accessing `req.user`. The user object is automatically appended to the request for you.
|
During the lifecycle of a request you will be able to access the data you have configured to be stored in the JWT by accessing `req.user`. The user object is automatically appended to the request for you.
|
||||||
|
|
||||||
### Definining Token Data
|
### Defining Token Data
|
||||||
|
|
||||||
You can specify what data gets encoded to the Cookie/JWT-Token by setting `saveToJWT` property on fields within your auth collection.
|
You can specify what data gets encoded to the Cookie/JWT-Token by setting `saveToJWT` property on fields within your auth collection.
|
||||||
|
|
||||||
|
|||||||
@@ -177,7 +177,7 @@ The following options are available:
|
|||||||
#### Edit View Options
|
#### Edit View Options
|
||||||
|
|
||||||
```ts
|
```ts
|
||||||
import type { CollectionCOnfig } from 'payload'
|
import type { CollectionConfig } from 'payload'
|
||||||
|
|
||||||
export const MyCollection: CollectionConfig = {
|
export const MyCollection: CollectionConfig = {
|
||||||
// ...
|
// ...
|
||||||
@@ -275,7 +275,7 @@ You can also pass an object to the collection's `graphQL` property, which allows
|
|||||||
|
|
||||||
## TypeScript
|
## TypeScript
|
||||||
|
|
||||||
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`.
|
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 `SanitizedCollectionConfig`.
|
||||||
|
|
||||||
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.
|
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.
|
||||||
|
|
||||||
|
|||||||
@@ -205,7 +205,7 @@ You can also pass an object to the global's `graphQL` property, which allows you
|
|||||||
|
|
||||||
## TypeScript
|
## TypeScript
|
||||||
|
|
||||||
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`.
|
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 `SanitizedGlobalConfig`.
|
||||||
|
|
||||||
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.
|
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.
|
||||||
|
|
||||||
|
|||||||
@@ -213,7 +213,7 @@ For more information about what we track, take a look at our [privacy policy](/p
|
|||||||
|
|
||||||
## Cross-origin resource sharing (CORS)#cors
|
## Cross-origin resource sharing (CORS)#cors
|
||||||
|
|
||||||
Cross-origin resource sharing (CORS) can be configured with either a whitelist array of URLS to allow CORS requests from, a wildcard string (`*`) to accept incoming requests from any domain, or a object with the following properties:
|
Cross-origin resource sharing (CORS) can be configured with either a whitelist array of URLS to allow CORS requests from, a wildcard string (`*`) to accept incoming requests from any domain, or an object with the following properties:
|
||||||
|
|
||||||
| Option | Description |
|
| Option | Description |
|
||||||
| ------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
|
| ------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
|
||||||
@@ -292,7 +292,7 @@ export const script = async (config: SanitizedConfig) => {
|
|||||||
collection: 'pages',
|
collection: 'pages',
|
||||||
data: { title: 'my title' },
|
data: { title: 'my title' },
|
||||||
})
|
})
|
||||||
payload.logger.info('Succesffully seeded!')
|
payload.logger.info('Successfully seeded!')
|
||||||
process.exit(0)
|
process.exit(0)
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|||||||
@@ -59,7 +59,7 @@ _For details on how to build Custom Views, including all available props, see [B
|
|||||||
|
|
||||||
### Document Root
|
### Document Root
|
||||||
|
|
||||||
The Document Root is mounted on the top-level route for a Document. Setting this property will completely take over the entire Document View layout, including the title, [Document Tabs](#ocument-tabs), _and all other nested Document Views_ including the [Edit View](./edit-view), API View, etc.
|
The Document Root is mounted on the top-level route for a Document. Setting this property will completely take over the entire Document View layout, including the title, [Document Tabs](#document-tabs), _and all other nested Document Views_ including the [Edit View](./edit-view), API View, etc.
|
||||||
|
|
||||||
When setting a Document Root, you are responsible for rendering all necessary components and controls, as no document controls or tabs would be rendered. To replace only the Edit View precisely, use the `edit.default` key instead.
|
When setting a Document Root, you are responsible for rendering all necessary components and controls, as no document controls or tabs would be rendered. To replace only the Edit View precisely, use the `edit.default` key instead.
|
||||||
|
|
||||||
|
|||||||
@@ -40,7 +40,7 @@ The following options are available:
|
|||||||
| `beforeDashboard` | An array of Custom Components to inject into the built-in Dashboard, _before_ the default dashboard contents. [More details](#beforedashboard). |
|
| `beforeDashboard` | An array of Custom Components to inject into the built-in Dashboard, _before_ the default dashboard contents. [More details](#beforedashboard). |
|
||||||
| `beforeLogin` | An array of Custom Components to inject into the built-in Login, _before_ the default login form. [More details](#beforelogin). |
|
| `beforeLogin` | An array of Custom Components to inject into the built-in Login, _before_ the default login form. [More details](#beforelogin). |
|
||||||
| `beforeNavLinks` | An array of Custom Components to inject into the built-in Nav, _before_ the links themselves. [More details](#beforenavlinks). |
|
| `beforeNavLinks` | An array of Custom Components to inject into the built-in Nav, _before_ the links themselves. [More details](#beforenavlinks). |
|
||||||
| `graphics.Icon` | The simplified logo used in contexts like the the `Nav` component. [More details](#graphicsicon). |
|
| `graphics.Icon` | The simplified logo used in contexts like the `Nav` component. [More details](#graphicsicon). |
|
||||||
| `graphics.Logo` | The full logo used in contexts like the `Login` view. [More details](#graphicslogo). |
|
| `graphics.Logo` | The full logo used in contexts like the `Login` view. [More details](#graphicslogo). |
|
||||||
| `header` | An array of Custom Components to be injected above the Payload header. [More details](#header). |
|
| `header` | An array of Custom Components to be injected above the Payload header. [More details](#header). |
|
||||||
| `logout.Button` | The button displayed in the sidebar that logs the user out. [More details](#logoutbutton). |
|
| `logout.Button` | The button displayed in the sidebar that logs the user out. [More details](#logoutbutton). |
|
||||||
@@ -345,7 +345,7 @@ export default function MyCustomIcon() {
|
|||||||
|
|
||||||
The `Logo` property is the full logo used in contexts like the `Login` view. This is typically a larger, more detailed representation of your brand.
|
The `Logo` property is the full logo used in contexts like the `Login` view. This is typically a larger, more detailed representation of your brand.
|
||||||
|
|
||||||
To add a custom logo, use the `admin.components.graphic.Logo` property in your Payload Config:
|
To add a custom logo, use the `admin.components.graphics.Logo` property in your Payload Config:
|
||||||
|
|
||||||
```ts
|
```ts
|
||||||
import { buildConfig } from 'payload'
|
import { buildConfig } from 'payload'
|
||||||
|
|||||||
@@ -39,7 +39,7 @@ export default buildConfig({
|
|||||||
import { vercelPostgresAdapter } from '@payloadcms/db-vercel-postgres'
|
import { vercelPostgresAdapter } from '@payloadcms/db-vercel-postgres'
|
||||||
|
|
||||||
export default buildConfig({
|
export default buildConfig({
|
||||||
// Automatically uses proces.env.POSTGRES_URL if no options are provided.
|
// Automatically uses process.env.POSTGRES_URL if no options are provided.
|
||||||
db: vercelPostgresAdapter(),
|
db: vercelPostgresAdapter(),
|
||||||
// Optionally, can accept the same options as the @vercel/postgres package.
|
// Optionally, can accept the same options as the @vercel/postgres package.
|
||||||
db: vercelPostgresAdapter({
|
db: vercelPostgresAdapter({
|
||||||
@@ -224,7 +224,7 @@ Make sure Payload doesn't overlap table names with its collections. For example,
|
|||||||
### afterSchemaInit
|
### afterSchemaInit
|
||||||
|
|
||||||
Runs after the Drizzle schema is built. You can use this hook to modify the schema with features that aren't supported by Payload, or if you want to add a column that you don't want to be in the Payload config.
|
Runs after the Drizzle schema is built. You can use this hook to modify the schema with features that aren't supported by Payload, or if you want to add a column that you don't want to be in the Payload config.
|
||||||
To extend a table, Payload exposes `extendTable` utillity to the args. You can refer to the [Drizzle documentation](https://orm.drizzle.team/docs/sql-schema-declaration).
|
To extend a table, Payload exposes `extendTable` utility to the args. You can refer to the [Drizzle documentation](https://orm.drizzle.team/docs/sql-schema-declaration).
|
||||||
The following example adds the `extra_integer_column` column and a composite index on `country` and `city` columns.
|
The following example adds the `extra_integer_column` column and a composite index on `country` and `city` columns.
|
||||||
|
|
||||||
```ts
|
```ts
|
||||||
|
|||||||
@@ -189,7 +189,7 @@ Make sure Payload doesn't overlap table names with its collections. For example,
|
|||||||
### afterSchemaInit
|
### afterSchemaInit
|
||||||
|
|
||||||
Runs after the Drizzle schema is built. You can use this hook to modify the schema with features that aren't supported by Payload, or if you want to add a column that you don't want to be in the Payload config.
|
Runs after the Drizzle schema is built. You can use this hook to modify the schema with features that aren't supported by Payload, or if you want to add a column that you don't want to be in the Payload config.
|
||||||
To extend a table, Payload exposes `extendTable` utillity to the args. You can refer to the [Drizzle documentation](https://orm.drizzle.team/docs/sql-schema-declaration).
|
To extend a table, Payload exposes `extendTable` utility to the args. You can refer to the [Drizzle documentation](https://orm.drizzle.team/docs/sql-schema-declaration).
|
||||||
The following example adds the `extra_integer_column` column and a composite index on `country` and `city` columns.
|
The following example adds the `extra_integer_column` column and a composite index on `country` and `city` columns.
|
||||||
|
|
||||||
```ts
|
```ts
|
||||||
|
|||||||
@@ -36,7 +36,7 @@ export const MyRadioField: Field = {
|
|||||||
| Option | Description |
|
| Option | Description |
|
||||||
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||||
| **`name`** \* | To be used as the property name when stored and retrieved from the database. [More](/docs/fields/overview#field-names) |
|
| **`name`** \* | To be used as the property name when stored and retrieved from the database. [More](/docs/fields/overview#field-names) |
|
||||||
| **`options`** \* | Array of options to allow the field to store. Can either be an array of strings, or an array of objects containing an `label` string and a `value` string. |
|
| **`options`** \* | Array of options to allow the field to store. Can either be an array of strings, or an array of objects containing a `label` string and a `value` string. |
|
||||||
| **`label`** | Text used as a field label in the Admin Panel or an object with keys for each language. |
|
| **`label`** | Text used as a field label in the Admin Panel or an object with keys for each language. |
|
||||||
| **`validate`** | Provide a custom validation function that will be executed on both the Admin Panel and the backend. [More](/docs/fields/overview#validation) |
|
| **`validate`** | Provide a custom validation function that will be executed on both the Admin Panel and the backend. [More](/docs/fields/overview#validation) |
|
||||||
| **`index`** | Build an [index](/docs/database/overview) for this field to produce faster queries. Set this field to `true` if your users will perform queries on this field's data often. |
|
| **`index`** | Build an [index](/docs/database/overview) for this field to produce faster queries. Set this field to `true` if your users will perform queries on this field's data often. |
|
||||||
|
|||||||
@@ -23,7 +23,7 @@ Let's see examples on how context can be used in the first two scenarios mention
|
|||||||
|
|
||||||
### 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.
|
To pass data between hooks, you can assign values to context in an earlier hook in the lifecycle of a request and expect it in the context of a later hook.
|
||||||
|
|
||||||
For example:
|
For example:
|
||||||
|
|
||||||
|
|||||||
@@ -33,7 +33,7 @@ Simply add a task to the `jobs.tasks` array in your Payload config. A task consi
|
|||||||
| `onSuccess` | Function to be executed if the task succeeds. |
|
| `onSuccess` | Function to be executed if the task succeeds. |
|
||||||
| `retries` | Specify the number of times that this step should be retried if it fails. If this is undefined, the task will either inherit the retries from the workflow or have no retries. If this is 0, the task will not be retried. By default, this is undefined. |
|
| `retries` | Specify the number of times that this step should be retried if it fails. If this is undefined, the task will either inherit the retries from the workflow or have no retries. If this is 0, the task will not be retried. By default, this is undefined. |
|
||||||
|
|
||||||
The logic for the Task is defined in the `handler` - which can be defined as a function, or a path to a function. The `handler` will run once a worker picks picks up a Job that includes this task.
|
The logic for the Task is defined in the `handler` - which can be defined as a function, or a path to a function. The `handler` will run once a worker picks up a Job that includes this task.
|
||||||
|
|
||||||
It should return an object with an `output` key, which should contain the output of the task as you've defined.
|
It should return an object with an `output` key, which should contain the output of the task as you've defined.
|
||||||
|
|
||||||
@@ -213,7 +213,7 @@ export default buildConfig({
|
|||||||
|
|
||||||
## Nested tasks
|
## Nested tasks
|
||||||
|
|
||||||
You can run sub-tasks within an existing task, by using the `tasks` or `ìnlineTask` arguments passed to the task `handler` function:
|
You can run sub-tasks within an existing task, by using the `tasks` or `inlineTask` arguments passed to the task `handler` function:
|
||||||
|
|
||||||
```ts
|
```ts
|
||||||
export default buildConfig({
|
export default buildConfig({
|
||||||
|
|||||||
@@ -260,7 +260,7 @@ If you are using relationships or uploads in your front-end application, and you
|
|||||||
{
|
{
|
||||||
// ...
|
// ...
|
||||||
// If your site is running on a different domain than your Payload server,
|
// If your site is running on a different domain than your Payload server,
|
||||||
// This will allows requests to be made between the two domains
|
// This will allow requests to be made between the two domains
|
||||||
cors: [
|
cors: [
|
||||||
'http://localhost:3001' // Your front-end application
|
'http://localhost:3001' // Your front-end application
|
||||||
],
|
],
|
||||||
|
|||||||
@@ -135,7 +135,7 @@ export const MyComponent: React.FC<{
|
|||||||
|
|
||||||
### Overriding Converters
|
### Overriding Converters
|
||||||
|
|
||||||
You can override any of the default JSX converters by passing passing your custom converter, keyed to the node type, to the `converters` prop / the converters function.
|
You can override any of the default JSX converters by passing your custom converter, keyed to the node type, to the `converters` prop / the converters function.
|
||||||
|
|
||||||
Example - overriding the upload node converter to use next/image:
|
Example - overriding the upload node converter to use next/image:
|
||||||
|
|
||||||
|
|||||||
@@ -3,7 +3,7 @@ title: Autosave
|
|||||||
label: Autosave
|
label: Autosave
|
||||||
order: 30
|
order: 30
|
||||||
desc: Using Payload's Draft functionality, you can configure your collections and globals to autosave changes as drafts, and publish only you're ready.
|
desc: Using Payload's Draft functionality, you can configure your collections and globals to autosave changes as drafts, and publish only you're ready.
|
||||||
keywords: version history, revisions, audit log, draft, publish, autosave, Content Management System, cms, headless, javascript, node, react, nextjss
|
keywords: version history, revisions, audit log, draft, publish, autosave, Content Management System, cms, headless, javascript, node, react, nextjs
|
||||||
---
|
---
|
||||||
|
|
||||||
Extending on Payload's [Draft](/docs/versions/drafts) functionality, you can configure your collections and globals to autosave changes as drafts, and publish only you're ready. The Admin UI will automatically adapt to autosaving progress at an interval that you define, and will store all autosaved changes as a new Draft version. Never lose your work - and publish changes to the live document only when you're ready.
|
Extending on Payload's [Draft](/docs/versions/drafts) functionality, you can configure your collections and globals to autosave changes as drafts, and publish only you're ready. The Admin UI will automatically adapt to autosaving progress at an interval that you define, and will store all autosaved changes as a new Draft version. Never lose your work - and publish changes to the live document only when you're ready.
|
||||||
|
|||||||
Reference in New Issue
Block a user