In the April 24th release of Boost 6.x-1.x-dev, Boost saves its cached files directly in /cache, rather than in cache/%{HTTP_HOST}, as it is configured in .htaccess. This is fine for my site, since I only have one domain, and I can rewrite the .htaccess rules accordingly, but this is probably not the intended behavior of the module.

Comments

mikeytown2’s picture

If it saves it directly in the /cache dir then the static file will not be served unless you rewrite the rules. For clearing the cache it also might be problematic. Did you set the Cache file path: on the performance page?

If those are set correctly, can you run this in a php block and tell me what it gives you?

echo variable_get('boost_file_path', boost_cache_directory(NULL, FALSE));
mikeytown2’s picture

Issue tags: +settings

I should probably add a logic check to the boost.install file so it will throw an error on the status page if the boost_file_path variable isn't set correctly. I could have it throw other errors as well...

EvanDonovan’s picture

It says that the path is "cache".

I didn't set the path as "cache/www.mysite.org" in the admin settings, because I assumed that the site name would be appended automatically. I guess that was the wrong assumption. Anyway, I rewrote the .htaccess rules so they work in my case. As for the cron, I'm running a cronjob every 6 hours that simply does an rm -rf *.* because it is faster than PHP and doesn't cause as much load.

A logic check on whether the path name was correct for the .htaccess rules would be great, as long as that isn't too difficult.

Thanks for taking the lead on this module's maintenance!

mikeytown2’s picture

It's supposed to default to "cache/www.example.com" if i remember correctly; www.example.com being your site.

function boost_cache_directory($host = NULL, $absolute = TRUE) {
  global $base_url;
  $parts = parse_url($base_url);
  $host = !empty($host) ? $host : $parts['host'];

  // FIXME: correctly handle Drupal subdirectory installations.
  return implode('/', !$absolute ? array('cache', $host) : array(getcwd(), 'cache', $host));
}

NULL is seen as empty by php, so it should grab your host name from the $base_url variable.
http://www.php.net/empty
Did you follow step #7 in the install file? This won't matter since your clearing the cache dir with your own cron job.
http://drupal.org/node/367081#comment-1504894

Would you mind running this php code block for me?

echo boost_cache_directory();

Did you install & enable boost via cvs/command line?

EvanDonovan’s picture

boost_cache_directory() returns /home/techmi5/public_html/gospelpedia/cache/www.gospelpedia.net. However, Boost saves the files directly in the cache directory.

$base_url is set in settings.php to http://www.gospelpedia.net.

I enabled Boost in admin/build/modules.

mikeytown2’s picture

I can't seem to find the reason why boost's boost_file_path variable got set to cache in your case. The code that initializes that is

define('BOOST_FILE_PATH',            variable_get('boost_file_path', boost_cache_directory(NULL, FALSE)));

http://api.drupal.org/api/function/variable_get
which then gets saved when you do a submit on the performance page because of this code

  $form['boost_file_path'] = array(
    '#type'          => 'textfield',
    '#title'         => t('Cache file path'),
    '#default_value' => BOOST_FILE_PATH,
    '#size'          => 60,
    '#maxlength'     => 255,
    '#required'      => TRUE,
    '#description'   => t('A file system path where the static cache files will be stored. This directory has to exist and be writable by Drupal. The default setting is to store the files in a directory named %default-path under the Drupal installation directory. If you change this, you must also change the URL rewrite rules in your web server configuration (.htaccess for Apache, lighttpd.conf for Lighttpd), or caching will not work.', array('%default-path' => boost_cache_directory(NULL, FALSE))),
    '#weight'        => -5,
  );

I can't give you a good answer as to why this happened to you. My only guess has to do with the $base_url, but that would only occur if this module was enabled via the command line.

EvanDonovan’s picture

Oh, I think I know now why this happened.

The first time that I submitted the form the cache directory did not exist. (I was thinking I had it symlinked to the cache directory on my live site, which is still on D5.)

So then I created the cache directory, but I forgot to chown it to nobody.

I got an error message for that, and so I chown'd it. Then the module was working fine, except, like I said, it was saving to cache directly.

Some other modules (like XML Sitemap and Deadwood, I think) create directories they need automatically. Maybe that would be helpful here also?

EvanDonovan’s picture

When I ran variable_set('boost_file_path', boost_cache_directory(NULL, FALSE)); it set it to the proper value of cache/www.gospelpedia.net. So I think my explanation above must be correct. (Something to do with how the form is validated, I imagine.)

mikeytown2’s picture

StatusFileSize
new353 bytes

I think the easiest way to prevent this error in the future is to set that variable in the install file. Thus when the module is first installed, it gets set to boost_cache_directory(NULL, FALSE).

mikeytown2’s picture

I need to throw an error in the status if it's set to cache/.

EvanDonovan’s picture

Ok, great. Thanks.

mikeytown2’s picture

Status: Active » Needs review
StatusFileSize
new1.57 KB

patch to check the cache dir

mikeytown2’s picture

Title: Boost saves files directly in cache directory, not in cache/%{HTTP_HOST} (in Apr. 24 dev) » cache directory not set to default on initial install - throw notice on status page if this happens
mikeytown2’s picture

Status: Needs review » Fixed

committed

mikeytown2’s picture

Status: Fixed » Needs review
StatusFileSize
new649 bytes

After clearing cache, if cache is empty upon viewing status page, boost will complain. This fixes that.

mikeytown2’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)
Issue tags: -settings

Automatically closed -- issue fixed for 2 weeks with no activity.