Speaking of web application projects in MSVS, it looks like they had a brand new refresh with long awaited codebeside updater. Known issues look unsignificant, except for Migration Wizard, perhaps. Looking forward to try that.

It’s been a while since I’ve posted and the blank page looks scarier than ever.

SDN and SPN sites went live on Sitecore 5.2 two weeks ago, on January 30th; it’s not exactly ‘news’ at this point. It has been a significant change in a number of ways: moving to a latest Sitecore from 4.3.2.5, using asp.net 2.0 and weird web projects in MSVS.2005.

We’ve also integrated our security with Microsoft CRM 3.0 system - there are no extranet users in Sitecore itself, and everything being fetched from CRM database and turned into virtual users with appropriate roles assigned.

The last but definitely not least is the MondoSearch search engine and Behavior Tracking by MondoSoft that we’re now using on all three (sdn4/sdn5/spn) sites. More posts to come on this.

It looks like we did fine – there was no downtime during the change (although, uhh, server had run out of disk space last weekend... and, uhh, some exceptions were flying around a couple of times) and everyone had to bear with me and stop updating the site for less than two weeks only.

What we’ve gained from that is a better performing solution (no kidding) and a large amount of very-own-dog-food. The later is especially important even from my limited experience – hopefully I’ve did a number of good things along the way.

Database migration wizard received the most attention obviously, trying to make sure that it can handle all the little Sitecore 4 oddities I’ve encountered. However, It will not be released in it current form, becoming a component in new Data Transfer tool instead. It’s expected to be released pretty soon, from what I know.

The last few days were spent on capturing my ‘experience’ on paper; I’ll put up a draft soon, begging for feedback.

Now I need a bottom line, and it looks like “I RULE!” doesn’t fit. I’ll try this: if anyone is considering moving to Sitecore 5 from 4, let me know. Let me know what bothers you the most, let me know what areas you’d like to see covered in migration guide – I’m information hungry. Hopefully (for me) I’ll have something to share in return.

There's a number of options to speed up your Sitecore development installation:

1. Disable the indexes. Indexes are responsible for the little search bar in Sitecore taskbar. If you can happily live without it, then comment out the <indexes> section inside your database section in web.config (that is most probably /databases/master/indexes). The search will go away, along with index updates on each item create/update/delete operation.

2. Switch your site to the 'live' mode. Live mode completely eliminates the need for publishing, which can be pretty annoying in development scenarios, by taking all items directly from the content authoring database. To activate find your website in <sites> section of web.config (the site is called 'website' by default) and change database="web" to database="master". This is the way Sitecore client site works on core database. Naturally, by switching the publishing off you also lose the publishing restrictions, that is 'do not publish'/'publish date' stuff.

A new Sitecore blog by Mark Cassidy - welcome.
Metanauts - CMS discussion forum. You've probably seen this one in yahoo groups.

I'm not sure whether it's a great example of Sitecore extensibilty or of things you shouldn't do, but I though I'd share it anyway :)

This little snippet adds shortcut to all content sections (and a little unsupported yet indispensable dbbrowser) to the Sitecore task bar. What is good about is, is that its very easy to install: download and unpack to your /sitecore/shell/override, its just two xml layouts with embedded code. The dark side is that you have to put them in override folder to replace the standard Sitecore start bar. So if the start bar changes in future builds - yours won't.

Fortunatelly, uninstalling is just as easy: remove the Startbar.xml and StartbarSections.xml files and thats it. Standard disclaimers apply: if your PC turns into evil alien monster and starts dissecting humans - you have been warned. Although it might be a good idea to keep your production server clean, I (humbly) find this control to be very useful in development environment.

Once again - download link (3kb).

I've mentioned earlier in Sitecore yahoo group the possibility of creating a replacement of multi list field by replacing left select box with a tree view. The control now is available at SDN5 in shared source form and I encourage everyone to take a look at it, as I believe the field to be very useful in situations when you have large number of items to choose from (Multi list with 100 items doesn't look pretty).

Sitecore 4 developers are familiar with the login rendering concept: It is possible for any rendering to have its counterpart login rendering which gets shown if the user doesn't have required permission to access content.

I'll use SDN as an example - try to access an item that anonymous user is not allowed to read, like http://sdn.sitecore.net/articles.ascx. You can still see the layout. Moreover, top menu renders items accessible to the current user (Documentation is a public section) and the breadcrumb shows your correct location (home / articles) even though you cannot see the item itself.

The main content rendering (the one in the centre) shows the 'please login' info because it has the login rendering set, and Sitecore layout engine knows that the current user (anonymous) is not allowed to access the current item (/home/articles).

The concept is fundamentally changed in Sitecore 5 because of one difference: if the current user is not allowed to access the current page, he is redirected to:

1. Login page if the login page is specified for the current site, controlled by the loginPage property of each individual site.
2. No access page, controlled by NoAccessUrl setting in web.config.

in any way, he won't be able the access the item as he used to in Sitecore 4 at SDN, even without the content.

This logic is baked in the ExecuteRequest processor in httpRequestBegin pipeline. It’s not easy to change it though (I've moved the explanation to the end of the post to avoid clutter). And it's not a good idea to modify bunch of processors only to make things as they were before anyway. Two common requirements for scenarios when user is not allowed to access content he tries to are:

1. User is presented with a friendly message explaining what happened.
2. Along with the friendly message, user can login and see the page he's trying to access.

Login page supports both:

1. Create a new item, and allow 'read' for everyone. Locate your site in the <sites> section of web.config, and set a loginPage property:
<sites>
  <website loginPage="/home/login.aspx" .. />
</sites>

This item will probably have the default layout of the site, but instead of the content rendering it should have a 'login rendering' explaining that a user has to login to access the item.

2. When redirecting to login page, Sitecore will fill two query string parameters: 'item' and 'login'. This solves the last requirement - how to redirect user back to the requested item.

I've made a little class to handle this for sdn/spn sites, here's how it can be used:

DomainAccessResult result = new LoginManager().Login(emailTextBox.Value, passwordTextBox.Value);

It performs the usual Sitecore.Context.Domain.Login() and
a) redirects user back to the requested item if any
b) redirects user to 'login failed page' if it’s specified either in web.config or class property.

download link: LoginManager.cs

--
If you allow all users to see restricted pages and allow ItemResolver processor (earlier in the same pipeline) to set the Sitecore.Context.Item property - you're creating a possible security hole. Renderings do not perform explicit permission check every time they need to output some content - having the Sitecore.Context.Item set is enough to know that the item meets all criteria and can be shown.

The other option is to leave standard ItemResolver processor but still modify ExecuteRequest: this way user will be redirected to layout but Sitecore.Context.item will remain null. Security is ok this way, but because context item is not set Sitecore layout engine has no clue which item user wanted to access (and wasn't able to) - therefore it cannot decide (among other things) whether it should show the login rendering or not.

One of the most common issues in Sitecore 4 to 5 migration is item names. Sitecore 5 has much more strict item naming rules by default:

1. Item name cannot be longer than 100 characters
2. Item name cannot end with a dot
3. Item name cannot start or end with blanks
4. Item name must not contain any of the characters specified by the 'InvalidItemNameChars' setting
5. Item name must match the regexp pattern specified by ItemNameValidatation setting

You can control 2 out of the 5 restrictions via the web.config. Their default values are:

<setting name="InvalidItemNameChars" value='\/:*?"&lt;&gt;|[]' />
<setting name="ItemNameValidation" value="^\w[\w\s\.]*$" />

You should try to avoid removing any chars from the InvalidItemNamechars - items with invalid characters in names can be source of unpredictable errors. ItemNameValidation, although more restrictive, is another case - its main purpose is to enforce url 'friendliness'. An url to the item is built using item name so it is important that the name is kept simple and in compliance with W3C standards so that url is short, easier to remember and not messed up with special characters encoded with their unicode values or Sitecore url encoding rules. Sitecore query is also quite sensitive to item names.

When developing solutions with Sitecore 5 right from the start it is good practice to leave the item name validation intact - keep item names simple, and use DisplayName property (found in Appearance section) to control title of the item in client. DisplayName is a languaged field so you will probably use it anyway in multilanguaged solutions.

Migration from Sitecore 4 is another story. It is desired to have as little changes as possible to preserve your urls and item links. Sitecore database migration tool does have the following logic baked in when item name is not 'good enough' for Sitecore 5: it enforces item naming rules from 1 to 4 one by one: cuts the item name to 100 characters, removes trailing dot, trims the name and then strips InvalidItemNameChars characters. If the item name is still not accepted by Sitecore 5 it means that the name doesn't match the ItemNameValidation pattern and upgrade tool has no other choice but to give up and replace the name with 'Invalid Name'. To avoid that you can tweak the ItemNameValidation pattern or even disable it completely when performing upgrade and then reenable it again to make sure that new items follow the 'best practice' rules.

The new release of upgrade tool will also keep track of all items it had to rename in a separate log file so that you can inspect it later and make sure that there are no broken links.

When the items are successfully transferred to Sitecore 5 you can use its built-in link checking capabilities to rename items without breaking any internal links. Please note however, that external links will be changed even in this case.

As with many other frameworks, you need a bit of insight on internal processes to create effective solutions.

 

Sitecore Query is XPath-like query language that allows both simple 'by name' or 'by path' resolutions and complex expressions. What is special about it is that query can be handled either directly in the database on data provider level or by the data manager tier. When the query is being resolved, data manager tries to use its data providers first and resorts to  higher level (read: slower) API in case of failure.

 

Sql server data provider (as well as the other standard providers I think) supports only a small subset of query: '/sitecore/content/home' - resolving item by path and '//home' - resolving item by name.

 

What does this really mean? Imagine that you have a large site with sql server database backend and you're trying to find some content items. For most simple scenario, we need to find all content items named 'needle':

 

Item content = Sitecore.Context.Database.Items["/sitecore/content"];
Item[] needles = content.Axes.SelectItems("//needle");

Sql server data provider supports this kind of query, so the query gets resolved directly in the database fairly fast even though we have a large number of content items. 

Then we complicate the requirements a bit: say our items have 'IsHidden' checkbox field and we only want needles that are not hidden:

Item content = Sitecore.Context.Database.Items["/sitecore/content"];
Item[] needles = content.Axes.SelectItems("//needle[@IsHidden != 1]");

Predicates are not supported by the sql server data provider, so it ignores the query. We don't have any other data providers in our database, so as I said earlier data manager resorts to higher level query api. This basically means that all items in the query scope (all descendants of /sitecore/content in this example) are loaded so that predicate can be evaluated against each item and the matching items are returned.

 

The difference between database and item evaluation can be quite dramatic. Now understanding how data manager and data providers work together to evaluate the query, lets improve our solution:

Item content = Sitecore.Context.Database.Items["/sitecore/content"];
// Limit ourselves to dataprovider-supported query
Item[] allNeedles = content.Axes.SelectItems("//needle");

// Do the additional filtering - [@isHidden != "1"] predicate evaluation.
List<Item> nonHiddenNeedles = new List<Item>();
foreach(Item item in allNeedles)
{
   if (item["IsHidden"] != "1")
   {
      nonHiddenNeedles.Add(item);
   }
}

By using '//needle' query we obtain all items named 'needle' in a very efficient way because the query is resolved in the database. There are probably only a few such items, so iterating through each of them to check the 'isHidden' field should also be fairly inexpensive and it only requires a few additional lines of code.

 

Sql server data provider will be able to support field value predicates soon, but the point remains the same: understand what kinds of query are supported by your database backend when querying against large item sets.

 

And there's another one: when creating data providers, support common query scenarios to avoid performance downfalls.

Please welcome new Sitecore blog - Alex de Groot: Few words about SiteCore from Holland. Its great to see Sitecore partners starting blogs too.