Having to work a bit on the server mentioned in this article, I found that most PHP pages were throwing random errors. Either Wordpress would say the uninformative “There has been a critical error on this website. Please check your site admin email inbox for instructions”, but there would be no email. I quickly enabled the Wordpress debug log, hit refresh, and BAM! already SIXTEEN megabytes!

Opened the log file and my face fell off! If you’re unfamiliar with the Wordpress blogging platform (which I stopped using a while ago for my personal site) has a Cron function. “Buy Andrei, what the fuck is a cron?”, you might ask hastily. Well, a cron handles scheduling time-based tasks in a computer system, and WP-Cron does the same in Wordpress. It basically does a series of tasks at a specific time or interval of time. WP-Cron works by checking, on every page load, a list of scheduled tasks to see what needs to be run. Any tasks due to run will be called during that page load.

Why did I highlight the on every page load part? Because it does this on every page load. And some developers do a somehow innocent loop in their code: “if this cron isn’t active, then add this cron”. Except for the moment when it’s already added, but the developer didn’t account for the caching system of the systems already in place. And tries again. And again. And again. Until something breaks. Or, luckily, a memory_limit, post_limit, or max_allowed_packet (in this case) is reached.

I’m not gonna name the plugin in cause, but you can easily discover it if you use any decent search engine. No, not Google, because it returns only 1 result on the search for “wsrs_update_blacklist_twicedaily”, and even that is from a site that’s suspended. Literally try ANY. OTHER. SEARCH. ENGINE.

Because the developer didn’t mind to properly check if there’s any caching system and only looked if the cron itself was set up, it kept trying to add itself to the cron list. I could add the entire log entry here, but it’s just a line that starts with

debug.log:[29-Feb-2024 01:49:23 UTC] WordPress database error Got a packet bigger than 'max_allowed_packet' bytes for query UPDATE `wp_options` SET `option_value` = 'a:85601:{

and then repeats the following for 85597 times, making the log file 16MB in size.

i:1707813538;a:1:{s:32:\"wsrs_update_blacklist_twicedaily\";a:1:{s:32:\"40cd750bba9870f18aada2478b24840a\";a:3:{s:8:\"schedule\";s:10:\"twicedaily\";s:4:\"args\";a:0:{}s:8:\"interval\";i:43200;}}}

If you encounter this issue, the solution is fairly simple, but it took me a bit to discover. The thing I’m going to mention below work fine in a production environment, without versioning and building scripts and shit. It’s a solution that’s fast, dirty, but most importantly, works. It also might break about 64 best practice rules, but we’re talking about a Wordpress site, not the infrastructure behind AliCloud. Please stop over-engineering your shit. But I digress, here are the steps:

1. Put the site in maintenance mode

Simplest and fastest method is to open /wp-content/your_theme_name/functions.php and throw in a die("Site will be back in a few seconds"); on the first line. Done that? Good. Now we can work hastily on the other steps.

2. Clear your caches

If it’s memcached, restart it. If it’s Redis, same. If it’s W3 Total Cache disk mode, wipe that. Opening a terminal window to the “wp-content” directory and running mv cache/ __cache && sudo rm -rf __cache works like magic for me sometimes.

3. Clear the wp-cron option

There are various ways you could do this, in SQL you could run UPDATE wp_options SET option_value = '' WHERE option_name = 'cron';, but that requires you to either log in to the mysql from terminal or open phpMyAdmin or whatever you’re using.

But as we have already the functions.php file open, go to the code you added in step 1 and prepend update_option('cron', '');. Prepend means “append, but at the beginning not at the end”. Save the file and check your homepage in the browser.

4. Check up and clean up

Once you’ve done this, the cron variable should be empty. Fire up a database and check that the cron option is empty (or it should have 5-15 tasks already added by other plugins, but not 85 fucking thousand times). Wait for a few minutes, recheck and see if everything’s still fine. If so, remove the code added in steps 1 and 3 and the website should bounce back.

5. GIve yourself a pat on the back

You fixed the site, now it’s time to relax with a Hugo and enjoy the new wallpaper you made.