Make WordPress Core

Opened 5 years ago

Last modified 5 months ago

#30940 new enhancement

Extend delete actions arguments

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


When using wp_delete_post(), four actions are fired: before_delete_post, delete_post, deleted_post and after_delete_post. All of them get the $postid argument.

In some situations, it might be useful to have some extra information about the post being deleted, to perform different actions depending on things like the post date or the post type. With extensive usage of custom post types, this becomes more evident.

We can always get that data from the post ID being passed as an argument on those four actions, but that will add extra database calls that we can easily avoid. Early in wp_delet_post(), we do get the post row object from the database to check for things like post type and post parent. It seems a waste to recreate that data again if needed, plus it is not there anymore on the last two actions due to, well, post deletion. This limits what can be done on those last two actions in a granular way (no different deleted_post action callback workflow on a per post type basis, for example).

I propose to extend those foud actions to take another optional argument, $post, being the post row object.

Attachments (2)

30940.patch (2.0 KB) - added by jadpm 5 years ago.
30940-2.patch (2.8 KB) - added by jadpm 5 years ago.

Download all attachments as: .zip

Change History (7)

5 years ago

#1 @helen
5 years ago

Do you think it would be confusing to developers that it's not a WP_Post object? Do we do this anywhere else? I don't disagree that the hooks could use more context, after_delete_post in particular since the post won't exist anywhere anymore, not even in cache.

#2 @jadpm
5 years ago

Yes, I though about that. But since the variable being used is te same old known $post although it refers to a row object, I just went along and kept it that way. May it be better to perform a WP_Post::get_instance() instead of doing a $wpdb->get_row()?

#3 @jadpm
5 years ago

New patch that creates and passes a WP_Post object.

I first thought about using WP_Post::get_instance, but it is quite useless to create cached data that is going to be deleted right away. AFAIK, creating a WP_Post object from the row object does not add anything extra but mapping the row attributes into the WP_Post object ones.

5 years ago

#4 @jadpm
5 years ago

  • Keywords has-patch added

#5 @SergeyBiryukov
5 years ago

  • Type changed from feature request to enhancement

Related: #31813

Note: See TracTickets for help on using tickets.