I have several web resources that are displayed on forms in Microsoft Dynamics. The web resources are html files that include JavaScript/CSS files. When I update the JavaScript files, I am seeing that the latest changes are not getting pulled to end user computers on their next use of the form. I believe this is because the previous version of the web resource has been cached on their machine.
According to this SO question, the solution would be to add a version to the script tag. However, according to the comments on the question, this solution does not work on Chrome and is considered a hack. I have also read here that Dynamics should automatically handle caching when web resources are updated, but does not do so reliably (which is my experience).
How can I force end user computers to get the latest version of my code on their next use of the form when I push out updates?
If you are only changing the files for development (ie. Once they are finished they won't change), then most browsers will allow you to disable the cache. In Chrome, this can be done as long as developer tools are open and you click the "disable cache" button in the network tab.
If they are going to change for the client with each request, then you can generate a random ID to be sent with the file (eg example.com/script.js?182hdh2). To allow this, just put some js in your html file (not in an external script) to import all the other files.
Related
I use Hostinger for hosting. Although I uploaded my files successfully, Chrome won't show the changes, while windows Explore does. It seems that the browser remembers the old version of the page and doesn't download the new files. It's the same on my friend's computer and phone, whom I showed the page before the update.
The page is pure HTML, CSS, and a bit of JavaScript. How can tell my browser it's a new version of a page? Without manually clearing the browser history etc.
www.michalrucinski.com
https://github.com/michalrutz/porto
You could rename index.html to index.htm so the old file would longer exist and the browser would be forced to search for an alternative file.
Or you can set up cache control in the HTTP headers, e. g. using .htaccess if your hosting plan supports it.
Browsers cache static files. It's what they're designed to do. 99% of the time, that's a good thing. Until we as developers update that static content.
If a developer updates a javascript file, but a user's browser pulls the cached version of it, then:
Best case, it'll be missing some new functionality until the browser decides to update its cache
Worse case, if you also updated the html page to call a javascript function that didn't exist in the older version of the javascript file that the browser cached, your page breaks
As developers, we know to hit Ctrl+Shift+R, or Ctrl+F5, or open dev console, disable cache on the Network tab, and reload. But users don't know that.
What is the best practice to handle updates to static content?
Is it to make sure that when you add new functions to a .js file, you push out the update to production a few hours/days before you update the html to call that function in <script> tags, allowing browsers to updated their cache over that time?
Is it to not call javascript functions from HTML within <script> tags at all?
Is there a way to somehow force browsers to expire cache on a specific static file when you update it?
Something else?
Obviously disabling all caching on your site is possible, but not a realistic solution.
PS. I'm not using any kind of frontend framework - just raw javascript/jquery. If the situation is different with frontend frameworks, I'd love to heard about that too at a high level
If I understand correctly, you want the JavaScript file to be updated for the user when you update. you should use service work API to create a cache version for specific files or use the Google workbox library. click here. for service worker API click here
Some years ago location.reload(true) allowed bypassing the cache like CTRL / Command+Shift+R does. Only Firefox continues to support this feature by now, but the hard reload using javascript is no longer supported on chromium based browsers. (spec doesn't describe this feature (anymore))
This change was also discussed on this issue on github/Microsoft/TypeScript and several other places on the web.
jQuery uses a simple workaround to be compatible with almost everything. If you load something with jQuerys jQuery.ajax({ url, cache: false }), it appends a _=TIMESTAMP parameter to the url, which has a similar effect but may bloat the cache.
You can make use of the Entity tag header (ETag). Entity tags are similar to fingerprints and if the resource at a given URL changes, a new Etag value must be generated by the server, which is a similar behavior to the Last-Modified header. (caniuse:etag)
Entity tags in: Apache, IIS, nginx (nginx docs), nodejs
It is also possible to clear the sites cache with a Clear-Site-Data: "cache" header. (mdn, caniuse:clear-site-data)
Everytime I deploy an update to our web application customers ring in with issues where their browser hasnt picked up that index.html has changed and since the name of the .js file has changed they run into errors. Presumably because their index.html still points to the old javascript file which no longer exists.
What is the correct way to ensure that users always get the latest version when the system is updated.
We have a HTML5 + AngularJS web application. It uses WebPack to bundle the vendor and app javascript into two js files. The files contain a hashname to ensure they are different once released.
Some other information
I can never replicate this issue locally (and by that I mean in debug, on our staging site or our production site)
We use CloudFlare but purge the entire cache after release
We have a mechanism in JS that checks on page load or every 5 minutes to see if the version of our API has changed, and if so show up a "Please refresh your browser" message. Clicking this runs window.location.reload(true);
Our backend is IIS
If you need users to pick up the latest index.html when they load your site immediately after you've updated the file, make index.html non-cacheable. That will mean the browser, CloudFlare, and any intermediate proxies aren't allowed to cache it, and that one file will always be served from your canonical server.
Naturally, that has a traffic and latency impact (for you and them), but if that's really your requirement, I don't see any other option.
There are spins on this. It might not be index.html itself that isn't cacheable, you could insert another resource (a tiny JavaScript file that writes out the correct script tags) if index.html is really big and it's important to cache it, etc. But if you need the change picked up immediately, you'll need a non-cacheable resource that identifies the change.
When I upload any changes in javascript files to my deployed site on Google cloud compute engine, the changes do not show up right away, if I load the js files in browser. The changes are physically there, validated by RDPing to the server. B
These changes sometime take 6 to 8 hours to show up in browser, and sometimes show up sporadically. What can I do to ensure that my changed js files take effect immediately on load?
I dont face this problem when I upload on my test server, which is not under cloud. Happens only on the google cloud server.
Try opening your builtin browser debugger (for example right-click on your page, if using Chrome, and click "Inspect"). Now select the Network tab. Now reload. Now look at the sizes of the files. If they are very small, then probably the browser loaded cached copies. You can verify this by checking the "Disable cache" option in the Inspector.
If it works correctly and the file updates right away when you have the browser cache disabled, then you need to investigate with your web server software to see how to cause it to invalidate caches. One mechanism you can look into is called "ETags."
What worked was invalidating the cloud cache for the file. Lesson learnt: always add version numbers to your js files.
I had problem that i added custom java script its included but when i changes its contents it doesn't effect. it runs older java script file. since i cleared cache. i deleted every folder of /var/ also. but still it runs older java script code. while i see it in uploaded file also it shows updated code but using URL of that java script in browser it shows old code.
I flushed magento cache storage. flushed cache of css/javascript also.
In case if any guy have solution let me know.
Thanks in advance.
EDITED
Same problem with css also. Changes doen't reflect. cleared cache a lot of times from back-end as well as cleared var folder also.
Your server probably have header information asking browsers to cache static files like JS/CSS. It is likely that your browser is still caching the old CSS files. One way to check if it is indeed the browser and not say accidentally editing the wrong CSS file is by enabling and disabling (only go one way to check) the CSS file merge. By doing so you are forcing the browser to fetch for a whole new file - essentially bypassing caching.
You may also want to take a look at our CSS/JS Versioning extension which includes automatic refresh of the file name hash based on CSS/JS file timestamps (sensitive to editing and changes) http://extensions.activo.com/css-and-javascript-versioning.html
Have you cleared your local browser cache on your workstation?
Often, CSS and JavaScript can stick mightily and no matter now much you flush Magento caching on the server, the workstation browser never requests and downloads the new script. These are static files, a change in file date doesn't trigger browser reload, only complete removal from the browser cache does.
Usually CTL-F5 about three times will do it, otherwise you have to go into the web browser setups and flush browser cache there.
Also, if you're using JavaScript/CSS Merge, you need to click the button on the Cache Management page to Flush JavaScript/CSS Cache as well.
The only other place things can gum up is if you're running APC cache, you may need to flush it as well so the block caching for the head can refresh. This only matters if you changed the script and CSS file names, which you probably haven't, so it likely doesn't matter.