Sparkle updates show in preview but not when uploaded - Safari

[FreewayFugitive]

Several people have posted before about sites not reflecting changes made in Sparkle when uploading. This evening I hit the same problem and I think may have found the reason why.

First off this only happened in Safari. Other browsers worked fine.

In my case, the footer section on a page did not show. It looked fine on preview:

but each time I looked at it on Safari I got this:

The footer had vanished.

Cleared the browser cache, cleared the cache on my server, used Safari Develop Empty Cache and cleared the Sparkle publishing cache, too. Republished the site. Repeated several combinations of the foregoing for about three hours.

Still I could not get it to work. The strange thing was if I went to another page the footer was there and if I linked back to the original the footer reappeared.

Then it dawned on me. I, and I suspect many of you, access your website pages using a Safari Bookmark. A bit of searching with DuckDuckGo hinted that Safari might handle caching for bookmarked pages differently. (The clue came from a post relating to Safari on IOS!)

I deleted the bookmark, cleared caches (again ) re-created the bookmark and the problem went away !

Now this may all have just been chance but if your newly published site does not reflect the changes you have made this may help.

Edit: The version of Safari I’m using is Version 14.0 (15610.1.28.1.9, 15610).

[Shadowfax]

Thank you @FreewayFugitive

Very interesting findings.

[macmancape]

I wish that they’d just kill off browser cache entirely. It’s a relic of the bad old days of dial up.

Someplace, I found a script to install on the server that kills that cache. (I have it at home on my Mac; I am at work now). It’s been helpful, especially with clients who swear I haven’t updated their website when I have!

Anyone else run into this problem?

[FreewayFugitive]

Yes, it’s a pity (unless I’ve missed it) that the Safari Develop options don’t allow you to stop ALL caching. I remember a method which directed the caches at the bitbucket (null device). I’ve not had a chance to follow this up on the Apple forums yet.

[francbrowne]

Cache-busting is normally handled by web development apps by making changes to some css or script names within the html. When the page is read, it will normally be assumed that such a change means that the content is new and will be loaded again instead of grabbing the cached version. In Sparkle, you will see that the same thing happens. Below is a screenshot of part of the HTML output generated by Sparkle.

You will notice that there is a randomly generated number after the css file name. This number changes every time the site is exported. This is the clue to the browser that the cached version is out of date and the new version should be loaded.

This works in most cases, but sometimes a more definitive approach is a little more predictable. Some web development apps use a query after the file name - this is a question mark followed by a version number. An example is shown below:

This means that the file retains its name, but the query tricks the browser into reloading the file again. In theory, the same thing should happen when using a random number in the file name itself. However, in some instances, browsers may simply treat the renamed file as an additional file rather than a changed file. This happens most frequently when doing incremental updates when only part of the site changes. Therefore, it’s usually worth uploading and overwriting the whole site in order to do a full cache-bust.

[RicC]

Please excuse me if this is a stupid suggestion. Often you are shown a cached page. Always remember to refresh/reload the link in your browser.