Detect available object caching backend(s) to guide users toward persistent object caching plugins

[westonruter]

Feature description

When persistent object caching is not enabled on a WordPress site, we provide the following Site Health test recommendation:

This is not very helpful because the only call to action is to a link to Learn more about persistent object caching (opens in a new tab), and the information on that handbook page is not very helpful for non-technical users. It's also not helpful because it doesn't provide specific plugins that should be used for implementing a persistent object cache.

In #1216 we explored attempting to detect the host running to then link off to host-specific instructions. However, determined that was not feasible: #1216 (comment).

What we can do, however, is detect if the PHP extensions are installed for Redis, Memcached, and APC/APCu. With that information, we can inform the user what persistent object caching backend they appear to have available and then we can perhaps provide some plugin suggestions for that backend. (Note we may need to also try to connect to Redis and Memcached to see that the servers are available.)

Instead of mentioning the specific plugins in the Site Health info recommendation, the list of backend-specific plugins can be in a documentation page on amp-wp.org. This documentation page can pull together the various pieces of information about object caching spread out across WordPress.org, including:

• https://make.wordpress.org/hosting/handbook/handbook/performance/#object-cache
• https://developer.wordpress.org/reference/classes/wp_object_cache/#persistent-caching

Ultimately, the user should ask their host for the recommended way to enable object caching first before they do it themselves. So our recommendation should be to first contact the host, and then continue with our guidance to try the plugins we've identified which may work with their site.

See support topics about object caching:

• https://wordpress.org/support/topic/how-enable-persistent-object-in-amp-plugin/
• https://wordpress.org/support/topic/amp-error-25/
• https://wordpress.org/support/topic/persistent-object-cache-is-not-enabled-2/
• https://wordpress.org/support/topic/persistent-object-caching-is-not-enabled-2/
• https://wordpress.org/support/topic/persistent-object-cache-is-not-enabled-amp/

Anything we can do to make it easier for users to enable object caching the better.

This is part of encouraging users to use page caching (#4386).

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

Implementation brief

QA testing instructions

Demo

Changelog entry

[westonruter]

Per @pierlon, note that W3 Total Cache allows for multiple backends:

It even supports writing to disk. We should avoid recommending that, however, since using the disk for object cache storage would be very slow. The recommendations we provide should be in descending order of precedence:

1. Redis
2. Memcached
3. APCu
4. disk

(Using the disk could even be worse than not having object caching at all, if the MISS rate is too high.)

[milindmore22]

A suggestion from the user from support topic using varnish cache to suppress the recommendation, as varnish eliminates the need for persistent object caching @westonruter your thoughts on this one?

[westonruter]

That's a good question. I've proposed the following:

Even though page caching like Varnish does reduce the need for persistent object caching, it is still recommended because it reduces the amount of data that is put into the wp_options database table (from transients).

One feature we’re going to be including in the next version (v2.2) is detection for whether or not page caching is enabled via a new Site Health test. See amp-wp#4386.

So a compromise I see here is that when we detect page caching is enabled, we can reduce the severity of not having persistent object caching from the current recommended status to something lesser. I suppose the only option there is good, which isn’t technically right but I guess it’s as good as we can get, but we can differentiate between the two with a color difference (green for actual good, and blue for info). There could be three states for this test then:

1. recommended w/ orange: “Persistent object caching is not enabled”
2. good w/ green: “Persistent object caching is enabled”
3. good w/ blue: “Persistent object caching is not enabled, but you have page caching.”

The latter two would both be included among “passed tests”.

How does that sound?

Note you can also remove site health tests with PHP filters. There’s a Site Health Tool Manager plugin which allows you to disable certain tests, although it has become a bit out of date.

[bartoszgadomski]

QA passed:

Caching services not available:

Memcached available:

Memcached and Redis available: