Improve "Empty Spam" and "Empty Trash" user experience

[johnjamesjacoby]

Now that plugins are doing more with post types, and dealing with sometimes hundreds of thousands of entries in the posts table, emptying spam and/or trash is starting to feel a little outdated.

When there is a need to empty many spam or trashed items, it's not uncommon for this page to timeout, or to reload in the browser in such a way that rendering is blocked while the server processes the mass deletion of content.

In my imagination, it would be a nice improvement to fallback to the current behavior for noscript, but to leverage the power of javascript being asynchronous to provide some kind of modal window to chug through the process, maybe with a progress bar and some basic error feedback if the empty action fails for any reason.

[karmatosed]

Experience wise this sounds like a really great idea. Any timeouts or stalling due to a large number is not a great experience. Beyond anything else we should be telling someone how long something has to go, if it takes long enough to notice.

I'm wondering if we can also bring in other visual experience improvements? Are there any good examples we can look at for inspiration outside of WP?

[cfinke]

Instead of actually doing the work of deleting all of the spam messages when "Empty Spam" is clicked, what about updating the comment_approved field of all spam comments to be something like spam-pending-delete, and then have the WP cron delete any comments with comment_approved=spam-pending-delete in batches.

That should reduce the delay significantly from the time when the user clicks the button to when their Spam folder appears to be empty, and it wouldn't require any new UI.

[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.

This changes the Comments screen Empty Spam/Empty Trash action to use AJAX batches when JavaScript is available, while keeping the existing form submit path as the no-JS fallback.

Validation:

• php vendor/bin/phpcbf --standard=phpcs.xml.dist src/wp-admin/admin-ajax.php src/wp-admin/includes/ajax-actions.php tests/phpunit/tests/ajax/wpAjaxDeleteComment.php
• php vendor/bin/phpcs --standard=phpcs.xml.dist src/wp-admin/admin-ajax.php src/wp-admin/includes/ajax-actions.php tests/phpunit/tests/ajax/wpAjaxDeleteComment.php
• npx grunt jshint:core --file=src/js/_enqueues/admin/edit-comments.js
• npm run test:php -- --group ajax tests/phpunit/tests/ajax/wpAjaxDeleteComment.php

[arkaprabhachowdhury]

Opened [PR #12420](​https://github.com/WordPress/wordpress-develop/pull/12420) to address this ticket. This changes the Comments screen Empty Spam/Empty Trash action to use AJAX batches when JavaScript is available, while keeping the existing form submit path as the no-JS fallback. Validation: - php vendor/bin/phpcbf --standard=phpcs.xml.dist src/wp-admin/admin-ajax.php src/wp-admin/includes/ajax-actions.php tests/phpunit/tests/ajax/wpAjaxDeleteComment.php - php vendor/bin/phpcs --standard=phpcs.xml.dist src/wp-admin/admin-ajax.php src/wp-admin/includes/ajax-actions.php tests/phpunit/tests/ajax/w The PR includes focused regression coverage, and its validation details are recorded in the PR description.

I picked this up because the ticket describes a concrete core behavior or edge case that remains relevant in current WordPress. The proposed change is intentionally scoped to the ticket and is submitted here for code review, with the technical discussion remaining on this ticket.