The Sitecore Context

The Data Template Field TITLES in Content Editor thread on the Sitecore Developer Network (SDN) forums prompted me to write this blog post about the Sitecore context. For more information about the Sitecore context, see the Presentation Component API Cookbook.

The Sitecore context, exposed by the static Sitecore.Context class, contains information about the Sitecore installation and the current HTTP request. Processors in the httpRequestBegin pipeline defined in the web.config file are largely responsible for defining the Sitecore context. After Sitecore determines the context database, it determines the context item in that database. The layout engine processes layout details in the context item. Like any other pipeline, you can add, remove, and override processors to implement desired functionality.

Properties of the Sitecore context indicate a variety of information, including the current managed web site and database accessed, the security context, and the content item requested including language and version. Some critical properties of the Sitecore context may expose a value before invocation of the corresponding pipeline processor.

Sitecore determines context properties from a variety of sources. For example, the context language can come from the URL path, from the query string, from a cookie, or from other information. Like many Sitecore context properties, Sitecore could determine the language from properties of the first /configuration/sitecore/sites/site element in the web.config file with attributes matching the current request (see web.config for more information). Sitecore context properties can also depend on cookies, such as for authentication, or to specify the user interface when the URL cannot.

The Sitecore user interfaces are part of a Sitecore solution that uses the exact same software architecture and APIS as the managed web sites that you develop, but with additional features such as the Sheer UI. Unlike your data, which publishes from the master database to one or more publishing target databases, the Core database drives the Sitecore user interfaces without publishing.

The URLs of the Sitecore browser-based desktop and the Content Editor user interfaces activate the /configuration/sitecore/sites/site element named shell, but the Page Editor or Preview by default access the /configuration/sitecore/sites/site element named web. Other aspects of the Sitecore context, such as the context database and language, may depend on other attributes of that element.

There are several important differences between the Sitecore context for the managed web site(s) and the Sitecore context for the user interfaces. For a managed Web site, the context user is typically a specific user or the anonymous user in the Extranet security domain. For the Sitecore user interfaces, the context user is an authenticated user in the Sitecore security domain. The context language for the managed web site and for the Page Editor and Preview user interfaces is the language of the published Web site, while the context language for the Content Editor and the Desktop is the language of the Sitecore user interface as selected on the Sitecore login screen. Probably most importantly, for Sitecore user interfaces including the desktop and the Content Editor, the context database is the Core database containing Sitecore configuration information rather than the Master database containing all versions of all managed content.

You can access the context database through the Sitecore.Context.Database property. In the Sitecore desktop and the Content Editor, you can access the content database through the Sitecore.Context.ContentDatabase property. In these user interfaces, the context database is always Core; the Content database is the Master database by default, but in the Sitecore desktop, can change if an administrator selects a database using the icon on the taskbar. On the managed web sites and in user interfaces such as the Page Editor and Preview, the context database defaults to the Master database and the content database is undefined.

The difference between the context database and the content database is especially important when developing Sitecore user interface components. Use the context database to configure your application; use the content database for data managed by the context user.

Consider how Sitecore determines the context database and the content database, which can depend on properties of the context site. Sitecore can use iframes for applications, which have URLs other than that of the parent window. The child window gets only context passed by cookies from the parent window, such as the authenticated user. To activate a site, put your application in a subdirectory matching its physicalFolder attribute, such as /sitecore modules/shell or even /sitecore/shell, and use the sc_content database to activate the content database if needed.

If data does not seem to appear in a database, consider the Sitecore context and publishing. Most likely, you added the data to the Master database, but have not published that data to the publishing target databases, and you are accessing a managed web site rather than a Sitecore user interface. Or maybe you automatically imported data into a publishing target database rather than the Master database, and publishing from Master to the publishing target removed those items, or you are accessing the Master database. Content may not appear if the context user does have security access rights to the data. Remember that you have to publish changes to access rights as well. For more reasons why content may not appear, see Missing Content on SDN.

The root cause of the original issue on the forum was the difference between the context language (Sitecore.Context.Language) and the content language (Sitecore.Context.ContentLanguage). The developer had correctly populated the Title property of a data template field for the content language rather than the context language.

Update 24.November.2010: Note that both Preview and the Page Editor set the context site as they would for the managed web site, but set the context database to Master, where the managed web sites typically use a publishing target database such as the default Internet publishing target that references the Web database.

  • Hi John, Thanks for this interesting article about Sitecore context. I would like to know if it’s possible to extend the Sitecore context with custom information. For example I would like to add the notion of country or region in my website. These information will be used on all layouts, sub-layouts and rendering. To do it I see 2 solutions:  - Create a new processor in the pipeline to add them in the Sitecore context.  - Code a method in my layouts to get the info and send them to sub-layouts and renderings (like sc_lang, sc_item,etc..)  Do you think this is possible to do it ? I think so but my main concern is to keep Sitecore as standard as possible to be able to upgrade it later.  Thanks in advance for your answer.

  • @Michael: Really sorry for the delayed response. Yes I am sure that such an approach is possible. The Sitecore.Context class is static, so I don't think that you can achieve this by adding extension methods to that class (though you might still give it a try).  If the property you need to determine is specific to the context site rather than the individual request, then I am sure you could add it to the class that represents the site, as that class is not static.

  • Hi John,  In a multisite environment is it possible to change programatically change the context when in Preview mode? Issue I have is our users normally use the preview mode to navigate around the site, find the page they need and then hit edit. They are not too comfortable with the Content Editor unfortunately. This works fine if they are on and need to edit site1, but if they preview site2 and try to navigate around the site then it sends them back to site1 since the navigation have links such as /contact which, since we are in the context of, send them back there.  I know there is a key "Preview.DefaultSite" in config, wondering if we can maybe change that programatically, or maybe we need to change the way the links are written out so it keeps the context?  I'm trying to avoid setting up an additional 3 URLs and having them log in via the respective site URLs into CMS if possible, this would then allow them to work through the entire content tree from one window.  thanks

  • @Kamruz:  Logging in using different host names is the easiest solution. How do users access the Page Editor? I mean, if the log in to the Page Editor using, they should only have access to site1; they would log in to to access that site. So it sounds like they log in to Desktop or Content Editor first. In that case, I think you would have to override the commands that launch the Page Editor (or Preview, which I think this also affects) to add the sc_site query string parameter. Then I think you would have to override the link provider to add sc_site to URLs if the user is in the Page Editor or Preview, in case they click on links within the Page Editor. This seems to be a common requirement, so if time allows, I will try to blog about it, or maybe a group can work on a Shared Source solution, or maybe something already exists.   In fact, maybe that one is the complete solution; I didn't check it thoroughly.

  • Just noting that Sitecore.Context is not actually a static class, but it exposes only static properties and methods. Sitecore might change it to a static class - support case 366827 seeks to get an explanation or classification of this issue as a defect. See also