Out of the box, WordPress has pretty great support for external object-cache implementations. Even its built-in object-caching helps WordPress be more performant and avoids redundant non-performant function calls and DB lookups. One of the challenges we have faced at WebDevStudios is the way WordPress handles including/loading an external object cache and determining whether the default implementation is used. I won’t go into all the details, but the part we have had issues with is the fact that if there is an object-cache.php file in the wp-content directory, WordPress assumes an external object cache exists and it should not include or perform its built-in object-caching implementation. The issues we have had are outlined below: We keep the code to be deployed to production in version control. This means we want/need to keep the object-cache.php file in the wp-content directory. WordPress object-cache plugins generally expect the user to transfer the object-cache.php file from the plugin’s directory directly to the wp-content parent directory. We prefer to keep the plugin’s object-cache.php file inside the plugin’s directory, NOT in the wp-content parent directory. This is because
Share This

We are using cookies on our website

Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.