[wp-hackers] Caching as part of the core

[Mike Schinkel]

On Jul 28, 2012, at 7:18 AM, Jeff Waugh wrote:
> I fully understand the use case you're describing, but that's not what
> wp-content/advanced-cache.php is for.

Where is it written on stone that there is an exact purpose for which advanced-cache.php is "for?"  I don't prescribe to the line of thought that something cannot be evolved to be used a certain way simply because someone said that is wasn't "for" that. If you ask 10 people what something is "for" you'll usually get at least 11 answers.

> A terminology issue: wp-includes/cache.php is for the most part an object
> cache *interface* (the implementation of which is only relevant within a
> single request), while wp-content/object-cache.php is an implementation.

Without an /wp-content/object-cache.php file, /wp-includes/cache.php *is* the implementation (WP_Object_Cache() is contained within.) 

I had proposed the need for /wp-includes/cache.php to be available when /wp-content/advanced-cache.php is loaded, it was your inclusion of /wp-content/object-cache.php that confused the terminology.

>> Themes and plugins can already use transients or the object cache API to
>>> cache fragments, while providing their own cache invalidation logic (or
>>> in the case of transients, timeouts).
>> 
>> Yes but that's irrelevant.  Themes and plugins can't use the existing
>> Transients or object cache API in /wp-content/advanced-cache.php if there
>> is any chance they won't be able to serve the content and thus must
>> continue loading WordPress.  WordPress does a require('
>> /wp-includes/cache.php') after it calls /wp-content/advanced-cache.php so
>> attempting to load them twice will result in an error.
> 
> Themes and plugins are (almost) entirely irrelevant at the early stage in
> which wp-content/advanced-cache.php kicks in -- that's because it's there
> for implementing page caching, which cares not for higher level nonsense
> like... themes and plugins. :-)

I agree themes and plugins are irrelevant at this stage, but it was you who mentioned first, not me.  I only mentioned them in reply to you.

> Dude, APIs are HARD. Caching is HARD. Cache invalidation is HARD. What
> you've described in the above paragraph is basically what already exists
> with the current transients and object caching APIs. 

Lots of things in life are hard. Doesn't mean they are not infinitely doable.

> Practical use case for you to chew on: I have a widget that I'd like to
> fragment cache, because building it takes a fair amount of time on each
> request. It displays thumbnails of images from the 10 most popular posts on
> the website, as determined by Google Analytics.
> 
> Note: Caching the fragment is "easy". Coming up with a sensible cache
> invalidation strategy (that isn't "regenerate it again every five
> minutes")... not so much.

What's currently missing in WordPress is a rigorous calculus for defining and evaluating page level criteria. WordPress has something basic for this, the internal query string, but it's never been fleshed out for use-cases other than routing. Development of a caching APIs could help flesh it out. The same thing could be used to specify on which pages a Widget should display, even without caching and there are other use cases we've identified in our shop that we'd like to use in our framework.

We've done some preliminary work on this for our needs, but we need to do more. And it would be even better if several of the people who work on core would get motivated to work on such a bit of infrastructure.

This is exactly the type of thing that is needed for caching; a standard method within WordPress to specific criteria for pages. We can either say: 1.) Caching is too hard, it can't be done, or 2.) If can be done and let's solve it. In general when #2 happens core improves by leaps and bounds, i.e. custom post types. When #1 happens, we get status quo.

> It's not religion. It's just difficult stuff that is best demonstrated
> outside core before it's brought in.

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'm not asking for caching in 3.5, or even a caching API in 3.5.  I'm asking that we start going down the long path that might eventually get us there by 4.0 or later. But it won't even be possible to get there without fixing some existing limitations. That's my focus.

> Transients are not useful in the context of (mostly application-logic-free)
> full page caching. This might suggest a misunderstanding of page caching,
> which hopefully I've explained above.

We may have to agree to disagree on this.

> Explain why someone would want multiple implementations of page or object
> caching, and what kind of logic would be used to choose between them.

Here are at least two reasons:

1.)  Imagine different mime types being cached by different plugins.  Sized images which are generated on first use, Content Posts and Pages, Excel Files, etc.  Each has a different plugin that manages caching of the different files types.

2.) Consider using the hypothetical new "Decisions-not-Options Cache(tm)"[1] plugin, and it's setting's page has one control: On or Off.  This is basically what the core team preaches how it should be done[2].  Now imagine the DnO Cache plugin has lots of hooks that allows a plugin developer to make changes to it's behavior using actions and filters.  These hooks *could* be configured in secondary dropins, but only if multiple hook-based dropins were possible. Which currently they are not.  (Yes, the end user could be tasked to perform surgery on /wp-content/advanced-cache.php, but if you advocate that as the better solution I'd have to ask "Really?" and point you to [3] & [4])

> I agree that a fragment caching API would be really cool [1]. But it can be
> implemented and demonstrated...

Realistically, but not without improvements to core.

As I said to Ryan, I'm going to post some code as soon as I get some other projects wrapped. Then we can discuss again.

-Mike