The best way to build a modern backend + admin UI. No black magic, all TypeScript, and fully open-source, Payload is both an app framework and a headless CMS.
MIT License
Bot releases are visible (Hide)
Published by denolfe 6 months ago
Full Changelog: https://github.com/payloadcms/payload/compare/v3.0.0-beta.15...v3.0.0-beta.18
equals
& not_equals
operators from fields with hasMany
(#5885) (a8c9625)Published by denolfe 6 months ago
Custom handlers will no longer resolve data
, locale
and fallbackLocale
for you. Instead you can use our provided utilities from the next
package
// ❌ Before
{
path: '/whoami/:parameter',
method: 'post',
handler: async (req) => {
return Response.json({
name: req.data.name, // data will be undefined
// locales will be undefined
fallbackLocale: req.fallbackLocale,
locale: req.locale,
})
}
}
// ✅ After
import { addDataAndFileToRequest } from '@payloadcms/next/utilities'
import { addLocalesToRequest } from '@payloadcms/next/utilities'
{
path: '/whoami/:parameter',
method: 'post',
handler: async (req) => {
// mutates req, must be awaited
await addDataAndFileToRequest(req)
// mutates req
addLocalesToRequest(req)
return Response.json({
name: req.data.name, // data is now available
fallbackLocale: req.fallbackLocale, // locales available
locale: req.locale,
})
}
}
Full Changelog: https://github.com/payloadcms/payload/compare/v3.0.0-beta.14...v3.0.0-beta.15
Shortens the name of auto-generated Postgres relations. Should dramatically reduce errors for users in PG. Also handles an issue with HMR in Postgres by properly destroying the database adapter before re-initializing it.
This change will require anyone running @payloadcms/db-postgres
to create a new migration and run it against their database.
pnpm payload migrate:create
will generate the new migrationpnpm payload migrate
will run the migration against your DBPublished by denolfe 6 months ago
email
and password
in login operation by @PatrikKozak in https://github.com/payloadcms/payload/pull/5899
Providing an email configuration is now optional. If using nodemailer before, you will need to install a new package @payloadcms/email-nodemailer
and use it in your config.
Email Configuration Before:
// via payload.init
payload.init({
email: {
transport: someNodemailerTransport
fromName: 'hello',
fromAddress: '[email protected]',
},
})
// or via email in payload.config.ts
export default buildConfig({
email: {
transport: someNodemailerTransport
fromName: 'hello',
fromAddress: '[email protected]',
},
})
Email Configuration After:
@payloadcms/email-nodemailer
packageinit
function has been removed.sendEmail
call will simply log the To address and subject.// Using new nodemailer adapter package
import { nodemailerAdapter } from '@payloadcms/email-nodemailer'
export default buildConfig({
email: nodemailerAdapter() // This will be the old ethereal.email functionality
})
// or pass in transport
export default buildConfig({
email: nodemailerAdapter({
defaultFromAddress: '[email protected]',
defaultFromName: 'Payload',
transport: await nodemailer.createTransport({
host: process.env.SMTP_HOST,
port: 587,
auth: {
user: process.env.SMTP_USER,
pass: process.env.SMTP_PASS,
},
})
})
})
// Create custom email adapter
// myAdapter.ts
import type { EmailAdapter, SendMailOptions } from 'payload/types'
export const myAdapter: EmailAdapter = ({ payload }) => ({
defaultFromAddress: defaults.defaultFromAddress,
defaultFromName: defaults.defaultFromName,
sendEmail: async (message) => {
// Perform any logic here
console.log(`To: '${message.to}', Subject: '${message.subject}'`)
return Promise.resolve()
},
})
// payload.config.ts
export default buildConfig({
email: myAdapter()
})
email
and password
in login operation (#4852) (1f00360)contains
query with special chars (#5774) (5fa99fb)CustomPublishButtonProps
to CustomPublishButtonType
(#5644) (7df7bf4)Published by denolfe 8 months ago
Published by denolfe 8 months ago
Published by denolfe 9 months ago
Published by denolfe 9 months ago
Published by denolfe 9 months ago
Published by denolfe 9 months ago
Published by denolfe 9 months ago
draft=true
in fetch for relationships (#4784) (0a259d2)value
key when filtering / querying for relationships (#4727) (d0f7677)Published by denolfe 10 months ago
text
(#4689) (d419275)Published by denolfe 10 months ago
Published by denolfe 10 months ago
actions
property to admin customization (#4468) (9e8f14a)@payloadcms/richtext-lexical
If you import TreeviewFeature, you have to rename the import to use TreeViewFeature (capitalized "V")
An unpopulated, internal link node no longer saves the doc id under fields.doc.value.id. Now, it saves it under fields.doc.value.
Migration inside of payload is automatic. If you are reading from the link node inside of your frontend though, you will have to adjust it.
Dropdown component has a new mandatory sectionKey prop
Most important: If you are updating @payloadcms/richtext-lexical
to v0.4.0 or higher, you will HAVE to update payload to the latest version as well. If you don't update it, payload likely won't start up due to validation errors. It's generally good practice to upgrade packages prefixed with @payloadcms/ together with payload and keep the versions in sync.
@payloadcms/richtext-slate
is not affected by this.
Every single property in the Feature
interface which accepts a React component now no longer accepts a React component, but a function which imports a React component instead. This is done to ensure no unnecessary client-only code is leaked to the server when importing Features on a server.
Here's an example migration:
Old:
import { BlockIcon } from '../../lexical/ui/icons/Block'
...
Icon: BlockIcon,
New:
// import { BlockIcon } from '../../lexical/ui/icons/Block' // <= Remove this import
...
Icon: () =>
// @ts-expect-error
import('../../lexical/ui/icons/Block').then((module) => module.BlockIcon),
Or alternatively, if you're using default exports instead of named exports:
// import BlockIcon from '../../lexical/ui/icons/Block' // <= Remove this import
...
Icon: () =>
// @ts-expect-error
import('../../lexical/ui/icons/Block'),
The types for SanitizedEditorConfig
and EditorConfig
have changed. Their respective lexical
property no longer expects the LexicalEditorConfig
. It now expects a function returning the LexicalEditorConfig
. You will have to adjust this if you adjusted that property anywhere, e.g. when initializing the lexical field editor property, or when initializing a new headless editor.
The following exports are now exported from the @payloadcms/richtext-lexical/components
subpath exports instead of @payloadcms/richtext-lexical
:
ToolbarButton
ToolbarDropdown
RichTextCell
RichTextField
defaultEditorLexicalConfig
You will have to adjust your imports, only if you import any of those properties in your project.