[wp-hackers] Caching as part of the core

[Bryan Petty]

On 07/28/2012 07:42 AM, Jeff Waugh wrote:
> I invite you to describe a caching-related* use case for which
> advanced-cache.php is useful that does not involve page caching.

It doesn't have to be non-page-caching-related. You could have multiple
uniquely different page caching systems that you need to use together.

What if you want to use one of the popular page caching plugins to
handle all your standard pages in the template hierarchy, but you also
need to provide another page caching system that handles pages served
through your own plugins?

One single page caching plugin/dropin can't even come close to
predicting how every plugin installed on your site should be cached, and
there's tons of plugins that provide custom pages that could (and
probably should) be cached.

But, that all falls under the topic of some new API that allows multiple
page caching systems to handle requests, and I really don't care about
that right now. I still feel like there's a deeper issue that needs
resolved first...

>> I completely agree with you here. But what I'm saying is that core
>> currently doesn't allow us to fully demonstrate for the reasons already
>> explained.
> 
> I'd like you to explain, in technical terms, why you can't build fragment
> caching on top of the primitives currently provided by WordPress core. I
> don't think this has been "already explained" at all.

This is where we're going in circles. This has been explained at least 3
times now, but whatever, let's try it again...

It's because fragment caching systems (and full page caching systems)
absolutely require a persistent object cache, otherwise, there would be
no reason to install them because there would be no benefit. The only
thing available in core that does this is by abusing the transient API
to do something it wasn't built for currently, which (as also pointed
out several times now) is fairly inefficient and inappropriate for this.
Again, we're back to plugging in your own object-cache.php (or requiring
the installation of another persistent object cache plugin) to implement
this in a plugin who's primary goal is page caching, not object
caching... all of the page caching plugins out there do this currently.

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. 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.

Martin Fowler would have a field day with this.

The rest of this is for everyone (not just Jeff)...

This is a mailing list to discuss possible improvements to *core*
WordPress. Mike and I obviously already know that we can install any
number of plugins and dropins (and write our own) to accomplish what we
need to here, but all we're trying to do is discuss how the current
*core* API could be improved to make this easier, more flexible, less
error prone, more efficient, and require less work on everyone's part
overall (for plugin authors and users).

I am disturbed at how condescending everyone here has been with both of
our comments because I keep reading the same thing over and over again:
"Just write a plugin/dropin." And in doing so, everyone has been
ignoring all of the problems being pointed out, and also ignoring all of
our suggestions for real improvements to *existing* core components.
It's not perfect, far from it in fact.

Neither of us are here for "support". We know what is possible here, and
how to hack the current version of WordPress to do this already.

I would encourage all of you to step back and go through our posts
keeping that in mind. Maybe we could actually get some productive
discussion going.

At least Mike and I have been able to identify a couple of the same
problems with some consensus on possible solutions even though we both
have very different goals in mind.

-- 
Bryan Petty
WordPress Developer
bpetty at bluehost.com