Make WordPress Core

Opened 9 years ago

Last modified 8 years ago

#21401 closed enhancement

Load packaged object cache when advanced-cache.php and object-cache.php don't implement wp_cache_init( ) — at Initial Version

Reported by: wonderboymusic Owned by:
Milestone: 3.7 Priority: normal
Severity: normal Version: 3.0
Component: Cache API Keywords: has-patch
Focuses: Cc:


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

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.

Change History (1)

Note: See TracTickets for help on using tickets.