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.

There's one common gotcha when adding your own web service to Sitecore: if you allow Visual Studio to do the job for you, it will create a new application for the web service to be placed in. This is always bad idea with Sitecore, and you will get 'httpRequestBegin' pipeline not found exception. To fix it simply remove the application.

And if for some reason your web service has file extension different from '.asmx' - create a custom httpBeginRequest processor to ignore all requests with that extension or add your webservice to IgnoreURLs setting.

Perhaps some of these will help better manage Sitecore solutions in VS 2005: Some Techniques for Better Managing Files in Visual Studio 2005 Web Projects (MSDN). In short: if you have a really large upload folder, you can make it a virtual folder (but not an application!) and open your web project as 'Local IIS' project instead of 'Filesystem' in visual studio. Then upload folder will not be a part of the site and will not be published by VS 2005.

And you can always use Sitecore MediaFolder setting to place your upload outside of the site root.

We have an interesting shared source release that I'd like to point your attention to. Xml data provider is a custom data provider that allows you to import any external data as long as you provide a transformation to Sitecore item xml format. So why is this so useful?

The provider comes with an example of importing RSS/Atom feed data. All you need to do is to create a new feed definition item, point it to valid feed and set settings like refresh rate. If the feed has any entries they will be shown as children of your item, being perfectly valid (although immutable) Sitecore items.

 

While we had some RSS reader components in past, this one is totally different: your presentation doesn't have to handle feed data in some different way - you can reuse your renderings and your skills, setting up rss feeds in no time.

However its important to see that RSS aggregation is merely an example of what can be done. To import any other kind of external data, all you have to do is to provide a xsl tranformation and a simple class to register it. Provider understands a fairly simple xml format that is similar to Sitecore item xml: you can find an example in provider documentation.

And with source code available to download, its easily extendable and a great example of writing your own data provider.

Give your warmest greetings to new Sitecore Support blog by Alexander Shyba. We have a fairly large number of interesting support cases each day, so I believe this is a must-subscribe for anyone dealing with Sitecore solutions. There are already a number of unusual entries that can save you some hair-pulling.

Jukka-Pekka Keisala posted a link to a great firefox extension: welcome IETab! It seamlessly embeds IE in a firefox tab, and guess what - Sitecore runs just fine in it, so now you can have IE-flawored Sitecore inside a firefox.
Must have - install.

Update: the only glitch I've found so far is that Ctrl+S doesn't work.