Onprem caching problem. After upgrade form does not display (correct) anymore

Hi everyone,

I have

  • a SP2019 farm onprem
  • with a modern Team-site
  • with a modern page
  • that hosts a simple Plumsail Form webpart
  • showing the new-form on a list

The form was made with Plumsail Forms (SP2019) version 1.8.7 and works perfect.

Than, I upgraded my solution from 1.8.7 to 1.9.0

# RETRACT solution
UnInstall-SPSolution -Identity "Plumsail.Forms.SP2019.wsp" -Confirm:$false

# REMOVE solution
Remove-SPSolution "Plumsail.Forms.SP2019.wsp" -Force  -Confirm:$false

# DELETE app from appcatalog
https://xxxxxxxx/sites/appcatalog

# ------------------------
# manual reboot (single server, development)
# ------------------------
Restart-Computer -ComputerName localhost 

# ADD solution
Add-SPSolution "C:\workdir\MyApps\SOFTWARE\SharePoint.Plumsail.FormsOnPrem\Install\v1.9\wsp\Plumsail.Forms.SP2019.wsp"

# DEPLOY solution
Install-SPSolution -Identity "Plumsail.Forms.SP2019.wsp" –GACDeployment -Force


# UPLOAD app to appcatalog
"C:\workdir\MyApps\SOFTWARE\SharePoint.Plumsail.FormsOnPrem\Install\v1.9\sppkg\Plumsail.Form.SP2019.sppkg"
https://xxxxxxxx/sites/appcatalog

PROBLEM

The problem now is that my browser client is doing some sort of caching (I think) and the form is not displayed correctly: the field controls are not displayed anymore.

Only after a full clear cache of my browser, the new version of the forms comes trough and the controls are displayed.
Even worse: If I create a new form on another list with my new Designer 1.9.0, the form wil not work on any browser that have somehow a cached version of the 1.8.7 Plumsail files!

This means that

  • If a user ever opened a Plumsail form
  • the admin decides to upgrade the solution on the farm
  • the the user can NOT open any form anymore.

As a SharePoint admin, we can decide to upgrade, but we can not control all our users to hard refresh their client. So we are looking for a solution that clears the cache of the browser (or that can avoid above behavior)

I tried already some javascript-stuff:

window.location.href = window.location.href

or

location.reload(true);

without any success.

The only thing that works is an "Empty cache and hard refresh"

after that, my controls (1) do display correctly on my form:

FYI:
on the console, I get following errors:

b250ab3daa1636c4b108.js:1     
Failed to load resource: the server responded with a status of 404 (Not Found)
Plumsail-Form.aspx:1 
Refused to execute script from 'https://xxxxxxxx/_layouts/15/plumsail/forms/widget/assets/js/2.b250ab3daa1636c4b108.js' because its MIME type ('') is not executable, and strict MIME type checking is enabled.
23.c31392c6480c19097e34.js:1     
Failed to load resource: the server responded with a status of 404 (Not Found)
Plumsail-Form.aspx:1 
Refused to execute script from 'https://xxxxxxxx/_layouts/15/plumsail/forms/widget/assets/js/23.c31392c6480c19097e34.js' because its MIME type ('') is not executable, and strict MIME type checking is enabled.

indicating that the pages wants to load the old javascript files of version 1.8.7 that are not available anymore after the upgrade.

Please advice!

kind regards,
Bart Plessers

Dear @bartplessers,
If the following code produces no result:
location.reload(true);

Then manual clearing is the only option, I am afraid. I will discuss it further with the dev team to find if there's a better solution to the problem.

Hi @Nikita_Kurguzov

Thanx for your answer!
However

  • location.reload(true); has no effecft
  • Manual clearing the cache is no option as mentioned earlier (we don't control several thousands of end users, mobile devices, etc...)

However,
Doing some reverse engineering, it seems that a file
_layouts/15/Plumsail/Forms/widget/spform.js
loads all the other *.js files

so by adding a rewrite rule to IIS, something like

_layouts/15/Plumsail/Forms/widget/spform.js?version=v1.9.0

maybe we can force the clients to reload the file from web (and not from cache).

However, I'm not sure this is the only file that should be reloaded after an upgrade. Can you please elaborate this a little?

And yes, please contact your developpers to solve this issues permanently if possible. This is a real problem in production environments!

grtz
Bart Plessers

Dear @bartplessers,
You can try the following and let us know if it works! It's strange to hear that the caching is so severe, normally it should continue functioning even after update, but definitely let us know if the following helps, we'll include this information in troubleshooting if it works. CSS files might not be updated though.

mmmmm
It seems some browsers do some more aggressive caching than others.
Above solution seems to work for FireFox, but not for chromium basesd browsers.... :frowning:

Hi @Nikita_Kurguzov ,

I have tried all kinds of settings on the server side:

Response Headers

      <customHeaders>
        <add name="X-MS-InvokeApp" value="1; RequireReadOnly" />
                <add name="Cache-Control" value="no-cache, no-store, must-revalidate, max-age=0" />
                <add name="Expires" value="0" />
                <add name="Pragma" value="no-cache" />
      </customHeaders>

URL-rewrite

        <rewrite>
            <rewriteMaps>
                <rewriteMap name="*.js" />
            </rewriteMaps>
            <rules>
                <rule name="Plumsail" stopProcessing="true">
                    <match url="(.*)_layouts/15/Plumsail(.*).js(.*)" />
                    <action type="Redirect" url="{R:0}?PlumSailVersion=1.8.7" redirectType="Temporary" />
                    <conditions>
                        <add input="{QUERY_STRING}" pattern="PlumSailVersion" negate="true" />
                    </conditions>
                </rule>
            </rules>
        </rewrite>

But non of this works, browser still gets file from disk cache. So once the files is cached, we are stuck for 365 days....

I can't force the browser to reload the .js/.css files with

window.location.href = window.location.href

or

location.reload(true);

So we are really stuck here!
The only thing I can see right now is that in your code, the references made to .js/.css files contain a version, i.e.

<script src="myJavascript.js?version=1.8.7"></script>

or

<link href="mycss.css?version=1.8.7" rel="stylesheet">

and every time you provide an upgrade, you change the version number in the references. Of just always add a random string to the url-parameter.

Is this something that can be considered?

Kind regards,
Bart Plessers

Dear Bart,
That's a great idea, thank you for the feedback! I've talked to the dev team - we'll try adding this into the next major release.

1 Like

Hello all,

That would be a huge improvement!
But for now the only good solution is to first adjust the cache setting of the Plumsail folder in IIS to a shorter cache time, for example 1 day. Within a year we are sure that we can safley install the new 1.9 version.

But it would be great if someone could provide yet another solution that would allow us to upgrade faster.
Maybe the Plumsail dev team can release a version 1.9.1. with that extra parameter in the URL? We are certainly willing to test this in our environments.

Kind regards,

Johan

2 Likes

Dear @Johan,
It will take some time for the next major update to arrive, it's not scheduled yet, but when it does arrive - we do plan to include the extra parameters in the URL.

1 Like

Maybe you can consider a "minor" upgrade with only this change implemented? We really are eager to use the latest version, and a year waiting is a long period....

grtz
B

Dear @bartplessers,
Have you tried the solution described above by the @Johan?

Hi @Nikita_Kurguzov ,

Yes, I did.
But it is already too late for that: users that had already opened a form, have the plumsail files already in cache for a period of 365 days.
Settings on IIS will not propagate to client until cache expires…
Because a server side upgrade of plumsail interferes with the cached version at client side, we can not upgrade right now.
I can change the setting on IIS, but have to wait for a year until every client has made at least one new connection to the server.

So this is not a solution for now

Kind regards
Bart

Dear @bartplessers,
I'll ask the dev team what can be done at the moment - we'll research the question.

1 Like