WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 6 months ago

#36603 new enhancement

wp_publish_post() does not fire post_updated action

Reported by: Rarst Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.6
Component: Posts, Post Types Keywords: has-patch
Focuses: Cc:
PR Number:

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)

36603.patch (1000 bytes) - added by chandrapatel 4 years ago.
I have added post_updated action in wp_publish_post() which is fire after edit_post action.

Download all attachments as: .zip

Change History (10)

#1 @SergeyBiryukov
4 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 4.6

Related: #24957

@chandrapatel
4 years ago

I have added post_updated action in wp_publish_post() which is fire after edit_post action.

#2 @Rarst
4 years ago

  • Keywords has-patch added; needs-patch removed

#3 @peterwilsoncc
3 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 fire
  • wp_post->date_modified does not change
  • wp_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: @Rarst
3 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 @DrewAPicture
3 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 @afercia
3 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.

This ticket was mentioned in Slack in #core by chriscct7. View the logs.


3 years ago

This ticket was mentioned in Slack in #core by voldemortensen. View the logs.


3 years ago

#9 @voldemortensen
3 years ago

  • Milestone changed from 4.6 to Future Release

This seems to need significant discussion which probably won't happen in time for 4.6, punting.

Note: See TracTickets for help on using tickets.