Cache-busting versioning strings

Skinning and designing Serendipity (CSS, HTML, Smarty)
Post Reply
yellowled
Regular
Posts: 7111
Joined: Fri Jan 13, 2006 11:46 am
Location: Eutin, Germany
Contact:

Cache-busting versioning strings

Post by yellowled »

For our $head_link_stylesheet we now use a cache-busting versioning string, which is ?v= plus a variable $serendipity['last_template_change'];

I was wondering if I could use said variable in smarty template (index.tpl, to be exact) as well? Can I assign it to a smarty variable in config.inc.php, and if so, how do I do that?

YL
Don Chambers
Regular
Posts: 3652
Joined: Mon Feb 13, 2006 2:40 am
Location: Chicago, IL, USA
Contact:

Re: Cache-busting versioning strings

Post by Don Chambers »

I think this will work....

config.inc.php:

Code: Select all

$serendipity['smarty']->assign('last_template_change', $serendipity['last_template_change']);
index.tpl:

Code: Select all

{$last_template_change}
=Don=
yellowled
Regular
Posts: 7111
Joined: Fri Jan 13, 2006 11:46 am
Location: Eutin, Germany
Contact:

Re: Cache-busting versioning strings

Post by yellowled »

Yes, it does. Thanks!

YL
Don Chambers
Regular
Posts: 3652
Joined: Mon Feb 13, 2006 2:40 am
Location: Chicago, IL, USA
Contact:

Re: Cache-busting versioning strings

Post by Don Chambers »

So how are you planning to use it?
=Don=
yellowled
Regular
Posts: 7111
Joined: Fri Jan 13, 2006 11:46 am
Location: Eutin, Germany
Contact:

Re: Cache-busting versioning strings

Post by yellowled »

Don Chambers wrote:So how are you planning to use it?
Erm, for cache-busting? :mrgreen:

Most themes these days come with theme-specific JS. I usually have a master.js for that. That file will be cached, so if you change it (especially if your server is configured to use the so-called far-future Expires headers), the visitor might still have the old version in the browser cache.

Code: Select all

<script src="{serendipity_getFile file="scripts/master.js"}?v={$last_template_change}"></script>
solves that issue.

YL
Don Chambers
Regular
Posts: 3652
Joined: Mon Feb 13, 2006 2:40 am
Location: Chicago, IL, USA
Contact:

Re: Cache-busting versioning strings

Post by Don Chambers »

Smart @$$!!! :mrgreen: :mrgreen:

Great idea. Probably good to add to preview_iframe.tpl as well.
=Don=
onli
Regular
Posts: 2822
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: Cache-busting versioning strings

Post by onli »

Have a good look whether that works properly. I think I saw in some installation (mine?) that this variable is empty. It could be caused by an outdated theme (did we rename the variable at some point?) of course.
garvinhicking
Core Developer
Posts: 30022
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Re: Cache-busting versioning strings

Post by garvinhicking »

This will indeed probably not work.

When people install an updated theme or a new s9y version, this string will not change.

It is supposed to work when themes are changed, so that the themes old CSS is not loaded (because the CSS path stays the same), not when files are changed...
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
yellowled
Regular
Posts: 7111
Joined: Fri Jan 13, 2006 11:46 am
Location: Eutin, Germany
Contact:

Re: Cache-busting versioning strings

Post by yellowled »

garvinhicking wrote:It is supposed to work when themes are changed, so that the themes old CSS is not loaded (because the CSS path stays the same), not when files are changed...
Huh. I guess I always assumed it was based on a template file changing (last modified or something) because that is what it is usually used for.

I tried using filemtime() instead, but that does not work at all; the variable is just empty, it seems. So for the time being I've resorted to setting a version number of the theme in the config.inc.php manually.

Code: Select all

$serendipity['smarty']->assign('last_template_change', '1.0.0');
That is not ideal, but it does what I intended. (Unless I forget to update it, of course.)

YL
Don Chambers
Regular
Posts: 3652
Joined: Mon Feb 13, 2006 2:40 am
Location: Chicago, IL, USA
Contact:

Re: Cache-busting versioning strings

Post by Don Chambers »

Hmmm.. that does seem interesting... but then you have serendipity.css and serendipity.js with a version equal to template change, but your theme's master.js version equal to a theme specific version?? Does that work ok?
=Don=
yellowled
Regular
Posts: 7111
Joined: Fri Jan 13, 2006 11:46 am
Location: Eutin, Germany
Contact:

Re: Cache-busting versioning strings

Post by yellowled »

Don Chambers wrote:but then you have serendipity.css and serendipity.js with a version equal to template change, but your theme's master.js version equal to a theme specific version?? Does that work ok?
Well, it applies a different kind of cache busting to the different files. That is not a problem per se, although it's not ideal. But it's not necessarily a problem that the serendipity.css and my master.js have a different versioning string at the end.

The point of this number after the ?v= is to indicate to browsers that “this is a new version of said file, you may not use the one already in the cache”. s9y is using this to prevent issues when switching themes (which makes sense given the fact that certain files will have the same filename in all themes).

This can also be useful if a site is still in development in the sense that these (cacheable) files still change (rather often, even). You don't have to tell anyone to clear their cache or to use a hard reload, you just assign a random number to any new build of these assets. (I especially like this because I don't have to tell clients to clear their browser cache because “it's still the same for me”).

But it's not that big of a deal for me that I would spend more time on this.

YL
Post Reply