Emptying Bin with large amount of posts results in whitescreen

[atomicjack]

When the Bin has a large amount of posts, e.g over 1,500, clicking Empty takes a long time to load, several minutes.

After it finishes, it loads a blank white page and has only deleted about 75% of the posts. There's ~500 remaining.

[justingreerbbi]

I am not sure this would be classified as a bug. It seems more like a server resource issue.

[hiddenpearls]

This might be because of max_execution_time of your server. Please increase it.

[atomicjack]

Replying to hiddenpearls:

This might be because of max_execution_time of your server. Please increase it.

In this case, would it be better for WordPress to check the max execution time and display a message before it occurs? So that the user has feedback, rather than a plain white page.

[justingreerbbi]

Replying to atomicjack:

Replying to hiddenpearls:

This might be because of max_execution_time of your server. Please increase it.

In this case, would it be better for WordPress to check the max execution time and display a message before it occurs? So that the user has feedback, rather than a plain white page.

No. WP can not know how much time it needs to remove the old posts. You may be able to run a execution timer that errors out right before it hits it limit but there is just too many variables in play. For an issue that can be remedied with a resource adjustment, there is not much need for a complex system. You are more than welcome to make a patch and submit it!

[peterwilsoncc]

The process WP takes to empty the trash is:

• Loop through selected posts:
  • check if user has permission to delete post, die if not
  • check the type of post
  • delete the post
    • delete revisions (itself a loop)
    • delete comments (a loop)
    • delete post meta (a loop)
    • DELETE post
    • unschedule if a future post

The action from this ticket becomes: optimise the processes of emptying the trash and deleting a post.

Further discussion would be whether this is worth-while, as is often the case the questions and thought experiments to run are:

• what are the pros and cons of doing so
• what are the pros and cons of not doing so
• what is the worst that can happen by doing this

[pento]

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.

[peterwilsoncc]

This ticket needs to be split up.

#37702: Accept array of IDs in delete_metadata_by_mid
#37703: Optimise wp_delete_comment as called from wp_delete_post

More to come.

[topher1kenobe]

Pippin made an excellent plugin for deleting thousands of comments. That process had/has this same issue, I'd recommend rolling it into core for both comments and all trashes. ​https://wordpress.org/plugins/batch-comment-spam-deletion/

[pbearne]

Is this still an issue?

[topher1kenobe]

Yes.

[pbearne]

I am thinking that we should look to the new Admin UI to have a task runner that can loop list of IDs and do an action on them with a nice process bar UI

This could used for this and any other bulk action