Boost advanced settings

Let's start looking at our advanced Boost configuration. The first item we want to note is that we can tell Boost to clear expired pages on cron runs. This will clear all expired cached pages when our cron runs. If you disable this, you will need to clear your Boost cache manually through the Boost: Pages cache status block (we looked at this block configuration in Chapter 5).

The next setting is even more flexible. Boost will only clear and flush expired content if it sees that there's been a change in the database timestamps, that is, if there's new database content. This is a setting you'll want to enable if you do not want to rely on the cron run to clear your site cache and if you have content being posted to your site frequently that you want your anonymous users to view without problems. Here we will take advantage of the Boost timestamp function, and use it to rebuild and flush cache only on pages that have been updated in the database. This PHP-based functionality will refresh the cache on that one specific Drupal node and not have to flush or rebuild the entire site cache. This enables you to target your Drupal nodes and database much more granularly rather than having to flush the entire Boost cache.

Let's go ahead and do this. We'll first check the box next to the Check database timestamps for any site changes.

Next, we're going to install the Rules module so that we can set up a rule that will run cron on our site every time a node is updated and saved. The Rules module allows you to define conditional PHP statements throughout your Drupal site and on specific Drupal events. The Rules module is on ( project/rules). Download the latest version of Rules, which is 6.x-1.1. Extract and upload the module to your /sites/all/modules directory.

Once uploaded to your site, go to your modules admin list and enable the Rules module and its constituent modules. Also, enable the PHP filter module if you have not already.

o Rules

Enabled Throttle Name Version Description

Lets you define conditionally executed actions based on occurring






Required by: Rules Administration UI (disabled). Rules Forms support (disabled). Rules Scheduler (disabled). Rules Simpletest (disabled)

Administration UI



Provides the administration UI for rules.

Depends on: Rules (disabled)


Rules Forms support



Provides events, conditions and actions for rule-based form customization.

Depends on: Rules (disabled)


Rules Scheduler



Schedule the execution of rule sets,

Depends on: Rules (disabled)




Tests the functionality of the rule engine

Depends on: Simpletest (missing). Rules (disabled)

Save your module configuration. Then visit the Rules configuration page by going to Rules | Triggered Rules | Add a new rule.

We're going to add a new rule and event by doing the following:

1. In the Label field, type in the following: Run cron when node is saved.

2. In the Event drop-down menu, choose the following event under the Node category: Content is going to be saved.

3. Check the box next to the statement: This rule is active and should be evaluated when the associated event occurs.

4. Click on Save changes.

Once you click on Save changes, you'll be presented with a screen that allows you to edit the Database Timestamp Boost rule you just configured. Here do the following:

Editing rule Database Timestamp Boost

The rule Database Timestamp Boost has been added. You can start D Rule settings (key=settingsJ weight=0) SJ Rule elements (key=elements, weight=0)

ON event Content is going to be saved

Add a condition

^S1 Add an action

• From the Select an action to add drop-down menu, select the Execute custom PHP code statement and then click on Next.

Select an action to add (key=name, weight=0):

Clear a page from the boost cache.

Publish content

Remove content from front page Save a content Set content title Set the content author Unpublish content

Unpublish content containing ke>word(s) PHP

Execute custom PHP code


Create or delete a content's URL alias Create or delete an URL alias Rule Scheduler

Delete scheduled rule sets

Schedule Example: Empty rule set working with content Rule Sets

Example: Empty rule set working with content Rules

Add a new date variable Add a new number variable weight=0)

.Id time: 23.6691188812 ms

• On the next screen, in the PHP Code box, copy and paste the following code. Remember here that you do not need to include the opening and closing PHP brackets <?php and ?>. global $base_root, $base_path;

drupal_http_request($base_root . $base_path . 'cron.php');

PHP Code:

global $base_root, $base_path;

drupal http request($base root . $base path . 'cron.php');


The code that should be executed. Don't include <?php ?> delimiters.


Adjust the weight to customize the ordering of actions.

The code that should be executed. Don't include <?php ?> delimiters.


Adjust the weight to customize the ordering of actions.

[ _" This code is provided from the Boost advanced settings help and I

support documentation page on (http://drupal. I org/node/583264) I

• Click on Save. You will receive a confirmation that The action Execute custom PHP code has been saved.

• Return to your Boost advanced settings and check the box next to Check database timestamps for any site changes. Only if there's been a change will Boost flush the expired content on cron.

• Save your Boost settings configuration.

0 Check database timestamps for any site changes. Only if theres been a change will boost flush the expired content on cron

As soon as you do this, Boost will now refresh the cache on any one page on your site that has been changed in the database.

Testing your Database timestamp settings

Let's go ahead and test the functionality we just implemented. You'll see immediately how this works in the new caching mechanism we've configured. First, logout of your site and then browse to a page and load it as an anonymous user. Check your /cache/normal/ folder to make sure the HTML version of the cached page is showing up. I'm visiting node/2 0 7 on my site and I notice immediately that once I load node/2 0 7, the HTML version shows up in my cache folder.

If you are having trouble seeing this happen through FTP or SFTP, refresh your remote window in your FTP client.

Now log back into your site and visit the same node as your admin authenticated user. Edit the node and add some content to it, or tweak some content so that the change will be noticeable to your anonymous users. I'm editing node/207 and I'm adding some new textual content to my title field for that node. Save your node.

Now, immediately go into your FTP client and refresh your remote view. You should see the HTML version of the node disappear. The script you are running through the Rules module and Boost is working. You made a database level change to this node and now the node cache has been flushed. The HTML version is gone and you're ready to serve out the latest version of this node to your anonymous users. To finish the test, logout of your site and load the same node, as an anonymous user. Now, immediately go into your FTP client and refresh. You should now see the cached version of the node again and you should also see the edited content on your node as an anonymous user. It's working!

You'll also notice that all of your other cached HTML page versions are unchanged and unaffected by this rule's actions. The PHP script you are running only targeted this one node that had changed content. Bear in mind that running cron using the rule you have created will cause the cron to run every time a node is saved. This may cause cron to run more frequently than you have it set to run via your Poormanscron module or a cron configuration you have configured on the server. If this is the case, then your cron could take more time to run because it will be flushing other module actions, for example, if your modules rely on cron for specific module functionality. Just keep this in mind as you work with this rule.

Let's look at some more Boost advanced settings. The next checkbox on the Boost settings page asks you if you want to force the site to only allow ASCII characters in a URL path. I would suggest leaving this checked if you're not using any content translation or i18n functionality on your Drupal site.

The next setting pertains to multisite environment and development. If you're running a multisite, you can select to Flush all sites caches in this database. This will only work if you're running a multisite environment from one Drupal database. So, if you want to flush all the sites' caches, you can enable this here. We're not running multisite currently, so I'm going to leave this unchecked.

Asynchronous Operation: output HTML, close connection, then store static file helps to speed up your caching process even more. Here the caching will generate the cached HTML page without paying close attention to the PHP on the page. PHP will remain running in the background, but the cache page will only pay attention to HTML. This will also help to generate faster page loads.

The next setting allows you to not only clear cached files, but also the entire folder in your /cache directory. This gives you an added feature to help clean house, but you need to be careful if you have set specific writeable subdirectories. If you clear those subdirectories, you will need to rebuild them again through FTP or a file manager and set the correct permission because clearing them will wipe them from the server. So use this with caution.

0 Only allow ASCII characters in path (key=boost_only_ascii_path, weight=0)

Only allowing ACSII characters is a safe way to cache pages. It severely limits il8n support so this can be turned off. Fair warning, disabling this may cause "page not found" errors depending on your url structure (spaces are bad, ect...). If you follow RFC 3986 you should be ok.

□ Flush all sites caches in this database (singe db, multisite). (key=boost_flush_all_multisite, weight=0)

This will flush/expire all cached files stored in this database, instead of only being specific to this site. Useful for il8n sites. You need to setup a separate cron call for each database (in your multisite install) either way though. This cowers shared database usage.: or place the boost tables into the a shared database, to have this setting work in a multiple database environment.

0 Asynchronous Operation: output HTML, close connection, then store static file. (key=boost_asynchronous_output, weight=0)

Run php in the background. When a cached page is generated, this will allow for faster page generation; downside is the headers are not the standard ones outputted by drupal; sends "Connection: close" instead of "Connection: Keep-Alive",

O Clear all empty folders from cache, (key=boost_flush_dir, weight=0)

Disable this if you have to set settings for each dir/subdir, due to the way your server operates (permissions, etc...).

The next four settings refer to Boost's integration and behavior with the CCK, Views, and Taxonomy modules. You can tell Boost to Clear all cached pages referenced via CCK with a node on insert/update/delete. This will clear the cached pages for any node that references another node via a CCK node reference field. Both nodes will be cleared. There is a module that works well with this functionality called the Node Referrer module. If you plan to use this functionality, you should install and configure this module.

You can also have Boost Clear all cached terms pages associated with a node on insert/ update/delete, Clear all cached views pages associated with a node on insert/update/and delete. Note that if you do this specifically, the views page associated with a node on insert can be a slow process because all of your Views will process so that Boost can locate the node that is being cached. Use this functionality with caution.

0 Clear all cached pages referenced via CCK with a node on insert/update/delete (key=boost_flush_cck_references, weight=0)

The Node Referrer module ¡5 recommended,

0 Clear all cached terms pages associated with a node on insert/update/delete (key=boost_flush_node_terrns. weight=0)

Works with view's taxononriy/ternri/% path as well as core,

0 Clear all cached views pages associated with a node on update/delete (key=boost_flush_views, weight=0) 0 Clear all cached views pages associated with a node on insert (key=boost_flush_views_insert, weight=0)

WARMING: This can be very sloWj all views get run to find out where this node lives,

You can tell Boost to clear cache when you put your site offline for maintenance mode, overwrite the cached file if it already exists, and not to cache a page if there is a PHP error on the page. We'll go ahead and check this box. You can also check the box next to the Do not cache if a message is on the page.

You can choose to turn off clean URLs for logged in users. We want to use clean URLs for both of our user bases, so we'll leave this unchecked. This setting is recommended for sites that have mostly admin-based authenticated users who may not mind using non-clean URLs.

You can also choose to use Aggressive Gzip caching if you have your site configured to use Books for Gzip caching.

□ Clear Boosts cache when site goes offline (key=boost_clear_cache_offline, weight=0)

Under site maintenance when the status is set to offline, boost clears its cache. If you do not want this to happen, clear this checkbox. Pages that are not cached will still send out a Site off-line message, so be smart if turning this off.

□ Overwrite the cached file if it already exits (key=boost_overwrite_file, weight=0)

This is useful if crawling a site before it goes live.

0 Do not cache if php error on page (key=boost_halt_on_errors, weight=0)

Selected - Do not cache the page if there are PHP errors. Not Selected - Cache pages even if it might contain errors.

0 Do not cache if a message is on the page (key=boost_halt_on_messages, weight=0)

Selected - Do not cache the page if there are drupal messages. Not Selected - Cache pages even if it might contain a drupal message,

□ Turn off clean url's for logged in users (key=boost_disable_clean_url, weight=0)

Drupal will output non clean url's for non anonymous users. This allows for the browser to cache the page and still have logging in work. This is more on the extreme side of tweaks.

0 Aggressive Gzip: Deliver gzipped content independent of the request header. (key=boost_aggressive_gzip, weight=0)

In order to deliver gzipped content independent of the header, this will test for gzip compression in a small iframe by sending it compressed content. This compressed content is javascript which creates a cookie with a note of gzip support. On the server side it checks for the cookie and then sends out gzipped content accordingly. See Website Performance - Activate Gzip. In short some firewalls/proxies mangle the gzip header; this gets around that, iframe is on non compressed version of the frontpage

Files: Enter in a 4 digit number (octal) that will be used by chmod(). Example 0664 (key=boost_permissions_file, weight=0):

Sometimes because of funky servers you need it use a different file mode then the default.

Directories: Enter in a 4 digit number (octal) that will be used by chmod(). Example 0775 (key=boost_permissions_dir, weight=0):

Another one of the tweaks that Boost allows for is the Expire content in DB, do not flush file. This will expire the database entry for the file or node before actually flushing the cached version of the node. Again, this provides even greater flexibility in your Boost configuration.

Finally, you can tell Boost to Ignore cache flushing (recommended only if you are caching CSS and JS files) and whether you want to record all Boost errors to the Drupal watchdog recent log entries.

Ignore cache flushing (key=boost_ignore_flush, vjeight=0):

O Disabled

® Only Ignore Clear Entire Cache Commands (Recommended If caching css/js files) O Ignore Clear Entire Cache Commands a Cron Expiration O Ignore All Delete Commands (Not Recommended)

Make a selection to put your site into a static cached state. Recommend turning on CSS £: JS caching if enabled.

Watchdog Verbose Setting (key=boost_verbose, weight=0):

| 5 Record all errors to the db log (watchdog) v |

Boost crawler settings

Boost crawler allows you to cache your Drupal pages preemptively, allowing pages to be cached before anonymous users or any visitor on your site loads them. First, you need to check the box to enable the cron crawler. You must check this box and save your entire configuration before you are able to check the specific caching boxes in the Boost crawler section of the Boost settings. I encourage you to test this functionality on your site before putting it in a production environment. You may not need to use pre-caching, but again the module provides you with this flexible functionality. The handbook content recommends using this functionality on shared hosts and in conjunction with the database timestamp configuration we enabled earlier in this chapter. You may also have to update your .htaccess settings to use this type of configuration.

Boost crawler (key=crawler, weight=U)

0 Enable the cron crawler (key=boost_crawl_on_cron, welght=0)

Pre-cache boosted URL's so they get cached before anyone accesses them. Enable the crawler first and save settings to use

Preemptive Cache settings.

Do not flush expired content on cron run, Instead recrawl and overwrite It. (key=boost_loopback_bypass, welght=0)

The "Overwrite the cached file if it already exits" must be turned on in order to enable this.

0 Preemptive Cache HTML (key=boost_push_html, weight=0)

Crawl Site after cron runs, so the cache is primed.

0 Preemptive Cache XML (key=boost_push_xrnl, weight=0)

Crawl Site after cron runs, so the cache is primed.

0 Preemptive Cache AJAX/JSON (key=boost_push_lson, welght=0)

Crawl Site after cron runs, so the cache is primed.

□ Crawl All URL's in the url_alias table (key=boost_crawl_url_alias, weight=0)

Preemptively cache all urls found in the Drupal url_alias table. This will crawl that page even if it is not expired. Enable 8: run cron to get the boost cache loaded.

Crawler Throttle (key=boost_crawler_throttle, weight=0):

Wait y. micro seconds in between hitting each url. 1000000 is 1 second.

Crawler Batch Size (key=boost_crawler_batch_size, weight=0):

Number of URL's each thread grabs per database operation.

Number Of Threads (key=boost_crawler_threads, weight=0):


Be careful when choosing more then 2 threads.

| Reset Crawler & Cron Semaphore |

Estimated Time to crawl site - highly inaccurate (key=boost_crawler_eta, weight=0):

121 sec

Remember that if you do change the above settings in the Boost crawler section, you may need to regenerate your .htaccess rules and re-paste them into your .htaccess file, as you will now have updated and potentially changed the settings. So, save your entire Boost advanced settings and main settings configuration first. Then, having done this, run your site's Status report. This will tell you whether Boost is configured correctly or if you need to update your .htaccess.

For example, I enabled the Boost cron crawler. Once I did this and visited my Status report, I received this error message:

Q Boost Boost crawler did not get a 200 response.

401 returned, Crawler URL (http://variantcube.corm/fire/boost-crawier) is not available, please report this issue

If you do need to make updates, go back to your Boost configuration page and click on the Boost htaccess rules generation link and copy your latest Generated Rules. Then paste this into your .htaccess file to update it.

Since I'm receiving this error, I'm going to go back and regenerate my Boost htaccess rules and re-paste them into my .htaccess file. Once I do this and run my Status report again, I should receive the green box telling me that Boost is running correctly and can run the Boost crawler.

Was this article helpful?

0 0


    Why don't i see "custom php code" in my triggered rules for druplal?
    9 years ago
  • segan saare
    How to disable cache in drupal?
    9 years ago
  • Suvi Hartonen
    How to refresh a page in php after select a weight in drupal?
    9 years ago
  • Jaska
    Is there a way to have boost crawler update items that will expire?
    9 years ago

Post a comment