Hyper Cache

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, particulary on the mysql side. Hyper Cache solved all my performace problems.

(My english is very low… send me notes and corrections… I appreciate them)

This page has just been moved from satollo.com and need a bit of reorganization. Be patience.

Hyper Cache main features

  • esay 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 kind 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:

define('WP_CACHE', true);

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 it self is explained to now modify it under a certain line.

Configuration

Expiration time

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 remeber 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. Why it’s better to expire a page (even with a long time)? Because a page is not only the article text, but there are other information, like categories list with posts numbers, latest comment list, latest posts list and so on. With new content, new comments, those lists becomes “old”.

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 textarea 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.

FAQ

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 info@satollo.net.

Some time software needs support to be effectively used. No doubt, write me to info@satollo.net 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 silentely 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 behaviour let some plugin to work correctly.

Are AdSense, Analytics, MyBlogLog and so on affected?

No, absolutely. Those kind of services are delivered with javascript so they still work. My sites all use those services and all have Hyper Cache installed.

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 funzion enabled).

Redirects and 404 not found are cached, too

WordPress sends a redirect on wrong URL or when a request doesn’t use the correct host (eg. domain.com instead of www.domain.com). Even if those are redirects and not served pages, WordPress and plugins will e activated by such requests, loading the database. If around the world there is a (wrong) link to you, every time it is used you will have two requests, not only one! Hyper Cache detects redirects and caches them using very little disk space. Not found pages are another problem.: when a request doesn’t match any page or post, WordPress creates the 404 page. This page is a normal html page that requires plugins, queries and so on. Hyper Cache, caches the 404 page and store only one file for this kind of requests. This behaviour optimize the missing resource requests, too, like images, css, javascript that are no more in your web space. Actually a WordPress blog without a cache system like Hyper Cache, will try to serve a page when a missing image is requested, creating a lot of load (it’s useful to check for missing resources in your blog tracking the sequence of requests made by the browser while loading a page: you can use Firefox with Live HTTP Headers extension).

Autoclean option

If a page is rarely requested, it stays in cache for days, using precious space. Enabling autoclean, 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 autoclean 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).

Drawbacks

The cache tries to be as much performat 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.

Technical notes

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 thw Hyper Cache buffer before Hyper Cache write it to disk.

To stop Hyper Cache to cache a specific request, simple declare a global variable:

global $hyper_cache_stop;

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:

add_filter(‘hyper_cache_buffer’, ‘myplugin_hyper_cache_buffer’);

where “myplugin_hyper_cache_buffer” is a function like the one below:

function myplugin_hyper_cache_buffer($buffer)
{
// work with buffer (it’s, usually, an UTF-8 string)
return $buffer;
}

I have not deeply test the latest feature, help me to test it if you have time!

This page, even if not complete, collects come configuration tips for Hyper Cache. If you have questions, please write me at <a href=”mailto:info@satollo.com”>info@satollo.com</a>.
<ul>
<li><a href=”#expiration-time”>Expiration time</a></li>
<li><a href=”#invalidation-methods”>Invalidation methods</a></li>
<li><a href=”#uri-rejection”>URI rejection</a></li>
<li><a href=”#faq”>Frequently Asked Questions</a></li>
</ul>
If you choosed to use Hyper Cache and are satisfied do a check of the advantages or the money saving it brings to you and consider to donate something: that will help me to continue the Hyper Cache developement.  <a href=”https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&amp;hosted_button_id=2595746″><img class=”alignnone” title=”Donate” src=”/english/images/paypal.gif” alt=”" width=”92″ height=”26″ /></a> Thank you!  <a name=”expiration-time”></a>
<h2>Expiration time</h2>
<strong>What means “expire a cached page after X minutes” and what’s the best value?</strong> 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 remeber 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.  Why it’s better to expire a page (even with a long time)? Because a page is not only the article text, but there are other information, like categories list with posts numbers, latest comment list, latest posts list and so on. With new content, new comments, those lists becomes “old”.  <a name=”invalidation-methods”></a>
<h2>Invalidation methods, what’s the best?</h2>
There is not a best method, it all depends on your needs.  <strong>Method “all”</strong>. 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.  <strong>Method “single page”</strong>. 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 page is invalidated too just to keep it coherent. But all the cache will be cleared if a post change it’s status from unpublished to published or from published to unpublished. That behaviour keeps all the blog pages updated (no links to article no more active or missing links to article just published).  <strong>Method “single page strictly”</strong>. I was asked to invalidate only and only tha cache page of a post when it is modified (even for a status change as explained), because there was no interest on having all the page perfectly updated.  <strong>Method “none”</strong>. 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 tha cache still respects the expiration time.  <a name=”uri-rejection”></a>
<h2>URI rejection and matching criteria</h2>
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 textarea <strong>without</strong> quotes. The matching criteria is “if the current URI <strong>starts</strong> 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.  <strong>What about if I need to reject a page with URI “/special” but cache the page with URI “/special-page”?</strong> Simply write the URI to reject surrounded <strong>with</strong> double quotes: “/special”. Hyper Cache will match exactly that page.  <a name=”faq”></a>
<h2>FAQ</h2>
<strong>The options panel is saying my installation has problems!</strong> Deactivate and reactivate the plugin: some files need to be rewritten. Then **re-save** the configuration even if you didn’t make changes.  <strong>Why have I to use Hyper Cache and not other cache systems?</strong> 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?  <strong>Where are the cache pages?</strong> In to the folder /wp-content/hyper-cache: if you empty that directory the cache starts from zero.  <strong>Why have I to donate? And how?</strong> 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 :-) . Or…  <a href=”https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&amp;hosted_button_id=2595746″><img class=”alignnone” title=”Donate” src=”/english/images/paypal.gif” alt=”" width=”92″ height=”26″ /></a> Thank you!