Testing your Boost configuration
Now we’re going to test out our Boost configuration and make sure everything is working with our initial basic settings and the .htaccess configuration that we’re running. Log out of your website in your current browser or open up another web browser so that you can browse around your site as an anonymous user.
The main thing we want to check on is that our static HTML type files (our Drupal pages or nodes) are being cached and stored in the cache directory we have specified in the module configuration. If we chose to use a GZIP compression, we will want to check to make sure the ZIP files are being generated and stored.
Also, run your Status report and view your log entries to check to see if any errors related to the module configuration are being thrown.
You should start noticing a performance boost on your site immediately, as you browse around your site. Start clicking around and opening different nodes on your site and admire the faster performance! You should notice it.
If we check the cache directory on our site, we should notice that the Boost module has started writing HTML files to our cache directory. In the directory you should now see the following folders:
/cache/normal/variantcube.com/fire/node
Boost has automatically created a new folder called /node where it will store the cached HTML versions of the Drupal pages it loads. For example, if we look into our /node directory, we should see a bunch of HTML files that have been cached while we’ve browsed anonymously on our site. You can almost see this happen in real time if you browse to a page and then immediately refresh your remote server/ site window in your FTP client (while in the /node folder). I see the following files corresponding to their Drupal nodes:
201_.html
202_.html
203_.html
206_.html
208_.html
These correspond to:
node/201
node/202
node/203
node/206
node/208
Also, at the root of our /fire directory, we should see any non-node pages (for example, pages created using Drupal Views module). In our case, our main Photo gallery View page has been cached: photo_gallery.html. This page corresponds to our photo_gallery View page.
You can immediately see the power and flexibility of this module by inspecting your cache directory.
You should notice a performance increase on all of these cached pages because the pages that are loading are now your Boost-powered HTML pages. So, multiple clicking on one Drupal node should demonstrate how quickly your pages are now loading.
The module has created another folder in your /fire/cache directory called perm. The /perm folder contains your CSS and JS files as they are cached. If you look in this folder, you’ll see paths to the following folders:
/cache/perm/variantcube.com/fire/files/css
/cache/perm/variantcube.com/fire/files/js
If you look in your CSS directory, you should see cached versions of your CSS files, and if you look in your /js directory, you should see a cached version of your JavaScript.
Another method of checking the module is working correctly is to view source on your pages (by viewing source in your web browser) and see if the following code is being added to your HTML output:
<!-- Page cached by Boost @ 2009-10-23 13:56:03,
expires @ 2009-10-23 14:56:03 -->
So the actual HTML source in the web browser will tell you that you are viewing a cached version of the page rather than a dynamically generated version of the page. It also tells you when this cached page version will expire—based on our configuration, basically one hour after it’s been loaded depending on our Boost module settings.
Everything appears to be working fine with our initial Boost installation and configuration. Sit back and behold the power of Boost!
Boost and Poormanscron
Checking our Status report will show us that we’re running an incorrect version of Poormanscron. Boost is optimized to work with the latest dev or 2.0 branch of Poormanscron. So let’s go ahead and install the latest version so that our cron runs will work correctly with Boost.
Visit the Poormanscron project page and download the 6.x.-2.0-beta1 release and extract and upload it to our /sites/all/modules directory. Then run your Status report again to check to make sure the Boost warning has disappeared. You may need to run your update.php script, as this module update will make changes to your database schema. Run update.php and then refresh your Status report.
In your Status report, you should now see the Boost row state: Boost Installed correctly, should be working if properly configured.
Configuring Poormanscron
The updated 2.x-beta1 version of Poormanscron is the precursor module to the eventual Drupal 7 core cron functionality. In Drupal 7, the functionality of the Poormanscron module will be part of the default core processes. For this reason the beta1 version does not give you a module configuration page. It will just run cron automatically, based on a setting on your Site information page. Go here to see that setting: Site configuration | Site information. Now you have an automatically run cron setting that you can select from. We’ll use the default 1 hour cron run. This is a nice preview of some of the new built-in functionality of Drupal 7 core.
