BREAKING: `ValidationError` now requires the `global` or `collection`
slug, as well as an `errors` property. The actual errors are no longer
at the top-level.
Changed the data to correctly match type generic being sent to the
generate functions. So now you can type your generateTitle etc.
functions like this
```ts
// before
const generateTitle: GenerateTitle = async <Page>({ doc, locale }) => {
return `Website.com — ${doc?.title?.value}`
}
// curent
import type { GenerateDescription, GenerateTitle, GenerateURL } from '@payloadcms/plugin-seo/types'
import type { Page } from './payload-types'
const generateTitle: GenerateTitle<Page> = async ({ doc, locale }) => {
return `Website.com — ${doc?.title}`
}
const generateDescription: GenerateDescription<Page> = async ({ doc, locale }) => {
return doc?.excerpt || 'generated description'
}
const generateURL: GenerateURL<Page> = async ({ doc, locale }) => {
return `https://yoursite.com/${locale ? locale + '/' : ''}${doc?.slug || ''}`
}
```
Breaking change because it was previously a FormState value.
## Description
Some authentication strategies may need to set headers for responses,
such as updating cookies via a refresh token, and similar. This PR
extends Payload's auth strategy capabilities with a manner of
accomplishing this.
This is a breaking change if you have custom authentication strategies
in Payload's 3.0 beta. But it's a simple one to update.
Instead of your custom auth strategy returning the `user`, now you must
return an object with a `user` property.
This is because you can now also optionally return `responseHeaders`,
which will be returned by Payload API responses if you define them in
your auth strategies. This can be helpful for cases where you need to
set cookies and similar, directly within your auth strategies.
Before:
```ts
return user
```
After:
```ts
return { user }
```
In case of breaking lexical data changes, you can simply call
`upgradeLexicalData({ payload })` to upgrade every lexical field in your
payload field to the new data format.
## Description
Properties within the Custom Collection Components config were not
properly cased. In the Payload Config, there are places where we expose
_an array_ of Custom Components to render. These properties should be
cased in `camelCase` to indicate that its type is _**not**_ a component,
but rather, it's an _**array**_ of components. This is how all other
arrays are already cased throughout the config, therefore these
components break exiting convention. The `CapitalCase` convention is
reserved for _components themselves_, however, fixing this introduces a
breaking change. Here's how to migrate:
Old:
```ts
{
// ...
admin: {
components: {
AfterList: [],
AfterListTable: [],
BeforeList: [],
BeforeListTable: [],
}
}
}
```
New:
```ts
{
// ...
admin: {
components: {
afterList: [],
afterListTable: [],
beforeList: [],
beforeListTable: [],
}
}
}
```
The docs were also out of date for the Root-level Custom Components.
These components are documented in CaptalCase but are in fact cased
correctly in Payload. This PR fixes that.
- [x] I have read and understand the
[CONTRIBUTING.md](https://github.com/payloadcms/payload/blob/main/CONTRIBUTING.md)
document in this repository.
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
- [x] This change requires a documentation update
## Checklist:
- [x] Existing test suite passes locally with my changes
- [x] I have made corresponding changes to the documentation
## Description
Ensures that exp and auth strategy are available from the `me` and
`refresh` operations as well as passed through the `Auth` provider. Same
as #6943
- [x] I have read and understand the
[CONTRIBUTING.md](https://github.com/payloadcms/payload/blob/main/CONTRIBUTING.md)
document in this repository.
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
Adds the ability to set response headers by using a new
`uploads.modifyResponseHeaders` property. You could previously do this
in Express in Payload v2.
You can do this like so:
```ts
upload: {
modifyResponseHeaders: ({ headers }) => {
headers.set('Cache-Control', 'public, max-age=86400')
return headers
}
},
```
**BREAKING:**
- Type narrowing for `relationTo` props on filterOptions, relationship
fields and upload fields
- Type narrowing for arguments of lexical relationship, link and upload
features
## Description
Standardizes all named field exports. This improves semantics when using
these components by appending `Field` onto the end of their names. Some
components were already doing this, i.e. `ArrayField` and `BlocksField`.
Now, all field components share this same convention. And since bundled
components were already aliasing most exports in this way, this change
will largely go unnoticed because most apps were _already_ importing the
correctly named components. What is ultimately means is that there was a
mismatch between the unbundled vs bundled exports. This PR resolves that
conflict. But this also introduces a potentially breaking change for
your app. If your app is using components that import from the
_unbundled_ `@payloadcms/ui` package, those import paths likely changed:
Old:
```tsx
import { Text } from '@payloadcms/ui/fields/Text'
```
New:
```tsx
import { TextField } from '@payloadcms/ui/fields/Text'
```
If you were importing direcetly from the _bundled_ version, you're
imports likely have not changed. For example:
This still works (the import path is top-level, pointing to the
_bundled_ code):
```tsx
import { TextField } from '@payloadcms/ui'
```
- [x] I have read and understand the
[CONTRIBUTING.md](https://github.com/payloadcms/payload/blob/main/CONTRIBUTING.md)
document in this repository.
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
- [x] Breaking change (fix or feature that would cause existing
functionality to not work as expected)
## Checklist:
- [x] Existing test suite passes locally with my changes
**BREAKING:** a bunch of exports have been moved around. There are now
two of them: `@payloadcms/richtext-lexical` and
`@payloadcms/richtext-lexical/client`. The root export is server-only.
If any imports don't resolve anymore after this version, simply change
the import to one of those, depending on if you are on the server or the
client
**BREAKING:**
- ServerFeature: `ClientComponent` has been renamed to `ClientFeature`
- ServerFeature: The nested `serverFeatureProps` has been renamed to
`sanitizedServerFeatureProps`
- ServerFeature: The FeatureProviderProviderServer type now expects 3
generics instead of 2. We have split the props generic into sanitized &
unsanitized props
- ClientFeature: The FeatureProviderProviderClient type now expects 2
generics instead of 1. We have split the props generic into sanitized &
unsanitized props
- ClientFeature: The nested `clientFeatureProps` has been renamed to
`sanitizedClientFeatureProps`
Fixes https://github.com/payloadcms/payload/issues/6869
Before, options from props were being stored in state and would not
update when props changed. Now options are memoized and will update when
the incoming `options` prop changes.
Allows `upload.handlers` to mutate the request. This can be useful when
you want to adjust headers on the request but do not want to return a
new response.
**BREAKING:** All `@payloadcms/ui/client` exports have been renamed to
`@payloadcms/ui`. A simple find & replace across your entire project
will be enough to migrate. This change greatly improves import
auto-completions in IDEs which lack proper support for package.json
exports, like Webstorm.
Copy of https://github.com/payloadcms/payload/pull/6842 for beta
Allows empty strings ('') as defaultValue for fields of types: 'text'; 'textarea'; 'email'; 'code'. This can be useful when you want to ensure the value is always a string instead of null/undefined.
## Description
Fixes an issue where the `unflatten` function would also unflatten json
objects when they contained a `.` in one of their keys
V2 PR [here](https://github.com/payloadcms/payload/pull/6834)
