How to Enable the Default WordPress Object Cache

by Jeff Starr on Wednesday, December 26, 2007 39 Responses

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:

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.

How to enable the 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:

1) Enable the caching mechanism — open your wp-config.php file and set the value of ENABLE_CACHE to “TRUE”:

define('ENABLE_CACHE', TRUE);

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

/wp-content/cache/

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 server 1
  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 ;)


39 Responses

Add a comment

[ Gravatar Icon ]

Rasheed#1

Thank you for this post.

But what about chmod 777 ?

Is it safe ?

Thanks

[ Gravatar Icon ]

DeepFreeze#2

The point that you mentioned, “saving you bandwidth”, I am quite sure that it might still be the same. But I am definitely sure that the Web Server CPU usage will drop down dramatically.

[ Gravatar Icon ]

Ozh#3

Indeed, it won’t save any bandwidth.

A noteworthy aspect of caching (be it WP-Cache, the built-in cache or whatever): whenever your blog takes ages to load and you have no clue where the problem comes from, just delete the /cache folder. More often than you’d think, it will fix everything.
On Dreamhost, I simply deactivated the cache on all the blogs I run because it was locking too often (I think the efficiency of it depends on some NFS configuration)

[ Gravatar Icon ]

Perishable#4

@Rasheed: If you are able, you should definitely use 755 over 777. 755 grants fewer permissions and is thus the preferable choice, however, this setting does not always work under all circumstances and on all servers, whereas 777 — although not ideal — generally does the trick.

@DeepFreeze: Yes, I see that now, I honestly don’t know what I was thinking (if anything) when I wrote that. I suppose it made sense at the time.. I guess that’s what I get for self-editing my content. I will definitely be fixing this — thanks for pointing it out ;)

@Ozh: Ouch! It hurts now ;) Sorry for the misinformation! Also, thank you for mentioning the “cure-all” cache-deletion trick. I have experienced this myself on more than one occasion, including, oddly enough, setting up the WP cache itself. It is a strange, frequently useless beast, I concur, however, it may prove beneficial for certain individuals and/or specific situations. Hopefully, this post will help shed some light on the overall implementation process.

[ Gravatar Icon ]

DeepFreeze#5

;-), Anytime Bro Anytime

[ Gravatar Icon ]

Frank#6

More Options for WP-Cache:

define('ENABLE_CACHE', true); // Cache on
define('CACHE_EXPIRATION_TIME', 604800); // Cachetime in seconds

and a small Plugin for control the cache:
http://bueltge.de/wordpress-cache-kontrollieren/479/

You can clear the cache with one click.
With best regards
Frank

[ Gravatar Icon ]

Perishable#7

Frank,

Thanks for reminding us about the CACHE_EXPIRATION_TIME option.. I was going to mention it in the article, but apparently failed to do so, for some reason or other..

Also thanks for sharing the WordPress Cache Controller plugin with us — I am sure users will find it useful! Clearing the cache with a single click is definitely sweet ;)

Cheers,
Jeff

[ Gravatar Icon ]

Frank#8

Welcome!

I have update this plugin with small addon. The plugin clear the cache, when you puplish, edit or delete comment and when you cjange private to puplish. You must not click, this functions is automaticly.
With best regards and sorry for my bad english.
Frank

[ Gravatar Icon ]

Perishable#9

Very good, Frank — thank you for sharing the update news with us!

Cheers,
Jeff

[ Gravatar Icon ]

Abhinav Singh#10

For me this never worked.

I tried deleting the cache folder, enable disable the things a few times but I could never see any files being generated in the cache folder.

Sorry, but your post sucked for me :(

[ Gravatar Icon ]

Jeff Starr#11

Hi Abhinav Singh, thanks for taking the time share your experience with us. Your frustration with the WordPress Object Cache is shared by many, including myself, hence the tutorial above. Hopefully you realize that the file-based object cache has been removed from all WordPress versions 2.5 or better. Looking at the site you linked to in your comment, it looks like you are running WordPress 2.5. Perhaps this is the issue?

Regardless of any specific problems you might be having, I have to emphasize that the methods described in my tutorial are peer-reviewed and quite sound. They have worked for a number of people running various versions of WordPress in a variety of different environments.

Btw, you shouldn’t fake your Feedburner subscriber count — it is dishonest, desperate, and makes you look like a real loser :(

[ Gravatar Icon ]

Abhinav Singh#12

Man it worked when I followed the steps and installed WP-Cache-2. So I am not sure where the problem was. Now I can see the cache files in the cache folder

And kuddos to you man. You are the first one who has found that out from over a thousand visitors to my site.

So now probably its time to release this hack where people can put the same on their sites :) Nothing that I am a looser, I created this as a hack. Though to release this for everyone, but then help myself back till someone picks me up on this ;)

Kuddos dude ;)

[ Gravatar Icon ]

btFish#13

There is something wrong wordpress2.7

[ Gravatar Icon ]

Jeff Starr#14

@btFish: Check out comment number eleven for an explanation.

[ Gravatar Icon ]

cyberhobo#15

Thanks for this bit of illumination on a dark topic. It still seems a bit mysterious to me what the object cache does since the removal of file-based caching. Are cached objects no longer persistent across requests? And why are there still freshly dated files the cache directory of my WP 2.7 installation?

Look at the code I would guess the answer to the first question is no, but the second question makes me think I’m missing something.

As a plugin author, I’d like to be able to cache things persistantly without depending on other plugins, but it’s not clear that the object cache provides this ability.

[ Gravatar Icon ]

Frank#16

WordPress bigger 2.6 has not a cache-directory, WP has now a object-cache.

[ Gravatar Icon ]

JK#17

Jeff, I too tried several attempts but no success yet on this one.

Do I need to have Wp-Cache2 and Wp-Super-Cache plugins installed to enable this built-in feature?

Thanks, JK

[ Gravatar Icon ]

Jeff Starr#18

@cyberhobo, @JK: As mentioned in comment #11, the file-based object cache has been removed from all WordPress versions 2.5 or better.

[ Gravatar Icon ]

cyberhobo#19

Thanks for answering. The files in the cache directory that are puzzling me must be created by something else. They are named with a hash ending in .spc.

[ Gravatar Icon ]

jidanni#20

Maybe you should add a warning at the top of this article, that one can no longer (do the title of this article) “Enable the Default WordPress Object Cache”, (which is apparently the case, if one reads through the comments.) And mention if there is any built in alternatives, or must one resort to plugins? Thanks.

[ Gravatar Icon ]

Jeff Starr#21

@jidanni: Thanks for the advice. I have included a note to this effect in the article. Cheers!

[ Gravatar Icon ]

php trivandrum#22

On an academic interest resurrected the file based object cache for wordpress. http://www.php-trivandrum.org/wordpress-plugins/wordpress-object-caching-in-file-system.html

[ Gravatar Icon ]

Jeff Starr#23

@php trivandrum: Good stuff! Thanks for sharing! :)

[ Gravatar Icon ]

bucabay#24

I’m working on a PHP Object Cache. An implementation for wordpress is coming along:

http://code.google.com/p/php-object-cache/

[ Gravatar Icon ]

Ferodynamics#25

According to the Codex, it changed to

define('WP_CACHE', TRUE);

not

define('ENABLE_CACHE', TRUE);

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

[ Gravatar Icon ]

cyberhobo#26

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

http://codex.wordpress.org/Transients_API

[ Gravatar Icon ]

Ferodynamics#27

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

[ Gravatar Icon ]

bucabay#28

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.

[ Gravatar Icon ]

Jeff Starr#29

@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!

[ Gravatar Icon ]

t3lamo#30

Thank you for this post

[ Gravatar Icon ]

bucabay#31

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

Trackbacks / Pingbacks
  1. 38 ways to optimize and speed up your WordPress blog | WordPressGarage.com
  2. HM2K.com » 10 wordpress performance optimisation tips
  3. Enlaces en mi del.icio.us, 4 12 2008 | Vectoralia
  4. Fondos de Pantalla » Blog Archive » Enlaces en mi del.icio.us, 4 12 2008
  5. PHP Trivandrum » Wordpress object caching in file system
  6. know-how.com.es » Convertir on-line páginas web en documentos pdf
  7. How to setup a blog/website based on wordpress (incl. performance and search engine optimizations) | all about IT infrastructure
  8. How to optimize and get better speed with your blog in wordpress | Dagorret
Share your thoughts..

Read Comment Policy

Comment Rules: No spam. No profanity. Use your real name. You may use simple HTML tags for style. Wrap all code in <code> tags. Learn more.



Previous post: December 22nd, 2007

Attention: Do NOT follow this link!