topic Re: Cache Issues: Deployments on our own domain in ArcGIS Web AppBuilder Questions

Cache Issues: Deployments on our own domain

JamesCrandall — Tue, 24 Oct 2017 15:32:51 GMT

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!

Re: Cache Issues: Deployments on our own domain

RobertScheitlin__GISP — Tue, 24 Oct 2017 15:45:59 GMT

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

Re: Cache Issues: Deployments on our own domain

JamesCrandall — Tue, 24 Oct 2017 15:49:17 GMT

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!

Re: Cache Issues: Deployments on our own domain

JamesCrandall — Tue, 24 Oct 2017 15:55:50 GMT

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.

Re: Cache Issues: Deployments on our own domain

RobertScheitlin__GISP — Tue, 24 Oct 2017 16:02:54 GMT

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.

Re: Cache Issues: Deployments on our own domain

KenBuja — Tue, 24 Oct 2017 16:41:46 GMT

Someone suggested using a cookie to solve that problem

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

Re: Cache Issues: Deployments on our own domain

JamesCrandall — Sun, 12 Dec 2021 07:56:27 GMT

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">‍‍‍

Re: Cache Issues: Deployments on our own domain

RobertScheitlin__GISP — Tue, 24 Oct 2017 17:59:55 GMT

Nothing that I am aware of.

Re: Cache Issues: Deployments on our own domain

JamesCrandall — Tue, 24 Oct 2017 20:38:38 GMT

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.

Re: Cache Issues: Deployments on our own domain

RobertScheitlin__GISP — Tue, 24 Oct 2017 20:50:38 GMT

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?

Re: Cache Issues: Deployments on our own domain

JamesCrandall — Tue, 24 Oct 2017 20:58:33 GMT

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

Re: Cache Issues: Deployments on our own domain

RobertScheitlin__GISP — Tue, 24 Oct 2017 21:02:15 GMT

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?

Re: Cache Issues: Deployments on our own domain

JamesCrandall — Tue, 24 Oct 2017 21:06:08 GMT

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)!

Re: Cache Issues: Deployments on our own domain

RobertScheitlin__GISP — Tue, 24 Oct 2017 21:13:23 GMT

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.

Re: Cache Issues: Deployments on our own domain

JamesCrandall — Tue, 24 Oct 2017 21:17:10 GMT

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

Re: Cache Issues: Deployments on our own domain

JamesCrandall — Wed, 25 Oct 2017 15:54:44 GMT

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!

Re: Cache Issues: Deployments on our own domain

RobertScheitlin__GISP — Wed, 25 Oct 2017 16:00:56 GMT

James,

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

Re: Cache Issues: Deployments on our own domain

JamesCrandall — Sun, 12 Dec 2021 07:56:30 GMT

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">‍‍‍‍‍‍

Re: Cache Issues: Deployments on our own domain

RobertScheitlin__GISP — Wed, 25 Oct 2017 16:19:36 GMT

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.

Re: Cache Issues: Deployments on our own domain

RobertScheitlin__GISP — Sun, 12 Dec 2021 07:56:33 GMT

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