[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       |
----------------------------+------------------------------
Description changed by wonderboymusic:

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

New description:

 '''This ticket has 3 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()}}}[[BR]][[BR]]
 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.

--

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