2

What triggers the aggregated/compressed CSS/JS file names to be regenerated?

Because of the default header for .css and .js set in Drupal's stock .htaccess is 2 weeks, this causes issues with Varnish which obviously just obeys the headers it receives from the application.

Caching .css/.js for 2 weeks isn't really necessary, our web servers can serve hundreds of requests for static files per second. It's the Drupal requests that always worry me. So I can change the .htaccess (though I actually override the Cache-control: max-age header in Varnish so we don't have to modify stock files provided by Drupal).

I have noticed that regeneration can sometimes can be triggered with a drush cc css-js but possibly only if the aggregated files are over a certain age.
Does anyone know what the logic is behind this?

Rather than overriding the header sent by Drupal, it would be useful to know when the file names are regenerated, because that's obviously a way of making sure that HTML code cached in Varnish is picking up a new set of CSS/JS files.

Improve this question

2 Answers 2

Reset to default
4

You're looking for drupal_build_css_cache & drupal_build_js_cache. The building happens when the file doesn't exist or when the combination of files used in the aggregate is different than before.

Looking at drupal_clear_css_cache & drupal_clear_js_cache the variable gets removed & any file older than 30 days gets deleted. By removing the variable, drupal will then check to see if the contents of the file has changed, if yes a new aggregate will be built. So the file name is built by using a hash of the files content and the quick lookup is built by a hash of the file names used.

If you want something that's a little smarter than core, doesn't cause a stamped of writes to the variables table on a cache clear, and keeps files around based upon usage instead of a 30 day window give Advanced CSS/JS Aggregation a try.

Improve this answer
1
  • Great info. According to the docs the CSS/JS names are hashes of the aggregated content, makes sense. So in that case the name should change whenever the content changes, so it doesn't matter if Varnish is caching the old ones for 2 weeks (due to the upstream headers set by Drupal's .htaccess). Just need to make sure the cached HTML in varnish is replaced with new HTML that references the new CSS/JS file names, which isn't too much of a worry with a 5min TTL on our busier sites. So long as I don't ever have to do a drush cc all to update CSS/JS then that's fine!
    – batfastad
    Apr 2, 2015 at 9:46
0

Completing mikeytown2 answer, this worked to clear up the aggregated names and forced a regeneration in my case:

drush vdel drupal_css_cache_files
drush vdel drupal_js_cache_files
drush vdel javascript_parsed
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.