beforeValidate hook changes still require page refresh to reflect changes with versions enabled.
Describe the Bug
I celebrated too early upon seeing #9691 and #10268, however, the issue still persists for me when versions are enabled for a collection.
when beforeValidate hooks run, their changes are not reflected in the UI until a user manually refreshes the page.
Link to the code that reproduces this issue
https://github.com/HarleySalas/payload-3-reproductions/tree/before-validate-requires-refresh
Reproduction Steps
clone the repo. sqlite contains the necessary data. You will be autologged in and you can visit the page collection to observe the behavior by removing the slug field and saving the document to get the slug to be generated via the Title field. Removing versions results in it working fine. As soon as it's got versions enabled, it just stops working and requires a full refresh to see changes reflected on the page.
Which area(s) are affected? (Select all that apply)
area: core
Environment Info
Payload: 3.16.0
Node: 22.2.0
SQLite, Postgres 16
I'm also having the same issue on 3.16.0. I have versions, drafts, and autosave enabled.
I also experienced the same thing with the beforeChange hook
I plan to look into this ASAP - just giving a quick update here
Just to chime in here with a few of my findings related to this issue:
Alongside the issues with the Admin UI not reflecting changes via hooks when autosave is enabled, hooks sometimes receive stale content from other related resources / fields.
Reproduction Steps
This is pretty easy to replicate using the default website template, here are a couple of examples:
Example 1 (Admin UI not updating)
Use the value of the "Title" field in a hook to update the SEO "Title" field:
- Add a basic beforeValidation hook to the existing
MetaTitleFieldfunction in the pages collection:
...,
overrides: {
hooks: {
beforeValidate: [({ data, value }) => (value = data?.title || '')],
},
}
...
- The meta "Title" field wont update until the page is refreshed.
Example 2 (data exposed to hooks is stale)
Using the included nested docs plugin:
- Enable nested docs for the pages collection in
src/plugins/index.ts. - Add a field with a basic beforeValidation hook like so:
...,
{
name: 'uri',
type: 'text',
hooks: {
// use the last breadcrumb's url as the uri for this doc.
beforeValidate: [({ data, value }) => (value = data?.breadcrumbs?.pop()?.url || '')],
},
},
...
- Create a new page and add a title.
- Breadcrumbs via the
nested docs pluginwont update until refresh. - The newly added URI field wont update even after refresh.
- The URI field will only update after another save and refresh.
Hypothesis / Findings
Disabling autosave and following the same step - instead this time clicking "Save Draft" rather than relying on autosave results in all fields being filled out correctly with no need for a refresh or additional save.
The issues with the nested docs plugin are far more impactful than just the admin ui not updating, digging deeper into the records returned when querying breadcrumbs on a draft doc show that the initial draft doc is returned and not the most recent autosave. Again, this is not the result when using the manual "Save Draft" button instead of autosave.
Further Context
To provide some context, I've tested this with the latest releases of Payload (at the time of writing) along with testing in Payload 2.0 and can see these issues are also present there. A best guess is some issue with the autosave function itself and how it bubbles events. As stated, without autosave enabled, when the standard "Save Draft" button is used, hooks work as expected, so this (as far as I can tell) points to something in the event lifecycle for autosave.
Payload: 3.18.0
@payloadcms/plugin-nested-docs: 3.18.0
Node: 20-Alpine
Mongo
If any further info or context is required please just let me know, I'm happy to provide more examples. Thanks for your continued work on this awesome CMS Payload team <3
Ah yes we have pretty much the exact same findings as jeremy, +1
Also here the same problem
Here too!
Having the same problem on 3.32.0. Can confirm that disabling autosave fixes it for me as well.
Same issue for me using 3.33.0, took me quite some time to find this issue and figure out this was a bug :/
Same issue for us on v3.36.1, though we're using a beforeChange hook. Disabling autosave fixes the issue.
I also see this issue on 3.41.0 if using beforeChange AND using versions.drafts.autosave: true. If I disable autosave, it works as expected.
I also have this issue on v.3.36.1, any progress on this?
I've got a fix queued up here: #13416
🚀 This is included in version v3.51.0
This issue has been automatically locked. Please open a new issue if this issue persists with any additional detail.