Make WordPress Core

Opened 9 years ago

Closed 4 years ago

Last modified 4 years ago

#30940 closed enhancement (fixed)

Extend delete actions arguments

Reported by: jadpm's profile jadpm Owned by: ocean90's profile ocean90
Milestone: 5.5 Priority: normal
Severity: normal Version: 4.2
Component: Posts, Post Types Keywords: has-patch
Focuses: Cc:

Description

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 9 years ago.
30940-2.patch (2.8 KB) - added by jadpm 9 years ago.

Download all attachments as: .zip

Change History (11)

@jadpm
9 years ago

#1 @helen
9 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
9 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
9 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.

@jadpm
9 years ago

#4 @jadpm
9 years ago

  • Keywords has-patch added

#5 @SergeyBiryukov
9 years ago

  • Type changed from feature request to enhancement

Related: #31813

#7 @ocean90
4 years ago

  • Milestone set to 5.5

#8 @ocean90
4 years ago

  • Owner set to ocean90
  • Resolution set to fixed
  • Status changed from new to closed

In 47582:

Posts, Post Types: Pass the post object to the before_delete_post, delete_post, deleted_post, and after_delete_post actions.

Props jadpm.
Fixes #30940.

#9 @ocean90
4 years ago

In 47856:

Posts, Post Types: Pass the post object to the delete_attachment action.

Also add the missing $post parameter to the delete_post and deleted_post actions in wp_delete_attachment().

See #30940.

Note: See TracTickets for help on using tickets.