When you make an update to a CSS or JS file, some repeat visitors will not see your changes due to client side caching, even when the aggregation cache is flushed. If there is HTML markup changes that depend on the updated CSS and Javascript, then the visitor could end up getting a completely broken page.

I'm constantly having to remind, clients, even coworkers to refresh when they tell me a page is broken after an update, and voila, its fixed. Well, for visitors, they don't get tech support, they just get a broken page.

This patch solves the problem by appending a timestamp query string to the source url of each CSS and JS file. This timestamp is stored in a system variable and reset whenever the CSS or JS cache is flushed. In the case of aggregation, the timestamp is appended to the serialized $types variable just before it is md5'd. Instead of appending a query string to the aggregated file, you simply get a different md5 value, resulting in a new file.

By running update.php, both CSS and JS caches are flushed, and the stored timestamp for both deleted, and the browser is sent all new CSS and JS files to load, regardless of aggregation. This does NOT affect JS files with their $cache argument set to FALSE, which will still get a new timestamp on every page load.

Suggestions and thoughts appreciated.

Scott

CommentFileSizeAuthor
preprocess-timestamp.patch4.1 KBsnelson

Comments

catch’s picture

Status: Needs work » Closed (duplicate)

This just got fixed in a seprate issue for update.php and cache-clear-all. http://drupal.org/node/199946