Cache Issues: Deployments on our own domain

[JamesCrandall]

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!

[JamesCrandall]

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?

Sorry Robert, I should have qualified my post with more info.  No, I did NOT alter any code or files -- just straight-up vanilla WAB apps that I added the eSearch widget to at their respective versions and then deployed each one during each test.

WAB 1.3 has the eSearch widget at version 1.3.0.2

WAB 2.5 has the eSearch widget at version 2.5

[RobertScheitlin__GISP]

But you are saying that you did not see a change in the widget UI going from 1.3 to 2.5. Meaning the widget UI stayed looking like the 1.3 UI?

[JamesCrandall]

Yes I see the change in the widget UI going from 1.3 to 2.5, then again back from 2.5 to 1.3.  I even did another round of this and at all tests the widget changed (ie. it did not appear to cache anything at all)!

[RobertScheitlin__GISP]

James,

  OK, that is what I expected since they added the developer version number to the file url paths in one of the versions. The issue with caching you will see is when you have updated a same WAB Version number with new config file for a widget or something. So say you have the eSearch 2.5 and have it deployed and then make a change to the search layers and re-deploy you would expect to see that new search layer change but likely will not because the eSearch widget.json will be cached in the apps configs. So that is the type of testing you want to do after you have made your no cache directive change to the index.html.

[JamesCrandall]

I see.  Thank you for that bit of info and will try to replicate that!

[JamesCrandall]

Robert,

I tested the scenario you specified above and I was able reproduce the caching issues in Chrome only.  IE did not cache the widget.  That is, reconfigurations of the eSearch widget that are redeployed would show the changes after a browser refresh.  However, in Chrome it required a clear of the cache in order to see those same changes.

Are you implementing anything in the eSearch widget that attempts to deal with this?

Thanks again!

[RobertScheitlin__GISP]

James,

   No I am not. It is an issue likely with the apps/configs/eSearch/config_eSearch.json getting cached.

[JamesCrandall]

Thank you!

Also, adding the meta tags in the index.html had no effect.  The only way to see changes in Chrome is to clear cached images and file.

<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]

James,

   I would not say that exactly. I believe there is a way to do this by expanding on the code that the WAB Development team added for making sure the version number of WAB is attached to the file requests. Currently they append the wab_dv=2.x if that was expanded to add a date stamp then it wold work.

[RobertScheitlin__GISP · Accepted solution]

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;
        });
      }
    },‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍