Add a way for users to easily bust browser cache when updating Docsify websites.

[trusktr]

For example, add a new queryForAllRequests option that is used for all requests. This specifies a query string to use in every request, and when someone updates their site, they can update this string, which will force a browser to treat all requests as new files from network instead of from cache.

window.$docsify = {
  queryForAllRequests: 'id=123'
}

where any time we update our website, we can change this value, which will force the browser to see all files as new files (uncached). We could then set the cache lifetime to larger number, and use only this approach to bust the browser cache. For example, the browser would request https://example.com/path/to/file.md?id=123 instead of just https://example.com/path/to/file.md. When we update our site, we can change the option to 'id=124' for example, and then the browser will fetch https://example.com/path/to/file.md?id=124 which it will see as a new file and will fetch it from network instead of from local cache.

[Koooooo-7]

I think the queryForAllRequests not that meaningful. Maybe we could have some config like

window.$docsify = {
  alwaysFetchLatest: true
}

Then docsify gonna add something like UUID or random version string, timestamp... on the query.

About the Requests, we make could expose a hook for user to custom Requests before we do fetch.

[trusktr]

@Koooooo-7 Interesting idea! There is one issue with alwaysFetchLatest: true: we don't necessarily want users of a website to always fetch the latest every time, because that will disable the benefits of browser caching and every access to a website will always be fetching from a server (higher monetary cost if someone has a website with lots of traffic).

Ideally want a website's users to fetch new content after we've updated the website.

I think the alwaysFetchLatest idea could be useful, but perhaps not for everyone.

The idea with queryForAllRequests: 'abc' is that we can update it when we want to specifically bust the cache for an update.

Maybe a better alternative for queryForAllRequests: 'abc' would be siteVersion: 123: when someone makes an update, they can change the number manually, or they can add tooling that places package.json version value there, etc.

This may also relate to

• Proposal: display multiple versions of docs #1289

[sogadm]

I think the queryForAllRequests not that meaningful. Maybe we could have some config like

window.$docsify = {
  alwaysFetchLatest: true
}

Then docsify gonna add something like UUID or random version string, timestamp... on the query.

About the Requests, we make could expose a hook for user to custom Requests before we do fetch.

window.$docsify = {
	...
	requestHeaders: { 'cache-control': 'no-cache', },
	...
};

This code snippet sets the "cache-control" request header to "no-cache". This means that the client (e.g., a web browser) will not use any cached responses when making this request, and instead it will always send a fresh request to the server.

In other words, it ensures that the latest version of a resource is fetched from the server each time the request is made, rather than using a possibly outdated copy from the cache.

After testing, it was found that this code only takes effect on .md files, while other file types such as js, css, or png are not affected. This should meet your requirements.

[jhildenbiddle]

@sogadm's suggest is good for those who with to address cacheing issue via a configuration option. The danger with this method is that site owners may use this option during testing, forget to remove it when done testing, and end up with a live site that disables cacheing for all visitors.

Another option is to disable cacheing using your browser's developer tools. This removes the risk of forgetting to remove any kid of test-related cache options.