Super Plugin Sale! Your Choice: BOGO or 30% Off »
Web Dev + WordPress + Security

How to Enable the Default WordPress Object Cache

Recently, while attempting to optimize site performance, I found myself experimenting with various caching mechanisms currently available for WordPress. Specifically, I explored each of the following caching options:

  • WP-Cache 2 [WordPress plugin]
  • WP Super Cache [WordPress plugin]
  • WordPress Object Cache [built-in caching mechanism]

While working with the two plugins, WP Cache 2 and Super Cache, I was pleased to discover crystal-clear instructions on each their respective sites. Having access to installation and usage information greatly facilitated the implementation of each of these caching techniques.

On the other hand, finding information about the default WordPress object cache proved virtually impossible. Finally, after locating some decent information, I was able to confirm my initial suspicions and subsequently decided to post a quick article outlining and describing this very straightforward caching method. Although enabling the WordPress cache turns out to be drop-dead easy, it is always good to be sure that you aren’t forgetting a step or otherwise overlooking some important aspect of the process.

Enable default WordPress cache in 3 easy steps

Note: This information applies to WordPress versions less than 2.5 only.

Ready? Implementing the default WordPress object cache is remarkably simple..

Step 1: Enable the caching mechanism

Open wp-config.php and set the value of ENABLE_CACHE to “TRUE”:


Step 2: Create the cache directory

Create a folder called “cache” and place it within the wp-content directory:


Step 3: Make the cache folder writable

Ensure that the folder is writable by setting its permissions to 755 or 777.



Once you have everything setup, surf around your site and check things out by reloading a few different pages. If the WordPress default object cache is working correctly, you will see a newly added slew of temporary cache files along with a newly created index.php file and wp_object_cache.lock file within the cache directory. Thus, if you don’t see any such files in the cache directory after surfing around your site, go back and recheck that you have correctly executed the proper steps. Note: if nothing seems to be happening with your cache — i.e., no cache files are being generated — you may want to try “rebooting the cache” via the following procedure:

  1. Disable the cache in wp-config.php
  2. Delete the cache directory completely from your server1
  3. Create a new cache directory, set the permissions, and re-enable caching in wp-config.php

I have also had luck simply deleting the cache directory and letting WordPress recreate it automatically. Remember, if it doesn’t work the first few times, try a few more times before giving up — it does work!


After you have confirmed that the object cache is working, you’re done. From that point on, or until you disable it, the cache should work as intended, saving you bandwidth resources and saving your visitors time. To verify this, navigate to a long-lost post that is buried way back in your archives somewhere — something that is completely off the radar. As you visit, note the page loading time. Now, visit the page again and compare the results. On average, while the native object cache is nowhere near as effective as either plugin method, it does manage to shave off a noticeable amount of loading time for your visitors.


Although the WordPress object cache may not work as well as either of the cache plugins currently available, it is an effective caching method that is a breeze to setup and run. And, best of all, the default caching mechanism works perfectly with virtually all WordPress plugins.


  • 1 Note: One final note concerning the WordPress object cache: all of the files may be safely deleted at your discretion — everything is regenerated automagically ;)

About the Author
Jeff Starr = Creative thinker. Passionate about free and open Web.
WP Themes In Depth: Build and sell awesome WordPress themes.

32 responses to “How to Enable the Default WordPress Object Cache”

  1. You don’t ever have to set file permissions to 777 for web applications. Set permissions to the least required, and make sure the PHP user has the required permissions. For example, if PHP is running as apache (mod_php takes on Apache user) or www-data then set the file’s user or group to www-data and give the user or group read and write permissions.

    If you do not have the permission to change the user of the file (chown command) then ask your host to do it for you.

  2. Ferodynamics 2010/01/11 5:14 pm

    According to the Codex, it changed to

    define('WP_CACHE', TRUE);


    define('ENABLE_CACHE', TRUE);

    but either way, it’s not working for me yet.

  3. WordPress 2.9 seems to be addressing my desires, at least in some scenarios, with the new Transients API:

  4. Ferodynamics 2010/01/11 5:55 pm

    Hmm, then how to enable this for 2.9.x?

  5. @Ferodynamics: as mentioned in comment #11, #18, and others, the default WordPress Object Cache was discontinued in version 2.5, so for anything newer you will need to use an alternate caching method.

    @cyberhobo: looks sweet – thanks for the tip :)

    @bucabay: technically correct, but in practice 777 is often the only setting that seems to work. As sad as it is, many users just don’t care enough or have enough time to be fussing with server settings, help-request tickets, and all of that jazz when all they want to do is “just install a plugin,” if you know what I mean. There are even some major plugins listed in the WP Plugin Repository that explicitly instruct users to use 777 during the installation process. Incredible!

  6. Thank you for this post

  7. @jeff Exactly. It is the only setting that seems to work, because you’re opening it to everyone. When in fact it is not the permissions that is the problem, it is the ownership of the files. Developers do not realize that they should tell users to chown the files, not chmod them. Those are both meaningless words to users at first, but at least one of them is correct. The chown command. Only if you cannot chown, or if your host is absolutely horrid and will not do it for you, should you resort to opening the files for everyone to write to and execute. (I’d recommend changing servers in that case).

  8. Yep, my entire hosting account was disabled the other day because I had breached the server CPU usage limit.
    I was completely oblivious to the fact that you could be penalised for such a thing, but it was recommended that I take steps to improve the caching on my site.

    And now I have tried your method, everything seems to be working well so far. Now to see if it has really imroved the situation server-side!

Comments are closed for this post. Something to add? Let me know.
Perishable Press is operated by Jeff Starr, a professional web developer and book author with two decades of experience. Here you will find posts about web development, WordPress, security, and more »
Banhammer: Protect your WordPress site against threats.
Crazy that we’re almost halfway thru 2024.
I live right next door to the absolute loudest car in town. And the owner loves to drive it.
8G Firewall now out of beta testing, ready for use on production sites.
It's all about that ad revenue baby.
Note to self: encrypting 500 GB of data on my iMac takes around 8 hours.
Getting back into things after a bit of a break. Currently 7° F outside. Chillz.
Get news, updates, deals & tips via email.
Email kept private. Easy unsubscribe anytime.