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

Beware of Credential Cache

As I've told before, we're now using Microsoft CRM system to manage extranet users. When you log in, the user data is being fetched from sql table, a virtual user is assembled using the ID from CRM and given the Sitecore security roles based on CRM permissions.

There's one catch though - Sitecore maintains a credential cache (since around 5.1 I think), so that it doesn't have to repeatedly calculate effective permissions for a given user to a given item. Once the user accesses the item the first time, permissions are calculated and stored in cache. Sitecore also makes sure to clear the cache when required. In our case, however, the user is changed inside the CRM system, and its our responsibility to let Sitecore know about it. Failing to do so might result in permission changes only taking effect after application restart.

There are several options to handle that:

1) Clear the cache once any entities affecting access permissions were changed.

In the case with Microsoft CRM that would mean registering a callout on 'account' or 'contact' entities change. The web service on Sitecore side listens for notifications and clears the cache on demand.

Pro: Security updates are in effect immediately
Con: More complicated, requires an outgoing connection from CRM to Sitecore web server

2) Clear the credential cache for a user each time he logs in

Overriding Sitecore.SecurityModel.Domain.Login(string, string) will hook you up right in there - it gets called each time the user tries to log in suppling her login and password

Pro: Simple
Con: Security might not be updated until user session times out. Cache is clearead unconditionally

To be honest I've wasted time on both. The CRM callout didn't fit in because of the need of active outgoing connection, and we're now using the second one.

[CredentialCacheController]

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.