[wp-trac] [WordPress Trac] #39418: Improve "Empty Spam" and "Empty Trash" user experience

[WordPress Trac]

#39418: Improve "Empty Spam" and "Empty Trash" user experience
-------------------------------------------------+-------------------------
 Reporter:  johnjamesjacoby                      |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Administration                       |     Version:  2.5
 Severity:  normal                               |  Resolution:
 Keywords:  needs-patch 2nd-opinion ui-feedback  |     Focuses:  ui
  has-ux-feedback needs-screenshots              |
-------------------------------------------------+-------------------------

Comment (by cfinke):

 I was able to achieve an 85% reduction in the time it took the next page
 to load after clicking "Empty Spam", but one major problem remains: the
 `current_user_can( 'edit_comment', $comment_id )` call that is made for
 each comment takes a significant amount of time on its own.  My new method
 would still require this call to ensure that a user is not removing a
 comment from Spam that they don't have permission to modify.

 I tested the two methods with sets of 10,000 randomly generated comments.
 The times listed are how long it took to process the deletion request, but
 doesn't include the additional time the new method would take to actually
 delete the comments later.

 `Current "Empty Spam" method: 56.7 seconds (on average)`

 `New "Empty Spam" method: 8.5 seconds (on average)`

 The calls to `current_user_can` took about 7 seconds for each of these
 methods.  Since it's not impossible for a user to have hundreds of
 thousands of spam comments, just those calls could take many minutes to
 complete.

 Employing a method like @johnjamesjacoby suggested where clicking "Empty
 Spam" triggers an async process that shows its progress somewhere in the
 admin would "avoid" this problem, since the actual runtime of the process
 wouldn't matter so much.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/39418#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform