Added web 2.0'ish license agreement popups on SDN5: try any paid product download, like the Sitecore itself (SDN and download access required). It's not intended to hide actual download location, and in fact is unobtrusive.

Done with modalbox, which worked out well. The only issue we've spotted so far is that the page is moving underneath the modal overlay because scrollbar disapears in IE. Let me know if you see anything else.

[A classic "look what I've done post"]

If you're lucky to have IIS6 serving your site, turning on the HTTP compression is a really easy way to decrease page loading times and cut bandwith. With compression enabled, web server can zip static and dynamic content before sending it over the wire. For this to happen the receiving side has to support compression too, as do all modern browsers.

There are two types of compression: static is essentially free. IIS will compress files on first request and store them on disk for future use, for minimal performance overhead. This works best for javascript and stylesheets. Dynamic compression allows .aspx output compressing; it's done on the fly and does add some CPU load. If processor isn't your bottleneck, enabling it is still a good idea.

For both types you need to define which file types should be compressed because the defaults are really lame: no css and no javascript.

On the new www.sitecore.net I've started with total frontpage load being 260kb and combining both compression types decreased it to 142kb. My favorite part is that prototype and scriptaculous (effects module only) javascript frameworks are 27kb total - at this point I refuse to take "prototype is too big" argument into consideration.

Useful links:

• Enabling HTTP compression walkthrough (and another one from microsoft)
• Web based checker - handy to see if compression is working and how much you're saving.

With the website launch I've been in invisible mode recently - here's a small comments catch up.

Danjal Johan - "What happened to Lucene?"
Why isnt there any documentation\ no walkthrow\ nothing - regarding setting up the Lausane Search with Sitecore...
I been searching sitecore yahoo.groups and sdn5.sitecore.net.... its like no one wants to talk about Lucene - Did Lucene commit a crime - why is "she" the black sheep of the Sitecore familly???...

Danjal, Lucene article is in the works as I write this, hopefully it will fill some gaps in this area.

Robert Huynh - "HTML Editor line break":
This is great commentary and information. I ran into this problem while training our content editors on how to use the editor. I agree with you on this issue, thus, will make the change to our new Sitecore installation to default to a paragraph instead of a break tag. Thanks!

Robert - thanks for the feedback, I'm happy that it helped you buiding a better site with Sitecore.

Comments RSS feed.

Less than a year from the last update, we've flipped the switch on the new public website this weekend. I hope you like it and find it better than the old one.

While it's not a total overhaul, I think it ended up being a major change. What I like about it is increased friendliness - more whitespace, text is easier to read and navigation is improved.

Some technical facts: the site is running on Sitecore 5.3.1 rev.070515 in a live mode. We use a simple two step "editing - published" workflow instead of publishing to control item visibility.

Your comments and criticism are very welcome, especially since I'm lucky to have people much more experienced in building websites reading this blog.

We've talked about setting the device programmatically and when it can be handy. Another trick that goes in the same category is layout substitution. Say we're building a mobile version of the web site and we want exactly the same set of sublayouts and renderings as in the desktop version, but placed on a different layout so that renderings can be rearranged freely using the placeholders.

Similar to the device resolver, we build a custom layout resolver processor to customize Sitecore's httpRequestBegin pipeline with out logic. The flow here is simple: if visitor uses handheld device, switch to a predefined layout. 

public class LayoutResolver
{ 
  if (IsMobileRequest())
  {
    using (new SecurityDisabler())
    {
      LayoutItem mobileLayout = Context.Database.GetItem(ID.Parse("{C10DBF03-F810-40A9-8ACB-5354428CC6BF}"));
      if (mobileLayout != null)
      {
        Tracer.Info("Overriding layout to mobile layout");

        // Change the layout to mobile layout  
        Context.Page.FilePath = mobileLayout.FilePath;
      }
      else
      {
        // writes error to Sitecore trace, visible in debug mode      

        Tracer.Error("Mobile layout not found");
      }

    }
  }
}

Make sure to place your layout resolver after the standard one, so that you override Sitecore's choice of layout and not vice versa:

<processor type="Sitecore.Pipelines.HttpRequest.LayoutResolver, Sitecore.Kernel" />
<!-- Sets mobile layout for requests from mobile devices -->
<processor type="Sitecore.Website.Pipelines.LayoutResolver, Sitecore.Website" />

Set up a naming convention for common fields and follow it. If the item has a title field, name the field "title" - no need to get creative here.

By coming up with something smart like "office title", or "news-headline" you're dooming yourself (or worse - someone else) to write boring and totally unnecessary code:

<xsl:choose>
  <xsl:when test="sc:fld('office title', .)">
    <xsl:value-of select="sc:fld('office title')" />
  </xsl:when>
  <xsl:otherwise>
    <xsl:value-of select="sc:fld('title')" />
  </xsl:otherwise>
</xsl:choose> 

etc..

• if you want editors to see a different field in the content editor, use the template field title, but make the internal field name follow the convention.
• consider avoiding duplicate fields altogether by using template inheritance.

I'm off for the next week to enjoy the beautiful city of Prague. To contact me, mail at alexey at alexeyrusakov dot com or +380 66 116 27 30.

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: