Sitecore friendly URL | Remove or change URL extension

Do you want to achieve friendly URL means remove .aspx extension or want to change .aspx extension to .asp, .php, etc. then this blog is for you!

Suppose we have original URL like this:
http://mysite.com/aboutme.aspx

We can achieve Friendly URL / Remove URL extension:
http://mysite.com/aboutme/

We can change URL Extension too:
http://mysite.com/aboutme.php
OR
http://mysite.com/aboutme.asp

We can achieve any of below URLs with few changes in Sitecore. We are going to achieve

1. How the above URL requests will be served
2. How all URLs generated by that request will follow same URL format.

 Let's see how.

How to achieve friendly url?

Sitecore architecture has inbuilt facility to achieve friendly URLs.
In Web.config, find below line and set addaspxextension="false", which simply removes aspx extension from generated URLs:

<add addaspxextension="false" alwaysincludeserverurl="false" encodenames="true" languageembedding="never" languagelocation="filePath" name="sitecore" shortenurls="true" type="Sitecore.Links.LinkProvider, Sitecore.Kernel" usedisplayname="false" />

Doing these change, Sitecore will respond to any friendly URL, also will generate all friendly URLs only. See below snap how we achieved.

How to change URL extension from .aspx to .asp, .html, etc.?

First thing is, Sitecore will support all the extensions which are Allowed from IIS. Second thing is, Sitecore itself has Allowed and Blocked extension list. So, all allowed extensions are by default accepted by Sitecore.

Any customized extension should work

You might be knowing all Sitecore processors in HttpRequestBegin pipeline. Using ItemResolver, Sitecore determines context item by the actual path from the URL without considering the extension. Means, whether extension is .aspx, .asp, .php, or even your name say .yogesh, not an issue, Sitecore will allow it and render page. :) Just thing to note, that extension should be allowed from Sitecore configurations.

See how to configure in web.config:

<preprocessRequest help="Processors should derive from Sitecore.Pipelines.PreprocessRequest.PreprocessRequestProcessor">
   <!-- Few processors might be there -->
   <processor type="Sitecore.Pipelines.PreprocessRequest.FilterUrlExtensions, Sitecore.Kernel">
      <param desc="Allowed extensions (comma separated)">aspx, ashx, asmx, asp, php, yogesh</param>
      <param desc="Blocked extensions (comma separated)">*</param>
      <param desc="Blocked extensions that stream files (comma separated)">*</param>
      <param desc="Blocked extensions that do not stream files (comma separated)"></param>
   </processor>
   
</preprocessRequest>

Now you can request any Sitecore page using asp, php or yogesh extension.

Page should generate all link by replacing the .aspx extension

Suppose we want to generate page urls with .asp extension.

For this, we have to set addaspxextension="true" means Sitecore will now generate URLs with .aspx extension. When the page is generating links of page output, we will replace the .aspx extension with .asp extension.

For that, we will change existing Link Provider with our customized one. See Web.config change.

<linkManager defaultProvider="sitecore">
      <providers>
        <!-- Comment below line which is default setting in Sitecore -->
        <!-- <add name="sitecore" type="Sitecore.Links.LinkProvider, Sitecore.Kernel" addAspxExtension="true" alwaysIncludeServerUrl="false" encodeNames="true" languageEmbedding="asNeeded" languageLocation="filePath" lowercaseUrls="false" shortenUrls="true" useDisplayName="false" /> -->

        <!-- Add our customized link provider -->
        <add name="sitecore" type="SitecoreTactics.MyLinkProvider, Sitecore.Kernel" addAspxExtension="true" alwaysIncludeServerUrl="false" encodeNames="true" languageEmbedding="asNeeded" languageLocation="filePath" lowercaseUrls="false" shortenUrls="true" useDisplayName="false" />

      </providers>
    </linkManager>

Our customized class will look like:

namespace SitecoreTactics
{
 public class MyLinkProvider : Sitecore.Links.LinkProvider
    {
        protected static new LinkBuilder CreateLinkBuilder(Sitecore.Links.UrlOptions options)
        {
            return new LinkBuilder(options);
        }

        public override string GetItemUrl(Item item, UrlOptions options)
        {
            string itemUrl = base.CreateLinkBuilder(options).GetItemUrl(item);
            if (this.LowercaseUrls)
            {
                itemUrl = itemUrl.ToLowerInvariant();
            }
            // Replace .aspx with .asp
            return itemUrl.Replace(".aspx", ".asp");
        }
    }
}

See below snap how it will look like:


Hope, it's working for you, Enjoy!!

Sitecore Event Queue - The Scalability King

Sitecore EventQueue architecture gives great scalability to Sitecore, launched with version 6.3. Enabling it can allows clustering of Content Management Servers (CMs) and Content Delivery Servers (CDs). It allows events on one server to be executed on other servers in a cluster.

Suppose, there are two instances of CM. Now, think how an item changed on CM1 will be reflected to CM2? There should be something like triggering mechanism to communicate both CMs. Event Queues are playing very important role to make both CMs synced.

How Event Queue works

1. When any item is saved on CM1, "item:saved" event is executed, it creates an instance of Remote Event (SavedItemRemoteEvent).
2. Now, the remote event is passed into Event Queue table in the respective Sitecore database. This event contains many things like Item Id, the Sitecore Instance Name on which event occured, Instance Type, Instance Data, User Name, date time when event occured, etc.
3. Each Sitecore Instance has a trigger to check this event queue periodically and collects all events to be processed.
4. All instances select events raised by other instances (Remote Events) like "item:saved:remote" and should be new or created after the instance's last processed event.
5. Suppose, the CM2 finds an event of "SaveItemRemoteEvent", then it clears cache related to the item and update the data of that item. Similarly, each different type of event has its own operations to perform, which are specified in the web.config in pipelines.

According to this architecture, the CMs can have many instances in a cluster, theoretically n numbers of CM or CD instances can work very well in a cluster using EventQueue and gets updated all the time. :)

Configure  Event Queues

To enable EventQueues, from web.config, find EnableEventQueues setting. Set its value to true. This setting can also be set from \App_Config\Include\ScalabilitySettings.config, which will be given more precedence over web.config settings.

<!--  ENABLE EVENT QUEUES
If enabled, Sitecore sends local events to the event queue available to remote instances, 
and handles events in the queue from remote instances. -->
      <setting name="EnableEventQueues">
        <patch:attribute name="value">true</patch:attribute>
      </setting>
<!--  Event Queue's processing interval. 
Event Queue will be requested to process after below given interval -->
      <eventqueue>  
       <processinginterval>00:00:02</processinginterval>  
      </eventqueue>

Things to take care regarding Event Queue

1. If we have more than one instances in an environment, it is must to EnableEventQueue on all the instances
2. The processinginterval should be as minimum as we can set, say 2 seconds, so each server gets synced in no time.
3. All CM instance should have exact time.
   If two instances have time difference of 5 minutes, then there the instance running late will get updates of other instance after 5 minutes, so sync will never be done between them.
4. When events are not triggered on time on the remote(other) servers, clear the EventQueue table from database.
   
   Let's consider a practical case, once a user by mistake published 10k items and publishing is going on through PI. There are few others items queued after it, which are more important. Now, we found that we have to stop the 10k items' to give priority to other items. We have only one option to restart PI. But after PI restart, once we found once that those 10,000 items started publishing again (No one added them again)!! Ufff.. finally we came to know there was some issue with Event Queue processing/clearing. We cleared Event Queue and restarted PI again, now good to see, problem is solved. :)

Different events handled by EventQueue

Event Queue is used to make CMs in sync when item operations like Save, Creation, Deletion, Recycling, Restore, etc. happens. This sync happens with the help of Master database EventQueue.

Suppose, we have a separate PI to do publishing apart from a CM. Now, each publish set from the CM is done by PI, how? It is just because of Event Queues. CM sends an event for PI to do publish. So, PI will trigger the event and starts doing actual publish.

When items are published from CM or PI, CD should be notified when the publish is completed, CD starts clearing html cache accordingly. This happens by Event Queue on web database.

Great Sitecore Event Queue architecture!!

Sitecore Query Strings Parameters

Sitecore gives different querystring parameters like choosing item, language, device, etc. stuffs to manage them easily without any configurations, etc. Also, it uses many querystring parameters to manage Content Editor efficiently.

Content Editor

There are many parameters Sitecore uses to manage content editor.

sc_content

- It changes the Sitecore database for the context of Content Editor. If querystring has value as sc_content=web, then content editor will open items from web database.

sc_lang

- It changes the Sitecore's default language. It is not exactly Item's language, but you can say language of the Sitecore's ribbon. For example, if sc_lang=en-GB, then in Content Editor, it will render the whole ribbon as en-GB language. If we pass this parameter for Preview/Page Editor/Normal mode, then it will set Items' language.

fo

- It will request Content Editor to open the given item directly. the item passed will be autopopulated from the tree and its properties will be shown without traversing the tree.

As per below snap, Products item has Item ID: {07D9A696-A2FE-4A59-88FB-A57FE386B8AD}. Now, if we want to open Products item directly in Content Editor, then we can pass querystring like fo={07D9A696-A2FE-4A59-88FB-A57FE386B8AD}. We can also pass Item Path instead of Item ID

ro

- It will request Content Editor to open the given item directly, but will be shown as a root item, means its parent will not be shown in the tree. Producta item has Item ID: {07D9A696-A2FE-4A59-88FB-A57FE386B8AD}.

If we pass querystring like ro={07D9A696-A2FE-4A59-88FB-A57FE386B8AD}, will open it as below.

Page Editor/Preview/Normal mode

There are many parameters Sitecore uses to preview pages.

sc_content

- It changes the database context for current requested page. If we request as sc_content=web, then it will render the whole page using item values from web database.

sc_lang

- It changes the language context for current requested page. If we request as sc_lang=de-DE, then it will render the whole page using item values from German language version. LanguageResolver processor is responsible for determining Context Language, which determins it using sc_lang querystring parameter or by current language cookie set in browser.

sc_itemid

- This parameter is mostly used for previewing particular item from Content Editor. When we preview any item from Content Editor, it opens preview/page editor window to view selected item's rendering. ItemResolver processor is responsible for determining Context Item, which determins it using sc_itemid querystring parameter or URL/site requested.

sc_device

We can change device using this parameter. If we pass sc_device=mobile, then mobile device will be set to Context Device. DeviceResolver processor is responsible for determining Context Device, which determins it using sc_device querystring parameter or by Browser agent.

Media(Images) Requests

There are many parameters Sitecore uses to alter image on-the-fly. You can refer my earlier post to see different querystring parameters for requesting images in Sitecore: Sitecore image control and querystring parameters

How Sitecore caching work

This post describes different levels of Sitecore caches. Cache plays very important role in website performance. So, understanding of all Sitecore caches is really important. If we understand all of them, then it would be easy to do performance tuning using cache settings.

This post contains just theoretical overview of cache, will be posting about practical usage and performance tuning of caches soon :)

We can check how different cache are allocated and cleared, we have a tool given by Sitecore: http://mysite.com/sitecore/admin/cache.aspx. Even a great tool available to Sitecore Market Place - Sitecore Cache Admin, which describes how actual cache is managed by Sitecore.

Different Database Cache:

Prefetch Cache

Prefetch caches contain items that Sitecore accesses during and immediately after initialization and items with children that Sitecore often accesses as a group. Sitecore maintains those caches over the life of the application.

Each database prefetch cache entry represents an item in a database. Database prefetch cache entries include all field values for all versions of that item, and information about the parent and children of the item.

Read How to configure prefetch cache and how it affects application startup.

Data Cache

Data caches are dependent on database prefetch caches, which operate at a lower level. Like database prefetch caches, each entry in a database data cache represents a single item in a database, including parent/child relationships and field values for all versions in all languages of that item. Sitecore does not pre-populate database data caches.

The Caching.DefaultDataCacheSize setting in the web.config file specifies the default size for database data caches.

The purpose of this cache is to minimize the amount of requests to the database. This is extremely important for performance, as requesting items from the database is rather expensive.

Item Cache

Item caches store items. Database item caches are dependent on database data caches, which operate at a lower level. Each entry in a database item cache represents a single version of an item in a single language. Sitecore does not pre-populate database item caches.

The Caching.DefaultDataCacheSize setting in the web.config file specifies the default size for database data caches.

Database item caches contain objects of type Sitecore.Data.Items.Item.

The Caching.DefaultltemCacheSize setting in the web.config file specifies the default size for database item caches.

It would be best to have the average size of an item in Caching.AverageltemSize configuration attribute.

Standard Value Cache

Standard values caches contain standard values for data templates in the database. Sitecore does not pre-populate database standard values caches. Database standard values caches do not depend on any other caches.

The Caching.StandardValues.DefaultCacheSize setting in the web.config file specifies the default size for database standard values caches.

Sitecore uses the Caching.StandardValues.AverageValueSize setting in the web.config file to estimate the amount of memory consumed by the database standard values cache.

Different Website Cache

If you don't specify cache at a level then it gets its values from default website cache in the web.config. We can customize all these cases site-wise.

<cacheSizes>
 <sites>
         <website>
            <html>10MB</html>
            <registry>0</registry>
            <viewState>0</viewState>
            <xsl>5MB</xsl>
         </website>
       </sites>
</cacheSizes>

HTML Cache

The HTML cache (also known as the output cache) associated with each managed Web site contains the output generated by individual renderings under different conditions.

Sitecore provides caching options which allow the rendered data to be retrieved from cache if the data source, device, authentication status, user, rendering parameters and/or query string parameters are the same as the previous request.

Sitecore allows developers to define output cache criteria in three places:

• In the Caching section of the sublayout and rendering definition item. (Global)
• In the properties of the presentation component when you statically bind it to a layout or sublayout. (Static Controls)
• In the Caching section of the Control Properties dialog when you bind a presentation component to a placeholder in layout details. (Dynamic)

HTML cache is disabled in the preview, webedit and debug modes.

Filtered Item Cache

The filtered items cache associated with each managed Web site contains information about versions of items relevant to different users.

The filteredItemsCacheSize attribute of each /configuration/Sitecore/sites/siteelement in the web.config file specifies the size of the filtered items cache for that managed Web site.

The Caching.DefaultFilteredItemsCacheSize setting in the web.config file specifies the default size of the size filtered items caches.

Registry Cache

The registry cache associated with each managed Web site contains data used primarily by the Sitecore user interfaces.

The registryCacheSize attribute of each /configuration/Sitecore/sites/site element in the web.config file specifies the size of the registry cache for that managed Web site.

The Caching.DedaultRegistryCacheSize setting in the web.config file specifies the default size for the registry caches.

Media Cache

Sitecore stores all media files to physical file system. All other cache are stored in RAM actually.

When publishing is done, Sitecore does not clear Media Cache like it does for other caches. Sitecore clears these media cache periodically.

User Cache

The client data store cache stores information about each authenticated user, such as the username or other user properties.

The Caching.DefaultClientDataCacheSize setting in the web.config file specifies the size of the client data store cache.

The disableClientData attribute of each /configuration/Sitecore/sites/site element in the web.config file enables or disables client data caching for that managed Web site.

Proxy Cache

Sitecore has a proxy item feature that allows items in one area of the content tree to appear in another.

These proxy items behave in the same way as normal items but have unique IDs to distinguish them from the original items.

The proxy cache keeps track of these IDs and how they map back to the original items.

How cache clearing works?

HTML cache

On publishing of any item, HTML cache is cleared. If we are using multisite module, the we can rewrite HTML cache module to clear HTML cache for item's related site. HTML cache for each page is built from multiple items, so publishing a single item, we cannot judge at how many items it would affect. That's why we have to clear full site HTML cache.

Item cache

Whenever any item is published, its Item Cache is also updated. If you publish an item which is linked to other items, then these items are cleared as well.

If you publish standard values or a template, it will clear all items based on that template.

If you delete/recycle/restore any item, its parent item's cache also updated, similarly while doing sorting, their siblings cache might get updated.

Data cache

Data cache is updated incrementally when changes take effect after a publish. It is rebuild incrementally when the items are requested again.

Prefetch cache

By default, items/templates specified in the config file are cached in Prefetch Cache when application initiated. Prefetch cache are updated same way of Data Cache.

Note: An ASP.NET application server restarts effectively removes all entries from all caches, except media cache. If we are using ASP.NET caching based on some items' values, we must clear ASP.NET cache too on publishing.

Sitecore Image Parameters and Image Control

This post is for those who are still:

- Creating duplicate Image Items on Sitecore for achieving Responsive Web Design or Image Gallery.
- Creating separate images for desktops, phones and tablets to achieve responsive web design.
- Creating Thumbnails, Preview and original images for image galleries.
- Resize images on-the-flyas per requirement.

Tired from maintaining multiple items(create, update, delete, publish) of each image?

There is a short and sweet solution within Sitecore itself to give freedom from above headache, that is Sitecore Image Parameters and Sitecore Image Control.

How it is beneficial?

- Using it, each requested image is created/scaled and cached on disk by Sitecore itself, so it does not impact on performance.
- This gives freedom from multiple uploads/updates/publish of same image and multiple Item Cache
- Saves lots of human efforts and time
- Freedom from, reduction in database size, beneficial from maintenance and point-of-view too.

Different Image Parameters:

w

Width of image

h

Height of image

mw

Maximum width of image

mh

Maximum height of image

iar

Ignore Aspect Ratio. Value should be 1 or 0.

as

Allow Stretch. Value should be 1 or 0.

thn

Create Thumbnail. Value should be 1 or 0.

bc

Background Color (When there is no aspect ratio set)

sc

Scale Image. 1 is default value.

Few Samples:

Expected Result	Sitecore Image Control	Image URL
Original	<sc:Image Field="My Image" />	http://com.com/~/media/myimage.jpg
Width=150	<sc:image field="My Image" width="150" />	http://com.com/~/media/myimage.jpg?w=150
Height=200	<sc:image field="My Image" height="200" />	http://com.com/~/media/myimage.jpg?h=200
Height=200 Width=200 Ignore Aspect Ratio	<sc:image field="My Image" width="200" height="200" iar="true" />	http://com.com/~/media/myimage.jpg?h=200&w=200&iar=true

You can findout all parameters for image control from:
http://sdn.sitecore.net/Articles/XSL/5%203%20Enhancements/Image%20Enhancements.aspx

Now, you will think that how can we achieve adaptive images using theImage control. Well, for that we have two approaches:

1. Use Sitecore Adaptive Images module.
2. Use JS plugins like responsejs. This is more preferable approach.
   
   This plugin needs all images to be rendered as below:
   
   
   Means, the the control we create, should render image tag supporting different size attribute and value urls.
   
   Here, if plugin finds the device screen is suitable to 330 width, it will update image's source to data-330's value. Similarly to data-961 when it finds device's screen suitable to 961 width.
   
   For this, we can extend Sitecore's Image Control to achieve this image rendering.

Enjoy!!

Sitecore 404 Page Not Found handler without 302

When your requested page not found and while handling 404 error page, are you getting 200 or 302 HTTP Status Error Code? Then there is something to do more to achieve 404. For SEO purpose, our 404 error page should return a 404 response header. By default Sitecore shows a Page Not Found page but it's not 404 in real.

There can be many approaches to achieve 404 in Sitecore depending on our requirement. Here, two of them are shown.

1. Show a specific Sitecore page on 404.
   This will show 404-Page Not Found page with current language, device and layout requested. Means, if you request any page from mobile and desktop, both will show 404 but with different rendering/output set in both device/layouts.
2. Simple 404 - Page Not Found text.
   This will simply show text with 404 status code.

1. Show a specific Sitecore page on 404.

Step - 1:

Create a new processor which will be used before ExecuteRequest in httpRequestBegin pipeline in web.config. If context item is null, then set an Sitecore Item (errorpage) as Context and set a flag in Request Cache that this request is of 404.

namespace SitecoreTactics.Pipelines.HttpRequest
{
    public class Page404Resolver : Sitecore.Pipelines.HttpRequest.HttpRequestProcessor
    {
        public override void Process(Sitecore.Pipelines.HttpRequest.HttpRequestArgs args)
        {
            // If current item not available in Sitecore, then
            if(Sitecore.Context.Item == null)
            {
                // Find an error-page item and set it to context Item
                Item item404 = Sitecore.Context.Database.GetItem("Path of error-page Item");
                Sitecore.Context.Item = item404;

                // Set a flag in request cache to say this request is of 404.
                Sitecore.Context.Items["is404"] = "true";
            }
        }
    }
}
//else, continue pipeline... So no need to write else block

Step - 2:

In web.config, do below settings in HttpRequestBegin pipeline.
Add above processor Page404Resolver below ItemResolver as below.

<httpRequestBegin>
  <-- few processors -->
  <processor type="Sitecore.Pipelines.HttpRequest.ItemResolver, Sitecore.Kernel" />
  <processor type="SitecoreTaxtics.Pipelines.HttpRequest.Page404Resolver, SitecoreTactics.Pipelines" />
  <-- few processors -->
</httpRequestBegin>

Step - 3:

In layouts, check whether this request Cache has flag to true (means 404), then set the Status Code to 404 and description
Change in Layout:

protected override void Render(HtmlTextWriter writer)
{
    base.Render(writer);

    // If current request is for 404-errorpage...
    if (Sitecore.Context.Items["is404"] == "true")
    {
        try
        {
            Response.StatusCode = 404;
            Response.TrySkipIisCustomErrors = true;
            Response.StatusDescription = "File not found";
            Response.End();
        }
        catch (ThreadAbortException)
        {
             // Log error
        }
    }
}

2. Simple 404 - Page Not Found text

To just write down some 404 message, use above processor itself, but change code as below. In this approach, there is no need to write any code in layout as above.

// If current item not available in Sitecore, then go for 404
if (Sitecore.Context.Item == null)
{
  System.Web.HttpContext context = System.Web.HttpContext.Current;
  
  // Apply Response Headers
  context.Response.TrySkipIisCustomErrors = true;
  context.Response.StatusCode = 404;
  context.Response.StatusDescription = "Page not found";
  
  try
  {
    // Write 404 - description to response
    string str404 = "The page you requested does not exist.";
    context.Response.Write(str404);
    context.Response.End();
  }
  catch (System.Threading.ThreadAbortException ex)
  {
    // Log error
  }
}

That's it, you have your 404!!

Sitecore Pipelines and Processors in web request

Sitecore is such a flexible CMS, you can do any customizations so quickly. Sitecore has customized ASP.NET's framework to provide more flexibility and power for itself and Sitecore developers.

Pipelines are nothing but to perform a sequential opterations/process, which is defined in web.config. Which gives better flexibility by adding new or overriding existing processors.

Below are the pipelines covered while any page is requested. These pipelines would be different on Staging and Live environment, also it depends on different modules installed on Sitecore environment.

initialize

---

This pipeline initiate Sitecore application

preProcessRequest

---

It is invoked for each HTTP request managed by ASP.NET. It is used to prevent Sitecore from processing requests with specific extensions other than .aspx. And yet, it is not used for request processing logic.

Below are processors in this pipeline:

NormalizeRawUrl

If Sitecore not getting proper raw URL, then it normalize (rewrite)  it and set into current context.

IIS404Handler

It handles 404 error page and rewrite to proper URL.

FilterUrlExtensions

It decides which extensions to allow or reject. i.e., aspx, html, asmx, ics, etc. are allowed (Allowed/Blocked extensions are specified within this processor configurations in web.config file)

StripLanguage

It rewrite the URL by embedding language.

httpRequestBegin

---

This pipeline contains processors which are used for request processing logic. It sequential finds Site, Device, Language, Item, Layout, etc. details for the requested URL and then allow Sitecore to continue rendering it.

CheckIgnoreFlag

This is where Sitecore realises the html file doesn’t exists and redirects it to it’s 404 page.

StartMeasurements

It starts timer to record performance counters/measurements. The timer is stopped and performance counters/measurements are retrieved in the httpRequestEnd pipeline’s StopMeasurements processor. If any counter exceeds the defined threashold, it's logged in log file.

IgnoreList

Decides whether handle the current request or not depending on the ignoreUrlPrefix setting value. It checks if the requested page is in the ignore URL list in the web.config.

Mostly the URLs which Sitecore does not render itself are set in IgnoreList. Like, RichTextEditor, Telerik Dialogs, axd files.

Set IgnoreUrlPrefixes to a '|' separated list of url prefixes that should not be regarded and processed as friendly urls (ie. forms etc.)

If such page is defined, the pipeline terminates

SiteResolver

It parses the incoming URL and Determines the current site defined in /configuration/sitecore/sites. It identifies Site either by hostname of the current request or by passed querystring parameter: sc_site.It resolves Sitecore Site object. This object is now added to the current Context (Sitecore.Context.Site)

UserResolver

Identifies current user and add it to current request context (Sitecore.Context.User). In backend, Sitecore uses standard ASP.NET membership.

DatabaseResolver

Identifies current database and add it to current request context.(Sitecore.Context.Database. It also resovles database by passing querystring parameter:sc_content.

BeginDiagnostics

If debugging is on, it starts diagnosis of sitecore request.

DeviceResolver

Resolves the current Sitecore device either by querystring parameter sc_device or then knowing BrowserAgent and add it to current context (Sitecore.Context.Site.Device)

LanguageResolver

Resolves the Sitecore context language and add it to current context (Sitecore.Context.Language). Language can be identified either by querystring parameter sc_lang or by cookie (SiteName#Lang) value set to the browser.

CustomHandlers

It triggers custom handlers defiend in customHandlers/handler in web.config. This fulfills use of .ashx requests. Like, for url starts with ~/media/, the hander is set to sitecore_media.ashx. So, it will proceed for all requests of media. Similarly we have different handlers for api, xaml, icon, feed, etc.

FilterUrlExtensions

This processor is actually deprecated, same processor is taking care in preprocessRequest pipeline.

QueryStringResolver

It analyzes such query string as “sc_itemid”. It checks this item in context database with context language. If this item is valid, then it sets it to current context.

DynamicLinkResolver

It parses dynamic links (Links served using ~link.aspx) and gives itemid, language and database details by using a media prefix syntax (specified in the configuration/sitecore/mediaLibrary/mediaPrefixes section of web.config).

Depending on it, it sets this item as Context Site item.

AliasResolver

One Sitecore item can have multiple aliases, means one item can be accessed using different URLs. It checks the requested URL to see if it matches an alias that exists on the system.

An Alias is a an alternate path for an item when browsing the web site.

For this "AliasesActive" setting should be enabled in web.config

DefaultResolver

Resolves the start path item for the context site. Sitecore instantiates this item using the “RootPath” and “StartItem” attributes of the context site by simply concatenating these values when

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

FileResolver

It checks whether this request is a physical file or not. If it is physical file, then will be served as is, otherwise Sitecore will use its filepath as default.aspx (Default Page) and and continue request with Sitecore rendering process. If it finds same Item Name and a physical file, then physical file will be getting more priority.

ItemResolver

Resolves the Sitecore context item from the incoming URL.

The item will be null when a request is requested, which does not find any Sitecore item.

LayoutResolver

It determins layout for the request from querystring parameter: sc_layout or by getting layout assigned to the Sitecore.Context.Item (Set from the presentation details). Sitecore assigns Layout to a request by updating Sitecore.Context.Page.FilePath

ExecuteRequest

Rewrites the context path and handles the “item not found” or ”layout not found” errors

renderLayout

---

PageHandlers

Custom page handlers are executed here defined in pageHandlers/handler in web.config. We are not having any custom page handlers.

SecurityCheck

Checks security of all items in request for current user. It also checks security depending on Current Site requested and Preview Mode.

InsertRenderings

Adds renderings to the current page, which are assigned.

PageExtenders

We can add page extenders here defined in pageextenders/pageextender. For example, PreviewPageExtender, WebEditPageExtender, DebuggerPageExtender

BuildTree

Builds full page, and expands all controls and placeholders.

InsertSystemControls

All controls are inserted to the page as System Controls.

InsertUnusedControls

All unused controls are inserted to the page as System Controls.

BrowserCaching

Sets browser caching headers. Also add last modified header (Item updated DateTime)

My first ever blog post!

This is my first ever blog post for Sitecore on my website and I am not sure what to write! 

I have lots of hopes and dreams associated with having a new website that allows me to do so many things that I have wanted to do for so long and yet haven’t had the ability (or time) to do properly.

I would be posting here about my learning, experiments and other tactics on Sitecore. Will see how this go ahead. :)