jquery.jsonp addresses issues with beforeSend and timeout

On the coat-tails of my previous post, I've come across the Google Code jquery-jsonp library and it's a saviour if you're working JSONP requests. Remember a JSONP request dynamically inserts a script tag into the DOM and doesn't use the same XMLHttpRequest as your typical AJAX request.

I ended up here because—much like beforeSend—the timeout parameter wasn't having any effect on my jsonp request: the request simply wouldn't time out despite the value supplied to this parameter.

In addition to supporting both beforeSend and timeout properties, jquery-jsonp adds some really nice caching support—both typical HTTP (aka "browser") caching and page-based caching that leverages the JavaScript VM's memory (apparently). Anyway it seems to work as advertised. Perhaps most importantly, the name of the callback can be changed.

A minified version of the code is available from Google Code and the documentation is concise and well-written with examples. 

Disable the Output Cache Programmatically with PowerShell

Restoring a content database from a production environment to a development machine for dev purposes can sometimes get a little bit interesting.

Our production environments generally have output caching enabled for performance reasons(see /_Layouts/sitecachesettings.aspx in your own environment) but developing or troubleshooting an issue in dev normally requires output caching be disabled to you can view the results of your work. Of course the output cache settings are stored within the site collection so using a production backup will normally bring the output cache setting along with everything else.

Of course you can manually disable output caching but that means remembering to do so. As our attach process is scripted in a batch file for repeatability and automation purposes, I recently added a step to disable the output cache programmatically. To do this, I wrote a little PowerShell script and call it from the batch file:

Param($Url)

write-host "User must be a site collection administrator or have full control within web application policy!"

[System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SharePoint”)
[System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SharePoint.Publishing”)

$cacheSettings = new-object Microsoft.SharePoint.Publishing.SiteCacheSettingsWriter($Url);
$cacheSettings.EnableCache = $false;

$cacheSettings.Update();

The script takes a single named parameter (Url) which specifies the site collection URL. As you can see, I'm working with the SiteCacheSettingsWriter class to set the EnableCache property to false before sending through an Update() command; of course the same thing can easily be accomplished in C#.

I call the script like so from my batch script:

powershell "& ./DisableOutputCache.ps1 -Url http://dev-moss"

I've parameterised this script since I restore content databases from multiple sites and didn't want the URL hard-coded.

As per my note, the account used to execute this script must be a site collection owner or have rights configured the web application policy or you'll encounter an access denied error.

 

westernaustralia.com Relaunch and Other Website Recent Activities

If you’ve been following the progress of the westernaustralia.com website over the years, you’ll already know the site was one of the first in Australia to be launched on the MOSS 2007 platform and has been consistently voted as one of the top fully branded SharePoint sites in the world ever since. Having worked on the site since the get-go and as the current technical lead for the project, I’m the proud owner of the site’s programmatic aspects; today I’m tickled pink to tell you, the SharePoint community, about yesterday’s launch of the new Tourism Western Australia brand, Experience Extraordinary, and, more specifically, the brand’s impact on the westernaustralia.com website.

At the moment we’re working with the Digital Marketing team on a two (or three phase) approach (depending on how you look at it) to implement the new brand. The first phase unfolded in August last year and involved the neutralisation of the preceding brand’s elements (The Real Thing) while the latest creative design agency, Host, was appointed. Phase 1 of the new brand implementation kicked off in the dev team a little over three weeks back and involved making the Photoshop mockups provided by Host into a living website. This work focused largely on the page banners (vibrant imagery, the tab, and extra height), the navigation, the background colour (trust me—everything is more complicated than you might think at first glance with wa.com!), what we call the ePostcards element, and the footer elements.

Here’s a picture of what I think is a visually stunning website and a vast improvement over its predecessor:

Phase 2 holds still more secrets but you can bet we’ll be making all the middle bits fit with the rest of the changes. One of the challenges we’ll be facing is getting the home page weight down from a whopping 1750KB and 100 requests. Stunning, certainly, but our CDN of choice (Akamai) allows us to get away with this sort of monkey business.

In addition to all the glam, we also took the opportunity to overhaul the heading infrastructure. This subsystem is designed to give content editors the ability to upload new banner images and all of the corresponding display data required to render the Flash banner. The Flash banner itself was built by Host from our previous banner and it takes as a parameter an XML file providing all the information it needs to display the banner images, text, links, and colours.

Obviously this data is stored in a list to which the FlashBanner.cs web part communicates at render time. Like I say, nothing in wa.com is as it first appears and one of the more complex requirements was allowing a subsite to override the banners displayed for for it and its children (in effect to support the major subsections of the site such as the destinations). Apart from simply walking up the site hierarchy recursively until a banner list is found, we then needed interrogate the list and emit an XML file acceptable to the banner; the URL to the file is finally cached with a dependency on the file itself.

Interestingly, this was one of the first times we started using event receivers on the banner lists to invalidate the cache when a banner is added, edited, or deleted; this keeps the content editors happy and productive and is one less of those annoying “is my banner cached in the browser cache | Akamai | reverse proxy| application cache | output cache | blob cache?” questions ;)

I’ll also point out we’re using a simple custom list for this instead of a picture library or custom list derived from a picture library. The previous version of this list was in fact a custom picture library but it suffered from broken thumbnails (which we now know how to fix) and proved rather cumbersome to use in practice (no reordering, a difficult view, etc). The move away from the picture library wasn’t, in retrospect, necessarily a great decision but it was probably the best decision at the time and came with considerable deliberation. The one major problem with the current approach is banner images must be uploaded separately to a real picture library and then referenced from the list; this is a bit of a double-up and disconnects the image itself from its metadata. As our understanding of list development and the peculiarities of these other list types increases, we may revisit this approach.

Also at a technical level, we recently move the site from our old IBM BladeCenter kit running Windows Server 2003 x86, MOSS 2007 SP1 (not even the Infrastructure Updates—gasp!), .NET 3.0, and a non-clustered SQL Server 2005 x86 database server. Everything was virtualised on ESX 4.0. We actually had three of these farms: one in prod, one in DR, and one for authoring; as content deployment never worked for the site, this meant a daily backup and restore of the content database from authoring to production and corresponding switch to or from DR (with DR actually being treated as a standby prod environment). That must have really sucked for our admin who had did that essentially manual task every business day since launch in May 2007. What. A. Drag.

From that setup, we moved to what was briefly the bees knees: Windows Server 2008 x64, MOSS 2007 SP2 + June 2009 CU, .NET 3.5 SP1, and a clustered SQL Server 2008 x64 database environment. Everything is still virtualised on ESX 4.0 and the entire setup is mirrored in DR. We’ve finally done away with the authoring farm so content editors are editing content in the production farm (we’re working towards a tiered security design and approval workflows, by the way, but our content editors have been working with the environment for years now and are mature in their understanding of how not to break the site ;). So no more daily content deployments and those of us in the dev team can finally start working with .NET 3.5 and LINQ.

For more on how we run the site, check out my Perth SharePoint User Group presentations and videos (things have changed but not that much):

http://blog.mediawhole.com/2009/02/how-we-do-wcm-at-tourism-wa-im-speaking.html

http://blog.mediawhole.com/2009/03/presenting-at-next-sharepoint-user.html

If you’ve read this far, you deserve the chance to win a prize. Want the opportunity to take an extraordinary taxi ride around the state of Western Australia? If so, check out the “brand activation” microsite: http://www.extraordinarytaxiride.com.au/

Note: I am employed by Tourism WA as a contractor working for Diversus. Mediawhole, mediawhole.com, and this blog are not associated directly with Tourism Western Australia or the westernaustralia.com website. The information provided above  is published independently as a member of the public and does not reflect the views of Tourism Western Australia or Diversus. Please consult a Tourism WA representative for more information about its brand, campaigns, and websites.

Flushing the Blob Cache

Sean McDonough has a really comprehensive post on several options for flushing the MOSS 2007 blob cache. Worth a read if you’re in need:

http://sharepointinterface.com/2009/10/30/manually-clearing-the-moss-2007-blob-cache/

Clear the Flash Cache aka Local Storage

You’re probably used to the idea of session state and cookies and how to clear them using you’re favourite toolbar. Did you know the Flash plug-in also has its own client-side cache called Local Storage? Just like any other cache, stuff will occasionally get stuck in Local Storage and you may need to clear it out.

You can control your local storage settings by right-click->Settings… on any Flash movie but as far as I know you can’t clear cached data using this approach. To comprehensively clear the Local Storage cache I use this web-based tool provided by Adobe:

http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager07.html 

Make 'Exires' Go Away

Yesterday I posted about the useless 'Exires' [sic] header moss emits with content served from the content database under the default configuration. "Shame on you MOSS!" was shouted with just cause.

Nevertheless, I've found a fairly easy way to make 'Exires' go away and configure MOSS to emit better cache headers. It's pretty simple and while it will cost you a bit of disk space it should also save on roundtrips to the database server... all you need to do is enable the MOSS BLOB cache (aka Disk Cache).

The BLOB cache is turned off by default (for some reason) but when enabled it'll grab a copy of content database resources on the first request and cache them on disk for faster access down the road. Not only that, but, despite the name, the BLOB cache makes MOSS smart enough to emit good Cache-Control headers with your content.

The BLOB cache is configured through the web.config at the web application level, which leads me to believe you won't be able to set different max-age values for different types of content or different content groupings (let's say you want your .css and .js files cached with a different max-age value--or none at all--from the served with your images). If you're used to doing this with the content expiration mechanism in IIS at the folder or item level you may be out of luck here.

Enabling the BLOB Cache is ridiculously easy. Dig into your site's web config and find the BlobCache element (you'll need to do this on all related sites--i.e. anonymous and authenticated if you're running both on the same server). Set the enabled attribute to "true" and you're set. You may additionally want to modify the location where MOSS stores the BLOB data (i.e. a non-system disk), add extra file types to those already configured, and add a max-age="3600" attribute. The max-age attribute will be included with the Cache-Control header and is defined in seconds. Be careful with this one because if you set it to too large a value, your content will cached for the entire duration unless users clear their browser caches. Finally, the maxSize attribute defines the maximum size of the BLOB cache in gigabytes.

<BlobCache location="D:\MOSS\Cache\Consumer" path="\.(gifjpgpngswfcssjs)$" maxSize="1" max-age="3600" enabled="true" />

MOSS instruments the BLOB cache using performance counters you can access in Performance Monitor to determine cache health, turnover, etc.

If you get the BLOB cache working you should also consider reviewing the MOSS Output Cache. I'll save the details for another post but this cache extends ASP.NET output caching and deals solely with page content.

MOSS 'Exires' Header

Dear Microsoft,

What is an "Exires" header? I know what an "ExPires" header is but I have a feeling none of us (not even IE) know what to do with Exires.

Sometimes you've really got to wonder whether MOSS went through any form of QA whatsoever (and our system administrator often asks that exact question). Below is a set of typical HTTP response headers for a file requested from MOSS.

HTTP/1.1 200 OKConnection: Keep-Alive
Content-Length: 453
Date: Mon, 05 May 2008 04:44:34 GMT
Content-Type: image/gif
ETag: "{E4BBF3CA-94E3-44CB-A5CF-DD38E3330E11},3"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 12.0.0.6219
Last-Modified: Wed, 19 Dec 2007 05:52:22 GMT
ResourceTag: rt:E4BBF3CA-94E3-44CB-A5CF-DD38E3330E11@00000000003
Exires: Sun, 20 Apr 2008 04:44:34 GMT
Cache-Control: private,max-age=0
Public-Extension: http://schemas.microsoft.com/repl-2

Note the useless Exires header. Without the extra 'p' this header is going to float right through any caches and will be ignored by the user agent. Not only that, but Exires is pumped out with most MOSS-based resource--that is any resource delivered from the MOSS content database (images, CSS, etc) excluding pages. Due to their size, images are great candidates for caching; likewise for the number of smaller files, like CSS and JavaScript, that otherwise clog up your page load times.