[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:
---------------------------+------------------------------
Changes (by kraftbj):

 * type:  enhancement => defect (bug)


Comment:

 I'd still expect these hooks to fire after the complete data has been
 saved and personally vote to still correct this.

 The particular use case I'm running into (a separate Jetpack instance from
 what is mentioned above):

 0. We fire off an action at `wp_insert_post` to handle post changes.
 1. We have a filter for an array of categories that a post in any of those
 categories would be excluded from being e-mailed out (our Subscriptions
 feature).
 2. We hook onto `wp_transition_post_status` to check if a post is being
 newly published to begin the process of flagging a post to be e-mailed
 out.
 3. Within that, we check if that being-published post is in a category
 that matches one from the array in item 1 above.

 In the Classic Editor or non-REST requests, `wp_insert_post` adds the
 categories/tags/terms at L3937
 https://github.com/WordPress/WordPress/blob/5.3/wp-includes/post.php#L3937
 and then L4136 https://github.com/WordPress/WordPress/blob/5.3/wp-
 includes/post.php#L4136 at the end of all of the work, actually fires off
 the function.

 In the REST API, `update_item` fires `wp_update_post` (which through all
 of the steps fires `wp_insert_post` and that hook) at L692 (
 https://github.com/WordPress/WordPress/blob/5.3/wp-includes/post.php#L4136
 ) and then later `handle_term` for categories, etc at L730
 https://github.com/WordPress/WordPress/blob/5.3/wp-includes/rest-
 api/endpoints/class-wp-rest-posts-controller.php#L730 .

 While I think this should be fixed so the behavior of `wp_insert_post`, et
 al matches the docs and previous behavior going back to 2.0, if nothing
 else, could we add a *new* hook that fires at the end of both processes.

 I kid with the name, but a `wp_insert_post_for_real` that we can add both
 in the `class-wp-rest-posts-controller.php` before the response AND at the
 end of `post.php` where `wp_insert_post` is already.

 The inline documentation of those hooks should be modified to clarify the
 different behaviors and that they're somewhat unreliable, to be frank.

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