[wp-trac] [WordPress Trac] #43256: wp_delete_post() should use get_post() not wpdb->prepare
WordPress Trac
noreply at wordpress.org
Thu Feb 8 06:22:28 UTC 2018
#43256: wp_delete_post() should use get_post() not wpdb->prepare
-------------------------------+-----------------------------
Reporter: charlestonsw | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Posts, Post Types | Version: 4.9.4
Severity: normal | Keywords:
Focuses: performance |
-------------------------------+-----------------------------
wp_delete_post() uses a custom SQL query to pre-load the post info in a
raw state and ends up adding one extra data I/O call per post/page being
deleted.
This bypasses the WP_Post::get_instance() wp_cache seeding. Consequently
later calls to get_post() such as the 'before_delete_post' action to call
_reset_front_page_settings_for_post() then falls through and calls
WP_Post::get_instance() calling a nearly-identical SQL query (adds LIMIT 1
to to the same query.
Is there any reason why the start of wp_delete_post() should not just call
$post = get_post( $postid ) ?
Replace:
{{{
$post = $wpdb->get_row( $wpdb->prepare( "SELECT * FROM $wpdb->posts
WHERE ID = %d", $postid ) );
if ( ! $post ) {
return $post;
}
$post = get_post( $post );
}}}
With:
{{{
$post = get_post( $postid );
if ( ! $post ) {
return $post;
}
}}}
reference article for in-depth analysis and performance implications is
online at [http://lance.bio/2018/02/08/improving-wp_delete_post-wordpress-
core/]
If this warrants attention I can find time to spin up my VVV box on latest
build and generate a patch file when time allows.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/43256>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list