[wp-hackers] Caching as part of the core

[Mike Schinkel]

On Jul 28, 2012, at 9: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.

Please re-read my posts on this thread; all my discussions related to advanced-cache.php have been discussing *page* caching, with 

> Which you'll see is noted above, with the important caveat: It's only
> relevant within a single request.
> 
> I invite you to describe a use case for wp-includes/cache.php within the
> context of wp-content/advanced-cache.php, noting that it is *not* an
> implementation of a persistent object cache. You might have to describe why
> using the wp_cache_* functions is preferable to... using variables. Hey, I
> like to set a challenge.

Again, please re-read my posts on this thread; my only reason for mentioning the persistent object cache related to page caching and fragment substitution is because the object cache is a dependency for Transients, which operates *across* pages.

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

It seems like maybe you dove in to debate this topic but failed to read the entire thread so you don't appear to understand the context or at least what I've previously said?  You haven't read the entire thread, right?

The problems are *not* that it *cannot* be done but instead that the core could improved for caching concerns:

1.) Currently you can have only one caching plugin to access advanced-cache so an end-user can't compose caching functionality from multiple plugins. That limitation is one of the reason caching continues to be a "must be custom for each site" endeavor. We should enable multiple plugins could each add a dropin of the same category which requires the order of code loading in /wp-settings.php needs to be changed to support hooks in dropins and for dropins to change slightly.

2.) It's currently not possible to capture fragments generically at the lowest level, so add the hooks to better enable fragment capturing.

3.) With Transients and hooks available in advanced-cache.php we could explore the creation of a simple page caching plugin with fragment substitution, i.e. we could write code.  This potential plugin could potentially be used by with very little configuration and hopefully no requirement to fiddle with the server at a technical level. It wouldn't give the best performance, but perfection isn't always needed. And more importantly it could be an exploration of a potential "core plugin" for caching, one that could establish some basic patterns and one that could support the creation of improved caching APIs.  But without Transients being able to be loading in /wp-settings.php nobody explore that without duplicating the equivalent of Transients.

I do understand caching is hard and APIs are hard, we are not discussing a complete new caching APIs for 3.5. Instead let's explore the impediments to a caching API. Like #1-#3 above.

Or a simpler way to say it is: You don't have to defend core against an abstract concept of caching. There's no urgency here. Abstract concepts will never make it into core. Focus on details, and please be open to others being able to good workable coded solutions you hadn't previously envisioned.

> - advanced-cache.php is, in practice, designed for page caching.

I've not said or implied otherwise.

> You will only ever want one of those, so a drop-in is fine.

Dropins are not fine, only one plugin can effectively control advanced-cache.php.

> It even says so in
> wp-settings.php: "For an advanced caching plugin to use. Uses a static
> drop-in because you would only want one."

Your quoting that in a debate ignores that a human wrote that comment, and humans are known to be short-sighted, unaware of other contexts, and often just plain wrong.  In this case I believe they were just being short-sighted.

> - a persistent object cache implementation will backend the wp_cache_* and
> *_transient APIs (which are aggressively used throughout the WordPress code
> base), both of which can be used to implement all kinds of caching
> strategies at the plugin and theme level (including fragment caching).

Now that statement generates the height of frustration for me. Much of this thread has been me saying we need access to Transients in advanced-cache.php.  Please do me the courtesy of reading this entire thread before your next reply.

-Mike