When you run your site in a live mode, you can still have the publishing restictions such as publish dates for items, do not publish flag and lifetime for versions to remain in effect. All you need to do is to find your site in <sites> section of web.config file, and add filterItems="true" to it.

The attribute is actually described in inline help above the sites section, but its often missed. Turning it on makes running some sites in live mode much more feasible. The catch that still remains (for live mode) is that if you use html cache, it will not be cleared because there's no publishing event to trigger that.

When converting a non-trivial Sitecore 4 solution to V5, consider switching off the search indexes in Sitecore. It should help to speed up the process quite a bit.

update: removing item:save event handlers might also save you some time:

<event name="item:saved">
  <handler type="Sitecore.Links.ItemEventHandler, Sitecore.Kernel" method="OnItemSaved"/>
  <handler type="Sitecore.Tasks.ItemEventHandler, Sitecore.Kernel" method="OnItemSaved"/>
  <handler type="Sitecore.Globalization.ItemEventHandler, Sitecore.Kernel" method="OnItemSaved"/>
  <handler type="Sitecore.Data.Indexing.ItemEventHandler, Sitecore.Kernel" method="OnItemSaved"/>
</event>

although out of these standard four, the first one is more likely to produce some impact, if you've already switched off indexing.

Unless you are running conversion on top of already existing items in V5 database, there's no need to look into item deletion. Saving an item, on the other hand, happens quite a few times.

Once you feel that you're getting close to the desired result, you can use Control Panel in Sitecore to rebuild link database and search indexes, to restore the standard functionality.

Since I don't have much to do in evenings, I'm having a great time reading "Getting Real" by 37Signals .. I think V5 is a fairly large product, but just like with less is better, you can stay small in big.

And speaking of getting real, SPN site has finally had a facelift this morning. Now I just need (apart from keeping my fingers crossed) to stretch SDN5 to be just as wide - I have no idea why we haven't done that before.

I think its quite common for various pieces of code in Sitecore to climb the item hierarchy up, seeking some inherited wisdom. A less common scenario, however, is to have a parent which is less visible than its child.

home
|
--news
   |
   --news item

(please bear with my advanced graph engine)

Imagine that you're not allowed to see the news section, but individual news items are just fine - either by mistake, or deliberately. So what happens if you have a code that goes up the tree ? (think breadcrumb)

Item item = this;
while (item != null)
{
   Collect(item.Fields["Menu Title"].Value);
   item = item.Parent;
}

You'll start with news item, which is fine. Then you go up to the news section, trying to read its field.. and get an exception, with a pretty clear message. That item that you don't have access to is considered to be "BrowseOnly", and reading fields of browse only items is bad.

To avoid seeing that exception in future, you need to add a guard clause looking for item.RuntimeSettings.BrowseOnly.

Hopefully this one stops biting me now.

It's a busy week, so I've been unresponsive a bit. Thanks everyone for the feedback, if you have more - throw that in. And just in case - I'll be in Copenhagen for the following 4 weeks, we can negotiate a price of SDN5/SPN/sitecore.net features you've always wanted.. Scrolling status bar anyone?

Thanks to staying at home with cold I had a chance to add a couple of new features to sdn5. I've also added a 'beta mode' so that they can be tested first. To enable the beta, just go to the http://sdn5.sitecore.net/?sdn5beta= - it will set the beta cookie and thats basically it. You can click 'back to normal' any time, but I'd appreciate if you also let me know whats wrong.

To the features:

It seems that web application project creates blank *.designer.cs files in total silence if you forget to reference assembly with the controls you have on the page. I've run into that while moving sdn5 msvs project into web application and forgetting to reference Sitecore.Webcontrols.

Previously:
* MSVS Web Application Project refresh
* All hail the web application projects

After another unfortunate accident at sdn, I had a strong desire to have at least a couple of simple tests to check that the sites are online and people can log in. With so many infrastructure changes it would hopefully help to reduce human element errors. Having the dense day schedule, it had to became a 'Thursday Night' project (thursay because I though of it at thursday and coudn't sleep until I try it)

Thanks to Scott Hanselman's blog, WATIR was the first thing that popped into my mind. WATIR stands for Web Application Testing in Ruby, and Ruby is being praised by its followers for elegance and joy most of all.

Cutting the long story short (it's actually a short story thanks to ruby) it worked out pretty well, and in a few hours I had tests that would check that

1. The homepage can be loaded and doesn't redirect anywhere else
2. It is possible to log in

WATIR uses Internet Explorer automation, so it will only work with IE available. Obviously it's not the tool of choice to have thorough UI tests, ensuring that everything works as it should in all browsers. However in my case, I think it does a great job with minimum effort.

[ruby source code]

Assuming that you have Ruby and Watir installed, you need to unzip it somewhere and start either cocrete tests (sdn5.rb, sdn4.rb..) or a complete suite (sdnSuite.rb). Double click the file and you should see IE window having its own life. Here's how the sdn5 test case looks like:

require 'Watir'
require 'SdnBase'
require 'test/unit'

class Sdn5 < SdnBase
   def setup
      super
      @homepage = "http://sdn5.sitecore.net/"
   end
 
   def test_homepage
      assert_homepage(/welcome/i)
   end
  
   def test_login
      go_homepage
      @browser.text_field(:id, /username/i).set(@username)
      @browser.text_field(:id, /password/i).set(@password)
      @browser.button(:name, /loginbutton/i).click
      assert(@browser.contains_text(/welcome ar@sitecore.net/i), "failed to log in")
   end
 end

Note that login tests will fail because I've removed my password in SdnBase.

Here's what will get you started:
1. Install Ruby for Windows. The simpliest way is Ruby one click installer
2. Install WATIR [http://wtr.rubyforge.org/]. Again, there's a windows installer available
3. Read WATIR user guide for starting steps
4. A great companion to WATIR would be either Firefox DOM explorer or IE web developer toolbar
[5]. If you want to get serious, Scott Hanselman has an NUnit-Watir integration guide

Another interesting thing to look at is Selenium:

"Selenium uses JavaScript and Iframes to embed a test automation engine in your browser. This technique should work with any JavaScript-enabled browser."

It supports xpath to access DOM elements, which is nice and familiar to Sitecore developers. I think it might even be reasonable to make Sitecore shell tests with something like that. It would definitely involve a combined effort, but might be worth looking at.

Html Agility Pack is shipped with Sitecore for a while, but now I actually needed something to process html fields. When you see a new API an API you haven't used before, write some code against it without looking into any reference (because the names are descriptive and/or somehow familiar) and it works the first time - doesn't it gives a kind of pleasant warm feeling inside?

HtmlField html = (HtmlField)item.Fields["text"];
foreach (HtmlNode node in html.SelectNodes("//img[@src]"))
{
  if (!string.IsNullOrEmpty(node.Attributes["src"].Value))
  {
    node.Attributes["src"].Value = ReplaceText(node.Attributes["src"].Value);
  }
}

Web application project has been a bless for me so far.. Although there's no migration wizard yet, converting the www.sitecore.net MSVS 2005 project (which I'm currenly working on) was a snap, and it was a huge relief from the first minute.

The project is basically a good old class library but with working asp.net designers, and thats good.

* Upgrading VS 2005 Web Site Projects to be VS 2005 Web Application Project
* Upgrading VS 2003 Web Projects to be VS 2005 Web Application Projects