Hyper Cache for WordPress is the secret dream of every hosting provider!
Hyper Cache is a cache system for WordPress. I wrote it because my hosting provider was very low in resources, particularly on the MySql side. Hyper Cache solved all my performance problems.
Please consider Lite Cache as well. Lite Cache is a caching plugin with less feature but better performances and solves a number of issues of Hyper Cache, like the cleaning of pages generated on blogs with pages comments.
Hyper Cache main features
- easy installation (from 2.5.9 version): just activate Hyper Cache and it works with a set of default values
- every cached page will be served without accessing the database
- gzip support for enabled browser with gzip caching (no page recompression on each request)
- four invalidation modes
- cache autoclean on configurable time interval
- “urls to bypass” configurable (with two kinds of matching)
- Global Translator plugin detection to avoid double caching
- mobile browser detection with two separate caches (wp-pda plugin compatible)
- low disk usage option
- redirects and 404 caching
- feed and home caching separate control
- user agents configurable rejection
- easy to install and configure, no file hacking or modification need
- last but not least the author will always listen to you!
Hyper Cache versions are announced and described with posts tagged hyper cache versions.
To get help or ask questions, the preferred way is to leave a comment on Hyper Cache Help post.
Hyper Cache is very useful to me, and I think it’s very useful to many other bloggers. May be some of you are saving a lot of money on low cost hosting provider. With that in mind consider a donation: it will help me to develope new features for Hyper Cache instead of writing italian gossip to earn something with AdSense… Thank you!
Download and Installation
Download it from the WordPress Plugin Repository. Activate and go to the options page to configure and save the configuration even if some parameters are already set! If no warning messages appear, the cache is ready to work. Open your wp-config.php file and add the line of code:
if not present, or, if present, modify it accordingly.
Pay attention: add that line of code just after the define(WPLANG, ”) not at the and of wp-config.php. In the file itself is explained to now modify it under a certain line.
What means “expire a cached page after X minutes” and what’s the best value? Hyper Cache stores an html page in it’s repository. On each reaquest for a page, Hyper Cache checks how much old that page is. If the cached page is older than the X time (in minutes) specified, that page is not served by Hyper Cache, but “re-created” by WordPress (like if a cache system was not here).
Hyper Cache then restores the generated page. I use 1440 minutes for my pages (one day), but remember that a page can be cleared on special events (like comment or modification by the blog owner). You can specify a zero value to avoid any kind of cache expiration.
Invalidation methods, what’s the best?
There is not a best method, it all depends on your needs.
Method “all”. If you need a really coherent and updated blog, you can choose the method “all”: each action on posts (eg. edit), new comment submission and so on leads to a complete cache invalidation. But it’s the more expensive (for your blog, not for the cache). Remember that Hyper Cache (at now) doesn’t intercept the blogroll modification or the theme change. For the latter there are good reasons. So if you plan to make big modification to the blog, manually invalidate the cache.
Method “single post”. With this method, Hyper Cache invalidate only the cached page of a post modified (with the editor or when a new comment is added to it). The home/archives pages are invalidated too if specified with relative option flag.
Method “none”. The cache is never invalidated whatever action will be made (new comments, new posts, editing, and so on). This method can be good if you do very little modification to your blog. Obviously the cache still respects the expiration time.
URI rejection and matching criteria
There are times when a page or a post has to be served always from WordPress. Given the URI (URI is the right word) of that post, it can be added to the url to reject textarea. Let’s go with an example. You have a special page that has not to be cache, let it to be under the URI “/special-page”. So, enter that URI in the text area without quotes. The matching criteria is “if the current URI starts with one of the specified, just skip the caching system”. Read the criteria, you can use the partial URI “/special” and the special page will be still rejected.
What about if I need to reject a page with URI “/special” but cache the page with URI “/special-page”? Simply write the URI to reject surrounded with double quotes: “/special”. Hyper Cache will match exactly that page.
I found no file in the cache folder. Try to set it to 777 permission level:for some reasons and on some provider Hyper Cache cannot write in that directory… there is no good explanations till now.
The options panel is saying my installation has problems! Deactivate and reactivate the plugin: some files need to be rewritten. Then **re-save** the configuration even if you didn’t make changes.
Why have I to use Hyper Cache and not other cache systems? I really cannot answer that question, but I wrote Hyper Cache to have an easly to install and crontrol cache system for WordPress that make me happy with a 4000 page views/day blog and a 12$/year hosting provider. Enough?
Where are the cache pages? In to the folder /wp-content/hyper-cache/cache: if you empty that directory the cache starts from zero.Do not delete the directory!
Why have I to donate? And how? There is chances that if you are using Hyper Cache you are saving a lot of money keeping you site in a cheap provider. This can be a reason. Or just because you find me a cool programmer and want me to keep in developing Hyper Cache and eating two times a day .
Help, support, bugs, feature request
Main place to ask support is here, but…
Any piece of software is great when it is really useful. Your request for new features, your bugs submission make the software better. No doubt, write me to firstname.lastname@example.org.
Some time software needs support to be effectively used. No doubt, write me to email@example.com and I’ll try to help out with your issues (clearly for free). I ask you only a little thing: be patience, I’m father of two little children, they have priority.
How Hyper Cache works
On each request, the cache engine is called by WordPress. It checks if the html for this request is in cache and is still valid. If so the html page is returned and everything stops. WordPress calls the cache engine BEFORE any other kind of operations, so not plugins are activated, no database connection established, no queries executed. Il the page requested is not in cache, the cache engine “capture” the html produced by WordPress and put it on file. If you are the blog owner and you did login (so you have the WordPress cookies), you are always served by WordPress, the cache engine silently pass through. Hence to test the cache performance use a clean browser or delete all the cookies!
Hyper Cache is nice with mobile blogs
When a blog uses wp-pda to serve different pages to mobile devices a general cache system didn’t work, because it stores in cache the normal or the mobile version of a page: it dipends by the first caller. Hyper Cache uses the wp-pda detection code and can store different pages for different devices (PDA or iPhone). So it’s wp-pda safe. I think it can work with other “mobile” plugin, I’ve not tested yet. The cache works only with permalink active. It doesn’t cache POST request or GET request with parameters. This behavior let some plugin to work correctly.
Are AdSense, Analytics, MyBlogLog and so on affected?
Gzip is no more a problem
If you are low of bandwidth and prefer to serve gzip compressed page to enabled browser… don’t worry. From version 2.0 gzip compression is working (if you provider has the gzencode function enabled).
Redirects and 404 not found are cached, too
If a page is rarely requested, it stays in cache for days, using precious space. Enabling auto clean, the cache clear all the expired cached pages at the specifies time interval. It’s not a real cron job, but on sites with a minimum of traffic works nice.
From version 2.5.5 auto clean is very important, do not disable it!
Cache invalidation methods
You can decide if the cache has to be completely invalidated every time there is a change, has to be invalidated only the single post modified (there is exceptions with this method) or never invalidated (relay only on cache timeout for every single page).
The cache tries to be as much quick as possible but that has some drawbacks. Specifically, when a page is in cache it is served directly and WordPress is not started. This means that no plugins are activated, so the ones that need to be called on each request (eg. for statistic) stop to give reliable results. This is a common issue to many cache systems, to say the truth.
Removing the plugin
Deactivate it. The deactivation removes some of the Hyper Cache files (see the technical notes). The wp-config.php is not changed, you can remove the “define” statement by hand: it doesn’t hurt, anyway.
The plugin create one file inside the wp-content folder. The file is “advanced-cache.php” and is required by WordPress. If the wp-content is not writable, Hyper Cache fails to install. A message should appear in the admin panel.
For plugin developers
You plugins can interact with Hyper Cache in two way: stopping it or dealing with the Hyper Cache buffer before Hyper Cache write it to disk.
To stop Hyper Cache to cache a specific request, simple declare a global variable:
and set it to “true”:
$hyper_cache_stop = true;
That forces Hyper Cache to not save the current page. I use it, for example, on my Newsletter plugin and on my Protector plugin that create/modify pages in different way for each users.
The second wau to interact with Hyper Cache is to intercept the buffer before it is written to disk. To do that you need to register a filter:
where “myplugin_hyper_cache_buffer” is a function like the one below:
// work with buffer (it’s, usually, an UTF-8 string)
I have not deeply test the latest feature, help me to test it if you have time!