On having layout is a mind saving in-depth article discussing internals of Internet Explorer rendering engine, why and how do the hacks work and so on.

I've just fixed a really weird Internet Explorer 7 bug (absolutely positoned element randomly jumping inside relatively positioned one) - it was unstable enough to hide until the finishing stages of the site development. Here's what saved my day:

As a rule of thumb, never position an element relatively without setting layout.

[..]

When possible, try to stick to cases where the containing block has layout and it is the parent of the a.p. [absolutely positioned] element (i.e. there aren't other ancestors in between the a.p. and the containing block).

So its Holly hack to the rescue again. And no, it didn't become obsolete with IE7.

Continuing on the settings you might want to know about, lets talk about the WebStylesheet:

<!-- WEB SITE STYLESHEET
CSS file for HTML content of Sitecore database.
The file pointed to by WebStylesheet setting is automatically included in Html and Rich Text fields.
By using it, you can make the content of HTML fields look the same as the actual Web Site
-->
<setting name="WebStylesheet" value="default.css" />

Having the preview mode is great, but it's better if rich text editor looks as close as possible to what visitors see on the live website.

For a quick fix, try pointing WebStylesheet to your main css file and see how it looks like. Depending on the styles, it might or might not be all you need to do. Sometimes styles depend on specific containers in html that are not there inside rich text editor: then you can create a simplified stylesheet that only includes styling for the basic elements such as eadings, paragraphs and some custom classes that your editors use.

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.