[wp-trac] [WordPress Trac] #45114: Fire publishing related hooks after all data is saved via the REST API.

[WordPress Trac]

#45114: Fire publishing related hooks after all data is saved via the REST API.
---------------------------+------------------------------
 Reporter:  peterwilsoncc  |       Owner:  (none)
     Type:  defect (bug)   |      Status:  reopened
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  REST API       |     Version:
 Severity:  normal         |  Resolution:
 Keywords:                 |     Focuses:
---------------------------+------------------------------

Comment (by kraftbj):

 Looking at this a bit closer, I'm interested in attempting the following
 approach:

 1. It appears the primary reason `create_item` in the REST posts
 controller runs `wp_insert_post` so early is to get a post ID back for use
 in the rest of the insert method.

 2. For non-updates, the logic in `wp_insert_post` is pretty simple to get
 an ID -- just `$wpdb->insert` into the posts table.

 3. Create a new Core function to "reserve" a post ID. For BC with
 `wp_insert_post`, the status can be `new` to mimic what `wp_insert_post`
 is doing and have a default dummy/blank information.

 4. The REST controller can call that function to get a post ID, do the
 work it is doing with the extra information and then call `wp_insert_post`
 to add everything (including the proper status) to the post.

 An alternative could be to do `wp_insert_post` as it is done right now,
 except not pass the status, retaining it for later. Then, just prior to
 `rest_after_insert_` hook, update the post with the proper status.

 I'm thinking the second scenario may be safer and would in particular help
 with my case of a "published" post firing the `wp_insert_post` hook
 prematurely, but open to anyone's thoughts about it.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/45114#comment:22>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform