- Steve McNiven
This one came though my drift today, thought I’d share the “why”
When I click a file link, sitefinity serves me the old version, not the updated one
Why it’s happening
So the good news, is this isn’t a Sitefinity problem at all; it’s a browser issue. When a file is requested the browser uses the FULL url as the cache key. So subsequent downloads just serve up the local file instead of having to get it again.
So if you clear your browser cache, you get the file again because there’s nothing locally to grab it from. Now telling all your users to clear their cache is not an option (because users). The fix is to somehow change that cache key (url) in some way to FORCE the new file.
Lets use this as the example url
It’s a nice clean url, you probably just pasted it into a content block link right? This is a cache nightmare and should be avoided.
Instead you should be using the SF Document picker to physically choose the file. The doc picker automatically adds a cache busting querystring value to the end, and any time that file gets updated through the backend UI, that version code changes and users are served the server version, not their local cached version!
You can change it yourself though too, however it changes *doesnt matter*
Kinda get the idea? You can do it by hand every time the file changes, or just let SF handle it for you.
In the case of the issue the user had though, they were physically changing the sitefinity file in /App_Data/Storage, not using the SF UI. Which means SF isn’t informed on the database side anything has been updated so all the version codes throughout the site didn’t change, even though they were linked properly.
In that case, a custom widget where you could manually bust the cache, or some simple jquery to find the file (or files) and append something unique on every load.