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.
Related
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.
I have a custom JS file with many functions in my MVC4 asp.net application. I marked the JS file as Content and selected Copy Always option in the properties. However, I can only view latest changes to that file if I clear the cache by pressing CTRL + F5. I was wondering if there is any other way to clear the browser cache automatically when I deploy the application to the server.
The server cannot instruct the browser to clear the cache for items that are already cached, because the cache prevents the browser from even asking the server about it. Even if you could, there may be other caches in between the server and the client.
One thing you can do is fool the browser into thinking that your new JS file is a different file by appending some value to the end of the URL, e.g.
<SCRIPT SRC="https://Domain.com/Scripts/MyScriptName.js?version=XXX">
Just increment XXX with each build and the browser will see the JS file as new and ignore any cache of previous versions.
Bundling can help by versioning the delivered js content. Read about it here.
Git has made updating my site a hell of a lot easier and quicker. I love it.
However, it seems when updating files with git, my browser seems to cling to old cacheable files much longer than it should.
I have no idea if this is just my browser, if it's a quirk of git, or if it's just a problem that affects only me for some other reason.
A couple days ago I found a bug on my site, so I fixed it and pushed a new version of the affected js file to my site.
When I do this, I find if I don't hit f5, then it'll load the old js file. So I always hit f5 and think nothing of it.
But for users of my site, they are probably having the same experience... which isn't good.
So I updated the js file 2 days ago and refreshed the home page, checked it was working and left it.
Just now, I checked another page on the site, loading the exact same js file and it was still using the old cached version. I hit f5, it now loads the new one.
Is there any way I can force all browsers to forget the cached version of old files? I figured this should just happen automatically after a cache's short lifetime.
Here's the headers from chrome:
As you can see, the cache control max-age is stupidly high. My server runs with nginx+apache, and a backend system called Vesta Control Panel (VestaCP).
If I fix the cache control on the backend, how do I then tell all of my user's browsers to forget the seemingly unforgettable cached version?
This depends on your setup. If your index page is HTML, you'll want to set the server cache to expire very quickly on HTML files, so it will reload your index page frequently. (This isn't an issue with an index.php, as it should reload every time). Then you'll want to filerev your resource files.
For instance, you can use grunt, gulp, or something similar that will append a unique string at the end of the filenames for all your resources, so script.js becomes script.1a34be4sde4.js and then the next update becomes script.3ezseasd4sad.js and so on. Or you could manually rename them, adding 1 each time (script-001.js, script-002.js, etc. - although with many files this would be a pain).
This way you can keep your max-age stupidly high and the user won't have to download that version of the file again. But when your index page points them to an updated version (new filename), they'll go grab the new version and cache it stupidly long.
The problem comes with using git push to update the site. To keep your repo clean, there are a few things you could do. What I'd probably lean toward is a post-receive hook script on the server that would checkout the pushed branch to a staging folder, run a build script, and move the final version to the deployment folder.
There are a couple of cache-busting techniques that you can use, none of which are particularly linked to git (and some may be anathema to it).
In your index.html, you could use a query cachebuster:
<script src="/js/core.js?cache=12345">
Which works in some cases (most browsers, AFAIK, won't re-use cached files if the query string is different). This means you have to change your index.html every time you update stuff. There's plenty other ways to do cache busting, google around and you'll probably find a dozen at least, each of which is the "best".
Personally, I use gulp-rev in combination with gulp-inject in my build process. gulp-rev will create a hash-based uniqid for the filename (so it renames core.js to core-ad234af.js), and then gulp-inject changes index.html so it pulls that file in, instead of core.js. I only do this when doing a production build (since in dev, I have cache-control set to 0).
But this all works because I don't do git push to deploy - I use git to get the source to my production server, and then build on that server with the production flag set.
I see this strange behavior (or may be I am missing something).
I have WebSphere 8.5. Deployed a EAR. Its working fine.
Instead of repacking and deploying every time for small change, I just copy the js and CSS files directly to the Websphere exploded folder and overwrite the existing files. I see the changes are getting reflected.
I just updated a JS file and added a couple jQuery functions and copied the file like above. Now when I refresh the page, I see the updated code (which is somewhere in the middle of the file). however the js file is not loading fully in all 3 browsers (IE8, Chrome and FF latest). It's getting cut off in the last 10 lines are so.
The file has 1784 lines. Not sure if there is a size limit on the browser side or WebSphere is tinkering with it or something else is going on. Any idea?
I did check the js file I copied to Exploded WebSphere folder. It has complete code.
Note that the page has a few more JS files (jQuery and other files) in addition to this one.
Edit:
I think WebSphere is keeping the size of the file somewhere (maybe?) and sending only that size every time, unless there is clean deploy or restart (?).
I removed a few lines of updated code. Now the browser loads, exactly that many number of additional lines of code. Once I remove my code completely, it loads the full file. (This is not an issue with the code though).
Is there a caching that I need to clear in WebSphere?
Check this page it Hot deployment and dynamic reloading. In general it says that you may need to restart the application.
Also check, if application reloading is enabled, however I'm not sure if it is relevant for static files.
If reloading of classes is enabled and the polling interval is greater
than zero (0), the application files are reloaded after the
application is updated. For JavaServer Pages (JSP) files in a web
module, a web container reloads JSP files only when the IBM extension
jspReloadingEnabled in the jspAttributes of the ibm-web-ext.xml file
is set to true. You can set jspReloadingEnabled to true when editing
your web module's extended deployment descriptors in an assembly tool.
You can restart app from console as provided in comments or via wsadmin script.
We have a client with thousands of users (who all use Internet Explorer) and a large amount of javascript files that enhance their user experience with our product.
The problem I'm having is that any time we update one of these scripts there is no way to know whether the client is seeing the latest version. What we're having to do is tell our client to do a hard refresh (ctrl+f5) before viewing any changes. Obviously this approach is not ideal.
I know that browsers cache based on the url, so one could use something like
<script src='myScript.js?ver=1.2'>
to get around the issue, but this is not an option for us.
I was hoping that there's some kind of header property or something similar that we could use to tell IE not to cache these scripts.
Any ideas?
You can also version the filename itself like jQuery does:
<script src='myScript-v1-2.js'>
Then, each time you revise the script, you bump the version number and modify the pages that include it to point to the name of the new script. This is foolproof vs. caching, yet still allows your viewers to receive the maximum benefit of caching and requires no server configuration changes for the .js file.
A full solution will typically include setting a relatively short cache lifetime for your host web page and then allow the various resources (stylesheet files, JS files, images, etc...) to have longer cache lifetimes for maximum caching. Anything that is fingerprinted can have a very long cache lifetime. See the reference that fabianhjr posted about for ways to set the cache lifetime of the host web page. It can be done in the web page itself (<meta> settings) or in the http headers via the server.
If you turn off caching for your script file (which would likely have to be done at the web server level for a script file) then all your viewers will lose the performance benefit of caching and you will lose the bandwidth and load-saving benefit of caching. If you use a common .JS file across many pages (a common design pattern), your viewers will see slower performance on every page.
Everything you need to know about cache http://www.mnot.net/cache_docs/
http://www.mnot.net/cache_docs/#CACHE-CONTROL <-- HTTP Headers