MAx Cache now works with W3 Total Cache: what hosts and site owners each do

W3 Total Cache sites on CloudLinux servers with cPanel can now have their cached pages sent directly by Apache or Nginx, so the server does less work for each one and visitors see pages loading faster. W3 Total Cache 2.11.0, out since 20 October, works with MAx Cache, CloudLinux’s web server module for cached WordPress pages. It’s the first caching plugin besides our own AccelerateWP to support it.

What changes depends on the web server. With Nginx in front of Apache, the usual Nginx setup on cPanel, Nginx sends the cached page itself and the request never reaches Apache. On Apache alone, the module finds the cached file directly, so Apache no longer works through the plugin’s rewrite rules on every request.

Using MAx Cache takes a step from the hosting provider and one from each site owner. The provider installs the module once per server. The site owner then turns the extension on, and W3 Total Cache offers it to them wherever it can serve their site.

Who does what

For hosting providers

You need a CloudLinux server with cPanel, running Apache or Nginx, and MAx Cache 1.2.7 or later, the first version that supports W3 Total Cache. The packages are in the stable repositories.

On Apache:

yum install libmaxcache ea-apache24-mod_maxcache

On Nginx, including Nginx in front of Apache:

yum install libmaxcache maxcache-nginx-configd ea-nginx-maxcache

The extra Nginx package is a small daemon that passes each site’s settings to the module. Installing it also starts it, so there is nothing else to run.

Nothing changes on a site until its owner turns the extension on, and the server has no per-site switch for it.

What your customers will see

Every site on W3 Total Cache 2.11.0 or later lists MAx Cache on its Extensions screen. Where the module is installed and the site’s settings allow it, W3 Total Cache also shows the owner a prompt in the dashboard with an Activate MAx Cache button.

On a server without the module, the Extensions screen tells the owner it isn’t installed, and with an older module it tells them to ask their hosting provider for an update. To send a customer the steps, link them to the site owners’ section.

Checking that the module serves

The module sets no response header by default. To see which requests it sends, add one, then test a site whose owner has activated the extension. On Apache, put this in the site’s .htaccess, outside any block, or the extension declines on that site:

<IfModule mod_headers.c>
Header always set X-CL-Served "1" "expr=%{HANDLER} == 'maxcache-cached-file'"
</IfModule>

On Nginx, add this to the server configuration:

add_header X-CL-Served $maxcache_status always;

Request a cached page twice, the first time to fill the cache:

curl -sS -o /dev/null https://example.com/
curl -sS -o /dev/null -D - https://example.com/ | grep -i x-cl-served

On Apache, the header appears when the module sent the page. On Nginx, it reads hit.

Sites on AccelerateWP

They keep using MAx Cache as they do today. W3 Total Cache is a second caching plugin the same module serves, and each site runs one or the other.

For site owners

If your site runs W3 Total Cache on a CloudLinux server, your hosting provider may already have installed the MAx Cache module. Where it can serve your site, W3 Total Cache shows a prompt in your dashboard to activate it.

You need W3 Total Cache 2.11.0 or later, and the module on the server, which your hosting provider installs. To turn it on:

1. Go to Performance → General Settings and set Page Cache to Disk: Enhanced. The module sends pages from Disk: Enhanced files only, so a site that caches pages another way, such as Disk: Basic, Redis or Memcached, has to switch to use it.
2. Go to Performance → Extensions, find MAx Cache and activate it, or use the Activate MAx Cache button in the prompt.

The extension writes the module’s directives into your site’s .htaccess, in a block of its own, and shows its state on the Extensions screen. Once the module is sending your cached pages, W3 Total Cache tells you so in a notice. Logged-in visitors, form submissions and pages you exclude from the cache still go to WordPress, as before.

If the extension declines

When it can’t reproduce your cache exactly, the extension stays off and says why on the Extensions screen. Your site keeps serving pages as it did before. The usual reasons:

• Named user-agent, referrer or cookie groups in W3 Total Cache
• Another plugin that moves W3 Total Cache’s cache files, or changes when a visitor may be served from cache
• A .htaccess file that WordPress can’t write to
• A MAx Cache module older than 1.2.7 (ask your hosting provider to update it)

If the extension is active but no pages come from the cache, check that WP_CACHE is true in wp-config.php.

How it works

W3 Total Cache keeps its cached pages as files under wp-content/cache/page_enhanced/. The extension describes that layout to the module: where the files are, which requests may be served from them, and which cookies and query strings change the file name. On each request, the module works out the file’s path itself and sends the file.

The directives, the header check and troubleshooting are in the MAx Cache documentation.