Thought a WordPress Plugin Broke My Site, Something Else Did
It’s possible to run a WordPress based web site without any other added functionality. However, for a feature rich web site the extra functionality provided by plugins help enhance your visitor’s experience. Plugins get updated regularly, for new features, bug fixes, security fixes and to work with the latest versions of WordPress. On most occasions updating WordPress and plugins is straight forward with the WordPress control panel/dashboard. So much so that complacency can set in. When that happens things eventually go wrong and painful lessons are learned.
Disciplined Software Update
The correct way to do a software update is:
- Try the update on a test system which replicates the live system.
- Only if the test passes is the update performed.
- Backup the current live system and data.
- Apply the update to the live system.
- Test the functionality of the live system.
- It it fails restore the backup.
Now this can be a little laborious and if the last 20 updates have worked without a hitch why bother. Well if things can go wrong one day they will. Here’s an example of how it went wrong.
A Plugin Broke WordPress! No You Thought It Did
WordPress broke WordPress. Here’s how it it was thought a plugin broke WordPress but it was a WordPress automatic update that broke WordPress. In this case a WordPress SEO by Yoast plugin was updated to version 1.7. The web site stopped working, it went down just displaying a blank white page. But the WordPress SEO update was not the reason. Here’s what happened and how it was fixed.
How The Broken WordPress Site Was Fixed
The site gets a reasonable amount of traffic. It sometimes reaches the memory limit on the shared hosting plan it is running on. When it stopped working, after updating to Yoast SEO 1.7, the first thing to do was to disable the SEO plug-in. After all the two events appeared to be linked. Often with a broken WordPress site it may not be possible to log into WordPress. To disable the plugin it had to be done by renaming the wordpress-seo folder in the wp-content/plugins directory on the server. Nearly all hosting plans provide a hosting control panel (e.g. cPanel) with a file manager to allow this to be done.
Despite this the site was still down. So it wasn’t Yoast’s WordPress SEO plug-in. Time to turn on WordPress debug. Opened wp-config.php on the server, changing define(‘WP_DEBUG’, false); setting it to true – define(‘WP_DEBUG’, true);
Went to the site home page and saw an error reported due to a code problem with kses.php in the wp-includes folder. This PHP code file was compared with kses.php from a WordPress install set (download from WordPress.org). The kses.php on the server was truncated. About a third of the size it should have been. The kses.php on the server was replaced with one from the install set. Success, the site was back up. WordPress debug could be turned off again, define(‘WP_DEBUG’, false);
Why Did The WordPress File Get Truncated?
With the site running again it was possible to log into the Dashboard. This showed a message:
“An automated WordPress update has failed to complete”
WordPress has automatic updates for minor releases. Since the kses.php file got truncated it can be assumed this happened during an automatic update at a similar time to the plugin update. The auto update probably coincided with a period of high traffic (hence low resources) on the shared hosting server. A file system issue on the server could have been a cause. To reduce this risk in the future automatic updates of WordPress are now disabled so they can be applied during times of lower traffic. Automatic updates can be disabled by adding this line to wp-config.php:
define( ‘AUTOMATIC_UPDATER_DISABLED’, true );
WordPress Housekeeping Completed
With the site running again some house keeping could be completed. First a backup using the hosting tools. The failed WordPress update is then applied manually through the dashboard. Then the wordpress-seo folder name was restored and WordPress SEO reactivated via the Plugins page. The lessons learnt:
- Do backup before updates.
- Have control on when updates are applied.
- With any software failure the real cause of the problem may be hidden so don’t take events at face value, look for the real evidence and cause.