Make sure you have webresource.axd included in your ignoreUrlPrefixes in Sitecore. It is used to serve resources embedded in assemblies, anything from javascript to images - atlas and some of the asp.net 2.0 rich controls won't work otherwise.

SDN5 site received a minor facelift and become a bit more firefox firefox 1.5 friendly. If I've broken anything, let me know.


Update: It looks like the layout is broken on Firefox versions < 1.5. Upgrading to 1.5 helps.

SDN5 gets rss feeds, done using Sitecore RSS Module. Check out and subscribe to downloads feed to get notified of new releases. Still need to find a place to stick pretty 'xml' button to.

Finally making use of DefaultButton of asp.net's Panel: searching at sdn5 should work fine with enter button now. If there are other places where enter behaviour should be fixed, send them in.

Speaking of search, sdn5 search autocomplete is finally live. Fixed the issue with list buttons appearing in IE after you hower over menu while autocomplete box is displaying (reported by Alex de Groot, thanks).

Microsoft released the Web Application Project for Visual Studio 2005, which is probably the best option you have working with Sitecore 5.2+ in MSVS. Download.

Very cool Microsoft's Monad shell gets RC1 under a brand new 'Windows PowerShell' name.

I used to have a CopySourceAsHtml visual studio add in to post sharply formatted code to blog. But it produced really dirty html which actually made my dasBlog unhappy and for some reason it doesn’t work well (or just doesn’t work) in vs2005.

Here’s a really nice macro on coding horror that works in any visual studio version and creates a much cleaner code. It’s a bit painful to install, but then you can assign a shortcut and forget. Mine is ctrl-c + ctrl-c.

Update: which wasn't a great idea for a hotkey..

I’m using asp.net 2.0 portal on Sitecore front end in the current project, and personalization features such as portlet drag-n-drop just won’t work unless asp.net understands that the user is logged in and can tell the difference between users.

Here’s my hack-n-slash solution: it envolves shim classes implementing IPrincipal and IIdentity, delegating everything to Sitecore. User id is returned as user name to asp.net, so that each user gets own personalization data (actually user names would also work, since they're unique). On each request, a custom processor in HttpBeginRequest pipeline (named AspnetUserSetter) puts the Sitecore principal in asp.net context.

And since I'm humble enough to allow asp.net do the rest, using default personalization database and provider - it just works. Now I wish it was easier to create custom frames around web parts.

Tons of great happened to Sitecore while I was keeping quiet. Completely revamped Content Editor looks amazing, and performs too.

In a weird turn of things, I have installed Office 12 after having a chance to try out our new interface.  It looks like I’m writing the post just to enjoy the experience.  Jakob and Lars have lots of screen shots and detailed info on their blogs.

For the developer goodness, Runi has made most of the main Sitecore API classes support remoting, and it is very simple to use – check out his post for a how to.  There is much more to it, like multiple template inheritance, and hopefully it will start getting out soon.

The best part is that is still the same Sitecore underneath - no breaking changes and no need to start anything from scratch.

And what about me? Well, my mission was to cruise the city promoting the new secret Sitecore Office 13 look and feel using our branding weapon:

I am flying back to Ukraine on Sunday morning. It sure has been a very exciting month thanks to everyone around – I truly appreciate that!

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.