What is the best approach to forcing updated custom tasks javascript to browsers ?

Jerry_Veldhuis

Every week or two we make improvements to our javascript in custom tasks. We're also finding that in the days following an update our analyst's browsers will sometimes be running old code with new because the browser has cached the javascript code. We've been relying on users forcing the cache to clear (ie in Chrome, F12, then Right-click on reload button and choose 'Empty Cache and Hard Reload') but we'd rather be in-front of the issue by somehow forcing the new javascript to user's browsers.

I've read a couple of approaches, one being adding version #s to every javascript function that way the developer can choose how to control what gets updated in cache or not. This seems like a good idea until you realize the maintenance nightmare it creates.

We're starting to test setting the content expiry at the site level (in IIS 6.2) but not sure what is an appropriate expiry.

We have thousands of users on our portals every day, so I'm hoping to get some experienced feedback instead of creating unnecessary server load using settings that don't work.

Couple of questions for the community:

1) is anyone using the javascript functioning versioning technique and if so, how is it working for you ?

2) is anyone changing the 'Expiry Web Content' values in IIS and seeing success ? And what expiry have you landed on and why ?

3) other solutions ?

Appreciate any insight.

jerry

Jerry_Veldhuis

Thanks everyone for their suggestions. We're in final testing of a solution where we set the Cache-Control value to 8 hours on just the CustomSpace folder. This looks like its resolves our issues as it applies to our custom code without affecting the rest of the Cireson Portal application.

Will keep you posted on how testing goes.

Tony_Collett

I've found in the past that by recycling the IIS CiresonPortal Application Pool, JS and CSS files are updated appropriately on the browser when the portal is loaded the next time. My sample size is pretty small however (compared to your sample size), and so this might not be the entire cure for the issue you are having. 

Jerry_Veldhuis

Tony_Collett said:

I've found in the past that by recycling the IIS CiresonPortal Application Pool, JS and CSS files are updated appropriately on the browser when the portal is loaded the next time. My sample size is pretty small however (compared to your sample size), and so this might not be the entire cure for the issue you are having. 

This definitely doesn't work for us. We are using 4.0.10 but don't this would be version specific behavior.

merlenette_jones

Jerry_Veldhuis said:

Every week or two we make improvements to our javascript in custom tasks. We're also finding that in the days following an update our analyst's browsers will sometimes be running old code with new because the browser has cached the javascript code. We've been relying on users forcing the cache to clear (ie in Chrome, F12, then Right-click on reload button and choose 'Empty Cache and Hard Reload') but we'd rather be in-front of the issue by somehow forcing the new javascript to user's browsers.

I've read a couple of approaches, one being adding version #s to every javascript function that way the developer can choose how to control what gets updated in cache or not. This seems like a good idea until you realize the maintenance nightmare it creates.

We're starting to test setting the content expiry at the site level (in IIS 6.2) but not sure what is an appropriate expiry.

We have thousands of users on our portals every day, so I'm hoping to get some experienced feedback instead of creating unnecessary server load using settings that don't work.

Couple of questions for the community:

1) is anyone using the javascript functioning versioning technique and if so, how is it working for you ?

2) is anyone changing the 'Expiry Web Content' values in IIS and seeing success ? And what expiry have you landed on and why ?

3) other solutions ?

Appreciate any insight.

jerry

Hello Jerry,

I would try clearing your browser cache (Ctrl+F5) this will refresh the browser itself and you should see your changes propagate through.

Merle

Jerry_Veldhuis

Merle, Ctrl+F5 doesn't work for us (so we're using the 'Empty Cache and Hard Reload' which clears more of the cache). And with 17000+ users, we're really hoping to find a solution that doesn't require them to identify when the cache is an issue and have to reset it.

Lasse_Strand_Ringvol

We have the same issue. What I have considered doing is to create a version-file in CustomSpace, then in custom.js just do a simple ajax-request and check version. If version is different, then use window.location.reload(true). The true-parameter is for enable "forceGet" and therefore will update the cache.

Example (Not tested):
Customspace\customversion.txt:
13

Custom.js:
$.get('/CustomSpace/customversion.txt?_=' + new Date().getTime(), function(d){
currentVersion = 12;
if( Number(d) > currentVersion ){
window.location.reload(true);
}
});

I haven't had the time to test it yet, but I think this could work IF window.location.reload(true) actually works.

carrie_medine

Hello,

The Cireson Portal does version its javascript files.  In order to increment this version and force the updated js changes you can modify the versions.json file by opening Windows Explorer on the server where the Cireson Portal web site is installed and navigate to the installation directory (C:\inetpub\CiresonPortal\bin by default) and open the versions.json file.   Increment the number within this file and then restart your Portal website.

Be aware that upon Portal upgrades this file will be overwritten and as you have already incremented it you may need to perform the increment again if the updated version contains the same number as your modification.
Thanks,
Carrie

Jerry_Veldhuis

Thanks Carrie, we'll give this a try

james_kleinschnitz

Please pay attention to the second point @carrie_medine made, if you change this file you will need to take over manual management of this version with each upgrade.  Maybe we can look at adding an additional version number unique to the custom css & js files.

Morten_Meisler

What happens if you version-control your custom task js files itself?

Instead of putting all code inside custom.js, you call each custom task or other custom functions, by this:

$.get('/CustomSpace/Tasks/Incident/mycustomtask_v.1.0.2.js)

Then increment the js file whenever something is changed. I also typically add a history changelog inside the file itself, to get an overview of what has been changed. That way you can also keep an archive of the old versions to do a fallback for good practice.

john_doyle

Maybe you could try adding this to the web.config file in C:\inetpub\CiresonPortal:

</code><code><pre class="CodeBlock"><code>...<br>  <location path="custom.js"><br>    <system.webServer><br>      <httpProtocol><br>        <customHeaders><br>          <add name="Cache-Control" value="no-cache" /><br>        </customHeaders><br>      </httpProtocol><br>      <caching enabled="false" /><br>    </system.webServer><br>  </location><br>
<span>...<br></configuration></span><code><configuration>

<pre class="CodeBlock"><code>This would instruct IIS not to cache the file in memory and tell the browser not to cache the file locally either.

Jerry_Veldhuis

Thanks everyone for their suggestions. We're in final testing of a solution where we set the Cache-Control value to 8 hours on just the CustomSpace folder. This looks like its resolves our issues as it applies to our custom code without affecting the rest of the Cireson Portal application.

Will keep you posted on how testing goes.

Brett_Etzel

Hello,

Did this work?

In IIS do you "Add Cache Rule"?

If it worked, what did you use for file name, etc.?

sc.png

Thanks!