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 hidden (Show)
Published by denolfe 3 months ago
plugin-search: make search collection fields override into a function that provides defaultFields inline with other plugins (#7095) (2bc8666)
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.
// 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',
},
},
]
},
}),
exports getSiblingData, getDataByPath, and reduceFieldsToValues from payload (#7070) (0a2ecf8)
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:
import { getSiblingData, getDataByPath, reduceFieldsToValues } from '@payloadcms/ui/forms/Form'
import { unflatten } from '@payloadcms/ui/utilities'
New:
import { getSiblingData, getDataByPath, reduceFieldsToValues, unflatten } from 'payload/shared'
The is-buffer
dependency was also removed in this PR.
updated admin panel color palette (#7011) (c2022f6)
Color values have changed and will have different
contrasts. If you use any of Payload's colors in your apps, you may need
to adjust your use of them to maintain proper styling/accessibility.
Colors palettes changed:
--theme-success-*
--theme-error-*
--theme-warning-*
--color-success-*
--color-error-*
--color-warning-*
--color-blue-*
Updates the color palette used throughout Payload to be more consistent
between dark and light values. Contrast values are now more in line with
the theme-elevation
contrasts. Some adjustments to the Toast
components as well to match light/dark mode better.
Published by denolfe 3 months ago
BREAKING: The minimum required Next.js version has been bumped from
15.0.0-rc.0
to15.0.0-canary.53
. This is because the way client
components are represented changed somewhere between those versions, and
it is not feasible to support both versions in our RSC detection logic.
Published by denolfe 4 months ago
Published by denolfe 4 months ago
BREAKING: Lexical may introduce undocumented breaking changes, if
you use the lexical API directly. Please consult their changelog:
https://github.com/facebook/lexical/releases/tag/v0.16.1
Removes PayloadRequestWithData in favour of just PayloadRequest with
optional types fordata
andlocale
addDataAndFileToRequest
andaddLocalesToRequestFromData
now takes in
a single argument instead of an object// before await addDataAndFileToRequest({ request: req }) addLocalesToRequestFromData({ request: req }) // current await addDataAndFileToRequest(req) addLocalesToRequestFromData(req)
Published by denolfe 4 months ago
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
// 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.
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:
return user
After:
return { user }
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:
{
// ...
admin: {
components: {
AfterList: [],
AfterListTable: [],
BeforeList: [],
BeforeListTable: [],
}
}
}
New:
{
// ...
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.
Published by denolfe 4 months ago
Published by denolfe 4 months ago
various type improvements (#6385) (ccbaee4)
relationTo
props on filterOptions, relationshipStandardizes 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:
import { Text } from '@payloadcms/ui/fields/Text'
New:
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):
import { TextField } from '@payloadcms/ui'
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
richtext-lexical: simplify creation of features (#6885) (d66b348)
ClientComponent
has been renamed to ClientFeature
serverFeatureProps
has been renamed tosanitizedServerFeatureProps
clientFeatureProps
has been renamed tosanitizedClientFeatureProps
Published by denolfe 4 months ago
in
& not_in
(#6773) (f6ba3be), closes #6741
Published by denolfe 4 months ago
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.
Published by denolfe 4 months ago
Published by denolfe 4 months ago
Published by denolfe 4 months ago
basePath
not handled for logout
route (#6817) (47ee40a)Published by denolfe 4 months ago
Exports from the payload
package have been significantly cleaned up. Now, just about everything is able to be imported from payload
directly, rather than an assortment of subpath exports. This means that things like import { buildConfig } from 'payload/config'
are now just imported via import { buildConfig } from 'payload'
. The mental model is significantly simpler for developers, but you might need to update some of your imports.
Payload now exposes only three exports:
payload
- all types and server-only Payload codepayload/shared
- utilities that can be used in either the browser or in Node environmentspayload/node
- heavy utilities that should only be imported in Node scripts and never be imported into bundled code like Next.jsWith this release, we've dramatically sped up the compile time for Payload by pre-bundling our entire UI package for use inside of the Payload admin itself. There are new exports that should be used within Payload custom components:
@payloadcms/ui/client
- all client components@payloadcms/ui/server
- all server componentsFor all of your custom Payload admin UI components, you should be importing from one of these two pre-compiled barrel files rather than importing from the more deeply nested exports directly. That will keep compile times nice and speedy, and will also make sure that the bundled JS for your admin UI is kept small.
For example, whereas before, if you imported the Payload Button
, you would have imported it like this:
import { Button } from '@payloadcms/ui/elements/Button'
Now, you would import it like this:
import { Button } from '@payloadcms/ui/client'
This is a significant DX / performance optimization that we're pretty pumped about.
However, if you are importing or re-using Payload UI components outside of the Payload admin UI, for example in your own frontend apps, you can import from the individual component exports which will make sure that the bundled JS is kept to a minimum in your frontend apps. So in your own frontend, you can continue to import directly to the components that you want to consume rather than importing from the pre-compiled barrel files.
Individual component exports will now come with their corresponding CSS and everything will work perfectly as-expected.
'@payloadcms/ui/templates/Default'
and '@payloadcms/ui/templates/Minimal
' are now exported from '@payloadcms/next/templates'
LogOut
icon. Old: import { LogOut } from '@payloadcms/ui/icons/LogOut'
New: import { LogOutIcon } from '@payloadcms/ui/icons/LogOut'
In effort to make local dev as fast as possible, we need to import as few files as possible so that the compiler has less to process. One way we've achieved this in the Admin Panel was to remove all .scss imports from all components in the @payloadcms/ui
module using a build process. This stripped all import './index.scss'
statements out of each component before injecting them into dist
. Instead, it bundles all of the CSS into a single main.css
file, and we import that at the root of the app.
While this concept is still the right solution to the problem, this particular approach is not viable when using these components outside the Admin Panel, where not only does this root stylesheet not exist, but where it would also bloat your app with unused styles. Instead, we need to keep these .scss imports in place so they are imported directly alongside your components, as expected. Then, we need create a new build step that separately compiles the components without their stylesheets—this way your app can consume either as needed from the new client
and server
barrel files within @payloadcms/ui
, i.e. from within @payloadcms/next
and all other admin-specific packages and plugins.
This way, all other applications will simply import using the direct file paths, just as they did before. Except now they come with stylesheets.
And we've gotten a pretty awesome initial compilation performance boost.
Published by denolfe 4 months ago
Published by denolfe 4 months ago
- Makes Gravatar the default