The WordPress Object Cache changed in WordPress 2.5 and removed a lot of file support from the code. This means that the Object Cache in WordPress 2.5 is completely dependent on memory and will not be saved to disk for retrieval later. The constant
WP_CACHE also changed its meaning.
In WordPress versions prior to 2.5 release, there were two constants that were used. One always enabled the cache and the other always disabled the cache. However, confusion was caused by both the constant values being booleans. In WordPress 2.5, those old constants were removed and a new one is used instead.
Normally, the WP_CACHE constant does not exist in wp-config.php. If it does exist, then it means that there is a file in wp-content folder named advanced-cache.php. This file, if it exists will be included (not to be confused with required, meaning that if it isn’t there and you remove it, it won’t halt the WordPress execution) and a function called
wp_cache_postload(), if it exists.
The way to disable the WordPress cache is to define another cache, also in the wp-content folder, called object-cache.php. However, the functions that are used by WordPress still need to be defined in the file. Mostly, if you return false, then WordPress will just retrieve from the database, which will decrease performance.
When you write a plugin which uses advanced-cache.php, make sure you include code which writes the WP_CACHE constant to the wp-config.php file for the user, in case they don’t have enough experience manipulating files themselves.
Note: the value inside of WP_CACHE is not important, what is important is that the constant is defined. So in theory, you can use:
But in practice, it is better to set the value to true instead:
In theory, the advanced-cache.php file is useful if you wish to save the output of the WordPress pages through the use of
wp_cache_postload() function. There are other purposes that can be handled through the
wp_cache_postload() function, but that is up to you the plugin developer to decide.
This file is optional, only the next file is required to replace the internal WordPress Object Cache.
You are replacing a file that has definitions used by WordPress, so you must also define those functions in your file and handle the cache using whatever method that you will be using the same way that the internal WordPress cache does.
This means that when wp_cache_get() is called, if the cached object does not exist, then you return false. If it does exist, then you return the object. The same way with other replaced functions.
What you would put in this file is Memcache implementation, or file based caching, or some other custom solution. The full implementation should go in this file and there can only be one caching implementation used at a time.