boost_cache_directory() intentionally includes the host portion of $base_url in the cache page (./cache/host/0) to support multisite operation. That's fine but it has an unintended consequence. Consider a site that is accessible via example.com and www.example.com. Files will be cached under both hostnames. cron is going to be run under one of the hostnames, so boost_cache_expire_all() will only expire files under that hostname; files under the other hostname will never be expired.

Actually, it's worse than that. On a client site we run cron via drupal.sh:

/home/httpd/httpdocs/scripts/drupal.sh http://default/cron.php

In this case, $base_url has the hostname "default" so in fact no files are ever wiped from the cache.

One solution is to run cron multiple times, once with $base_url referencing each possible hostname, but that is pretty ugly. I'm leaning towards adding a new Boost admin setting, "Cache hostnames to expire" or somesuch, which lets the admin list the directories under ./cache to be expired. boost_cache_clear_all() and boost_cache_expire_all() would then iterate through that list.

Comments?

Comments

moshe weitzman’s picture

moshe weitzman commented

Well, google has said loudly that it really doesn't want folks to run same site on multiple domains like www.example.com and www.example.com. you should really be doing a 301 redirect in .htaccess for this. there is commented out code in our .htaccess for this.

Given that, I think it is fair to require that each site in a multisite has its own cron. I'm not firm in that opinion, but it is my gut.

This is still a gotcha, and should be documented.

bjaspan’s picture

bjaspan commented

Fair point.

bjaspan’s picture

bjaspan commented
Status: Active » Closed (works as designed)