## Description
Adds `loginWithUsername` option to auth config. When set to true, it
will inject an `username` field into the collection config which
replaces the `email` field in the UI. The `email` field is still
required but not unique.
The `username` field can be extended by passing a field named `username`
to your auth collection. Anything added to this field will be combined
with the initial field.
- [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] New feature (non-breaking change which adds functionality)
## Checklist:
- [X] Existing test suite passes locally with my changes
---------
Co-authored-by: Jarrod Flesch <jarrodmflesch@gmail.com>
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>
Closes https://github.com/payloadcms/payload/issues/6953
```ts
// the following types can now take in arguments for User type
GenerateVerifyEmailHTML<User>
GenerateVerifyEmailSubject<User>
GenerateForgotPasswordEmailHTML<User>
GenerateForgotPasswordEmailSubject<User>
```
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 }
```
## 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
## 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
