Beware the Wordpress Cron Options

Posted By Grant Forrest |  last update 09-Jan 2013

HNY to all my SCATA colleagues, I hope everyone had a good break and avoided the various lurgies doing the rounds.

I used the quiet time over New Year to do some server upgrades. In particular, our version of MySQL was very out of date. I went from 5.0 to 5.5, skipping version 5.1 on the way. Apart from a few minor glitches it all went smoothly. A few sites needed password resets but overall I was very impressed with our server software (cPanel/WHM) and its upgrading tools.

A more problematic upgrade was going from PHP 5.3 to 5.4. This took a few sites down, in particular an eCommerce site based on a product called TradingEye. Fortunately we only have one install of this so-called ‘commercial’ product. A pattern seems to emerge where Open Source projects are well prepared for new major PHP releases whereas ‘commercial’ products are up to a year (or more) behind. This has forced me to consider virtualising one of my servers and setting up a container for ‘legacy’ sites which are only able to run on ancient versions of PHP/Apache etc.

Another site that went down with PHP 5.4 was a fairly recent Wordpress 3.5 install. It would only return a 404 (page not found), no matter what was requested. The apache error log was chock full of very confusing entries pointing toward MySQL latency as the problem. In the end, I isolated the problem to the wp_options table that has a row ‘cron’ which presumably updates various things on a schedule. This had somehow either become corrupted or was inompatiblewith MySQL 5.5. Writing an empty string to it fixed the problem immediately, and next time I looked, Wordpress had re-written some valid data into it. I suspect the 404 error was Wordpress trying to send a 500 (Internal Server Error) and failing.

Ho hum, all in a days work for an unpaid server admin.