Archive

Archive for March, 2010

SharePoint cache settings when restyling

When restyling web applications, you have to think of the cache settings which are set to the different resource files, since you want people to see the new styles without having to clear their local cache. These files for example can be:

  • Style Sheets
  • Images
  • Java Scripts

If we for example open a normal team site and open up Fiddler, we will see how long the files are cached (you might want to first clear your cache or use a hard refresh to force all files to download).


Figure 1: Default Team Site


Figure 2: Fiddler trace of the loading of the default Team Site

When you look at the Fiddler trace, you can see the following cache settings:

  • The aspx file is not cached.
  • The Java Scripts are cached for a year.
  • The style sheets are cached for a year.
  • The images are cached for a year.

The reason for this is that the newly created web site, the content expiration is not enabled for the web site itself, but it is enabled for the four virtual directories:

  1. _controltemplates
  2. _layouts
  3. _vti_bin
  4. _wpresources

For the virtual directories the default setting is to enable content expiration for 365 days.


Figure 3: By default the settings for the Web Site is to not use content expiration


Figure 4: The default setting for the _layouts folder is to use content expiration for 365 days

These default cache settings can be updated, but otherwise this means: You can NOT simply update your resources in the _layouts folder and expect your users to see the update immediately!

Possible solutions

To overcome the caching problems, there are multiple solutions. For example:

  1. Use new filenames
  2. Use new directory
  3. Use a query string

Use new filenames

The first possible solution is to simply rename all the files you are changing during the restyling of SharePoint. This will allow you to bypass the client side cache. You will however need to:

  1. Rename all the files you store in the _layouts folder which have changed.
  2. Find and update all the filenames you refer to inside your Java Scripts, if they are stored in the _layouts folder.
  3. Find and update all the filenames (f.e. images) you refer to inside your Style Sheets, if they are stored in the _layouts folder.
  4. Find and update all the filenames you refer to inside your code, if they are stored in the _layouts folder.
  5. Find and update all the filenames you refer to inside your master pages, if they are stored in the _layouts folder.
  6. Find and update all the filenames you refer to inside your pages, if they are stored in the _layouts folder.
  7. Find and update all the filenames you refer to inside your control templates, if they are stored in the _layouts folder.
  8. Etc.

The downside here is you have to search for every file individually, which can be time consuming and error prone.

Use new directories

When storing your own files in the _layouts folder, a best practice is to use your own subfolders. An option would be to rename all your subfolders in the _layouts folder. That would bypass the client side cache. For this you will need to:

  1. Rename all the directories you store in the _layouts folder
  2. Find and update all the filenames you refer to inside your Java Scripts, if they are stored in the _layouts folder
  3. Find and update all the filenames (f.e. images) you refer to inside your Style Sheets, if they are stored in the _layouts folder
  4. Find and update all the filenames you refer to inside your code, if they are stored in the _layouts folder.
  5. Find and update all the filenames you refer to inside your master pages, if they are stored in the _layouts folder.
  6. Find and update all the filenames you refer to inside your pages, if they are stored in the _layouts folder.
  7. Find and update all the filenames you refer to inside your control templates, if they are stored in the _layouts folder.
  8. Etc.

This method is easier than the one above (using new file names), since you can do a find/replace on your solutions and just replace the directory name. You will however need to update the directory naming and probably the relevant documentation.

Use a query string

Another option is to use a query string after the resource files you are using. This is actually how SharePoint internally solves the issue as well:

 
Figure 5: Page source of default Team Site

Within SharePoint you can let the query string “?rev=xxxxxxxxxxxxxx” be generated automatically by using the SPUtility.MakeBrowserCacheSafeLayoutsUrl. This function will place “_layouts/” before and “?rev=[some string here]” after a given string. This however is a server side action which would in turn be triggered for every resource you use. This is a load on the system which can be avoided. Another downside of this function is that it will only work for files stored in the layouts folder on the file system. This means it will not work for the images folder. Besides that, this might work in your code files, master pages and aspx pages, but you’ll have to jump through a couple of hoops to get this working in style sheets and java scripts!

What we in turn did was placing a string like “?rev=201003221230” after all loaded resources. The number is actually a timestamp from when we started on the change. This means you’ll have to:  

  1. Find and update all the filenames you refer to inside your Java Scripts, if they are stored in the _layouts folder
  2. Find and update all the filenames (f.e. images) you refer to inside your Style Sheets, if they are stored in the _layouts folder
  3. Find and update all the filenames you refer to inside your code, if they are stored in the _layouts folder.
  4. Find and update all the filenames you refer to inside your master pages, if they are stored in the _layouts folder.
  5. Find and update all the filenames you refer to inside your pages, if they are stored in the _layouts folder.
  6. Find and update all the filenames you refer to inside your control templates, if they are stored in the _layouts folder.
  7. Etc.

But the benefits are:

  1. With a next rebranding you can easily do a replace all on the string “?rev=201003221230” on your solution.
  2. You don’t have to keep track of which files you actually modified.
  3. No additional actions on the server are needed.
  4. It works for every file type.
Advertisements
Ben Prins

What I want to remember about SharePoint

blog.frederique.harmsze.nl

my world of work and user experiences

Bram de Jager - Coder, Speaker, Author

Office 365, SharePoint and Azure