HI,
With CSS and JavaScript being changed when XWay rebuilds a site (especially when changes are made), you may find that even if you upload the files to the server, when you view the site the old files may still be cached. It may be that they are cached locally, OR (and this is pretty much the norm now), the ISP will cache them, and that cache may not refresh for a while.
You get this with Freeway too. I have an Action that adds ?v= to those script and style URLs it can find - with being changed when the user requires it. This effectively busts the caches, but only once - until the number changes.
I notice that other apps do similar - Hype is one I use and it does this kind of thing. I’d like top suggest that XWay does this when CSS or Script files change.
A clever trick I stole for an Action I created a while ago appends an MD5 hash of the file being linked to as a query string. It means that the hash remains the same while the file is unchanged but gets updated overtime the file’s contents change. Doing things this way means that files can be cached when they are unchanged but should load again when the hash changes.
Hi,
That’s why my Action needs a manual intervention to change the query string - that way the cache busting bit doesn’t change every time, which could result in continuous whole site publishes.
On 5 Dec 2019, at 13:14, Tim Plumb <email@hidden> wrote:
A clever trick I stole for an Action I created a while ago appends an MD5 hash of the file being linked to as a query string. It means that the hash remains the same while the file is unchanged but gets updated overtime the file’s contents change. Doing things this way means that files can be cached when they are unchanged but should load again when the hash changes.
Create a plain text file and add the following style to it;
body {
color:red;
}
2. Save the file to the desktop as sample.css
3. Open Terminal and type md5 (a space character) and then drag the file from step 2 to the Terminal window
You should have something like; md5 /Users/tim/Desktop/sample.css
4. Hit return and you should get back an MD5 hash for the file; 30e4fbad35a297a2aef2ea86c4752a76
5. Now lets return to the file in step 1 and change the code to read;
body {
color:blue;
}
6. Save the file and repeat steps 3 and 4 (or simply rerun the last command in terminal)
7. You should get a new hash value; 3e5ce25a6b6fdb6c6b57efbd45b68d7d
8. If you change the CSS back to as it was in step 1 (color:red) you’ll get the hash value back we saw in step 4
You’ll see that the hash value is unique to the state of the file. If the file changes the hash will as well but if the file stays the same then the hash remains unchanged as well.
This means that you can append a hash value on a file (or make the file name the hash is you like) knowing that the browser or server will only server files from the cache that it has seen before. If a file changes then the hash will change and the query string on the file should prevent the user from seeing a cached version of the data.
The only overhead with this is having Freeway (for example) calculate the hash for the file even if the file hasn’t changed. In that Action I created it just blindly did it each time but I suspect it could have saved a split second on each publish by checking if the file had been updated since the last publish cycle.