[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:  dev-feedback   |     Focuses:
---------------------------+------------------------------

Comment (by kraftbj):

 Replying to [comment:27 TimothyBlynJacobs]:
 > I definitely think this is a risk. And to me it seems conceptually
 simpler that for block editor post types, use `rest_after_insert` and for
 others use `save_post` and call it a day.
 >

 That doesn't work because the REST API isn't the exclusive way to edit
 those post types. Ignoring the Classic Editor, something like someone
 using a XML-RPC client (or Press This) to save a post sometimes and using
 the block editor sometimes.

 >
 > I wonder if there is a more resilient way of doing these kinds of checks
 that rely on `save_post` in the first place? Because while the REST API is
 the primary way people are having this issue, it would happen with any
 code that does a `wp_insert_post()` and then updates meta fields or uses
 `wp_set_post_terms` afterwords, which is pretty common for plugins to do.
 >
 > My instinct is to write it something like this:

 This feels suboptimal to me given the simplicity of being able to use
 `save_post` before, but probably the most practical solution.

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