Opened 4 years ago
Closed 12 months ago
#52635 closed defect (bug) (worksforme)
Save revisions on the `wp_after_insert_post` action
Reported by: | peterwilsoncc | Owned by: | adamsilverstein |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Revisions | Keywords: | needs-patch needs-testing needs-dev-note |
Focuses: | rest-api | Cc: |
Description
Currently revisions are created on the post_updated
hook which fires within wp_insert_post()
, wp_publish_post()
and related functions.
The call to wp_save_post_revision()
is added by core as a default action:
add_action( 'post_updated', 'wp_save_post_revision', 10, 1 );
For sites wishing to save meta data with their revisions via a plugin this occurs prior to meta data saving been saved in the rest api and therefore the block editor. This results in an off-by-one error for the meta data stored against each revision.
Moving the generation of revisions to the wp_after_insert_post
hook added in WordPress 5.6 will ensure that the post object, terms and meta data have all been saved before the revision is generated.
As the wp_after_insert_post
hook fires on both post creation and post update, a maybe save wrapper function may be needed to determine if the revisions should actually be generated. (Or a wp_after_update_post
hook but ideally not.)
Backward compatibility
A search of the WordPress repositories show that 14 plugins (the highest with 3,000,000+ installs) and zero themes are de-registering the default action to save revisions.
To maintain backward compatibility WP might need to allow for removing the hook on post_updated
.
Change History (2)
#2
@
12 months ago
- Milestone Awaiting Review deleted
- Resolution set to worksforme
- Status changed from assigned to closed
Revisions are now saved on wp_after_insert_post
as requested by this ticket, since https://core.trac.wordpress.org/changeset/56714.
Closing this as fixed, thanks @peterwilsonccfor opening - if I missed anything feel free to reopen.
Great suggestion @peterwilsoncc I was thinking the same when the new hook was added. I'll try to look into this further. Thanks for the plugin reference, that is helpful to have to ensure we don't break backwards compatibility.