WordPress on Kubernetes

In the previous lesson we’ve configured a WordPress plugin to persistently store its object cache in a Redis database. This allows us to access certain WordPress data significantly faster.

In this lesson we’ll continue building on that, and add full page caching support to our WordPress application. This will serve entire HTTP requests from our centralized Redis database, without having to execute any of the underlying WordPress code apart from the bootstrapping process.

Note: all code samples from this lesson are available on GitHub.

Meet advanced-cache.php

We’ve already hinted at advanced-cache.php in an earlier lesson in this tutorial. This is a drop-in file that loads very early in the WordPress bootstrap process, before any themes or plugins are loaded, even before most of the rest of WordPress core is loaded.

This drop-in is the perfect place to serve a cached response if we have one, and most WordPress-based page caching plugins will operate around this special file.

Unfortunately we’re very limited in options here, and can’t use the popular caching plugins, like WP Rocket, WP Super Cache, and others, because they are filesystem-based plugins. Given our lack of a shared filesystem in our Kubernetes cluster (an NFS mount would be too slow for caching!) we’ll need a different, central place to store our cache.

Redis is a perfect solution, especially given that we already use it as a persistent object cache in WordPress.

Batcache

Automattic’s Batcache plugin is a very simple full page caching plugin for WordPress, which relies on a persistent object caching backend. The plugin uses the native WordPress APIs to interact with this backend, which means that it will work well with Redis, Memcache and any other configuration. It also means that we don’t need any additional services in our Kubernetes cluster.