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 4 months ago
BREAKING
- Our internal field hook methods now have new required
schemaPath
and
pathprops
. This affects the following functions, if you are using
those:afterChangeTraverseFields
,afterReadTraverseFields
,
beforeChangeTraverseFields
,beforeValidateTraverseFields
,
afterReadPromise
- The afterChange field hook's
value
is now the value AFTER the
previous hooks were run. Previously, this was the original value, which
I believe is a bug- Only relevant if you have built your own richText adapter: the
richText adapterpopulationPromises
property has been renamed to
graphQLPopulationPromises
and is now only run for graphQL. Previously,
it was run for graphQL AND the rest API. To migrate, use
hooks.afterRead
to run population for the rest API- Only relevant if you have built your own lexical features: The
populationPromises
server feature property has been renamed to
graphQLPopulationPromises
and is now only run for graphQL. Previously,
it was run for graphQL AND the rest API. To migrate, use
hooks.afterRead
to run population for the rest API- Serialized lexical link and upload nodes now have a new
id
property.
While not breaking, localization / hooks will not work for their fields
until you have migrated to that. Re-saving the old document on the new
version will automatically add theid
property for you. You will also
get a bunch of console logs for every lexical node which is not migrated
Published by denolfe 4 months ago
number
& text
fields in where builder (#6662) (e3003b4)fileHasAdjustments
files or fileIsAnimated
files (#6710) (921a5c0)metadata.pages
for height if animated (#6729) (2f9ed34)array
& blocks
& group
fields from sort (#6574) (507e095), closes #6469
Published by denolfe 4 months ago
metadata.pages
for height if animated (#6728) (10c6ffa)fileHasAdjustments
files or fileIsAnimated
files (#6708) (6512d5c)We now export toast from
sonner
instead of
react-toastify
. If you send out toasts from your own projects, make
sure to use ourtoast
export, or installsonner
. React-toastify
toasts will no longer work anymore. The Toast APIs are mostly similar,
but there are some differences if you provide options to your toastCSS styles have been changed from Toastify
/* before */ .Toastify /* current */ .payload-toast-container .payload-toast-item .payload-toast-close-button /* individual toast items will also have these classes depending on the state */ .toast-info .toast-warning .toast-success .toast-error
https://github.com/payloadcms/payload/assets/70709113/da3e732e-aafc-4008-9469-b10f4eb06b35
Published by denolfe 4 months ago
array
& blocks
& group
fields from sort (#6576) (9f52562)Types are now auto-generated by default.
You can opt-out of this behavior by setting:
buildConfig({ // Rest of config typescript: { autoGenerate: false }, })
Published by denolfe 5 months ago
Description
Updates the
fields
override in plugin redirects to allow for
overriding// before overrides: { fields: [ { type: 'text', name: 'customField', }, ], }, // current overrides: { fields: ({ defaultFields }) => { return [ ...defaultFields, { type: 'text', name: 'customField', }, ] }, },
- This bumps the minimum required node version from node 20.6.0 to node
20.9.0. This is because 20.6.0 breaks type generation due to a CJS node
bug, and 20.9.0 is the next v20 LTS version. The minimum node 18 version
stays the same (18.20.2)
Published by denolfe 5 months ago
Published by denolfe 5 months ago
Fixes #6630
This only applies to you if you using db-postgres and have created the
v2-v3-relationships
migration released in
v3.0.0-beta.39
from @payloadcms/db-postgres <= v3.0.0-beta.40.Steps to fix
- Delete the existing v2-v3-relationships migration file.
- If changes were made to your config since the previous migration was
made, you will need to revert those by checking out a previous commit in
your version control.- Recreate the migration using
payload migrate:create --file @payloadcms/db-postgres/relationships-v2-v3
to make the migration with
the snapshot .json file.
BREAKING:
- This upgrades the required version of lexical from 0.15.0 to 0.16.0.
If you are using lexical directly in your project, possibly due to
custom features, there might be breaking changes for you. Please consult
the lexical 0.16.0 changelog:
https://github.com/facebook/lexical/releases/tag/v0.16.0
userEmailAlreadyRegistered
translations (#6549) (56c6700), closes #6535
field.admin
in WhereBuilder (#6534) (4f9d78d)admin.disableListColumn
property (#6530) (eeddece), closes #6521
Published by denolfe 5 months ago
BREAKING: useEditorFocusProvider has been removed and merged with
useEditorConfigContext. You can now find information about the focused
editor, parent editors and child editors within useEditorConfigContext
Published by denolfe 5 months ago
BREAKING CHANGE:
Moves
upload
field andrelationship
fields withhasMany: false
&
relationTo: string
from the many-to-many_rels
join table to simple
columns. This only affects Postgres database users.TL;DR
We have dramatically simplified the storage of simple relationships in
relational databases to boost performance and align with more expected
relational paradigms. If you are using the beta Postgres adapter, and
you need to keep simple relationship data, you'll need to run a
migration script that we provide you.Background
For example, prior to this update, a collection of "posts" with a simple
hasMany: false
andrelationTo: 'categories'
field would have a
posts_rels
table where the category relations would be stored.This was somewhat unnecessary as simple relations like this can be
expressed with acategory_id
column which is configured as a foreign
key. This also introduced added complexity for dealing directly with the
database if all you have are simple relations.Who needs to migrate
You need to migrate if you are using the beta Postgres database adapter
and any of the following applies to you.
- If you have versions enabled on any collection / global
- If you use the
upload
field- If you have relationship fields that are
hasMany: false
(default)
andrelationTo
to a single category (has
one) relationsWe have a migration for you
Even though the Postgres adapter is in beta, we've prepared a predefined
migration that will work out of the box for you to migrate from an
earlier version of the adapter to the most recent version easily.It makes the schema changes in step with actually moving the data from
the old locations to the new before adding any null constraints and
dropping the old columns and tables.How to migrate
The steps to preserve your data while making this update are as follows.
These steps are the same whether you are moving from Payload v2 to v3 or
a previous version of v3 beta to the most recent v3 beta.Important: during these steps, don't start the dev server unless you
havepush: false
set on your Postgres adapter.Step 1 - backup
Always back up your database before performing big changes, especially
in production cases.Step 2 - create a pre-update migration
Before updating to new Payload and Postgres adapter versions, run
payload migrate:create
without any other config changes to have a
prior snapshot of the schema from the previous adapter versionStep 3 - if you're migrating a dev DB, delete the dev
push
rowfrom your
payload_migrations
tableIf you're migrating a dev database where you have the default setting to
push database changes directly to your DB, and you need to preserve data
in your development database, then you need to delete adev
migration
record from your database.Connect directly to your database in any tool you'd like and delete the
dev push record from thepayload_migrations
table using the following
SQL statement:DELETE FROM payload_migrations where batch = -1
Step 4 - update Payload and Postgres versions to most recent
Update packages, making sure you have matching versions across all
@payloadcms/*
andpayload
packages (including
@payloadcms/db-postgres
)Step 5 - create the predefined migration
Run the following command to create the predefined migration we've
provided:payload migrate:create --file @payloadcms/db-postgres/relationships-v2-v3
Step 6 - migrate!
Run migrations with the following command:
payload migrate
Assuming the migration worked, you can proceed to commit this change and
distribute it to be run on all other environments.Note that if two servers connect to the same database, only one should
be running migrations to avoid transaction conflicts.Related discussion:
https://github.com/payloadcms/payload/discussions/4163
Published by denolfe 5 months ago
userEmailAlreadyRegistered
translations (#6550) (e0a6db7)Published by denolfe 5 months ago
Changes the
fields
override for form builder plugin to use a function
instead so that we can actually override existing fields which currently
will not work.//before fields: [ { name: 'custom', type: 'text', } ] // current fields: ({ defaultFields }) => { return [ ...defaultFields, { name: 'custom', type: 'text', }, ] }
Published by denolfe 5 months ago
disableListColumn
fields not hidden in table columns (#6445) (bcc506b)BREAKING:
- bumps minimum required next.js version from
14.3.0-canary.68
to
15.0.0-rc.0
- bumps minimum required react and react-dom versions to
19.0.0
(19.0.0-rc-f994737d14-20240522
should be used)@types/react
and@types/react-dom
have to be bumped to
npm:[email protected]
using overrides and pnpm overrides, if
you want correct types. You can find an example of this here:
https://github.com/payloadcms/payload/pull/6429/files#diff-10cb9e57a77733f174ee2888587281e94c31f79e434aa3f932a8ec72fa7a5121L32Issues
- Bunch of todos for our react-select package which is having type
issues. Works fine, just type issues. Their type defs are importing JSX
in a weird way, we likely just have to wait until they fix them in a
future update.
Description
Renames the
Save
toSaveButton
, etc. to match the already
established convention of thePreviewButton
, etc. This matches the
imports with their respective component and type names, and also gives
these components more context to the developer whenever they're
rendered, i.e. its clearly just a button and not an entire block or
complex component.BREAKING:
Import paths for these components have changed, if you were previously
importing these components into your own projects to customize, change
the import paths accordingly:Old:
import { PublishButton } from '@payloadcms/ui/elements/Publish' import { SaveButton } from '@payloadcms/ui/elements/Save' import { SaveDraftButton } from '@payloadcms/ui/elements/SaveDraft'
New:
import { PublishButton } from '@payloadcms/ui/elements/PublishButton' import { SaveButton } from '@payloadcms/ui/elements/SaveButton' import { SaveDraftButton } from '@payloadcms/ui/elements/SaveDraftButton'
- I have read and understand the
CONTRIBUTING.md
document in this repository.
Published by denolfe 5 months ago
Change the exports of DefaultListView and DefaultEditView to be renamed
without "Default" as ListView// before import { DefaultEditView } from '@payloadcms/next/views' import { DefaultListView } from '@payloadcms/next/views' // after import { EditView } from '@payloadcms/next/views' import { ListView } from '@payloadcms/next/views'
Published by denolfe 5 months ago
Published by denolfe 5 months ago
BREAKING:
- The minimum required next version is now 14.3.0-canary.68. This is
because we are migrating away from the deprecated
experimental.serverComponentsExternalPackages next config key to
experimental.serverExternalPackages, which is not available in older
next canaries- The minimum
react
andreact-dom
versions have been bumped to
^18.2.0 or ^19.0.0. This matches the minimum react version recommended
by next
next: removes initPage export from barrel file (#6403) (553bb4b)
replaces admin.meta.ogImage with admin.meta.openGraph.images (#6227) (9556d1b)
remove unused staticOptions config on uploads (#6378) (a6bf058)
Removes the unused
staticOptions
on upload config, it was previously
typed to express configuration and is unused anywhere in the codebase
BREAKING: This upgrades all lexical packages from 0.14.5 to 0.15.0.
If there are any breaking changes within lexical, this could break your
project if you use lexical APIs directly (e.g. in custom features). We
have not noticed any breaking changes within core. Please consult their
changelog: https://github.com/facebook/lexical/releases/tag/v0.15.0"