I’ve packed up all things Sitecore related and moved to my new home at:

By now this blog should be off the main Sitecore RSS feed so this shouldn’t be a double post except for those of you who subscribe to my blog directly (thank you).

For now this will lay dormant but I might from time to time post non-Sitecore related musings.

As promised here is the recording of the Sitecore Performance Webinar:


Also since the resolution of the video isn’t high enough to see the code I’ve also included a Sitecore package containing all the code samples I used during the presentation which you can download here.

I really hope this is of use to everyone, feel free to post any questions or suggest additions that could have been made to the webinar.

Quick post, I’m going to be running a Webinar next month on how to get the most out of your Sitecore site in terms of performance and stability. You can reserve your spot here and if you’re not able to make it I’ll be recording it for download later.

It’s going to be a technical deep dive so if that’s not for you then feel free to forward the invite url to anyone who might be interested.

Fri, Jul 23, 2010 10:00 AM – 12:00 PM AEST


  • Technical Introduction – What should we be able to expect from Sitecore in terms of performance?
  • Divide and conquer – First steps, how to break down the problem.
  • Starting on a solid footing – Avoid “gut feelings”; get solid stats on how the site performs.
  • General improvements – What can we do outside of Sitecore?
  • Sitecore specific improvements – What can we change in Sitecore?
  • Content Entry – How can we speed up the Sitecore UI?
  • Next steps… – How to maintain performance improvements.

HTML is a bit of a tricky beast, for a long time you couldn’t make any changes at all without technical knowledge of how it works. Quickly enough people created HTML “editors” but until recently they’ve been well, frankly rubbish. Thankfully the one used it Sitecore ticks all the boxes; it has all the standard editing features you’d expect to see and behaves in a WYSIWYG fashion.

The only downside to this process however is that rich text editors still can’t replicate a web developer’s ability to produce HTML that is always compliant with XHTML standards, especially once all the features of the rich text editor have been enabled.

This presents a particular problem for projects caught between the conflicting requirements of 100% compliant XHTML websites while also allowing non-technical content editors to make changes using the fully featured Rich Text Editor. Here are 5 suggestions that will help you with both of these:

  1. Rich Text Editor Snippets – This feature in Sitecore allows you to insert prefabricated HTML templates that have already been validated for XHTML compliance. An example would be a div containing Lorem Ipsum text with a placeholder image floating to the right. Content editors can then insert this snippet into the RTE via a dropdown menu and then change the filler text and image to suit, the underlying HTML itself however will be unchanged. A good example of how this can be done can be found on learnsitecore.cmsuniverse.net.
  2. Sitecore WebStylesheet – Any CSS classes stored in this style sheet (default.css) will be available in the rich text editor via the “Apply CSS Class” dropdown menu. This allows editors to style their content according to a predefined style guide instead of using hardcoded inline styles. This also greatly reduces the amount of non-transitional compliant HTML generated as most of the invalid statements are regarding style related tags such as align=”left”. Additional details on configuring this feature can be found in the Client Configuration Cookbook on the Sitecore Developer Network.
  3. Automatic Workflow triaging of content – With a small amount of development a workflow action could be created that would automatically put items that fail validation into an “Awaiting Web Developer” state. From here someone with technical HTML knowledge could manually fix the errors and then move the item into the normal “Awaiting Approval” state. This way the content editors would no longer have to worry about HTML validation and items would only be escalated if special attention was required. I’ve gone ahead and created this in a previous blog post which you can find here.
  4. Customize the RTE Profile – Each rich text field is associated to a profile which defines which buttons are available (e.g. bullet points, bold, italic). I would recommend standardising this across the site and only removing those features which aren’t required. More information on configuring the RTE profiles can be found in the Client Configuration Cookbook on the Sitecore Developer Network.
  5. Reduce use of Rich Text fields – In many cases the problem can be avoided in its entirety by simply redesigning the page so it no longer needs the rich text field, you can achieve this by replacing it with a series of single and multi-line text fields. This has the added bonus of keeping content and presentation separate which allows for greater reuse and flexibility.

Good news everyone!

I’ve joined Sitecore as a Solution Architect in their Brisbane Australia office!

Things have been pretty hectic since I decided to jump ship for the other hemisphere which hopefully explains the lack of blog posts. Once everything is settled I’m sure I’ll get back into the swing of things.

I’ve been keen to work for Sitecore for a while now but why Brisbane? Below is a sample of what tempted me back to the the Antipodes:

I’ve been looking at the new Visual Studio 2010 beta and it looks like it’s going to make all sorts of improvements over VS2008.

One of the features I really like is the web.config transformations; this is exactly what I’ve been looking for in Sitecore installs. When you’re deploying Sitecore to a production server there is always a raft of settings that need changing, you can manually keep track of them or use features like configSource attributes but there always seems to be problems. In VS2010 however you can keep a set of transformation web.configs for your various deployments:


Part of the MSBuild deployment process is that it creates a new web.config with the changes you’ve specified in the transformation files. The files themselves contain the settings that need changing and details on how to match them within the original web.config:

<?xml version="1.0"?>
<!-- For more information on using web.config transformation visit http://go.microsoft.com/fwlink/?LinkId=125889 -->
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <connectionStrings configSource="App_Config\ConnectionStrings.Debug.config" xdt:Transform="Replace" />
  <sitecore database="SqlServer">
    <sc.variable name="dataFolder" value="E:\WebApplications\vs2010test\data" xdt:Transform="Replace" xdt:Locator="Match(name)"  />
      <site name="vs2010test_english" xdt:Transform="Replace" xdt:Locator="Match(name)" language="en" hostName="english.vs2010test.local" ...
      <site name="vs2010test_japanese" xdt:Transform="Replace" xdt:Locator="Match(name)" language="ja-JP" hostName="japanese.vs2010test.local" ...
      <site name="vs2010test_german" xdt:Transform="Replace" xdt:Locator="Match(name)" language="de-DE" hostName="german.vs2010test.local" ...
      <setting name="IndexFolder" xdt:Transform="Replace" xdt:Locator="Match(name)" value="E:\WebApplications\vs2010test\data\indexes" />
  </sitecore >
    <customErrors mode="RemoteOnly" xdt:Transform="Replace"/>

The important attribute is xdt:Transform=”Replace” which replaces the setting in the original web.config with the new one. This works fine when there is just a single node of that type such as <connectionStrings/>.

For nodes with multiple instances such as <site/> you can distinguish them using xdt:Locator=”Match(name)” which tells the transformer to match the element to the original using the name attribute.

Once all the changes are made you should end up with a new web.config that is configured for your deployment target machine. There is the added bonus that all of these transform files are stored in source control alongside the original web.config.

I’ve also been looking at the Team Development for Sitecore product from Hedgehog software (deserves own blog post), combined with this and I think my deployment issues will be solved. Hopefully :)

Bit of a mini-post, I saw a writeup on how to create new template types for Visual Studio so I went ahead and created one for the Sitecore XSLT Rendering files. Save the below file to your Visual Studio templates folder (Tools->Options->Projects & Solutions) and you’re done. When you next go to add an xslt file you can pick the Sitecore XSLT Rendering (which I got from the latest 6.2 release) listed under my templates.


If you wish to modify it you can just make changes to the xsl.xslt file in the zip file.

The File

Next Page »


Get every new post delivered to your Inbox.