Open myShoggoth opened 3 years ago
Yeah, usually you have to configure your web assets build too prepend a hash of the bundle's content to the filename, so that when the content changes, the path of the static asset in the HTML changes too, which is a nice cache-busting technique
Do any web experts know if there's some server setting (that perhaps goes to the browser in an HTTP header) that causes the browser to not bother looking for page changes? If I change a page on my own personal website then a simple refresh (not even a Ctrl-refresh, let alone deleting worker processes!) is enough to get the new page. It makes me wonder if something is misconfigured on the server.
Maybe we can just ask IOHK? I've hit the original page again today, served from Netlify, so maybe CDN configuration issues at play here as well?
Best practice is as follows
Routes to pages need a no-cache header, so the browser always fetches the html and never caches it.
All routes to static assests should be set to cache with an infinite ttl, then the assests links need to contain a hash of themselves to force redownload and recache when it changes.
I don't know what GitHub.io exposes for header controls, but if you like I can furnish nginx config that embodies the best practices mentioned above.
I can't get the new page at all. Just the old one, every time.
I need to do a control-refresh (on windows) to get the new stuff.
Sent from my iPhone
On Jun 2, 2021, at 4:41 PM, simonpj @.***> wrote:
I can't get the new page at all. Just the old one, every time.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
I'm seeing this as well. I get what I assume is the older design (solid purple background), and navigation is completely broken. When I Shift-Refresh, I get what I guess is the new design (white background) and navigation works again. But Refresh again reverts to the old design and broken navigation. I haven't yet tried killing the service worker, but I have rebooted my machine several times since my visit to the old design, and it's still broken, so I can't imagine it's an old process causing it. I'll investigate and let you know.
It looks like this will be fairly widespread, judging from the number of reports and the fact that I didn't do anything unusual except visit the page several times.
I haven't yet tried killing the service worker, but I have rebooted my machine several times since my visit to the old design, and it's still broken, so I can't imagine it's an old process causing it. I'll investigate and let you know.
Okay, unregistering the service worker worked and fixed the site for me. Just stopping it did not (as I expected).
Can confirm it works very well here
Here are recipes for Chrome and Firefox:
Go to URL about:serviceworkers Find haskell.foundation Click Unregister
Go to URL chrome://serviceworker-internals/ Find haskell.foundation Click Unregister
I found a StackOverflow answer that seems to describe how we can resolve the problem. It requires knowing the filename of the file from which the service worker was loaded. I can only see two ways to find out:
If you have a browser that is still showing the old website please follow my instructions above and report the "script" corresponding to the haskell.foundation entry.
We have the repository for the old website. I can't see anything that is obviously a service worker script but maybe someone else can. I believe IOHK generously contributed this site. Perhaps someone there can tell us.
Having an outdated site is terrible from a communications point of view. We really ought to increase the priority of this ticket.
Michael Snoyman has a browser still showing the old website and confirms that the old service worker seems to be running from https://haskell.foundation/sw.js
. I can't see how such a file could have been created from the old repository. Perhaps it's a node, gatsby or Netlify feature.
Anyway, I believe that we can now implement the StackOverflow answer that I linked above. I suggest that this is given high priority.
Thanks @tomjaguarpaw for finding that critical recipe to fix this! Hopefully it works. I'm still also getting the old site.
@goldfirere Does this fix things on your browser?
The fix seems to work for me, but @mboes says it doesn't for him. I did force-refresh once this morning. Maybe the fix means that one force-refresh is enough? Previously, I had to force-refresh on every load.
I've seen it myself and it has been reported by many, I often have to control-refresh to get the new site. Is there something we need to add to the metadata of the site to tell browsers to clear the cache or limit it?