InSitecore

Sitecore Language Name Validator

Tue, 05 Feb 2013 08:12:25 -0500

In our discussion of LanguageResolver, one of the issues we identified was the possibility of Item Name and Language Name collisions. That is, Sitecore will interpret the first slug of a URL as a language if it can – even if that language isn’t in use on the Site or in the Instance.

This is a problem for abbreviations that collide with languages. Some common abbreviations that might cause conflict include:

AR (Arkansas) maps to Arabic
CA (Canada) maps to Catalan
ID (Identity) maps to Indonesian
IS (Information Services) maps to Icelandic
IT (Information Technology) maps to the Italian language (this is the example that brought this issue to my attention)
Etc.

One possible solution to this problem is to add a custom validator to Sitecore that reports a validation error whenever a top-level item has a name conflict with a language. The user is then free to change the name to prevent a language conflict.

Custom Validators

Before we write our code, let’s review custom validation. Validators allows you to indicate warnings and errors about the fields of items. Validation comes in three forms:

Field Validators. Field validators are assigned on field definition items and run against the value of the target field.
Item Validators. Item-level validation can be assigned on Template Standard Values and will run against all items that implement from the template (or one of its inheritors).
Global Item Validators. These are Item-level validation items, but they run against all items, all of the time.

Here are the steps for creating a custom validator:

Create a class that inherits from Sitecore.Data.Validators.StandardValidator
Implement the required methods:
1. Parameterless constructor
2. Serialization constructor
3. Name property
4. Evaluate method
5. GetMaxValidateResult method
Compile and add your assembly to your Sitecore Instance’s `bin` directory
Create a Validation Rule definition item in the Content Tree under /sitecore/system/Settings/Validation Rules
Apply the rule using a validation rule field
1. For Field Validators, apply the rule on a field definition item
2. For Item Validators, apply the rule on a Template Standard Values item
3. For Global Item Validators, apply the rule on the /sitecore/system/Settings/Validation Rules/Global Rules item

If you’re using Sitecore Rocks, instead of creating a class in Step 1, create a Validation item in the Sitecore > UI group of the Add New Item dialog. This will create the class, and a definition item in the Content Tree of the master database.

Implementation

This brings us to the implementation for our case. Our validator needs to check that an item won’t create a name conflict. We’ll be checking for these scenarios:

An item is an immediate child of a site’s Home item and the item’s Name or Display Name can be parsed as a language
When the item’s link is generated, the first slug in the URL can be parsed as a language

We’ll need to check every Site defined in the instance, so we can correctly handle multi-site configurations. However, many Sites don’t need validating (e.g., the shell Site for the Sitecore UI). Validation items have a Parameters field. We can use this field to send in runtime configuration to our validation. In our case, we’ll let users specify a Sites parameter in this field, e.g., Sites=website to check just the website Site.

So here’s the sample code. Note that the first several lines are mostly boilerplate from Rocks. The meat of this implementation is in the Evaluate method.

namespace InSitecore.Sample.Validation {
    using System;
    using System.Collections.Generic;
    using System.Runtime.Serialization;
    using Sitecore;
    using Sitecore.Data.Validators;
    using Sitecore.Globalization;
    using Sitecore.Links;
    using Sitecore.Sites;
    using Sitecore.Web;

    // TODO: Automatically created Item in Master database
    // "/sitecore/system/Settings/Validation Rules/
    // Item Rules/LanguageNameConflictValidator" when creating
    // LanguageNameConflictValidator class. 

    [Serializable]
    public class LanguageNameConflictValidator : StandardValidator {
        public LanguageNameConflictValidator() {
        }

        public LanguageNameConflictValidator(
            SerializationInfo info, StreamingContext context )
            : base( info, context ) {
        }

        public override string Name {
            get {
                return "Language Name Conflict Validator";
            }
        }

        protected override ValidatorResult Evaluate() {
            var item = this.GetItem();

            // Starting assumptions: we have an item, it's a content item
            // (e.g., from /sitecore/content), and it has a parent.
            // Return if these assumptions aren't met
            if( item == null
                    || item.Parent == null
                    || !item.Paths.IsContentItem ) {
                return ValidatorResult.Valid;
            }

            // Get a list of sites to check.
            // If no sites are specified, load them all
            var siteNames = new List();
            if( this.Parameters.ContainsKey( "sites" ) ) {
                siteNames.AddRange(
                    this.Parameters[ "sites" ].Split( new[] { ',', '|' } )
                );
            }

            if( siteNames.Count == 0 ) {
                siteNames.AddRange(
                    Sitecore.Configuration.Factory.GetSiteNames()
                );
            }

            // Loop the sites, checking if this is a child of that site
            foreach( var siteName in siteNames ) {
                var site = Sitecore.Configuration.Factory.GetSite( siteName );

                if( site == null ) { continue; }

                var siteRootItem = Context.Database.GetItem( site.StartPath );
                if( siteRootItem == null ) { continue; }

                // We only need to consider the case when an item is an immediate
                // child of a home item
                // NB: This might not be a good assumption for a specific
                // implementation; for example,
                // if you're using your own LinkProvider
                if( item.Parent.ID != siteRootItem.ID ) { continue; }

                // Now, try a number of different ways
                // of testing if there is a language
                // confict with this item
                var triggerName = "";
                Language lang = null;

                if( Language.TryParse( item.Name, out lang ) ) {
                    triggerName = "Name";

                } else if( Language.TryParse( item.DisplayName, out lang ) ) {
                    triggerName = "Display Name";

                } else {
                    // If the Name and DisplayName didn't match,
                    // maybe the generated URL will.
                    // We're going to use a SiteContextSwitcher to
                    // temporarily get Sitecore
                    // to act like Context.Site is pointing to a
                    // different site. This lets
                    // us use the settings for that other site.
                    string url = null;
                    using( new SiteContextSwitcher( site ) ) {
                        // Make sure that we're not going to see an actual langague slug in the URL
                        var options = new UrlOptions() {
                            LanguageEmbedding = LanguageEmbedding.Never
                        };
                        url = LinkManager.GetItemUrl( item, options );
                    }
                    // This will get the URL's file path
                    // Basically, the non-domain, non-query string
                    // portion of the URL
                    var filePath = WebUtil.ExtractFilePath( url ?? "" );
                    var languageSlug = WebUtil.ExtractLanguageName(
                        filePath ?? ""
                    );

                    if( Language.TryParse( languageSlug, out lang ) ) {
                        triggerName = "URL's file path (" + filePath ?? "" + ")";
                    }
                }

                if( lang != null ) {
                    // We matched a language; set the validation error
                    this.Text = this.GetText(
                        "The item \"{0}\" is a top-level child of "
                        + the \"{1}\" site and its {2} "
                        + "has a conflict with the {3} language.",
                        item.Name, site.Name, triggerName,
                        lang.CultureInfo.DisplayName
                        );
                    return this.GetFailedResult( ValidatorResult.Error );
                }
            }
            return ValidatorResult.Valid;
        }

        protected override ValidatorResult GetMaxValidatorResult() {
            return this.GetFailedResult( ValidatorResult.Error );
        }
    }
}

Thoughts on httpRequestBegin - Custom Language Resolver

Tue, 18 Dec 2012 11:02:00 -0500

Last week we took a look at the httpRequestBegin pipeline and overriding the ItemResolver. Today, let’s give some time to the LanguageResolver.

Overriding Options

Just as in the ItemResolver case, there are two basic ways to override LanguageResolver:

Inherit and extend the existing LanguageResolver
Create a new processor that acts in addition to the standard LanguageResolver

However, with Languages specifically, you might want to take a third option: replacing the standard LanguageResolver completely.

The Problem with Language

Unlike some other processors, the LanguageResolver does not skip processing if language has already been specified earlier in the pipeline. So, even if you create a new processor that happens before LanguageResolver, if Sitecore picks up a language setting in LanguageResolver, your settings will be discarded.

Sitecore’s standard LanguageResolver will look for languages in two different ways:

An sc_lang query string parameter. E.g., http://site.net/page.aspx?sc_lang=en
A language code embedded as the first slug in a URL. E.g., in http://site.net/en/page.aspx the /en/ chunk will be interpreted as requesting the English language.

(You can read the details here.)

This poses a special problem if your URLs include an initial slug that looks like a language. For example, one client told me that they tried to have an IT department top-level section on their website, which would generate links like http://site.net/IT/some-page.aspx. The LanguageResolver would find the initial /IT/ slug and interpret it as a language. Instead of trying to find an item at /sitecore/content/home/IT/some-page with an English language version, it would try to find an item at /sitecore/content/home/some-page with an Italian language version. Clearly, not the desired result.

Sitecore will try to interpret any initial slug as a language even if that language is not in use on the site or the Sitecore instance.

LinkManager and `languageEmbedding`

Sitecore remembers your language selection by saving a cookie with the name <SiteName>#lang. If you have cookies turned off, Sitecore can’t remember your language selection across requests.

To get around this problem, you can use the languageEmbedding attribute on the LinkProvider in web.config. That attribute can take three values:

always: Always embed the language in the link. Whenever a link is requested from the LinkProvider, Sitecore will embed the item’s language in the URL as an initial slug, so it can be found by LanguageResolver.
never: Never embed the language in the link.
asNeeded: Embed the language in the link only until language has been set. The asNeeded value should be avoided because URLs for the same item will change during a single visit to the site. That’s bad for SEO and bad for predictable URLs in general.

Using languageEmbedding nicely gets around the cookie issue, but it also has the nice effect of separating your URLs for different languages.

Challenges & Solutions

We’re left with a number of challenges, and some potential solutions:

If you want to handle languages yourself, even if you create an earlier language processor, Sitecore will disregard the language selection you make if it LanguageResolver detects a language setting. To resolve this, you could add your custom processor after the standard LanguageProcessor. However, you’ll have to manually check that Sitecore hasn’t set its language in a way you want to handle so you can roll back to the default language for the site.
You might have name collisions with top-level site sections and language codes. You could create item-level validation that does not allow top-level items to use names or display names that collide with languages. To test this, you could use the Sitecore.Globalization.Language.TryParse static method. (Stay tuned, my next post will have a demo implementation for this approach.)
To persist language choices across requests, Sitecore only has two options: URL embedding and cookies. However, there are many approaches that might be useful. For example:
- DMS Tag value on the visitor reporting their preferred language
- User profile setting for the visitor’s preferred language
- ASP.NET Session variables that can be retrieved using cookie-less sessions
The current implementation of detecting language requests only has two approaches: sc_lang query strings and URL-embedded language codes, but you may be interested in using other techniques. For example:
- The culture reported by the browser
- Most common language used in the region detected with a geo-ip lookup
- The language indicated by the display name of the item (i.e., enhancing the ItemResolver to look items up by their display name in any language, then specifying the language based on the language version found).

Solving Language the Sitecore Way

Each of these individual problems can be addressed independently, based on your specific implementation requirements. And, if you have a monolingual website, none of this really matters.

But, if you approach the problem by creating a single new custom LanguageResolver that tries to deal with all of the issues identified in this post, you’ll end up with a big class full of implementation details. Sitecore has a pattern that we like to use in cases like this: Pipelines!

Briefly, you could create a new pipeline that resolves language in a series of discrete steps. Changing how Sitecore identifies language can then be easily modified and extended.

In a future post, we’ll create just such a pipeline.

Thoughts on httpRequestBegin - Custom Item Lookups

Thu, 13 Dec 2012 14:49:00 -0500

Yesterday we looked at the details behind the httpRequestBegin pipeline. Today, I wanted to share a few thoughts on the pipeline and extending it.

Custom Item Lookups

A relatively common scenario for developers is the need to override the standard Item lookup process as defined in the ItemResolver. There are two ways to accomplish this:

Sublcass Sitecore’s standard ItemResolver and implement your custom code in a Process() method override.
Create a new processor and inject it into httpRequestBegin before the existing ItemResolver. This technique works because ItemResolver will not change Context.Item if it has already been set.

Generally, I recommend option #2 because:

It’s more portable. Your new code will not have any dependancies on Sitecore’s ItemResolver.
It’s more modular. The code for your custom lookup logic is separated in to its own class and Include files.
It modifies the pipelines in a predictable way. A new programmer coming on board will be able to identify changes to the pipeline but know that all of the regular processors continue to work in the expected way.

Implementation

(See the next section on how Sitecore Rocks simplifies this process.)

First, create a new HttpRequestProcessor subclass that will handle your custom lookup logic. For example:

using Sitecore;
using Sitecore.Pipelines.HttpRequest;

namespace InSitecore.Sample {
    public class CustomItemResolver : HttpRequestProcessor {

        public override void Process( HttpRequestArgs args ) {
            if( Context.Item == null ) {
                return;
            }

            // Implement custom custom item lookup logic here
        }
    }
}

Next, create an Include file that will insert your processor before ItemResolver. For example:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <pipelines>
      <httpRequestBegin>
        <processor type="InSitecore.Sample,InSitecore.Sample"
          patch:before=
"processor[@type='Sitecore.Pipelines.HttpRequest.ItemResolver, Sitecore.Kernel']" />
      </httpRequestBegin>
    </pipelines>
  </sitecore>
</configuration>

Save that file as CustomItemProcessor.config in your Sitecore instance’s Website/App_Config/Include directory.

Sitecore Rocks

If you use Sitecore Rocks, you’ll find the process of creating pipeline processors much easier.

Instead of adding a class, choose Add New Item.... In the dialog, open the Sitecore templates, then the Pipelines subfolder. Choose Http Request Processor and both the class file and the include file will be created automatically.

Sitecore httpRequestBegin Pipeline - In Detail

Tue, 11 Dec 2012 16:06:00 -0500

Pipelines are Sitecore’s way of executing operations in an easily extensible way. Sitecore passes off execution of an operation to a Pipeline as defined in web.config. There, each of the processors listed are executed in sequence. In this way, you can easily modify how Sitecore executes operations by modifying the pipelines.

This is the first in a series of blog posts detailing exactly how the Sitecore pipelines operate. In each post, I’ll take one pipeline and describe each of its processors in a fair amount of detail. I might also add a follow-up post on my thoughts on the pipeline.

In today’s post, we’ll look at the pipeline at the heart of the Sitecore execution process - httpRequestBegin. This pipeline is responsible for properly populating the Sitecore.Context object and making sure execution gets passed to the correct class or file.

httpRequestBegin has 21 processors (19 if DMS isn’t installed), so this is going to be a pretty long post!

What follows is not official Sitecore documentation and is taken from looking at Sitecore.Kernel code in a decompiler (Reflector and dotPeek). You should use this post as informational not official.

With that out of the way, let’s take a look at each of httpRequestBegin’s processors. You can follow along by searching your web.config file for httpRequestBegin.

CheckIgnoreFlag

Class: Sitecore.Pipelines.PreprocessRequest.CheckIgnoreFlag
Assembly: Sitecore.Kernel

Description:
Determines if a blanket pipeline active flag has been set.

There are two reasons it might not be set, and both are handled in a the preprocessRequest pipeline’s FilterUrlExtensions processor.

The request might have a blocked extension. In the FilterUrlExtensions config entry, there are settings for allowed and blocked extensions. If this request has a blocked extension, then then flag will be set to false.
A request might be set up to be handled by a Custom Handler. Custom Handlers are defined in web.config in /configuration/sitecore/customHandlers. If this request matches the trigger attribute of any of those handlers, then pipelines don’t need to run, since requests will be processed by the Custom Handler rather than regular Sitecore processes. If there’s a Custom Handler match, then the flag will be set to ‘false’.

By default, Sitecore sets a SitecoreOn flag to true. If either of the above conditions are met, that flag will be set to false. The SitecoreOn flag is set in the Context.Items collection.

This processor checks the SitecoreOn key’s value to determine if the httpRequestBegin pipeline should run. If the value is false, then the entire httpRequestBegin pipeline is aborted.

StartMeasurements

Class: Sitecore.Pipelines.HttpRequest.StartMeasurements
Assembly: Sitecore.Kernel

Description:
Prepares some performance checks in Sitecore’s Items collection. These are retrieved in the httpRequestEnd pipeline’s StopMeasurements processor and tested against some thresholds. If any threshold is exceeded, it’s written out to the log file as a warning. You can change what threshold is tested in the StopMeasurements configuration in web.config.

Here are the checks that get tracked:

SC_REQUEST_MEASUREMENT_TIMER key: a new timer object. This will check total elapsed time for the request. The related threshold is TimingThreshold.
SC_REQUEST_MEASUREMENT_ITEMS key: a count of items accessed. This will check total number of item accesses during the request. The related threshold is ItemThreshold. (The count of accesses is retrieved from Sitecore.Diagnostics.PerformanceCounters.DataCounters.ItemsAccessed.)
SC_REQUEST_MEASUREMENT_MEMORY key: total allocated memory as reported by the garbage collector. This will check total memory consumed during the request. The related threshold is MemoryThreshold. This value is retrieved from System.GC.GetTotalMemory().
SC_REQUEST_MEASUREMENT_URL key: the current request’s raw URL.

StartDiagnostics

Class: Sitecore.Analytics.Pipelines.HttpRequest.StartDiagnostics
Assembly: Sitecore.Analytics

Description: This processor is only present if DMS is installed.
Starts the Analytics logger for logging notifications. During DMS processing, log entries are sent through the Analytics logger rather than the standard Sitecore logger.

IgnoreList

Class: Sitecore.Pipelines.HttpRequest.IgnoreList
Assembly: Sitecore.Kernel

Description:
Identifies if the file path of the requested URL is in the ignore list. The ignore list is managed by the IgnoreUrlPrefixes Sitecore Setting item in web.config. If the URL’s file path begins with an entry in IgnoreUrlPrefixes, the rest of this pipeline is aborted.

SiteResolver

Class: Sitecore.Pipelines.HttpRequest.SiteResolver
Assembly: Sitecore.Kernel

Description:
Determines which Sitecore site, as defined in /configuration/sitecore/sites, was requested and updates Sitecore.Context.Site with that information. Sitecore determines this by checking the following:

A query string parameter for sc_site
If the EnableSiteConfigFiles Sitecore Setting is set to true, then Sitecore will check the request’s physical file directory for a site.config file. Note that the directory it checks will be the full directory path; Sitecore won’t ascend the directory structure looking for a site.config file. For example, if you have a URL for http://site.net/dir1/dir2/file.aspx, you would need to have a physical directory and for dir1 and dir2 and a site.config file in both directories.

If the EnableSiteConfigFiles setting is false, or the directory doesn’t exist, or there is no site.config file in that directory, the algorithm continues with 3, below.

If you’re going to use site.config, which I’d recommend against for its maintenance challenges, the site.config consists of a single site element with a reference attribute that points to the site element in web.config. For example:

<site reference='website_name' />
This is the main part of the algorithm that will be hit most frequently. Sitecore uses the Sitecore.Sites.SiteContextFactory class’s GetSiteContext static method to retrieve the SiteContext information associated with the request. It does this by passing in the requested host name, full request path and port number. Next, it loops across each site defined in configuration/sitecore/sites and tests if the current request matches.

Because Sitecore will examine each of the site elements in the order they’re listed in web.config, it’s important to have your most generous match (e.g., for the default website site that Sitecore ships with) listed after more specific options.

If none of these techniques work, Sitecore.Context.Site will end up with null, which may force later processors to abort.

UserResolver

Class: Sitecore.Pipelines.HttpRequest.UserResolver
Assembly: Sitecore.Kernel

Description:
This processor determines the current request’s user account by setting the Sitecore.Context.User property.

Because Sitecore uses standard ASP.NET membership, it starts by examining the HttpContext.Current.User property. If it’s been set already, and it’s a Sitecore User object (Sitecore.Security.Accounts.User) then Sitecore uses that. If it hasn’t been set, Sitecore tries to retrieve the user from the username saved in the standard ASP.NET FormsAuthentication ticket Sitecore sets during authentication.

In the case that HttpContext.Current doesn’t exist (e.g., code is running outside a regular ASP.NET web request, then Sitecore tries to use the current thread’s user.

If neither of these techniques work, Sitecore returns the default user account. This is going to be the Anonymous user on the current security domain, which is set by the current Site, as discovered in the previous SiteResolver processor.

DatabaseResolver

Class: Sitecore.Pipelines.HttpRequest.DatabaseResolver
Assembly: Sitecore.Kernel

Description:
This processor allows you to override the Database specified by the Site in SiteResolver. If you want, you can append an sc_database query string parameter with the name of a database.

Overriding is only allowed if the current user is an admin or a member of Sitecore Client Users, since specifying this value allows users to connect to something other than web.

BeginDiagnostics

Class: Sitecore.Pipelines.HttpRequest.BeginDiagnostics
Assembly: Sitecore.Kernel

Description:
This processor determines what happens if you try to run in Debug Mode in the page editor. That is, it checks that settings are correct; that security is correct; and that debug mode is enabled in Sitecore Settings. If all settings check out, Debug Mode, Profiling, etc., are enabled.

DeviceResolver

Class: Sitecore.Pipelines.HttpRequest.DeviceResolver
Assembly: Sitecore.Kernel

Description:
This processor determines which Device Sitecore will use to resolve presentation. It tries the following approaches, in order:

The value of the sc_device query string parameter - either the name or GUID of a device in the Context database.
The device attribute on the Context’s Site. That is, Sitecore.Context.Site.Device, as specified in web.config in the current site’s device attribute.

By matching the values in the Device’s definition item’s fields. First, Sitecore tries to match the Query string field, then the Browser agent field.

Note to match Query string field, every key-value pair in the Query string field has to match the keys in the incoming request’s query string. Empty or non-existent keys in the incoming query string will fail to match. Here are some examples:

Field	URL QS	Matches?
mydevice	Any request	No
mydevice=on	?mydevice	No
mydevice=on	?mydevice=on	Yes
mydevice=on	?mydevice=anything_else	No
mydevice=on	?foo=yes&mydevice=on&bar=no	Yes
mydevice=on&subdevice=2	?mydevice=on	No
mydevice=on&subdevice=2	?mydevice=on&subdevice=2	Yes

To match the Browser agent field, Sitecore just checks if the field value is contained anywhere in the HttpContext.Current.Request.UserAgent’s property value.

The defaultDevice attribute on the Context’s Site. That is, Sitecore.Context.Site.DefaultDevice.
A device that has its Default field checked (raw value of "1").

Note the difference between a site’s device and defaultDevice. Site.Device overrides Query string and Browser agent field values, while Site.DefaultDevice is the fallback if those fields fail to match.

LanguageResolver

Class: Sitecore.Pipelines.HttpRequest.LanguageResolver
Assembly: Sitecore.Kernel

Description:
The LanguageResolver determines which language Sitecore should use, if it’s being set during the current request.

During the normal processing of a request, when the language is not being set, Sitecore will retrieve the current language like this:

The sc_Language key of the Sitecore.Context.Items collection.
The value of the a language cookie SiteName#lang (e.g., for the default website site the cookie key would be website#lang.
The language specified in the language attribute of the site config element.
The language specified in the defaultLanguage Sitecore Setting in web.config.
Failing all other options, the language resolved as en.

During this processor, Sitecore checks if the language was specified in an sc_lang query string parameter. If not, it also checks for any language code that was extracted by the preprocessRequest pipeline’s StripLanguage processor. That processor pulls out the first chunk from the request’s URL (from an initial / to the next / or . character).

If either were set, Sitecore sets the current language which updates the sc_Language key of the Sitecore.Context.Items collection and updates the language cookie (see #2, above). This has the effect of setting the Sitecore.Context.Language property.

CustomHandlers

Class: Sitecore.Pipelines.HttpRequest.CustomHandlers
Assembly: Sitecore.Kernel

Description:
This processor dispatches requests to specialized handlers that are required. These handlers are defined in web.config under configuration/sitecore/customHandlers.

If the current request ends with the a handler’s file (e.g., sitecore_media.ashx), then Sitecore aborts the current pipeline, since this request is specifically targeting a handler directly.

If the current request should be handled by a custom handler (e.g., a URL that starts with ~/media should be handled by sitecore_media.ashx), then Sitecore rewrites the Context’s path information and aborts the pipeline.

Otherwise, processing continues normally.

FilterUrlExtensions

Class: Sitecore.Pipelines.HttpRequest.FilterUrlExtensions
Assembly: Sitecore.Kernel

Description:
This processor is deprecated and is here just for backwards compatibility. This processor has an empty Process method.

On the other hand, the preprocessRequest pipeline has a FilterUrlExtensions processor that ensures requests can proceed and that pipelines should be executed.

QueryStringResolver

Class: Sitecore.Pipelines.HttpRequest.QueryStringResolver
Assembly: Sitecore.Kernel

Description:
This processor checks for two values that can be specified in query string parameters:

sc_itemid: specifies the Sitecore Item for the current request. Only if the ID can be found through Sitecore.Context.Database.GetItem() is Sitecore.Context.Item set to that Item. Ignored if Sitecore.Context.Item has been set in a previous processor.
xmlcontrol: specifies that a Sitecore xmlcontrol should be used as the layout for rendering.

DynamicLinkResolver

Class: Sitecore.Pipelines.HttpRequest.DynamicLinkResolver
Assembly: Sitecore.Kernel

Description:
This processor checks if the request was for a specific ID using the ~/link.aspx syntax, or a media item by using a media prefix syntax (specified in the configuration/sitecore/mediaLibrary/mediaPrefixes section of web.config).

This processor only checks for these links if the Context.Item hasn’t already been set by an earlier processor.

If an item has been selected using these syntaxes, it’s assigned to Sitecore.Context.Item.

AliasResolver

Class: Sitecore.Pipelines.HttpRequest.AliasResolver
Assembly: Sitecore.Kernel

Description:
This processor checks if the request was for an alias instead of a regular item.

First, it checks if aliases are enabled in the AliasesActive Sitecore setting in web.config. If aliases aren’t active, it skips to the next processor.

If aliases are active, it checks if any alias matches the current request’s LocalPath property (HttpRequestArgs.LocalPath). The LocalPath is the portion of the URL after StartPath, generally just the path without domain and port information.

If there’s an alias match, it will try to find the Item pointed to by the alias. If it can find that Item, and the Context.Item hasn’t been set yet, then Context.Item is updated with the Item from the alias. If Context.Item has already been set, then the execution skips to the next pipeline. Note that this means that aliases are searched even if Context.Item was previously assigned, so a large number of aliases could have performance implications.

If Context.Item couldn’t be updated (and still isn’t set), Sitecore will set the Request’s FilePath to the alias’s URL, if present. For example, this is the case for an alias with an external link.

DefaultResolver

Class: Sitecore.Pipelines.HttpRequest.DefaultResolver
Assembly: Sitecore.Kernel

Description:
This processor sets Context.Item to the default Item for the current Context.Site, if set.

The default Item is applied only if all of these things are true:

Context.Item hasn’t been set yet
Context.Database has been set (usually from Context.Site.Database)
Context.Site has been set and Context.Site.StartPath is non-empty (i.e., positive length)
The LocalPath is empty or equals /default

If all of these things are true, it will attempt to retrieve the site’s StartPath item. StartPath is the concatenation of the site’s rootPath and startItem attributes. For example /sitecore/content/home in the default install of Sitecore’s website site. If the Item can be retrieved, it’s assigned to Context.Item.

FileResolver

Class: Sitecore.Pipelines.HttpRequest.FileResolver
Assembly: Sitecore.Kernel

Description:
The FileResolver checks if there is a physical file at the request path. If there is, then that file will be executed as the Layout for the page instead of any Presentation assigned to the item itself. Sitecore.Context will be available and fully populated, even if a physical file is executed.

The existence of the FileResolver allows you to have Sitecore execute files directly instead of using the normal Sitecore rendering process from an Item in the database.

Note that file names must fully match, including extension. For example, if there’s an item in the Content Tree at /sitecore/content/home/test1 and a file in the root of the Sitecore application named test1.aspx, here’s what will happen with different URL’s:

URL	Result
site.com/test1	Content Item
site.com/test1/	Content Item
site.com/test1.aspx	Physical File

In this way, physical files take precedence over Content Items. Note that in the third example, above, that even though test1.aspx is executed, Sitecore.Context.Item will be populated with the /sitecore/content/home/test1 item in the ItemResolver processor of this pipeline.

ItemResolver

Class: Sitecore.Pipelines.HttpRequest.ItemResolver
Assembly: Sitecore.Kernel

Description:
Although all of the processors in this pipeline are important, this is the one that many people will feel is the “heart” of the pipeline.

ItemResolver translates the requested URL in to a Content Item from the Content Tree – in other words, this is what finds the item a visitor is looking for when they click on a link.

In the following notes, Sitecore Decoded means that encoding replacements have been completed. Encoding replacements are specified in web.config in /configuration/sitecore/encodeNameReplacements.

Sitecore finds the requested Item by following these steps:

If Context.Item has already been set, skip to the next processor.
Try to do a straight lookup from the Sitecore Decoded ItemPath, which is the non-domain portion of a URL, stripped of query string, extensions and trailing / characters.
Attempt to a lookup from the LocalPath, which is the ItemPath with StartPath removed.
Attempt the same, but Sitecore Decoded.
Try with the Context.Site.RootPath prepended to LocalPath.
Try the same, but Sitecore Decoded.
Resolve by a name search. In this step, the resolver tries to get the start item specified in Context.Site.RootPath. If it can find it, it scans each child looking for a match on each chunk of the request’s Sitecore Decoded LocalPath using the Item’s Display Name and Name properties.
Same as 6, but tries with only the ItemPath portion of the URL.
Finally, if the sc_usesitestartpath query string parameter has been set to true, then the Context.Site.StartItem Item is returned.

If all of these steps fail, the Sitecore.Context.Item will be set to null.

PageLevelTestItemResolver

Class: Sitecore.Analytics.Pipelines.HttpRequest.PageLevelTestItemResolver
Assembly: Sitecore.Analytics

Description: This processor is only present if DMS is installed.
This processor checks if page-level A/B tests have been initialized on the current item and does any runtime setup required for those tests if they exist.

LayoutResolver

Class: Sitecore.Pipelines.HttpRequest.LayoutResolver
Assembly: Sitecore.Kernel

Description:
This processor determines which Sitecore Layout will be used to satisfy the current request.

If Context.Item hasn’t been set, or if Context.Page.FilePath (the layout to be used) has already been set, then processing skips to the next processor.

This processor tries to find a layout using these steps:

Determine if the sc_layout query string parameter supplied a valid reference (path or GUID) to a Layout definition Item.
If not, see of the Context.Item has a Layout assigned through the Context.Item.Visualization.Layout property, which is set through normal Presentation Layout Details dialogs.
If a valid Layout Item has been found, Sitecore will first try to use any XML Controls that have been assigned to it through the Control or Path fields. The processor will also work to decode and transcribe XML Control references (e.g., xmlcontrol query strings).
Otherwise, the Layout’s Path will be assigned as a standard .aspx file
Finally, if no Layout could be found, Sitecore will use the Layout specified in the DefaultLayoutFile Sitecore Setting, if present.

Sitecore assigns Layout to a request by updating Sitecore.Context.Page.FilePath. If none of these techniques work, that property will return null or the empty string.

ExecuteRequest

Class: Sitecore.Pipelines.HttpRequest.ExecuteRequest
Assembly: Sitecore.Kernel

Description:
This is where the rubber meets the road. This processor finalizes activity and makes sure the Sitecore.Context is ready for the execution process to begin. It checks the following:

That Context.Site has been assigned and the current user has Site Enter permissions. If Site Enter is not granted, Sitecore will redirect to an Access Denied message.
If no Context.Item has been assigned, Sitecore will redirect to a Item Not Found error message.
If no Layout has been assigned (in Context.Page.FilePath), then Sitecore will redirect to a Layout Not Found error message.
If the Layout assigned is not internal to this application, Sitecore will emit a Response.Redirect to the URL specified in Context.Page.FilePath.
Finally, if none of that happens, Sitecore updates the HttpContext’s paths with a call to RewritePath with the location of the physical file to execute.

End of Pipeline

After this, ASP.NET will continue execution normally as HttpContext has the correct paths and Sitecore.Context has been fully populated.

.NET 4.5 Compatibility

Fri, 05 Oct 2012 09:06:00 -0400

Right now, Sitecore has an incompatibility with .NET 4.5 If you have .NET 4.5 installed, you will find that you can’t log in to any of your Sitecore instances.

.NET 4.5 modifies some code that the login page calls and will throw an Exception. Previously, the only solution was to uninstall .NET 4.5 and reinstall .NET 4.0. However, it turns out that the code path that causes the Exception is only reached if you’re asking the login page to remember the last username used in a cookie. If you turn this feature off, you’ll be able to login again.

Simply modify the Login.RememberLastLoggedInUserName setting in web.config to false. Here’s an example include file:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
     <sitecore>
        <settings>
            <setting name="Login.RememberLastLoggedInUserName">
                 <patch:attribute name="value">false</patch:attribute>
            </setting>
        </settings>
     </sitecore>
 </configuration>

To use this include file, follow these steps:

Open Notepad (or your preferred text editor)
Paste the configuration code above, including the opening <configuration> and closing </configuration> tags
Save the file under you Sitecore instance’s directory in \Website\App_Config\Include. Name the file aspnet_45_fix.config

(Thanks to Michael Mavrofrides for pointing me to this fix)

Automatically Logging in to the Sitecore Desktop

Mon, 25 Jun 2012 10:52:32 -0400

For development, I have Internet Explorer set to flush cache and history at close. That means that whenever I launch IE and log in to Sitecore, and have to select the Desktop again under options. That can get annoying, especially for local Sitecore installs where I’m doing development. I generally always want to log in to the Desktop.

Unfortunately there is no global setting to fix this. That is, there is no always log in all users to the Desktop setting. That’s because the login page (/sitecore/login/default.aspx) base class (Sitecore.sitecore.login.LoginPage) hard codes Content Editor as the default interface.

There are two solutions. One easy, one hard. I’d recommend the first (easy) solution, but the second solution is interesting from a Sitecore internals perspective.

Option 1: Set the User’s Profile

In this technique, we assign use the User Account’s Profile tab to specify which user interface they should log in to. Once you’ve set this, the user will always log in to that page, regardless of what they select in the Options section of the Login page.

This is the technique I use for dev instances of Sitecore.

Login to Sitecore with an account that has access to the User Manager application (e.g., admin)
Open the User Manager
Double-click the account you want to edit
Click on the Profile tab
In the Start Url radio options, choose Desktop
Click OK

This user will now always log in to the Desktop.

Option 2: Change the Login Processor

Sitecore handles logging users in using processors. We can hook in to the post-login processor, LoggedIn, and redirect to a url. Here’s an example code file:

using System.Web;
using Sitecore.Pipelines.LoggedIn;
using Sitecore.Web;

namespace InSitecore.Examples.Pipelines.LoggedIn {

  public class RedirectOnLogIn : LoggedInProcessor {

    // Which query string param should we be looking for
    // we default to "url" becuase that's where Sitecore
    // will put its redirect url if you've enabled
    // the Authentication.SaveRawUrl setting.
    private string _queryStringParamName = "url";

    public string QueryStringParamName {
      get { return _queryStringParamName; }
      set { _queryStringParamName = value; }
    }

    public override void Process(LoggedInArgs args) {
      // Bail on all processors as soon as possible for max performance
      if (Sitecore.Context.GetSiteName() != "login") { return; }

      string url = HttpUtility.UrlDecode(
          WebUtil.GetQueryString(this.QueryStringParamName, "")
      );
      if (!string.IsNullOrWhiteSpace(url)) {
        WebUtil.Redirect(url);
      }
    }

  }
}

And an example include file to hook it up:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <processors>
      <loggedin>
        <processor mode="on"
            type="InSitecore.Examples.Pipelines.LoggedIn.RedirectOnLogIn,
                  InSitecore.Examples" />
      </loggedin>
    </processors>
  </sitecore>
</configuration>

Now, instead of logging in to http://sitecoreinstance/sitecore, you should use a url like

http://sitecoreinstance/sitecore/login?url=shell/default.aspx

That will log you in and drop you on the Desktop.

You’ll notice that the processor class has a QueryStringParamName parameter. You can use this to control which query string parameter the processor will pay attention to. For example, if you’d prefer to use the query string param “redirect” (e.g., http://sitecoreinstance/sitecore/login?redirect=shell/default.aspx), you can modify the include file like so:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <processors>
      <loggedin>
        <processor mode="on"
            type="InSitecore.Examples.Pipelines.LoggedIn.RedirectOnLogIn,
                  InSitecore.Examples">
          <QueryStringParamName>redirect</QueryStringParamName>
        </processor>
      </loggedin>
    </processors>
  </sitecore>
</configuration>

Manually Uninstalling Sitecore

Fri, 22 Jun 2012 07:46:00 -0400

For the last few days, I’ve been doing a lot of work with DMS using our internal training site, SiteSetter. SiteSetter is a manual install of Sitecore. That is, no .exe installer wizard to help you get things set up. The process of manually installing Sitecore is pretty straight forward once you’ve done it a few times.

I’ve created at least four different SiteSetter installs this week, and now I’m getting to the point where I’m ready to remove them. Unfortunately, because they were installed manually, they need to be uninstalled manually too.

Here’s my guide for manually uninstalling Sitecore. In this case, it’s a DMS-acitve one, so there’s an extra database that we need to deal with (Sitecore_Analytics), but other than that, these instructions should work for any manually installed Sitecore instance.

Note that you should never manually uninstall a Sitecore instance that was installed with an installer program. Instead, use the Add/Remove Programs or Programs and Features tool of your OS.

Uninstalling Sitecore

This instructions assume you’ve installed Sitecore using the standard conventions. You might find your files in slightly different places. You may have named your databases something else, so update these instructions to fit your install scenario.

We will be manually deleting databases and files – There is no undo from this process. Your files and databases will be permanently deleted.

Step 1: Remove the IIS configuration

Open the IIS Manager (inetmgr from the Start search box)
In the left-hand pane, open the node for your local machine.
Open the node for Sites
Find your Sitecore instance’s website. Right-click on it and select Remove. A confirmation dialog will open. Click Yes.
In the left-hand pane, click on Application Pools
In the right-hand pane, find your instance’s Application Pool. Right-click on it and select Remove. A confirmation dialog will open. Click Yes.
Close IIS Manager

Step 2: Remove the hosts file entry

Open Notepad with Administrator privileges:
1. Find Notepad in the Start menu: Start > All Programs > Accessories > Notepad
2. Right-click on the Notepad shortcut and select Run as Administrator. Notepad opens.
Click File | Open. The File Open dialog opens.
Enter this path in to the File name text box:
```
%windir%\system32\drivers\etc\hosts
```
Find your Sitecore instance’s reference in the list of host headers. It will look something like:
```
127.0.0.1    SitecoreInstanceName
```
Delete that line
Save and close

Step 3: Detach your databases

Open SQL Server Management Studio
Connect to your local database server
Open a new query window: File | New | Query with Current Connection.

Paste the following SQL code in to the query window:

USE master

DECLARE
      @name SYSNAME
    , @sql VARCHAR(MAX)

SET @name = '<YOUR INSTANCE NAME HERE>'

SET @sql = '
    DROP DATABASE {0}Sitecore_Analytics
    DROP DATABASE {0}Sitecore_Core
    DROP DATABASE {0}Sitecore_Master
    DROP DATABASE {0}Sitecore_Web
    '

SET @sql = REPLACE( @sql, '{0}', @name )

EXEC( @sql )

Make sure that the @name variable (on line 7) has been set to your Sitecore instance’s name. If you don’t have DMS installed, delete line 10, the one that ends with Sitecore_Analytics.

Close SQL Server Management Studio.

Step 4: Delete the file system

In Windows Explorer, find the folder for your Sitecore intstance, usually
```
C:\inetpub\wwwroot\<YOUR INSTANCE NAME>\
```
Delete that folder

And that’s it. Your manually installed Sitecore instance has been removed from your system.

Spoofing DMS GeoIP Lookups for Localhost

Tue, 19 Jun 2012 19:08:00 -0400

When you’re working with a copy of DMS locally or on your local network, your reports will be filled with empty GeoIP information because MaxMind doesn’t have information for local or internal addresses.

Alexander Doroshenko has a great solution to this problem related in this blog post. Basically, you can manually add a cached IP lookup to the Analytics database and update any historical entries. There’s a SQL file you can download from that blog post that does the work for you.

You’ll need to specify the IP address you’re updating plus the results of the lookup. For example, ISP, Country, Region, City, etc. You can get this info directly from MaxMind. Visit MaxMind’s City Lookup Page and put in the IP address you want to spoof.

(Not sure which IP to spoof? Try your external IP – just Google “What’s my IP?” and Google will give you you’re current external IP address.)

Refreshing TreeviewEx Controls

Sun, 17 Jun 2012 19:36:00 -0400

When you’re creating your own Sitecore applications, you might need to use a TreeviewEx control, like the one in the Content Editor that displays the Content Tree.

You might want to change the selected item in your code. You can do so using code like this:

var selectedItem = Context.ContentDatabase.GetItem("/sitecore/content/home");
this.MyTreeviewEx.SetSelectedItem(selectedItem);

Unfortunately, that won’t update the display. To make sure the display updates, set the TreeviewEx’s data context’s Folder. The DataContext for your TreeviewEx is usually set decoratively in your XAML. In my case, the DataContext has an ID of TreeDataContext:

this.TreeDataContext.SetFolder(selectedItem.Uri);

MVC Released Internally

Mon, 11 Jun 2012 11:25:15 -0400

Sitecore announced over the weekend that MVC support is being added with an internal build of Sitecore - v.6.5.1.

Read more from Lars Nielsen, and some technical challenges of setting up WinForms and MVC support in a single instance from John West here.