WordPress Plugin: Override Comment Deadline

Today I’m pleased to release a discussion-focused plugin to the directory, called Override Comment Deadline. Now you can have “Automatically Close Comments” enabled in your discussion settings to limit spam activity on old posts while keeping commenting open on specific posts. To use it, make sure you’ve set a deadline on the discussion settings page and then edit any post and check the box to keep comments open indefinitely.

Get it!

You can download Override Comment Deadline from WordPress.org or install it from the Add New Plugins page in your admin starting today. If you have suggestions for changes, you can fork the plugin and submit pull requests with GitHub.

Clean up bloated WordPress comment tables

Spam comments are the worst. Even with Akismet active to prevent them from appearing on your site, they can still cause problems. That’s because the comment still gets stored and Akismet creates comment meta entries every time it does something. Over the course of time those unnecessary database entries can amount to hundreds of megabytes even on a reasonably small site. Multiply that by a couple hundred sites on a multisite network, and it can quickly start costing you real money in terms of hosting and causing serious problems when you back up your database.

Fortunately, MySQL can help you eliminate all this comment meta bloat with a few simple queries:

DELETE FROM wp_comments WHERE comment_approved = "spam";
DELETE FROM wp_commentmeta WHERE meta_key LIKE "akismet_%";

As always, make sure to back up your database before running any destructive queries on it.

Once you’ve deleted all of those Spam comments and Akismet meta entries, make sure to optimize the database tables.

OPTIMIZE TABLE wp_comments;
OPTIMIZE TABLE wp_commentmeta;

If you’re running a multisite network, you’ll have to run the delete queries and the optimizations for each site, or at least each site which is causing problems. To determine which tables are the most bloated, you can run a query like this:

SELECT table_name AS "Tables", 
    round(((data_length + index_length) / 1024 / 1024), 2) "Size in MB" 
    FROM information_schema.TABLES 
    WHERE table_schema = "YOUR_DATABASE_NAME" AND table_name LIKE "%comment%"
    ORDER BY (data_length + index_length) DESC;

This will list all comment and commentmeta tables sorted by size, from largest to smallest. Once you have a list of all tables you want to clean up, you can run the DELETE and OPTIMIZE queries for each table. Or, you could write a script to clear this generally useless data from your database at regular intervals.

Debug WP-Cron with Trigger Scheduled Events

I’ve added a new plugin to the directory called Trigger Scheduled Events, which does pretty much what it says on the tin. With it, you can view a list of all events scheduled by WP-Cron and run any of them instantly instead of waiting until the next time the event is scheduled to be fired.

WP-Cron is useful because it allows you to schedule events to happen later using the wp_schedule_event() function, but during development this can lead to a lot of waiting around to see if your code works. Trigger Scheduled Events gets around this problem by allowing you to run your events on demand.

Get it!

You can download the plugin through the Add New menu from your WordPress admin or you can download it from the plugin directory. If you’d like to make suggestions for improvements, you can do that over at the plugin’s GitHub page.

SSL error when upgrading a WordPress Multisite Network

When updating to WordPress 4.0, I recently saw a scary-looking error when running the database upgrade on a network with some SSL sites. It triggered when trying to update tables for a site with an SSL certificate.

Warning! Problem updating https://blog.network.com/. Your server may not be able to connect to sites running on it. Error message: SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines: SSL3_GET_SERVER_CERTIFICATE: certificate verify failed

To be totally honest, I’m not exactly sure why this happens, but I was able to find a way to fix it by telling WordPress to ignore SSL checks when running the database upgrade. Create a file in wpcontent/mu-plugins/ and name it something like network-upgrade-ignore-ssl.php. Put the following in the file:

<?php
add_filter('https_ssl_verify', '__return_false');
add_filter('https_local_ssl_verify', '__return_false');
?>

That’s it! You should now be able to get through your upgrade smoothly.