[wp-hackers] Caching as part of the core
almog.baku at gmail.com
Wed Jul 25 00:16:59 UTC 2012
The most famous php-application is implement caching as as integral part of
In drupal for example, there is based cache and you can install a module
who extend this caching.
By the way, drupal - patches to the core is really something unaccepted -
so I really not like this drop-ins idea.. hacky = bad.
If you ask me we should replace this hacky-dropins with much more hooks to
the core, and option to extend it(by using OOP for ex.)
On Wed, Jul 25, 2012 at 2:11 AM, Bryan Petty <bpetty at bluehost.com> wrote:
> On 07/24/2012 12:38 PM, Otto wrote:
> > Page caching would indeed use the advanced-cache.php drop-in.
> > WP-Super-cache does exactly that. Using transients there would be
> > highly difficult, however I'm not sure that you'd want to,
> > realistically. Transients are essentially wrappers around database or
> > object cache calls. Storage of whole-page caching methods is capable
> > of being done more directly, and much faster, without the overhead
> > transients and the object cache bring to the table. Either you store
> > the page cache in a way that bypasses the need for PHP to execute at
> > all (super-cache) or you store the page directly in an external memory
> > system, where the WP_Object_Cache overhead is not helpful to you.
> Ok... so now you'll admit that the Transients API has high overhead, is
> difficult to use, and is in-appropriate for page or fragment caching.
> You also admit that the dropins are "hacky as heck".
> However, you'll still tell me that's what I should use when I so much as
> suggest that WP_Object_Cache could be expanded (in a 100% backwards
> compatible way) to support persistent cache backends in core like it
> used to, but done the right way this time.
> I didn't honestly think I had to actually submit a patch yet just to
> explain what I was proposing since nearly everyone else implements a
> flexible caching system with multiple backends nearly the same way, and
> the way I'm proposing. How about some examples then?
> In the category of PHP applications that aren't built on frameworks
> since this is where WordPress falls in:
> 1. MediaWiki:
> 2. phpBB:
> 3. Gallery:
> 4. phpMyAdmin used to use phpExcel's cache library:
> All of them are mostly designed the same way object cache APIs are
> designed on nearly all the frameworks, let's jump to those:
> 4. CakePHP: https://github.com/cakephp/cakephp/tree/master/lib/Cake/Cache
> 5. Symfony: http://www.symfony-project.org/api/1_4/sfCache and
> 6. Kohana: https://github.com/kohana/cache/tree/3.2/master/classes/cache
> 7. CodeIgniter:
> (Zend purposely left off the list, but it does multiple persistent
> object cache backends the same way too - just very different frontend)
> This isn't even limited to PHP. Even though Python and Ruby web
> application processes handle multiple requests, they still implement
> object cache APIs the same way:
> 8. Django:
> 9. Beaker (a python cache/session library):
> 10. Ruby on Rails:
> MediaWiki doesn't even tell everyone they should write object cache
> implementations in extensions. They provide over a dozen persistent
> object cache backends to choose from including multiple memcache backends.
> How about this...
> What if the Transients API was converted over to a WP_Object_Cache
> backend, and used as the default fallback instead of the file backend if
> none of the accelerators are available (APC/XCache/WinCache)? The
> current API can still continue to fire off the same filters (and will
> just make calls into wp_cache_get/set()) and new code can feel fine
> about using wp_cache_get() with an expiration again, and page/fragment
> caching plugins have a persistent object cache to use before the hooks
> system is initialized. The transients API is really just a DB object
> cache backend anyway (but with filters).
> Bryan Petty
> WordPress Developer
> bpetty at bluehost.com
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
More information about the wp-hackers