[Pro] CSS versioning to prevent caching problems

Freeway
1

I’ve long experienced serious browser caching problems with CSS files generated by Freeway. The scenario goes like this. I make a change in Freeway, then upload, then check in Safari (reading files off my web server, not Freeway preview), and I find the the pages are messed up. So I click reload in Safari (tiny round circular icon to the right of the address bar), but sometimes that doesn’t load the new CSS file and just shows the cached version. So I then press the Option key and then click reload in Safari again, and then Safari will usually display the new CSS file from off my web server and the page displays perfectly.

The problem is that I know how to press Option and click reload to make the page look right. And when that doesn’t even work, I know to relaunch Safari to make it work. But the rest of the planet does not know those tricks, nor do they want to fuss with them. So until my newly upload CSS file gets cached by the browser, everyone who frequents my websites will see the page as broken or strange. I am sick and tired of this, hence my post here today.

What I’ve tried to do to remedy the problem is modify my .htaccess file with the following cache control code:

# Assign 3-month Browser Cache storage for these static assets:
<FilesMatch ".(ico|pdf|zip)$">
Header set Cache-Control "max-age=7257600, public"
</FilesMatch>

# Assign 2-week Browser Cache storage for these static assets:
<FilesMatch ".(jpg|jpeg|png|gif|js)$">
Header set Cache-Control "max-age=1209600, public"
</FilesMatch>

# Assign 18-hour Browser Cache storage for CSS:
<FilesMatch ".(css)$">
Header set Cache-Control "max-age=64800, public"
</FilesMatch>

And as you can see, the shortest cache duration is assigned to CSS. But even 18 hours isn’t short enough. I’ve tried to prevent caching too, but that isn’t a perfect solution.

What I really need Freeway to do for me is generate “versioned” CSS code like this:

<link rel="stylesheet" type="text/css" href="styles.css?version=26">

Alternatively, Freeway could just change the name of the CSS file every time, as that would solve the problem too.

Has anyone created an Action that accomplishes this automatically?

Thanks,

James Wages

freewaytalk mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

2

In my experience, this is only a problem for people who visit often – the developer and her client, for example. Both can be trained. However, that said, it should not be difficult to add a timestamp “querystring” to all the CSS file URLs. I’ll see if I can put something together later. I’m not sure if an Action could do this (although that would be the most useful way) because the link URL is generated by Freeway when it uploads the file, and it doesn’t present as a separate attribute that you are free to tinker with.

I’m imagining something like this could work as a patch, but I wouldn’t leave it in place all the time, since it will cause every request for a stylesheet to side-step the cache, and that cache is there for a useful purpose.

var today = new Date();
$$('link[rel="stylesheet"]').map(function(elm){
    elm.writeAttribute('href', 
      elm.readAttribute('href') + '?t=' + today.getTime() / 1000);
});

Walter

On Dec 10, 2017, at 8:22 PM, JDW email@hidden wrote:

I’ve long experienced serious browser caching problems with CSS files generated by Freeway. The scenario goes like this. I make a change in Freeway, then upload, then check in Safari (reading files off my web server, not Freeway preview), and I find the the pages are messed up. So I click reload in Safari (tiny round circular icon to the right of the address bar), but sometimes that doesn’t load the new CSS file and just shows the cached version. So I then press the Option key and then click reload in Safari again, and then Safari will usually display the new CSS file from off my web server and the page displays perfectly.

The problem is that I know how to press Option and click reload to make the page look right. And when that doesn’t even work, I know to relaunch Safari to make it work. But the rest of the planet does not know those tricks, nor do they want to fuss with them. So until my newly upload CSS file gets cached by the browser, everyone who frequents my websites will see the page as broken or strange. I am sick and tired of this, hence my post here today.

What I’ve tried to do to remedy the problem is modify my .htaccess file with the following cache control code:

# Assign 3-month Browser Cache storage for these static assets:
> <FilesMatch ".(ico|pdf|zip)$">
> Header set Cache-Control "max-age=7257600, public"
> </FilesMatch>
> 
> # Assign 2-week Browser Cache storage for these static assets:
> <FilesMatch ".(jpg|jpeg|png|gif|js)$">
> Header set Cache-Control "max-age=1209600, public"
> </FilesMatch>
> 
> # Assign 18-hour Browser Cache storage for CSS:
> <FilesMatch ".(css)$">
> Header set Cache-Control "max-age=64800, public"
> </FilesMatch>

And as you can see, the shortest cache duration is assigned to CSS. But even 18 hours isn’t short enough. I’ve tried to prevent caching too, but that isn’t a perfect solution.

What I really need Freeway to do for me is generate “versioned” CSS code like this:

<link rel="stylesheet" type="text/css" href="styles.css?version=26">

Alternatively, Freeway could just change the name of the CSS file every time, as that would solve the problem too.

Has anyone created an Action that accomplishes this automatically?

Thanks,

James Wages

freewaytalk mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

freewaytalk mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

3

Has anyone created an Action that accomplishes this automatically?

Thanks,

James Wages

Yes.

You now what? This was going trough my mind a few weeks back, and given that other HTML creation apps do this, I wrote one quickly that just adds a ?v=x (where x is a number) at the end of any CSS that’s included on the page. It does the same for any tag too (just in case). There’s a button in the Action Palette that increments the number when you feel it needs to be done, so it’s not entirely automatic. It also only knows about CSS and JavaScript that’s been included using the tag stream.

I’ve just not had the time to post this on my Actions site yet.

freewaytalk mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

4

Paul and Walter, thank you for your replies.

Paul, I was thinking that an action could do versioning automatically. For example, it would have the ability to automatically add a version number to every single CSS file the Freeway generates. It would start with number 1 and then go up to 10 and after 10 it would start versioning at 1 again, and in that way it could be completely automatic.

James Wages

freewaytalk mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

5

Walter and Paul,

Here is a screencast with voiceover that I just made which shows the severity of the problem and how ScriptyLightBox3 plays a role in it:

It’s not only CSS pertaining to ScriptyLightBox, but ScriptyLightBox is the only problem that is not remedied by holding down Option and clicking RELOAD in Safari.

After watching, any additional thoughts or suggestions you may have would be appreciated.

Thanks,

James W.

freewaytalk mailing list
email@hidden
Update your subscriptions at:

6

How will Freeway know to do this? It would have to somehow need to work it out based on some assumptions, and I know how much you hate Actions causing sites republishing needlessly. Adding a bit of manual control does allow you to determine if such a thing is necessary. At times, I’ve seen Freeway not seeming to dirty anything or republish when I’ve changed a style. This can be used to force a republish as well as upping the counter.

It also handles JavaScript - but I’m not aware of any external JavaScript Actions beyond the ones I have myself.

Word of caution - this only handles scripts and CSS that have been added to the tag stream. If you have used markup in some form, or an Action that dumps in raw text instead of a tag, then this Action won‘t process that.

Anyway, here’s what I have (and have been using myself for the last few weeks).

http://www.actionsworld.com/Actions/CSSVersion

Hope it’s helpful.

On 11 Dec 2017, 9:28 pm, JDW wrote:

Paul and Walter, thank you for your replies.

Paul, I was thinking that an action could do versioning automatically. For example, it would have the ability to automatically add a version number to every single CSS file the Freeway generates. It would start with number 1 and then go up to 10 and after 10 it would start versioning at 1 again, and in that way it could be completely automatic.

James Wages

freewaytalk mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

7

James, the Externalise Action (http://www.actionsforge.com/actions/externalize) may be of use to you.

It appends an automatically generated query string onto the end of the CSS and JS references. This string is a MD5 hash of the file contents itself so if the file changes (you’ve added, edited or removed styles for example) then the hash will change. This should be enough to make the whole process completely transparent.

freewaytalk mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

8

Tim and Walter,

I am currently using Walter’s Stylesheets Action, version 2.3 (as per bottom right corner of Actions palette), named “ExternalStyleSheets.fwaction”. I also have “External stylesheets” ENABLED in Document Setup > Output.

QUESTION#1
To use Tim’s “Externalise” Action, I know that I must DISABLE “External stylesheets” in Document Setup. But is “Externalise” compatible with Walter’s “ExternalStyleSheets.fwaction”?

“Step 4” in the Externalise Action allows me to specify only CSS on my local hard drive, but it doesn’t allow me to specify a link to existing CSS files on my web server. In contrast, Walter’s “ExternalStyleSheets.fwaction” DOES let me specify “links” to CSS files on my server, which is why I use it. Those linked CSS files are cached and almost never change and I like them that way. They do not pose the problem I mentioned earlier in this thread.

So is “Externalise” compatible with “ExternalStyleSheets.fwaction”?

Next…

QUESTION#2
I have read the “Externalize.pdf” instructions, but Steps 2 & 4 still confuse me. Step-2 seems to say that I should use Externalise, Publish, then find all the generated CSS files (generated by the Externalise Action), and then combine them into a single file (if I wish). But Step-4 seems to say I can add other CSS files, which I assume means I should add my hand-crafted “consolidated” CSS file here? If so, what of the other CSS files that the Externalise Action generated? I’m confused what happens here.

Lastly…

QUESTION#3
It seems that the only way to use Externalise is to apply the Action individually to every single page in the site, and then laboriously change Action’s palette settings on every single page. On a huge site, this is a huge amount of work. Is this really what we must do?

Thank you in advice for your time in answering the above questions.

Sincerely,

James Wages

freewaytalk mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

9

Paul Dunning,

Wow!

I just tried your action here:

http://www.actionsworld.com/Actions/CSSVersion/

I merely applied to the Site Folder (in left side panel), Published and uploaded, then I checked pages in Safari. Without having to restart Safari, the problem is SOLVED!

Yes, it dirties all the pages in my site, but actually the wicked-but-useful Site Mapper action already does that due to a bug, so your action is not introducing anything new. It properly versions CSS generated by Walter’s ScriptyLightBox3 Action, which is the main problem I discuss in my YouTube video posted above.

I see your Action starts off versioning CSS at 1. Does it reach a certain number and then loop back to 1 again?

I will continue testing over the next week to see that it continues doing it’s job, but so far so good. Super easy to use and effective!

Thank you,

James

freewaytalk mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

10

Hi James,
Glad it does what you want. That’s good news!

It just keeps on counting upwards. I think if you hit any numerical limit, you’ll have done a lot of work on it! Maybe I’ll swap over to a time stamp in the future if that seems more appropriate.

This was a quick and dirty fix for the problem as I saw it, and it certainly helps when developing things that rely a lot on CSS being kept up to date.

freewaytalk mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

11

I hope the counter will count up to QUADRILLION because this stupid Site Mapper action rebuilds my website daily TWICE before I can upload. Seriously… TWICE. I hate this stupid Action. And yet, there is no other Action that does what it does. And there is no third part solution that makes building a site map as easy either. If Site Mapper did not dirty all pages in the site every 24 hours (that’s right, it dirties the page twice, then no more until the following day), it really would be the perfect action for what it does.

Anyway, bless you Paul Dunning for your Action magic! You are an Actions WIZARD in the extreme!

–James Wages

freewaytalk mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

12

Janes - thanks for your kind words. The counter only ncrenemts when you click the button, not at every publish. That gives you more control over when you think a cached version needs replacing. So don’t worry - I don’t think you’ll hit that limit!

On 14 Dec 2017, 12:32 am, JDW wrote:

I hope the counter will count up to QUADRILLION because this stupid Site Mapper action rebuilds my website daily TWICE before I can upload. Seriously… TWICE. I hate this stupid Action. And yet, there is no other Action that does what it does. And there is no third part solution that makes building a site map as easy either. If Site Mapper did not dirty all pages in the site every 24 hours (that’s right, it dirties the page twice, then no more until the following day), it really would be the perfect action for what it does.

Anyway, bless you Paul Dunning for your Action magic! You are an Actions WIZARD in the extreme!

–James Wages

freewaytalk mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

13

Hi Paul,

Yeah, I found that out today when the stupidly painful “Site Mapper” action dirtied all the pages in my site and I uploaded. I then realized I need to click the button to make your Action do it’s job. Automation would be great, because I know there will be times I will forget, upload every page in my site, then see it broken, then go click the button and then have to upload it again. But at least it is a real solution to this serious problem which I did not have before.

I guess I am the only person on earth using ScriptyLightBox3. It’s not a big problem for my other CSS files for some reason. They seem to obey when I click RELOAD, but the CSS file created by ScriptyLightBox3 is stubborn. Perhaps there are other Freeway users who actually do have this problem but they don’t notice it because they either don’t test their sites enough or because they just don’t care. But I do care, and your Action really does work wonders, Paul. It’s fabulous in my book!

–James Wages

freewaytalk mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

14

James, could you point me to a URL where you use the SL3 Action? I would like to look at it in the Safari Web Inspector, and see if I can figure out why the code is so long-lived. When you say that it sticks with the old settings, are these the few bits you can change in the Action? Because I could totally understand if the rest of the CSS didn’t change – it comes from the Amazon Cloudfront CDN, and the expiration is set in years. But there is no way for you to change that code, either.

Walter

On Dec 14, 2017, at 8:34 PM, JDW email@hidden wrote:

Hi Paul,

Yeah, I found that out today when the stupidly painful “Site Mapper” action dirtied all the pages in my site and I uploaded. I then realized I need to click the button to make your Action do it’s job. Automation would be great, because I know there will be times I will forget, upload every page in my site, then see it broken, then go click the button and then have to upload it again. But at least it is a real solution to this serious problem which I did not have before.

I guess I am the only person on earth using ScriptyLightBox3. It’s not a big problem for my other CSS files for some reason. They seem to obey when I click RELOAD, but the CSS file created by ScriptyLightBox3 is stubborn. Perhaps there are other Freeway users who actually do have this problem but they don’t notice it because they either don’t test their sites enough or because they just don’t care. But I do care, and your Action really does work wonders, Paul. It’s fabulous in my book!

–James Wages

freewaytalk mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

freewaytalk mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

15

Walter,

Here are a couple web pages from my site that use ScriptyLightBox3:

At left you see a product photo. Below the photo you see a row of “PDF” icons. The two icons at left have ScriptyLightBox3 applied. So when you click either of them, as shown earlier in this thread in my YouTube video, overlay content should appear. But when the browser caching problem happens, just as you can see in my video, when you click the icons, nothing appears. If you then scroll to the bottom of the page, the overlay content sits there, beneath the very footer of the page. Clicking RELOAD or Option-RELOAD will not fix the problem. I must restart the browser.

When I use Paul’s action and when I physically click the BUTTON that Paul has setup in the Actions palette, it will increase the versioning of CSS, which solves the problem. But if I forget to click the button in Paul’s action, then the version number will remain the same, and after I upload, I get the same problem you see in my YouTube video.

If you’ve not watched that YouTube video yet, I highly recommend it because it makes the problem very clear:

In the video, you can see the Actions palette and all the settings I use for ScriptyLightBox3.

–James Wages

freewaytalk mailing list
email@hidden
Update your subscriptions at:

16

These pages remind me of why the Action was designed the way it is. The JavaScript does all the custom styling using data-variables that you place in the HTML. The actual JavaScript never changes, and never needs to, so it is hosted on CloudFront with a cache time-to-live measured in years. When I revise the JS, I change the Action to point to a different (also cached) URL entirely (using the Action version number in the URL to signal which version of the Action it belongs to).

So I’m curious what you saw in your page that didn’t appear to be updating in your design, and therefore why you needed to add the version parameter to get a “new” version of the script? You aren’t really breaking any caches here – the file is the same as it ever was (last version changed on May 10, 2015). If you are not seeing any difference in the way the page looks, the real culprit would be the html itself being cached, because that’s where all the configuration differences are encoded.

Walter

On Dec 14, 2017, at 9:30 PM, JDW email@hidden wrote:

Walter,

Here are a couple web pages from my site that use ScriptyLightBox3:

SCIBORG® 540: DIGI-LINKスマートセキュリティ

VISION 1480: DIGI-LINKスマートセキュリティ

At left you see a product photo. Below the photo you see a row of “PDF” icons. The two icons at left have ScriptyLightBox3 applied. So when you click either of them, as shown earlier in this thread in my YouTube video, overlay content should appear. But when the browser caching problem happens, just as you can see in my video, when you click the icons, nothing appears. If you then scroll to the bottom of the page, the overlay content sits there, beneath the very footer of the page. Clicking RELOAD or Option-RELOAD will not fix the problem. I must restart the browser.

When I use Paul’s action and when I physically click the BUTTON that Paul has setup in the Actions palette, it will increase the versioning of CSS, which solves the problem. But if I forget to click the button in Paul’s action, then the version number will remain the same, and after I upload, I get the same problem you see in my YouTube video.

If you’ve not watched that YouTube video yet, I highly recommend it because it makes the problem very clear:

Free

In the video, you can see the Actions palette and all the settings I use for ScriptyLightBox3.

–James Wages

freewaytalk mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

freewaytalk mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

17

Walter,

As I said, the thing that is not updating properly (without CSS versioning) is the overlay content, which is made to overlay on the page in the browser via the ScriptyLightbox3 Action used in Freeway Pro 7. As shown in my video, the problem happens when I make a tiny change to my site, which triggers the Stupid and Painful Site Mapper action to dirty all the pages in my site, and then I upload, and then I go to Safari and check the page (pulled off my web server, not a FW preview), and the problem occurs. Specifically, as shown in my video, the problem is that when clicking on the icon that triggers the ScriptyLightBox 3 overlay, the overlay does not appear over the page where it is supposed to appear. You have to scroll to the very bottom of the page, and then below the footer, you will see the content dumped there.

Here’s my video link:

For whatever reason, versioning the CSS files works. So long as I manually click the button in Paul Dunning’s Action before I upload, it will increase the version number by 1 and then after I upload, I will check in Safari, clicking the icon that triggers the ScriptyLightBox3 code, and the overlay appears perfectly and in the correct position on the page.

But if I forget to click the button in the Actions palette on Paul’s action, then the version number does not change, and if I upload and then check in Safari, the ScriptyLightbox3 overlay gets cast to the very bottom of the page, below the footer again.

So I would suggest that you watch my screencast on YouTube, as that shows you exactly what my eyes see, which is exactly what I have described here in text form.

Thanks,

James W.

freewaytalk mailing list
email@hidden
Update your subscriptions at: