Automatically Move New WordPress Comments to Trash with Custom Code

Last Updated:

This WordPress blog occasionally receives legitimate comments, but it has been inundated with spam comments. To combat this issue, several strategies have been employed.

  1. Added code to prevent comments that are either too short or excessively long from being posted.
  2. Redirected all new comments to the trash and only restored legitimate ones while permanently deleting the spam comments.

However, the Breeze plugin from Cloudways does not accommodate the scenario of moving comments to the trash when the comment status is checked, leading to critical errors when visitors attempt to leave comments. To circumvent this issue, I created a simple code snippet and added it to the child theme's functions file.

Moving All New Comments to Trash in WordPress

This WordPress blog has received numerous spam comments, many of which consist of one or two-word responses, while some are excessively lengthy. Deleting long comments can be cumbersome.

To streamline this, I implemented code to prevent comments under 5 words or over 250 words from being submitted.

WordPress Comment Word Count Limit

This restriction on comment length appears to significantly reduce the amount of spam received.

While I typically receive only 1-2 legitimate comments daily, spam can easily exceed 100. Therefore, I configure all new comments to be moved to the trash, restoring the genuine ones while deleting the rest.

In the WordPress dashboard, navigate to Settings » Discussion, and enter a dot (.) under "Disallowed Comment Keys" to automatically move all new comments to the trash.

I found this approach more convenient than using plugins like Akismet. However, after an update to Breeze by Cloudways, a critical error arose when moving comments to the trash.

Upon checking the error log, I discovered the issue originated from the purge_post_on_new_comment() function within the Breeze plugin.

PHP Fatal error:  Uncaught TypeError: Breeze_PurgeCache::purge_post_on_new_comment(): 
Argument #2 ($approved) must be of type int, string given in 
/home/website/public_html/wp-content/plugins/breeze/inc/cache/purge-cache.php on line 420

Upon further examination, I found that the related function was defined as follows:

public function purge_post_on_new_comment( int $comment_ID, int $approved, array $commentdata ) {
		if ( empty( $approved ) ) {
			return;
		}
		// File based caching only
		if ( ! empty( Breeze_Options_Reader::get_option_value( 'breeze-active' ) ) ) {
			$post_id = $commentdata['comment_post_ID'];

			Breeze_CloudFlare_Helper::purge_cloudflare_cache_urls( array( get_permalink( $post_id ) ) );

			$url_path = get_permalink( $post_id );
			// Purge local cache for the URLs list.
			$this->clear_local_cache_for_urls( array( $url_path ) );

			$this->detect_comments_page_clear_cache();
			$this->clear_op_cache_for_comments( $comment_ID );
		}
	}

The problematic aspect was that the $approved variable needed to be an integer, but since I had configured my blog to send all comments to the trash, it triggered a critical error.

Typically, the $approved value from the comment_post hook can be one of the following:

  • '0' → Not approved (pending)
  • '1' → Approved
  • 'spam' → Marked as spam
  • 'trash' → Moved to trash
  • 'delete' → Deleted

Since I had set it to automatically move to trash, the $approved value was 'trash' instead of an integer like '0' or '1', causing the Uncaught TypeError to arise.

I contacted Cloudways’ support team via live chat, and they quickly provided a solution. They informed me that they modified the purge-cache.php file of the Breeze plugin to resolve the issue.

Please be informed that the issue was resolved by making some changes in the code of the breeze plugin, in file wp-content/plugins/breeze/inc/cache/purge-cache.php. Rest assured, the issue has been resolved now.

However, when the Breeze plugin was updated, the modified file was replaced again, resulting in the issue recurring.

Reverting the purge-cache.php file would resolve the issue again, but I found it too laborious to repeat this each time the Breeze plugin received an update. As a temporary solution, I created a simple code snippet and added it as a plugin.

// Function to move comments from non-logged-in users to the trash
function move_non_logged_in_comments_to_trash( $comment_id ) {
    // If the user is not logged in
    if ( ! is_user_logged_in() ) {
        wp_trash_comment( $comment_id );
    }
}

add_action( 'comment_post', 'move_non_logged_in_comments_to_trash' );

By adding the above code to the child theme's functions file, all new comments submitted by non-logged-in users (guests) will be directed to the trash.

I sent the code to the Cloudways representative for review, and they suggested modifying it to apply to both logged-in and non-logged-in users. 😄

function move_all_comments_to_trash( $comment_id ) { 
    wp_trash_comment( $comment_id ); 
} 

add_action( 'comment_post', 'move_all_comments_to_trash' );

Depending on the situation, adding either of these two codes to the child theme's functions.php file will result in all new comments being moved to the trash.

If you are using Cloudways’ Breeze plugin and want to redirect all new comments to the trash, consider implementing the previously mentioned codes instead of relying on the "Disallowed Comment Keys" feature in Settings » Discussion to avoid triggering critical errors.

Once the Breeze plugin is updated to resolve the critical error, I will remove the code presented in this article.

Conclusion

As the number of visitors to your WordPress site increases, so does the volume of spam comments. In the past, most spam was in foreign languages such as English, Japanese, or Chinese, but recently there has been a noticeable rise in spam comments in Korean.

If you’re using Cloudways’ Breeze plugin and have it set to move all new comments to the trash, you may encounter fatal errors. In this case, you can temporarily resolve the issue using the code provided in this article.

See Also...