How to handle / cleanup obsolete aggregated css / js?

Question

I'm only using Drupal 7 built in CSS / JS aggregation, however the files folder where the css.gz and js.gz files live are filling up at a fairly rapid pace, and while I'm sure it'll be a while before it starts to totally fill up the drive, nows as good a time as any to get a handle on the situation.

• Current file count in /js is 335
• Current file count in /css is 451

Is there any standard method I should be employing to deal with this situation? I'd prefer a solution that keeps the drupal in the loop.

Additionally, I see that many of the gz files have non-gz counterparts. Is there some reason both .css and .css.gz files are kept? Degredation maybe?

Thanks

Answer 1

This is actually by design so that cached pages with older versions of files don't get broken. See this closed issue.

TL;DR: They will be deleted automatically 30 days (or whatever your drupal_stale_file_threshold variable is set to) after they were created via drupal_clear_css_cache() and drupal_clear_js_cache(). So the solution is to modify the drupal_stale_file_threshold value to something lower than the default 30 days.

• When are old files deleted

  Old cache files are not deleted immediately when the lookup variable is emptied, but are deleted after a set period by drupal_delete_file_if_stale(). This ensures that files referenced by a cached page will still be available.

drupal_delete_file_if_stale() defaults to 30 days - so if a) Cron is running properly and b) you see aggregated files older than 30 days, you have a different problem.

variable_get('drupal_stale_file_threshold', 2592000) is the 30 day check. variable_set('drupal_stale_file_threshold', 172800) would change the timeout to two days. On a site where cache handling is strictly controlled, the time could be even shorter.

Source: http://api.drupal.org/api/drupal/includes!common.inc/function/drupal_build_css_cache/7
See drupal_delete_file_if_stale() for more information.

• Is there some reason both .css and .css.gz files are kept?

  If CSS gzip compression is enabled, clean URLs are enabled (which means that rewrite rules are working) and the zlib extension is available then create a gzipped version of this file. This file is served conditionally to browsers that accept gzip using .htaccess rules.

Source: http://api.drupal.org/api/drupal/includes!common.inc/function/drupal_build_css_cache/7 (In the function comments)

Also see drupal_build_js_cache() which is nearly identical to drupal_build_css_cache().

Answer 2

After 4 years, I have to disagree with the first answer, where the author states :

"This ensures that files referenced by a cached page will still be available.".

Maybe certains things have been changed/optimized in the aggregation provisioning of older files, but if I delete an older file manually on the server at files/advagg_js (which I apparently still use in one of my browsers), the subsequent page reload is regenerating exactly the same file again with recently added javascript source code, as if drupal_build_js_cache() was executed on that aggregated file name.

eg. js__22qMV1d_G25luSFBkuR7bIuKD5FE80eKuXx6ldibEixg__yjA2JTeF2f1LUJ3PMdjMr8k9nOPZQJIcvVw-c5Gz_yc__FY0NTHFBVMd9MIGE5srDXTejEZGP-ccSH7UX2zImN-0.js

So I am concluding setting a significant lower drupal_stale_file_threshold would not cause any problems, and even deleting all aggregated files followed by a cache clear will force a regeneration of aggregates (tested and confirmed working on page reloads)

Answer 3

• Get the Rules module
• Add a new rule that will be executed when the cron is running
• As an action select execute php code.
• Write the php code

Might be something like this:

$dir = 'your/directory/';
  foreach(glob($dir.'*.*') as $v){
  unlink($v);
}

These php functions might help you to modify the code as you like.

• Glob http://php.net/manual/en/function.glob.php
• unlink http://uk.php.net/manual/en/function.unlink.php

Be very careful before executing this! If not used right you may delete your site! Before trying this code test it on a localhost