Opened 9 years ago
Last modified 6 years ago
#36603 new enhancement
wp_publish_post() does not fire post_updated action
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.6 |
Component: | Posts, Post Types | Keywords: | has-patch |
Focuses: | Cc: |
Description
do_action( 'post_updated', $post_ID, $post_after, $post_before);
Gives convenient access to before/after state of the post for actions that are conditional on exact changes performed.
wp_publish_post()
inconsistently doesn't fire this hook, even though it does fire edit_post
and save_*
hooks that come before and after it. This makes it impossible to rely on post_updated
hook since it will never fire for any update performed by wp_publish_post()
.
Attachments (1)
Change History (10)
@
9 years ago
I have added post_updated
action in wp_publish_post()
which is fire after edit_post
action.
#3
@
9 years ago
Within core wp_publish_post()
is only called from check_and_publish_future_post()
, it lacks two features of wp_update_post()
and wp_insert_post()
:
post_updated
does not firewp_post->date_modified
does not changewp_post->date_modified_gmt
does not change
My educated guess is it's by design and publishing a scheduled post is not considered an update per se.
A number of suitable actions are fired in wp_transition_post_status()
, my inclination is to leave wp_publish_post()
unchanged.
#4
follow-up:
↓ 5
@
9 years ago
My educated guess is it's by design and publishing a scheduled post is not considered an update per se.
It changes one of the most important post fields in a major way. If it's by design I would like to hear a reason why it shouldn't be handled consistently with every other post change.
A number of suitable actions are fired in wp_transition_post_status()
None of the hooks in status transition give access to full before/after state of the post.
#5
in reply to:
↑ 4
@
9 years ago
Replying to Rarst:
My educated guess is it's by design and publishing a scheduled post is not considered an update per se.
It changes one of the most important post fields in a major way. If it's by design I would like to hear a reason why it shouldn't be handled consistently with every other post change.
I can get on board with the idea that publishing a scheduled post constitutes a post update.
On whether we should add the hook, I actually wonder if maybe we shouldn't look at deprecating wp_publish_post()
and switch to using wp_insert_post()
in check_and_publish_future_post()
instead. You can attempt to maintain a parallel use-case for only so long before it becomes pointless.
Of course we pick up a hook or two in the process, but it also would streamline the API a bit. It would need a good bit of tests to make sure we aren't breaking something.
#6
@
9 years ago
Replying to peterwilsoncc:
My educated guess is it's by design and publishing a scheduled post is not considered an update per se.
That's the point I guess :) Users can actually modify a scheduled post before publishing it and as far as I understand there's no way to detect this. By the way seems the history here is a bit complicated see [21942] and [23206] and the related tickets and see also 21963.
Related: #24957