#30940 closed enhancement (fixed)
Extend delete actions arguments
Reported by: |
|
Owned by: |
|
---|---|---|---|
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)
Change History (11)
#2
@
10 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
@
10 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.
This ticket was mentioned in PR #202 on WordPress/wordpress-develop by ocean90.
5 years ago
#6
Trac ticket: https://core.trac.wordpress.org/ticket/30940
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.