Releases: payloadcms/payload
v3.0.0-beta.43
v3.0.0-beta.43 (2024-06-07)
Features
- adds draft validation option (#6677) (52c81ad)
- plugin-redirects: update fields overrides to use a function (#6675) (e4a9029)
- richtext-*: allow omitting the root editor property (#6660) (11c3a65)
- upgrade minimum node 20 version from 20.6.0 to 20.9.0 (#6659) (9bd9e7a)
Bug Fixes
- next: live preview device position when using zoom (#6665) (7c8d562)
- max versions config not being respected on globals (#6654) (8dd5e4d)
BREAKING CHANGES
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)
Contributors
- Jarrod Flesch (@JarrodMFlesch)
- Paul (@paulpopus)
- Jacob Fletcher (@jacobsfletch)
- Alessio Gravili (@AlessioGr)
v2.19.3
v3.0.0-beta.42
v3.0.0-beta.42 (2024-06-06)
Bug Fixes
Contributors
- Jacob Fletcher (@jacobsfletch)
- Alessio Gravili (@AlessioGr)
v2.19.2
v3.0.0-beta.41
v3.0.0-beta.41 (2024-06-05)
Features
- support Next.js basePath config property (#6628) (b2751f7)
- ui: expose RowLabelProps (#6627) (1afd221)
- richtext-lexical: upgrade lexical from 0.15.0 to 0.16.0 and port over relevant playground changes (#6620) (da35afb)
Bug Fixes
- db-postgres: create predefined migration missing json schema output (#6641) (ff82bb5)
- update file-type dependency and fix dependency version mismatch (#6638) (2077da8)
- translations: explicitly declare date-fns v3 as a dependency (#6626) (aeb4df8)
- resizing animated images (#6623) (bcd277e)
- migration file cannot be imported (#6616) (cafc13a)
BREAKING CHANGES
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.
- richtext-lexical: upgrade lexical from 0.15.0 to 0.16.0 and port over relevant playground changes (#6620) (da35afb)
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
Contributors
- Dan Ribbens (@DanRibbens)
- Alessio Gravili (@AlessioGr)
- Elliot DeNolf (@denolfe)
- Jacob Fletcher (@jacobsfletch)
- Patrik (@PatrikKozak)
- Paul (@paulpopus)
v3.0.0-beta.40
v3.0.0-beta.40 (2024-06-04)
Features
- match next.js env file loading behavior in bin scripts & importConfig, clean up installed packages & mismatching package versions (#6601) (59cde0d)
- richtext-lexical: configurable fixed toolbar (#6560) (f41bb05)
Bug Fixes
- pin ajv to 8.14.0, as 8.15.0 is broken (#6606) (45b02d8)
- plugin-form-builder: fix bug with optional chain operator in field overrides logic (#6602) (1aece39)
- db-postgres: type issue in migratePostgresV2toV3 call if ts strict mode is enabled (#6585) (c3589de)
- richtext-lexical: minor design improvements (#6575) (c7fbd76)
- critical getPredefinedMigration dependency error (#6578) (6b9c796)
- richtext-*: fix client features were not loaded properly, improve performance of LexicalProvider, slate cell component was non-functional, support richtext adapter Cell RSCs (#6573) (5cb49c3)
BREAKING CHANGES
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
Contributors
- Alessio Gravili (@AlessioGr)
- Paul (@paulpopus)
v2.19.1
v2.19.0
2.19.0 (2024-06-04)
Features
Bug Fixes
- pin ajv to 8.14.0, as 8.15.0 is broken (#6607) (4a54aa7)
- adds new
userEmailAlreadyRegistered
translations (#6549) (56c6700), closes #6535 - adjusts sizing of remove/add buttons to be same size (#6527) (a352ebc), closes #6098
- focalPoint undefined handling (#6552) (fcfc3c5)
- pagination on polymorphic relationship field requesting entries with page parameter set to NaN (#5366) (547acfe)
- safely evaluates
field.admin
in WhereBuilder (#6534) (4f9d78d) - separate sort and search fields when looking up relationship. (#5964) (c009219), closes #4815 #5222
- ui field validation error with
admin.disableListColumn
property (#6530) (eeddece), closes #6521 - ui: blocks browser save dialog from opening when hotkey used with no changes (#6365) (8f03cd7), closes #214
v3.0.0-beta.39
v3.0.0-beta.39 (2024-05-30)
Features
Bug Fixes
BREAKING CHANGES 💥
Moves upload
field and relationship
fields with hasMany: 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
and relationTo: '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 a category_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) relations
We 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 have push: 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 version
⚠️ Step 3 - if you're migrating a dev DB, delete the dev push
row from your payload_migrations
table
If 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 a dev
migration record from your database.
Connect directly to your database in any tool you'd like and delete the dev push record from the payload_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/*
and payload
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:
#4163
Contributors
- Elliot DeNolf (@denolfe)
- Dan Ribbens (@DanRibbens)
- Jacob Fletcher (@jacobsfletch)
v3.0.0-beta.38
v3.0.0-beta.38 (2024-05-30)
Features
- next,ui: improves loading states (#6434) (92f458d)
- extracts buildFormState logic from endpoint for reuse (#6501) (321e97f)
Bug Fixes
- cpa: safer command exists check (#6569) (4884f0d)
- ui: adjusts sizing of remove/add buttons to be same size (#6529) (f1db24e)
- ui field validation error with admin.disableListColumn property (#6531) (7f15147)
- translations: adds new
userEmailAlreadyRegistered
translations (#6550) (e0a6db7) - cpa: more package manager detection improvements (#6566) (0d7d3e5)
- duplicate options appearing in relationship where builder (#6557) (3474642)
- plugin-search: Render error on custom UI component (#6562) (aa02801)
- ensure relationship field pills respect isSortable property (#6561) (425576b)
- ability to query relationships not equal to ID (#6555) (043a91d)
Contributors
- Elliot DeNolf (@denolfe)
- Patrik (@PatrikKozak)
- Jarrod Flesch (@JarrodMFlesch)
- Paul (@paulpopus)
- Jessica Chowdhury (@JessChowdhury)
- Jacob Fletcher (@jacobsfletch)