Cache Issues: Deployments on our own domain

JamesCrandall · ‎10-24-2017

I'm hoping to see if others are experiencing problems deploying WAB applications developed with WAB Developer 2.x, specifically, when an existing WAB is re-deployed with updates to the same url address. Do your user's experience problems with browser caching the original WAB?

In the past we had experienced some problems where user's would navigate to the updated WAB but the updated functionality was not there and the original WAB application was presented. As a result (at the time) it was decided to publish updated WAB applications to a new url/address and just add a version number to the url.

I'd prefer to simply deploy any updated WAB's to the same url rather than manage new url's with redirects.

Any input is appreciated!

RobertScheitlin__GISP · ‎10-25-2017

James,

This change to the WidgetManager.js will ensure that the widgets config json is never cached (line 20 and 21):

    _tryLoadWidgetConfig: function(setting) {
      var def = new Deferred();
      //need load config first, because the template may be use the config data
      if (setting.config && lang.isObject(setting.config)) {
        //if widget is configurated in the app config.json, the i18n has beed processed
        def.resolve(setting.config);
        return def;
      } else if (setting.config) {
        if(require.cache['url:' + setting.config]){
          def.resolve(json.parse(require.cache['url:' + setting.config]));
          return def;
        }
        var configFile = utils.processUrlInAppConfig(setting.config);
        // The widgetConfig filename is dependent on widget label,
        // IE8 & IE9 do not encode automatically while attempt to request file.
        var configFileArray = configFile.split('/');
        configFileArray[configFileArray.length - 1] =
          encodeURIComponent(configFileArray[configFileArray.length - 1]);
        configFile = configFileArray.join('/');
//Append date to ensure you get the latest json file
        configFile += "?currentVersion=" + Date.now();
        return xhr(configFile, {
          handleAs: "json",
          headers: {
            "X-Requested-With": null
          }
        });
      } else {
        return this._tryLoadResource(setting, 'config').then(function(config){
          //this property is used in map config plugin
          setting.isDefaultConfig = true;
          return config;
        });
      }
    },‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

View solution in original post

RobertScheitlin__GISP · ‎10-24-2017

James,

There has been a thread or two on this. I can not rememeber if a good workaround for this issue comming out though:

Refreshing Web Appbuilder

https://community.esri.com/thread/172632

JamesCrandall · ‎10-24-2017

I found that thread too but wasn't sure if these items at WAB Developer 1.2/1.3 were still contained in our current version of 2.5 --- I'll dig around to take a look.

Thank you!

JamesCrandall · ‎10-24-2017

The big question is: why is this issue specific to WAB products?

I could be incorrect in my understanding, but I don't know if our other enterprise apps (SAP, or any other business app) has to deal with cache problems anytime they rollout a new version to the same url.

RobertScheitlin__GISP · ‎10-24-2017

James,

This is a general browser thing that the browser will cache files so it can bring up the page faster. So it is NOT specific to WAB. Other apps may use the non cache timestamp workaround for preventing files from being cached.

KenBuja · ‎10-24-2017

Someone suggested using a cookie to solve that problem

https://community.esri.com/message/594417

JamesCrandall · ‎10-24-2017

Aside from never allowing the browser to cache, what other potential affects (if any) would the following added to the index.html bring up?

<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate">
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Expires" content="0">‍‍‍

RobertScheitlin__GISP · ‎10-24-2017

Nothing that I am aware of.

JamesCrandall · ‎10-24-2017

I did some testing and simply cannot reproduce the original issue.

1. Create duplicate WAB applications in WAB Dev 1.3 and 2.5

2. Deploy 1.3 version and verify EnhancedSearch widget functions at that version

3. Keep same IE 11 browser open, deploy 2.5 version to same location (url). EnhancedSearch widget functions at that version.

4. Keep same IE 11 browser open, deploy 1.3 version again to same location (url). EnhancedSearch widget functions at that version.

I was expecting the browser to cache the widget at each version (there are obvious differences in functionality from 1.3 to 2.5) but they didn't appear.

I replicated this same test method using the AdvancedDraw and regular ESRI Draw widgets, on multiple computers with different login/user accounts. Basically the same results as above: upon a refresh of the browser (not a close/open/back_forward) the widgets would function as expected.

RobertScheitlin__GISP · ‎10-24-2017

James,

Just to be sure. What you are saying is that with the no cache stuff in the index,html you did not see the change to the widget going from 1.3 to 2.5?