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

[wonderboymusic]

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

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.

[wonderboymusic]

Of note - if someone loads an external object cache that doesn't implementl wp_cache_init, the default cache will load and potentially have a bunch of duplicate functions - that will still produce a fatal error and should. This is more for instances where the file is installed wrong or is blank.

[jeremyfelt]

History - 13185 was when previous decision (speed related) was made to not use file_exists() for advanced-cache.php.

[wonderboymusic]

Just did some speed tests - 0.00001 is the difference once APC kicks in. This doesn't affect overall performance in any perceptible way.

[mikeschinkel]

Related #21412

[nacin]

If object-cache.php is blank and it gets loaded by default, then you'll get an instant fatal error, pre-patch.

Should this be desired, in the interest of giving a developer proper feedback? As it is, if object-cache.php is installed but incomplete (specifically, missing wp_cache_init()) then with or without the patch, fatal errors will still occur.

WP_CACHE is specifically related to advanced-cache.php, not object-cache.php. So I'm having a hard time separating the two different factors here in the initial bug report. (Part 2)

(1), the wp_using_ext_object_cache() function, is good to me.

[nacin]

Both of these are enhancements.

[wonderboymusic]

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

[scribu]

Related: #22661

[devesine]

Refreshed patch against r23698.

[wonderboymusic]

Refreshed

[ryan]

We've avoided the file_exists() check on advanced-cache.php to avoid the extra sysopen. Checking WP_CACHE has been sufficient.

[wonderboymusic]

In 25289:

Introduce wp_using_ext_object_cache() - mimic wp_suspend_cache_invalidation() and discourage direct access to $_wp_using_ext_object_cache, cleaning up importing of globals in functions and provides function to modify that global. Loads the packaged object cache when an external cache hasn't been loaded or doesn't contain wp_cache_init().

Fixes #21401.