[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:  5.6
Component:  REST API       |     Version:
 Severity:  normal         |  Resolution:
 Keywords:  dev-feedback   |     Focuses:
---------------------------+-----------------------

Comment (by peterwilsoncc):

 Replying to [comment:30 TimothyBlynJacobs]:
 > Any instance where all the post data can't be added via `wp_insert_post`
 arguments will be affected by this. Which is why in my mind when you need
 the absolute completed state of the object, and the action performed is
 final ( you aren't listening for hooks to sync things ), then `save_post`
 should be used as an indicator that a new post is coming and be queued for
 action, but not immediately processed following a pattern similar to what
 I outlined in comment:27.

 This is true but the typical use case for the hooks at the end of
 `wp_insert_post()` has been to update or read post data entered via the
 edit screen. This was lost once the block editor switched to using the
 REST API.

 Separating the hooks to a seperate function would also allow for plugins
 adding posts added programatically to make use of the hooks by calling
 them after terms and meta data has been added. In that sense, I think it
 does solve the underlying problem.

 Re: the code sample above, it prevents the code running on such hooks from
 accessing both the old and new state on transitioning posts. It would be
 possible to pass that around but that would still miss having an up-to-
 date post when Core creates revisions, processing term counts and some
 other functionality. I've experimented with
 [https://github.com/peterwilsoncc/wp-populated-publish moving the actions
 to later hooks in a plugin] and it causes other problems.

 Using the shutdown hook also becomes problematic when adding multiple
 posts via wp-cli, as the shutdown hook only runs once rather than each
 time a post is updated.


 ----

 I accept your concern it's risky and I regret not pushing harder for a fix
 back in 5.0 but having tried several approaches haven't been able to
 discover a less risky way of doing it.

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