Title: save_post hook $update parameter
Last modified: February 15, 2017

---

# save_post hook $update parameter

 *  [Charles St-Pierre](https://wordpress.org/support/users/charlesstpierre/)
 * (@charlesstpierre)
 * [9 years, 3 months ago](https://wordpress.org/support/topic/save_post-hook-update-parameter/)
 * In the save_post hook, how exactly does the $update parameter work?
    It “seems”
   unstable from time to time.
 * I took a look in wp_insert_post, and $update is set to TRUE if the $postarr array
   specifies the ID.
 * I might be mistaken, but from a user standpoint, when you start creating a post
   and save it for the first time, $update must be false. However, it doesn’t always
   seem to be the case.
 * Is it because of the draft auto-save? If it is, the $update parameter is really
   counter intuitive.
 * What would be the right way to know if save_post is running an $update or not.
   
   I’ve seen a comparison between $post->post_date and $post->post_modified but 
   it doesn’t seem exactly right. There is the classic DOING_AUTOSAVE constant check,
   but I guess that funks the thing up.
 * Shouldn’t the $update be better designed?

Viewing 2 replies - 1 through 2 (of 2 total)

 *  Moderator [bcworkz](https://wordpress.org/support/users/bcworkz/)
 * (@bcworkz)
 * [9 years, 3 months ago](https://wordpress.org/support/topic/save_post-hook-update-parameter/#post-8810601)
 * User standpoint? What (end) user is using $update? 🙂
 * I know what you mean. It’s essentially a flag for whether an existing post record
   should be updated or a new one created. Very similar (but not identical) to your
   observation about the ID. Yes, the auto-save facility confuses the issue. Auto-
   saves of published posts do not update the original post record. I see $update
   more as an internal variable and never make use of it myself. I’ve found all 
   the control I need from the various hooks generated by wp_transition_post_status().
   I find these preferable to “save_post”, which is often much too broad. For example,
   newly published posts fire “draft_to_publish” and published posts being updated
   fire “publish_to_publish”. $update is not available through these, there’s no
   need.
 * Once you accept that $update is mainly an internal variable, then there is no
   need to “design” it better. It works fine as an internal variable, even if it
   doesn’t make intuitive sense. I suspect it was never truly “designed”. Initially,
   it probably was very clear how it worked. As WP evolved, it’s use morphed to 
   fulfill new needs to the point the assigned “update” moniker no longer made complete
   sense.
 *  Thread Starter [Charles St-Pierre](https://wordpress.org/support/users/charlesstpierre/)
 * (@charlesstpierre)
 * [9 years, 3 months ago](https://wordpress.org/support/topic/save_post-hook-update-parameter/#post-8810704)
 * I tell the End user (my client) that a bunch of stuff gets done when he first
   creates a custom post_type Post. I tell him all works fine, because I tested 
   it. When he creates the Post, he takes more time than me, and the “bunch of stuff”
   doesn’t get done because by the time he saves, it’s “an update”.
 * The transition_post_status is a good way to go in some cases, thanks for reminding
   me.
 * Still, I believe there should be a way to hook when the user “creates a new post”.
   That is a Human action that should be easily identified.

Viewing 2 replies - 1 through 2 (of 2 total)

The topic ‘save_post hook $update parameter’ is closed to new replies.

 * In: [Developing with WordPress](https://wordpress.org/support/forum/wp-advanced/)
 * 2 replies
 * 2 participants
 * Last reply from: [Charles St-Pierre](https://wordpress.org/support/users/charlesstpierre/)
 * Last activity: [9 years, 3 months ago](https://wordpress.org/support/topic/save_post-hook-update-parameter/#post-8810704)
 * Status: not resolved

## Topics

### Topics with no replies

### Non-support topics

### Resolved topics

### Unresolved topics

### All topics