WordPress.org

Make WordPress Core

Opened 6 months ago

Last modified 2 months ago

#42864 assigned defect (bug)

REST API: Fire an action after items are completely inserted/updated

Reported by: pento Owned by: danielbachhuber
Milestone: 5.0 Priority: normal
Severity: normal Version:
Component: REST API Keywords:
Focuses: rest-api Cc:

Description

In wp_insert_post() and wp_insert_comment(), the corresponding wp_insert_post and wp_insert_comment actions are run at the very end, after all meta and additional fields are inserted or update.

The equivalent REST API rest_insert_* actions are fired before the meta and additional fields are updated - there isn't an action to hook into, which is triggered after.

I expect this to become more of an issue with Gutenberg, as the behaviour of the existing post editor is that the post and related data have been completely updated by the time wp_insert_post fires.

Related: Gutenberg#3898, #38905.

Change History (3)

#1 @joemcgill
6 months ago

One side affect of this behavior is that if you're trying to support post meta in revisions, there is no hook that fires at the end of the process, meaning meta gets out of sync by one revision each time a new post + meta is saved.

Relevant code is in WP_REST_Posts_Controller::update_item() and it may be relevant that the rest_insert_* hooks were moved to higher up in the method in r39288.

#2 @rmccue
6 months ago

I thought these were also inconsistent, but as it turns out, I think r39288 helped make them consistent, although in the process we lost a crucial ability. We should introduce common hooks across all of these for a final action:

  • rest_insert_attachment is after attachment creation/update, but before meta + additional fields
  • rest_insert_comment is after comment creation/update, but before meta + additional fields
  • rest_insert_{post} is after post creation/update, but before meta + additional fields + sticky + terms + featured media ({post} is the post type).
  • rest_insert_{term} is after term creation/update, but before meta + additional fields ({term} is the taxonomy)
  • rest_insert_user is after user creation/update, but before roles + meta + additional fields

These actions are still useful if you want to do something when the object is updated, but not as useful as they could be.

I'm thinking a rest_did_insert_{type} for all of these across the board, called with the same parameters, but fired at the end of the relevant method rather than after the object change.

#3 @danielbachhuber
2 months ago

  • Owner set to danielbachhuber
  • Status changed from new to assigned
Note: See TracTickets for help on using tickets.