I’ve written articles on Jetpack Autoupdate before — you’ll find some of them in the Jetpack blog. For many neglected sites autoupdate of plugins is a good idea. Plugins often have security patches that you should not ignore. Sometimes they have compatibility updates to allow them to work with the latest update to WordPress.
However autoupdate of ANY software, whether on your phone, desktop computer, or mobile device is only as good as the software doing the update. Over the years I have yet to find a single software company that can publish a 100% never-fails update to their software stack. Of all the companies that are pushing software, Apple seems to be the least prone to fatal crashes — the kind that take your business or personal productivity offline for hours or days. They are not infallible by any means and introduce plenty of “oh, that’s a pain in my ass” bugs on a regular basis.
Even season veterans such as Till cannot escape the millions of combinations of site installs that may create corner cases that break software. Something in the latest 1.3.6/1.3.7 updates to his plugin, or possibly changes to WordPress, or changes to the underlying operating systems or PHP have broken the Redis Object Cache plugin.
This will manifest itself as a non-responsive website , usually with a basic 500 (Internal Server Error) reply.
The quick fix is to disable REDIS by adding this line to your wp-config.php file:
define( 'WP_REDIS_DISABLED' , true );
This will force the object-cache.php file that the plugin has you move into the WordPress root directory to not run any of the code within.
Wait for a future Redis Object Cache plugin update before turning it back on.
If you are running your own Linux server — an AWS EC2 instance, perhaps, you may want to check that your etc daemon I’d not accessible.
Read this ARS Technica article for more info:
First things first -let’s get setup.
One of the common processes that runs in Store Locator Plus is deleting locations. For sites with a few dozen locations the process runs smoothly. For sites with thousands of locations but deleting one or two at a time, not a big deal. But for sites that are deleting tens-of-thousands of locations at a time the process becomes painfully slow. A mere 2,500 locations can take up to a full minute to be removed on a fairly decent performance server. That’s not the type of performance I like to see from our product.
After digging into the performance of the PHP stack initial indicators point to the custom post types as the primary culprit. It turns out that deleting a single custom post type in the WP_Posts table runs through a dozen gyrations to delete the post. Multiple filters are called, associated taxonomies are delete, taxonomy meta is deleted. It is a TON of extra overhead. But even with removing records from a half-dozen tables the data queries seem out-of-control.
Removing just 9 locations generates over 190 data queries. If there is one thing that has not changed in decades of writing software it is that data queries are costly. They may run on solid-state drives with advanced memory caching but doing 190 data queries is still far slower than nearly any other part of the application.