Archive

Archive for the ‘Styling’ Category

Display templates not reflecting ALL changes

April 10, 2014 4 comments

Lately I’ve been working a lot with custom display templates and custom refiners. This worked all pretty well, I could update the look and feel by changing the body without any problem. However, when I made changes in the head section of the display template, this didn’t seem to reflect my changes… And there you update your Managed Properties and in my case I also added some logic to retrieve some variables.

Using the debugger of Internet Explorer I saw the old version of the Javascript files were still used for the display templates. Somehow these where cached… The URL of my display template ended with ?ctag=122$$15.0.4481.1005. Well this number of course can change, but somewhere the old version was still in the SharePoint cache. This led me to look at my Result Types, since my display templates are used based on those…

On the top of the page I found the following message:

PropertySyncNeeded

Just click the Update link and you will get the following message:

PropertySyncDone

Refresh your search result page and the latest version of your display template will be used!

Advertisements

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