JavaScript files not Updating in Site Assets or other SharePoint Libraries

So ran into a very weird issue.  I had just finished patching our Dev and Test servers to the November 2017 CU.  And after this occurred, any updates to solutions using JavaScript injection was not working.  I’ll describe the problem in more detail here right away, but I want to make sure I give a call out to Trevor Seward.  Trevor blogs from The SharePoint Farm and kudos goes to him for pointing me at the Blob Cache (but I am getting ahead of myself).

The Problem

I just finished patching some Dev and Test servers to Nov2017CU (SharePoint 2013).  Since then, any solutions that were using JS injection from Site Assets were not updating. I’d make a change to the file, the library reflects that I made the change, but when I attempted to load the page accessing the js file, the changes were not reflected.  Hard refreshes and full cache cleans were not affecting it.  If I closed and reopened my editor (VSCode) my changes were gone. When I looked at the version history, the current version didn’t have my changes, but the previous version did. If I tried to revert to that version, it didn’t take (still showed the previous version of the file).

Then things got really weird. I deleted the entire file from the library and reset IIS (heck, I even rebooted the server at one time). It somehow still loaded the file. The file is no longer in the library, but the server is still serving it up to the browser. I confirmed it is not getting the file from another location as the Dev tools are showing the file is located in the Asset Library the file was deleted from.  Even users who have never accessed the site before were still getting that file in their browser.

The Cause

So I put out the call for help to a couple of forums and Trevor responded.  Asked if we had the blob cache enabled.  What is the blob cache you ask?  Good question.  In a nutshell, the blob cache is SharePoint’s way of saving calls to the database (slow) and instead putting the files on the server’s file system (fast).  So files that are large or called often can be stored there for faster response to users.  You can read more on the blob cache here.  So getting back to the problem at hand, if you don’t know for sure if you have blob cache enabled or not, you need to check the web.config of your SharePoint web application.  Once you have opened it up, do a search for “BlobCache location”.  This will take you to the entry for the blob cache:

Scroll all the way over to check the enabled property

To confirm this was the issue I went into the blob cache location and found the site I was looking for (note, the site collections are by guid so you will have to go digging).  Sure enough, when I found the location my files were saved in, there was the file I had deleted from SharePoint.  Because this was here, even though the site no longer contained the file, it was still being served from the file system.

BTW: The SharePoint patching might have caused this or it could have been just a coincidence, but the root problem was the blob cache.

The Resolution

So SharePoint allows you to flush the blob cache.  In SharePoint 2010 you could do it from the site collection or using stsadm.  Instructions can be found here.  However, for SharePoint 2013 and 2016 you are going to have to use PowerShell.  The commands you want are:

$spWebApp = Get-SPWebApplication <Web APP URL>
[Microsoft.SharePoint.Publishing.PublishingCache]::FlushBlobCache($spWebApp)

There is no need to reset IIS for this.  The change is immediate.  Another thing, is don’t get concerned if you still see the files on the file system.  They don’t get deleted.  The cache once cleared just means that SharePoint won’t look there and hopefully once it starts looking there again, will store the updated versions of your files and not get stuck at the old version like it did in this case.

The Resolution Part 2

Planning ahead you may wish to look at adding query strings to the URL of your script tag.  For example:

<script type="text/javascript" src="javascriptfile.js?version=1.0.1" />

Each time you update the file it forces the client to go looking for a newer version of the file.  So if you update and change the tag to version=1.0.2, your browser is going to say, well I only have 1.0.1 so I need to ask for a newer version.  In theory this will allow it to get the latest version.  Thanks to Chris Romp and Gautam Sheth for more information on this.

A downside to this though is that you could end up with multiple versions of the JavaScript file in your browser cache until it is cleared.

 

Again, big thanks to Trevor for the assist.

 

Thanks for reading!!