[wp-trac] [WordPress Trac] #37671: Emptying Bin with large amount of posts results in whitescreen
WordPress Trac
noreply at wordpress.org
Tue Aug 16 03:49:55 UTC 2016
#37671: Emptying Bin with large amount of posts results in whitescreen
-------------------------------------+-------------------------------------
Reporter: atomicjack | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Future Release
Component: Posts, Post Types | Version:
Severity: normal | Resolution:
Keywords: needs-patch needs-unit- | Focuses: administration,
tests | performance
-------------------------------------+-------------------------------------
Changes (by pento):
* keywords: => needs-patch needs-unit-tests
* focuses: administration => administration, performance
* version: 4.5.3 =>
* milestone: Awaiting Review => Future Release
Comment:
Wow, that code is so terribly inefficient.
Some immediate thoughts, ordered by easiest win to hardest.
Order the `$comment_ids` array by `comment_ID DESC`, so that newest
comments are deleted first, and `wp_delete_comment()` doesn't need to re-
parent every single sub-comment that it's just about to delete.
`delete_metadata_by_mid()` could be extended to take an array of meta ids,
none of the actions fired prevent a delete from occurring, so they can all
be fired, then the delete could happen in one query. This could also be
used by `wp_delete_comment()`.
There's a reasonable argument for `wp_delete_posts()` and
`wp_delete_comments()` functions that optimise how they do all their
queries - updating comment and post parents could be optimised, and
clearing the cache can happen at the end.
A new `wp_delete_revisions()` would be able to use `wp_delete_posts()`,
giving more performance benefits.
If someone wants to tackle a patch, I'm happy to review, etc.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/37671#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list