I cannot stop being amazed at the number and weirdness of problems fixed in Internet Explorer 6 by the infamous Holly Hack.

I think I need to make a t-shirt, just out of honest appreciation:

Neil Pullinger created a Sitecore google co-op search that searches through 18 Sitecore related sites, which is definitely a nice thing to have in your troubleshooting arsenal.

For better or worse there are three distinct places you would dig Sitecore gems from: SDN5 search, the evergrowing SDN5 forum search, and all of the public blogs that you can use this custom google search for.

Update: Jukka-Pekka Keisala mentions another Sitecore blog search made as a netvibes portlet.

Our google analytics account has been upgraded to a newer version, as any data junkie I'm wondering around looking here and there. I must say it looks nice, has all the fancy sparklines, etc.

Some stats on browser usage (last week):

Internet Explorer: 70%
Firefox: 24%
Safari: 2.5%

Internet explorer versions:

IE 7.0: 57%
IE 6.0: 42%

<!-- HTML EDITOR LINE BREAK
Specifies the tag that the HTML editor inserts on Enter. Values can be
"br", "div" and "p".
-->
<setting name="HtmlEditor.LineBreak" value="br" />

HtmlEditor.LinkBreak is one of those settings you should know about. By default it's set to 'br', which means that every time editor presses Enter in Sitecore Content Editor, a '<br />' tag is inserted.

I think it's wrong - isn't the enter button supposed to start a new paragraph? Changing the setting to "p" gets you there. Shift+enter, on the other hand, does the line break - here goes the <br /> tag.

Here is the difference between two; first, the default br setting:

Paragraph 1 [click enter]
<br />
Paragraph 2 [click enter]
<br />
..

Changing it to p:

<p>Paragraph 1 [click enter]</p>
<p>Paragraph 2 [click enter]</p>

It is semantic html, it feels right and is easier to style, even if you're not concerned with standard compliance. I wonder if there is still a compelling reason to keep having <br /> as a default?

Most methods in XslHelper are virtual, so it's possible to tweak the output of sc:something() functions and <sc:something /> controls in XSL renderings. To change the behaviour of all renderings in Sitecore solution, modify the sc xsl extension registration in web.config:

<xslExtensions>
  <extension mode="on" type="Sitecore.Xml.Xsl.XslHelper, Sitecore.Kernel" namespace="http://www.sitecore.net/sc" singleInstance="true" />
  <extension mode="on" type="MyNamespace.MyClassDerivedFromXslHelper, MyAssembly" namespace="http://www.sitecore.net/sc" singleInstance="true" />

To use the derived extension selectively, just register it as a new xsl extension.

Note that it's a fairly crude hack probably involving some string manipulation, but as such it can also help when other methods fail.

Today's post shows how to add Default Layout to your Sitecore devices. This can be handy if you don't want to tediously update multiple templates / items just to configure the same layout for the new device over and over.

A good example of that is enabling RSS output for every item: it's natural to use a separate device/layout for that, but the layout is the same for all items in the solution. So instead of modifying templates and items, httpRequestBegin pipeline processor is used:

public class DefaultLayoutResolver
{
  private static readonly ID xmlLayoutID = ID.Parse("{8CF08867-5789-40CA-A0A4-01D059E50E11}");

  public void Process(HttpRequestArgs args)
  {
    if ((Context.Device != null) && (Context.Device.Name.ToLowerInvariant() == "xml") &&
     (Context.Item != null) && (Context.Item.Visualization.Layout == null))
    {
      LayoutItem layout = Context.Database.Items[xmlLayoutID];
      if (layout != null)
      {
        Context.Page.SetLayout(layout);
      }
    }
  }
}

Add the processor right after the standard Sitecore LayoutResolver processor, so that Sitecore configuration takes precedence.

The same code is reused in Printers Inc to output raw item XML. For more flexibility, you can add the "Default Layout" lookup field to a device template and modify the DefaultLayoutResolver to read that value.

Sitecore has two kinds of item XML representation, or flavors if you will.

Serializer XML is the heavyweight format, containing everything Sitecore needs to know to get the item from one solution and paste into other: all attributes, field values in all versions and languages. It is used by the packager.

To get serializer xml programmatically:

item.GetOuterXml(deep);

XSLT XML is the internal interpretation that is fed to XSL renderings (tranformations). This is the lightweight brother, containing only item attributes and field ids. No field values, only the current version and language. You would want to know how it looks like if you code XSL renderings.

To get XSLT xml programmatically:

ItemNavigator navigator = Factory.CreateItemNavigator(rootItem);
writer.Write(navigator.OuterXml);

In the next (3.0.13, soon to be released) version of demo site, we have added the option to output item XML in both flavors to demonstrate what it feels like:

http://<demositeurl>/?xml=    => Serializer XML flavor of the current item (no children)
http://<demositeurl>/?xml=&deep=true    => Serializer XML flavor of the current item and all descendants
http://<demositeurl>/?xml=&xslt=true    => XSLT XML flavor of the current item and all descendants (always 'deep')

Thanks to John West for the idea.

Dmitry, Yan and I are in Copenhagen April 16-20; looking forward to that.

I'll probably be the last one to point out that the Sitecore 5.3.1 is out: check out Peter's series of posts on new features. What I can add is that our www.sitecore.net is also updated from the Sitecore 5.2 it was originally built on, the media content is moved to the database, all of the fancy stuff.

The migration went fairly painful, although I must admit it does help to have the mastermind of the whole migration framework sitting nearby. Thanks Sergey!

If your site can be run in disconnected mode (like our printers demosite during some demonstrations), google analytics javascript errors can be annoying. Here's how to avoid them:

if (typeof(urchinTracker) != "undefined") {
  urchinTracker();
}

This way it works just fine in connected mode, and quietly fails when internet connection is not available.