main.css?ts=<?= time() ?> Has me confused.

[Greg Lumley]

Hi! In busy learning to know PW better I'm looking at existing code.

I have Bitpoets Editorial Responsive Blog as example. While looking through the code I've just found this line in the blog-head.php 

<link rel="stylesheet" href="<?= $config->urls->templates ?>assets/css/main.css?ts=<?= time() ?>" />

I hope it's not a stupid question but I've never seen this before...

main.css?ts=<?= time() ?>

I notice the main template is empty but of course renders on the front end.

Using a timestamp really has me totally confused. Can someone explain it to me please. 

Thank you! 

Greg

[eydun]

The idea is that the link to the css-file will change every second, and the browser will be tricked into thinking this is a new stylesheet and loading it fresh every time (and not cached copy).

[Greg Lumley]

Aha! That makes total sense. Heck if I'd used my brain for a moment I probably could have realised that.

Thank you Eydun. 

G

[Greg Lumley]

Okay, I'm still stuck on this... if the main.css is empty, where does the styling stored? 

In other words if I wanted to modify any styling where would I do it? 

Thank you.

Greg. 

[elabx]

There's gotta be some CSS file loading (if the site has any actual styles), check your Network tab on chrome to check what's loaded, also if you inspect any element it should indicate the style's source. Otherwise, it might have been output right into the html body. 

[MoritzLost]

9 hours ago, Greg Lumley said:

In other words if I wanted to modify any styling where would I do it? 

I don't really know that site profile, but looking at the repository there's a SASS folder, you're probably supposed to compile the CSS from that. You can do that with sass or node-sass.

10 hours ago, eydun said:

The idea is that the link to the css-file will change every second, and the browser will be tricked into thinking this is a new stylesheet and loading it fresh every time (and not cached copy).

Just for the sake of completion: This is horrible for a live site. You usually want to have something like this during development so you don't have to do a full reload every time, but on a live site this will prevent all your visitors from ever caching your site's CSS. This will have a bad impact on page speed, so make sure to remove that on the live site!

[BitPoet]

15 minutes ago, MoritzLost said:

Just for the sake of completion: This is horrible for a live site. You usually want to have something like this during development so you don't have to do a full reload every time, but on a live site this will prevent all your visitors from ever caching your site's CSS. This will have a bad impact on page speed, so make sure to remove that on the live site!

That. The main.css under site/templates/assets/css is meant as a convenient place to add custom styling (no sass/less magic involved here). I had meant to change that time() call to an mtime() call as an example of how to bust the cache whenver the file is changed, but I apparently never got around to it. Brushing up my site templates is another point on my growing todo list.

The default styling is done in site/templates/assets/css/blog.css, but you won't see that filename in the developer console because the site template uses the AOIM module to combinde and minimize the js and css files.

[LostKobrakai]

1 hour ago, MoritzLost said:

You usually want to have something like this during development so you don't have to do a full reload every time

Nowadays open dev tools and disable the cache in there. No need for hacky cache busting on each request.

[eydun]

Sometimes you have to burst the css-cache, to ensure that visitors that have visited your site earlier, will get an updated version of the css-file.

[LostKobrakai]

Sure, but this is imo best done by appending e.g. the md5 hash of the file contents for cache busting. This one will actually only change if the css file itself changed.

[Greg Lumley]

1 hour ago, LostKobrakai said:

Sure, but this is imo best done by appending e.g. the md5 hash of the file contents for cache busting. This one will actually only change if the css file itself changed.

That makes a lot of sense. 

[Greg Lumley]

5 hours ago, BitPoet said:

That. The main.css under site/templates/assets/css is meant as a convenient place to add custom styling (no sass/less magic involved here). I had meant to change that time() call to an mtime() call as an example of how to bust the cache whenver the file is changed, but I apparently never got around to it. Brushing up my site templates is another point on my growing todo list.

The default styling is done in site/templates/assets/css/blog.css, but you won't see that filename in the developer console because the site template uses the AOIM module to combinde and minimize the js and css files.

Thank you BitPoet!

I hadn't thought of that. ?

[MoritzLost]

1 hour ago, LostKobrakai said:

Sure, but this is imo best done by appending e.g. the md5 hash of the file contents for cache busting. This one will actually only change if the css file itself changed.

As an alternative to this approach, my new Cache Control module also includes an optional feature for browser cache busting. You retrieve a version string (by default, a timestamp) through the module that is stored inside the cache. As soon as you clear the cache through the module, this version string gets cleared as well, and a new version string is generated during the next request. This ensures that any assets cached by the browser are cleared alongside all server-side caches. Just throwing it out there ?

[bernhard]

2 hours ago, LostKobrakai said:

Sure, but this is imo best done by appending e.g. the md5 hash of the file contents for cache busting. This one will actually only change if the css file itself changed.

Doesn't that need to generate the md5 hash of the file on every request (if not cached)? I guess filemtime() is a lot faster than md5_file()?

[LostKobrakai]

At best you do that as a compile step. I hardly deploy any content anymore, where I don't have a js/css buildstep or even CI. Those are great places to do such things once per "change" of the running code.