Wordpress Plugins – Extensions

Just another WordPress.com weblog

Quick Cache ( A WP Super Cache Alternative ) 2.1.4

Authors: WebSharks, PriMoThemes
If you care about the speed of your site, Quick Cache is one of those plugins that you absolutely MUST have installed. Quick Cache takes a real-time snapshot ( building a cache ) of every Page, Post, Category, Link, etc. These snapshots are then stored ( cached ) intuitively, so they can be referenced later, in order to save all of that processing time that has been dragging your site down and costing you money
Installation:
Quick Tip: WordPress® can only deal with one cache plugin being activated at a time. So, you’ll need to un-install any existing cache plugins that you’ve tried in the past. In other words, if you’ve installed WP-Super-Cache, DB-Cache-Reloaded, or any other caching plugin, un-install them all before installing Quick Cache. One way to check, is to make sure this file: /wp-content/advanced-cache.php is NOT present; and if it is present, delete it before installing Quick Cache. That file will ONLY be present if you have a cache plugin already installed. If you don’t see it, you’re good.

Quick Cache is very easy to install ( follow these instructions ):

Upload the /quick-cache folder to your /wp-content/plugins/ directory.
Activate the plugin through the Plugins menu in WordPress®.
Navigate to the Quick Cache panel & enable it.

How do I know that Quick Cache is working?

First of all, make sure that you’ve enabled Quick Cache. After you activate the plugin, go to the Quick Cache Options panel and enable it, then scroll to the bottom and click Save. All of the other options on that page are already pre-configured for typical usage. Skip them all for now. You can go back through all of them later and fine-tune things the way you like them. Once Quick Cache has been enabled, you’ll need to log out. Cache files are NOT served to visitors who are logged in, and that includes YOU! In order to verify that Quick Cache is working, navigate your site like a normal visitor would. Right-click on any page ( choose View Source ), then scroll to the very bottom of the document. At the bottom, you’ll find comments that show Quick Cache stats and information. You should also notice that page-to-page navigation is lightning fast compared to what you experienced prior to installing Quick Cache.

Running Quick Cache On A WordPress® MU Installation

WordPress® MU is a special ( multi-user ) version of WordPress®. If Quick Cache is installed under WordPress® MU, it will be enabled for ALL blogs the same way. The centralized config options for Quick Cache, can only be modified by the MU Site Administrator operating on the main site with Blog ID# 1. Under WordPress® MU, a special file: quick-cache-mu.php will be added to your mu-plugins directory automatically. That special file prevents the Quick Cache plugin from being visible to other blog owners, even when the Plugins Menu is turned on in your MU options panel. This is recommeded for security purposes, because Quick Cache is a unique plugin, that should only be modified, updated, or de-activated by the Site Administrator, not by individual blog owners.

Even without the quick-cache-mu.php file, Quick Cache still has internal processing routines that prevent configuration changes by anyone other than the Site Administrator. The quick-cache-mu.php file just removes any confusion that may occur as a result of the plugin being listed as a possible option to other blog owners; which only occurs when you have the Plugins Menu enabled in your MU options. If you’re running the standard version of WordPress®, you can safely ignore this notation, because you won’t even have an mu-plugins directory. WordPress® MU is a special ( multi-user ) version of WordPress® that is normally installed by web developers.

faq:
How do I know that Quick Cache is working the way it should be?

First of all, make sure that you’ve enabled Quick Cache. After you activate the plugin, go to the Quick Cache Options panel and enable it, then scroll to the bottom and click Save. All of the other options on that page are already pre-configured for typical usage. Skip them all for now. You can go back through all of them later and fine-tune things the way you like them. Once Quick Cache has been enabled, you’ll need to log out. Cache files are NOT served to visitors who are logged in, and that includes YOU! In order to verify that Quick Cache is working, navigate your site like a normal visitor would. Right-click on any page ( choose View Source ), then scroll to the very bottom of the document. At the bottom, you’ll find comments that show Quick Cache stats and information. You should also notice that page-to-page navigation is lightning fast compared to what you experienced prior to installing Quick Cache.

What is the down side to running Quick Cache?

Ummm, how can we say this… There is NOT one! Quick Cache is a MUST HAVE for every WordPress® powered site. In fact, we really can’t think of any site running WordPress® that would want to be without it. To put it another way, the WordPress® software itself comes with a built in ( hard-coded ) action reference for an advanced-cache.php file, because WordPress® developers realize the importance of such as plugin. The /wp-content/advanced-cache.php file is named as such, because the WordPress® developers expect it to be there when caching is enabled by a plugin. If you don’t have the /wp-content/advanced-cache.php file yet, it is because you have not enabled Quick Cache from the options panel yet.

So why does WordPress® need to be cached?

To understand how Quick Cache works, first you have to understand what a cached file is, and why it is absolutely necessary for your site and every visitor that comes to it. WordPress® ( by its very definition ) is a database-driven publishing platform. That means you have all these great tools on the back-end of your site to work with, but it also means that every time a Page/Post/Category is accessed on your site, dozens of connections to the database have to be made, and literally thousands of PHP routines run in harmony behind-the-scenes to make everything jive. The problem is, for every request that a browser sends to your site, all of these routines and connections have to be made ( every: yes, every single time ). Geesh, what a waste of processing power, memory, and other system resources. After all, most of the content on your site remains the same for at least a few minutes at a time. If you’ve been using WordPress® for very long, you’ve probably noticed that ( on average ) your site does not load up as fast as other sites on the web. Now you know why!

In computer science, a cache (pronounced /kash/) is a collection of data duplicating original values stored elsewhere or computed earlier, where the original data is expensive to fetch (owing to longer access time) or to compute, compared to the cost of reading the cache. In other words, a cache is a temporary storage area where frequently accessed data can be stored for rapid access. Once the data is stored in the cache, it can be used in the future by accessing the cached copy rather than re-fetching or recomputing the original data.

Where & why are the cache files stored on my server?

The cache files are stored in a special directory: /wp-content/cache/. This directory needs to remain writable, just like the /wp-content/uploads directory on many WordPress® installations. The /cache directory is where MD5 hash files reside. These files are named ( with an MD5 hash ) according to your MD5 Version Salt and the HTTP_HOST/REQUEST_URI. ( See: Quick Cache -> Config Options -> MD5 Version Salt ).

Whenever a request comes in from someone on the web, Quick Cache checks to see if it can serve a cached file, it looks at your Salt, it looks at the HTTP_HOST/REQUEST_URI, then it checks the /cache directory. If a cache file has been built already, and it matches your Salt.HTTP_HOST.REQUEST_URI combination, and it is not too old ( See: Quick Cache -> Config Options -> Expiration ), then it will serve that file instead of asking WordPress® to re-generate it. This adds tremendous speed to your site and reduces server load.

If you have GZIP compression enabled, then the cache file is also sent to the browser with compression ( recommended ). Modern web browsers that support this technique will definitely take advantage of it. After all, if it is easier to email a zip file, it’s also easier to download a web page that way. That is why on-the-fly GZIP compression for web pages is recommended. This is supported by all modern browsers.

If you want to enable GZIP, create an .htaccess file in your WordPress® installation directory and put the following few lines in it. Alternatively, if you already have an .htaccess file, just add these lines to it, and that is all there is to it. GZIP is now enabled!

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/xml text/css text/plain
AddOutputFilterByType DEFLATE image/svg+xml application/xhtml+xml application/xml
AddOutputFilterByType DEFLATE application/rdf+xml application/rss+xml application/atom+xml
AddOutputFilterByType DEFLATE text/javascript application/javascript application/x-javascript
AddOutputFilterByType DEFLATE application/x-font-ttf application/x-font-otf
AddOutputFilterByType DEFLATE font/truetype font/opentype
</IfModule>

If your installation of Apache does not have mod_deflate installed. You can also enable GZIP compression using PHP configuration alone. In your php.ini file, you can simply add the following line anywhere: zlib.output_compression = on

What happens if a user logs in? Are cache files used then?

The decision engine that drives these techniques is under your complete control through options on the back-end. By default, Quick Cache does not serve cached pages to users who are logged in, or users who have left comments recently. Quick Cache also excludes administrational pages, login pages, POST/PUT/GET requests, CLI processes, and any additional User-Agents or special pattern matches that you want to add. POST requests should never be cached. A CLI request is one that comes from the command line; commonly used by cron jobs and other automated routines.

Will comments and other dynamic parts of my blog update immediately?

There is an automatic expiration system ( the garbage collector ), which runs through WordPress® behind-the-scenes, according to your Expiration setting ( See: Quick Cache -> Config Options -> Expiration ). Then there is also a built-in expiration time on existing files that is checked before any cache file is served up, which also uses your Expiration setting. In addition; whenever you update a Post or a Page, Quick Cache can automatically prune that particular file from the cache so it instantly becomes fresh again. Otherwise your visitors would need to wait for the previous cached version to expire. ( See: Quick Cache -> Config Options -> Dynamic Cache Pruning ).

By default, Quick Cache does not serve cached pages to users who are logged in, or users who have left comments recently. Quick Cache also excludes administrational pages, login pages, POST/PUT/GET requests, CLI processes, and any additional User-Agents or special pattern matches that you want to add. POST requests should never be cached. A CLI request is one that comes from the command line; commonly used by cron jobs and other automated routines.

Can I customize the way cache files are stored & served up?

Quick Cache provides you with the ability to customize the Salt used in MD5 hash generation for cache storage, and that directly affects the way they are served also. The ability to customize the Salt used in cache storage is important to advanced webmasters. Some sites offer unique services and serve special versions of certain files across different devices. The ability to control how different versions of pages are cached, is critical to advanced webmasters that need to tweak everything and customize the caching engine to their specific needs. ( See: Quick Cache -> Config Options -> MD5 Version Salt ). If you don’t understand what a Salt is, or what an MD5 hash is, that is 100% ok 🙂 If you don’t understand what it is, you probably don’t need it. That simple 🙂 Using a custom Salt is a very advanced technique and it is not required to benefit from speed enhancements provided by Quick Cache.

How do I enable GZIP compression? Is GZIP supported?

There is no need to use an .htaccess file with this plugin; caching is handled by WordPress®/PHP alone. That being said, if you also want to take advantage of GZIP compression ( and we do recommend this ), then you WILL need an .htaccess file to accomplish that part. This plugin fully supports GZIP compression on its output. However, it does not handle GZIP compression directly. We purposely left GZIP compression out of this plugin, because GZIP compression is something that should really be enabled at the Apache level or inside your php.ini file. GZIP compression can be used for things like JavaScript and CSS files as well, so why bother turning it on for only WordPress® generated pages when you can enable GZIP at the server level and cover all the bases.

If you want to enable GZIP, create an .htaccess file in your WordPress® installation directory and put the following few lines in it. Alternatively, if you already have an .htaccess file, just add these lines to it, and that is all there is to it. GZIP is now enabled!

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/xml text/css text/plain
AddOutputFilterByType DEFLATE image/svg+xml application/xhtml+xml application/xml
AddOutputFilterByType DEFLATE application/rdf+xml application/rss+xml application/atom+xml
AddOutputFilterByType DEFLATE text/javascript application/javascript application/x-javascript
AddOutputFilterByType DEFLATE application/x-font-ttf application/x-font-otf
AddOutputFilterByType DEFLATE font/truetype font/opentype
</IfModule>

If your installation of Apache does not have mod_deflate installed. You can also enable gzip compression using PHP configuration alone. In your php.ini file, you can simply add the following line anywhere: zlib.output_compression = on

How can I serve a different set of cache files to iPhone users?

Set your MD5 Version Salt to the following:

((preg_match(“/IPHONE/i”, $_SERVER[”HTTP_USER_AGENT”])) ? “IPHONES” : “”)

This effectively creates two versions of the cache. When iPhone browsers are detected, Quick Cache will prepend IPHONES to the HTTP_HOST.REQUEST_URI, before it generates the MD5 hash for storage.

How can I serve a different set of cache files based on a cookie?

Set your MD5 Version Salt to the following:

((preg_match(“/BlueLizards/i”, $_COOKIE[”BlueLizardsCookie”])) ? “BlueLizards” : “”)

This effectively creates two versions of the cache. When BlueLizardsCookie contains BlueLizards, Quick Cache will prepend BlueLizards to the HTTP_HOST.REQUEST_URI, before it generates the MD5 hash for storage. Another, even simpler way to handle this, would be to use the value of a specific cookie to generate multiple variations of the cache. So instead of the Ternary expression shown above, you would simply set your Version Salt to:

$_COOKIE[”someCookie”]

The value of $_COOKIE[”someCookie”] is what would be used as your Version Salt. It would even be OK if $_COOKIE[”someCookie”] was equal to an empty string. In that case the default version of the cache would be used.

I’m a plugin developer. How can I prevent certain files from being cached?

define(“QUICK_CACHE_ALLOWED”, false);

When your script finishes execution, Quick Cache will know that it should NOT cache that particular page. It does not matter where or when you define this Constant. Quick Cache is the last thing to run during execution. So as long as you define this Constant at some point in your routines, everything will be fine. Quick Cache also provides backward support for define(“DONOTCACHEPAGE”, true), which is used by the WP Super Cache plugin as well. Another option is: $_SERVER[”QUICK_CACHE_ALLOWED”] = false. The $_SERVER array method is useful if you need to disable caching at the Apache level using mod_rewrite. The $_SERVER array is filled with all Environment variables, so if you use mod_rewrite to set the QUICK_CACHE_ALLOWED Environment variable, that will end up in $_SERVER[”QUICK_CACHE_ALLOWED”]. All of these methods have the same end result, so it’s up to you which one you’d like to use.

What should my expiration setting be?

If you don’t update your site much, you could set this to 1 week ( 604800 seconds ) and optimize everything even further. The longer the cache expiration time is, the greater your performance gain. Alternatively, the shorter the expiration time, the fresher everything will remain on your site. 3600 ( which is 1 hour ) is the recommended expiration time, it’s a good middle ground. That being said, you could set this to just 60 seconds and you would still see huge differences in speed and performance.

Quick Cache ( A WP Super Cache Alternative ) 2.1.4

Advertisements

April 19, 2010 - Posted by | download, extension, extensions, free, get, internet, plugin, plugins, Uncategorized, wordpress

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: