searchPlugin's searchOverrides for the collection now takes in a fields
function instead of array similar to other plugins and patterns we use
to allow you to map over existing fields as well if needed.
```ts
// before
searchPlugin({
searchOverrides: {
slug: 'search-results',
fields: [
{
name: 'excerpt',
type: 'textarea',
admin: {
position: 'sidebar',
},
},
]
},
}),
// current
searchPlugin({
searchOverrides: {
slug: 'search-results',
fields: ({ defaultFields }) => [
...defaultFields,
{
name: 'excerpt',
type: 'textarea',
admin: {
position: 'sidebar',
},
},
]
},
}),
```
## Description
Exports `getSiblingData`, `getDataByPath`, `reduceFieldsToValues`, and
`unflatten` from `payload`. These utilities were previously accessible
using direct import paths from `@payloadcms/ui`—but this is no longer
advised since moving to a pre-bundled UI library pattern. Instead of
simply exporting these from the `@payloadcms/ui` package, these exports
have been moved to Payload itself to provision for use outside of React
environments.
This is considered a breaking change. If you were previously importing
any of these utilities, the imports paths have changed as follows:
Old:
```ts
import { getSiblingData, getDataByPath, reduceFieldsToValues } from '@payloadcms/ui/forms/Form'
import { unflatten } from '@payloadcms/ui/utilities'
```
New:
```ts
import { getSiblingData, getDataByPath, reduceFieldsToValues, unflatten } from 'payload/shared'
```
The `is-buffer` dependency was also removed in this PR.
- [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)
## Checklist:
- [x] Existing test suite passes locally with my changes
- Improves type for `jsonSchema` property of JSON field
- Adds type generation of JSON field with `jsonSchema`
- Adds `typescriptSchema` property to fields that allows you override
default field type generation by providing a JSON schema.
- Adds `typescript.schema` property in payload config, to allow for any
modifications of the type schemas
---------
Co-authored-by: Alessio Gravili <alessio@gravili.de>
Exports the fields from the SEO plugin so that they can be used anywhere
inside a collection, new exports:
```ts
import { MetaDescriptionField, MetaImageField, MetaTitleField, OverviewField, PreviewField } from '@payloadcms/plugin-seo/fields'
// Used as fields
MetaImageField({
relationTo: 'media',
hasGenerateFn: true,
})
MetaDescriptionField({
hasGenerateFn: true,
})
MetaTitleField({
hasGenerateFn: true,
})
PreviewField({
hasGenerateFn: true,
titlePath: 'meta.title',
descriptionPath: 'meta.description',
})
OverviewField({
titlePath: 'meta.title',
descriptionPath: 'meta.description',
imagePath: 'meta.image',
})
```
Removes PayloadRequestWithData in favour of just PayloadRequest with
optional types for `data` and `locale`
`addDataAndFileToRequest` and `addLocalesToRequestFromData` now takes in
a single argument instead of an object
```ts
// before
await addDataAndFileToRequest({ request: req })
addLocalesToRequestFromData({ request: req })
// current
await addDataAndFileToRequest(req)
addLocalesToRequestFromData(req)
```
---------
Co-authored-by: Paul Popus <paul@nouance.io>
## 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 }
```
## Description
<!-- Please include a summary of the pull request and any related issues
it fixes. Please also include relevant motivation and context. -->
The v3 documentation mislead people by using PassportJS even though it's
not in v3 and custom strategies should be used instead with the correct
link.
- [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
<!-- Please delete options that are not relevant. -->
- [x] Chore (non-breaking change which does not add functionality)
- [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
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
