[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