[wp-trac] [WordPress Trac] #21401: Load packaged object cache when advanced-cache.php and object-cache.php don't implement wp_cache_init( )

[WordPress Trac]

#21401: Load packaged object cache when advanced-cache.php and object-cache.php
don't implement wp_cache_init( )
----------------------------+------------------------------
 Reporter:  wonderboymusic  |       Owner:
     Type:  enhancement     |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Cache           |     Version:  3.0
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |
----------------------------+------------------------------

Old description:

> '''This ticket has 2 purposes:'''
>
> 1) introduces {{{wp_using_ext_object_cache()}}} - mimic
> {{{wp_suspend_cache_invalidation()}}} and disallow direct access to
> {{{$_wp_using_ext_object_cache}}}, cleans up importing of globals in
> functions and provides function to modify that global[[BR]][[BR]]
> 2) allows {{{WP_CACHE}}} to load the wp-packaged object cache when
> {{{advanced-cache.php}}} and {{{object-cache.php}}} don't implement
> {{{wp_cache_init()}}}
>
> When '''define( 'WP_CACHE', true )''':
>
> As it stands, if you declare {{{WP_CACHE}}} = true, WP will try to load
> {{{advanced-cache.php}}} without checking if the file exists (it does the
> check for {{{object-cache.php}}}). {{{advanced-cache.php}}} shouldn't be
> required. Batcache is awesome, but at its core is just a handler for an
> output buffer. You should be able to mess with {{{object-cache.php}}} and
> not worry about {{{advanced-cache.php}}}. And by worry about I mean, have
> {{{WP_DEBUG}}} on and not get a warning / error.
>
> {{{wp_start_object_cache()}}}, at its core, is on the hunt for
> {{{wp_cache_init()}}} and then sets the toggle for the external object
> cache. We only care about the external object cache if it has that
> function. Rather than throwing a fatal error if their is a missing
> method, load the default object cache.
>
> If someone installs Batcache and Memcached properly, then nothing changes
> - files load, all is good. If they install 2 blanks files, the default
> Object Cache will load. If they install an external object cache without
> {{{wp_cache_init()}}}, the default cache loads.
>
> IMO - there is no reason to turn off non-persistent caching or throw a
> fatal error if the author of a cache plugin sucks or the user made a
> mistake in moving the files.

New description:

 '''This ticket has 2 purposes:'''

 1) introduces {{{wp_using_ext_object_cache()}}} - mimic
 {{{wp_suspend_cache_invalidation()}}} and disallow direct access to
 {{{$_wp_using_ext_object_cache}}}, cleans up importing of globals in
 functions and provides function to modify that global[[BR]][[BR]]
 2) load the wp-packaged object cache when {{{object-cache.php}}} doesn't
 implement {{{wp_cache_init()}}}
 3) adds file_exists for advanced-cache.php

 {{{wp_start_object_cache()}}}, at its core, is on the hunt for
 {{{wp_cache_init()}}} and then sets the toggle for the external object
 cache. We only care about the external object cache if it has that
 function. Rather than throwing a fatal error if their is a missing method,
 load the default object cache.

 If someone installs Memcached properly, then nothing changes - file loads,
 all is good. If they install a blanks file, the default Object Cache will
 load. If they install an external object cache without
 {{{wp_cache_init()}}}, the default cache loads.

 IMO - there is no reason to turn off non-persistent caching or throw a
 fatal error if the author of a cache plugin sucks or the user made a
 mistake in moving the files.

--

Comment (by wonderboymusic):

 I chatted with Jaquith earlier and he pointed out that half of this ticket
 made no sense - edited!

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/21401#comment:10>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software