This plugin generates static html files from your dynamic WordPress blog. After a html file is generated your webserver will serve that file instead of processing the comparatively heavier and more expensive WordPress PHP scripts.
The static html files will be served to the vast majority of your users, but because a user’s details are displayed in the comment form after they leave a comment those requests are handled by the legacy caching engine. Static files are served to:
- Users who are not logged in.
- Users who have not left a comment on your blog.
- Or users who have not viewed a password protected post.
99% of your visitors will be served static html files. Those users who don’t see the static files will still benefit because they will see different cached files that aren’t quite as efficient but still better than uncached. This plugin will help your server cope with a front page appearance on digg.com or other social networking site.
If for some reason “supercaching” doesn’t work on your server then don’t worry. Caching will still be performed, but every request will require loading the PHP engine. In normal circumstances this isn’t bad at all. Visitors to your site will notice no slowdown or difference. Supercache really comes into it’s own if your server is underpowered, or you’re experiencing heavy traffic. Super Cached html files will be served more quickly than PHP generated cached files but in every day use, the difference isn’t noticeable.
The plugin serves cached files in 3 ways (ranked by speed):
- Mod_Rewrite. The fastest method is by using Apache mod_rewrite (or whatever similar module your web server supports) to serve “supercached” static html files. This completely bypasses PHP and is extremely quick. If your server is hit by a deluge of traffic it is more likely to cope as the requests are “lighter”. This does require the Apache mod_rewrite module (which is probably installed if you have custom permalinks) and a modification of your .htaccess file. Visits by anonymous or unknown users will be served this way.
- PHP. Supercached static files can now be served by PHP. The plugin will serve a “supercached” file if it exists and it’s almost as fast as the mod_rewrite method. It’s easier to configure as the .htaccess file doesn’t need to be changed. You still need a custom permalink. You can keep portions of your page dynamic in this caching mode. Your server may not cope as well with a really large amount of traffic. (You’re gaming Digg aren’t you? You’ll need mod_rewrite, the rest of us are ok with PHP!)
- Legacy caching. This is mainly used to cache pages for known users. These are logged in users, visitors who leave comments or those who should be shown custom per-user data. It’s the most flexible caching method but also the slowest. As each page is different it’s often better not to cache pages for these users at all and avoid legacy caching. Legacy caching will also cache visits by unknown users if this caching mode is selected. You can have dynamic parts to your page in this mode too.
If you’re new to caching use PHP caching. It’s easy to set up and very fast. Avoid legacy caching if you can.
Advanced users will probably want to use mod_rewrite caching, but PHP caching is almost as good and recommended for everyone else. Enable the following:
- PHP caching.
- Compress pages.
- Don’t cache pages for known users.
- Cache rebuild.
- CDN support.
- Extra homepage checks.
Garbage collection is the act of cleaning up cache files that are out of date and stale. There’s no correct value for the expiry time but a good starting point is 1800 seconds if you’re not using legacy mode. If you are using that mode start with an expiry time of 600 seconds.
If you are not using legacy mode caching consider deleting the contents of the “Rejected User Agents” text box and allow search engines to create supercache static files.
Likewise, preload as many posts as you can and enable “Preload Mode”. Garbage collection will still occur but it won’t affect the preloaded files. If you don’t care about sidebar widgets updating often set the preload interval to 2880 minutes (2 days) so all your posts aren’t recached very often. When the preload occurs the cache files for the post being refreshed is deleted and then regenerated. Afterwards a garbage collection of all old files is performed to clean out stale cache files. With preloading on cached files will still be deleted when posts are made or edited or comments made.
See the WP Super Cache homepage for further information. Developer documentationis also available for those who need to interact with the cache or write plugins.
There’s a GIT repository too if you want to contribute a patch.
The changelog is a good place to start if you want to know what has changed since you last downloaded the plugin.
Interested in translating WP Super Cache to your language? Grab the development version where you will find an up to date wp-super-cache.pot. Send any translation files to donncha @ ocaoimh.ie and thank you!
The cache directory, usually wp-content/cache/ is only for temporary files. Do not ever put important files or symlinks to important files or directories in that directory. They will be deleted if the plugin has write access to them.