You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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.
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.
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).
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.
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.
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.
Activity
Kleidukos commentedon May 29, 2021
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
tomjaguarpaw commentedon May 29, 2021
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.
Kleidukos commentedon May 29, 2021
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?
Fresheyeball commentedon May 29, 2021
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.
simonpj commentedon Jun 2, 2021
I can't get the new page at all. Just the old one, every time.
myShoggoth commentedon Jun 3, 2021
liskin commentedon Jun 9, 2021
It's a service worker: #61 (comment)
cdsmith commentedon Jun 11, 2021
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.
cdsmith commentedon Jun 11, 2021
Okay, unregistering the service worker worked and fixed the site for me. Just stopping it did not (as I expected).
cdsmith commentedon Jun 11, 2021
https://stackoverflow.com/questions/33704791/how-do-i-uninstall-a-service-worker looks relevant
Kleidukos commentedon Jun 11, 2021
Can confirm it works very well here
tomjaguarpaw commentedon Aug 16, 2021
Here are recipes for Chrome and Firefox:
Firefox
Go to URL about:serviceworkers
Find haskell.foundation
Click Unregister
Chrome
Go to URL chrome://serviceworker-internals/
Find haskell.foundation
Click Unregister
tomjaguarpaw commentedon Aug 16, 2021
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.
tomjaguarpaw commentedon Aug 16, 2021
Having an outdated site is terrible from a communications point of view. We really ought to increase the priority of this ticket.
tomjaguarpaw commentedon Aug 16, 2021
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.
goldfirere commentedon Aug 16, 2021
Thanks @tomjaguarpaw for finding that critical recipe to fix this! Hopefully it works. I'm still also getting the old site.
tomjaguarpaw commentedon Oct 13, 2021
@goldfirere Does this fix things on your browser?
goldfirere commentedon Oct 13, 2021
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.
Try to unregister browser serviceworker left over from previous site. C…