[wp-hackers] Caching as part of the core

[Jeff Waugh]

On Sun, Jul 29, 2012 at 11:16 AM, Bryan Petty <bpetty at bluehost.com> wrote:

> When every plugin of a fairly generic type (in this case, page caching)
> requires the installation of the same plugins (APC/memcache), that gives
> off a "smell" like the core WP API is lacking adequate support for
> something it should already have.
>

Not every page caching plugin needs wp-content/object-cache.php, but it's a
handy way to share code. Particularly if it's as well-written and
widely-trusted as the Memcache and APC drop-ins.

Batcache requires a persistent object cache implementation (:161-166). It
once used memcache directly.

WP Super Cache will load a persistent object cache implementation and
optionally use it (experimental feature according to the admin pages).

W3 Total Cache, being... special... does its own thing, has multiple
backends, etc.

This doesn't seem like a bad state of affairs to me. Surely before you
adopt application-level page caching, you're going to use a persistent
object cache, and you'll configure your system to use it appropriately.
Then, should you choose a page cache designed for key/val style storage,
it'll automagically use the implementation you've chosen. No more
integration to do, benefit of shared code, etc.


> What's worse about this is that WordPress already has an object cache, but
> it sucks, so everyone plugs in a replacement, and the only reason *all* of
> them do it is because it isn't persistent. That's something we can fix.
>

It's not that it sucks -- in fact, it does jolly good work, despite being
restricted to a single request -- it's that many WordPress users won't be
able to use a persistent object cache implementation at all. Those who
*can* use one will need to choose an implementation appropriate to their
deployment. Just one.

Please don't think I'm pooh-poohing the entire discussion -- I'm loosely of
the opinion that it would be nice if WordPress core did more for users when
it comes to caching. But that applies mostly to nicely integrated fragment
caching, rather than many of the things mentioned in this thread.

Walking through the core code, and the common caching-related plugins, only
reaffirms my support for the current approach. It turns out that clever
people have had quite a bit of time and paid attention to make good
decisions about this stuff. :-)