Context

Resolving Custom Context.Item in Sitecore MVC

Posted on by jammykam

One of the most common customizations that I have seen in Sitecore is the addition of custom processors in the httpRequestBegin pipeline, usually to add is some custom logic to resolve the context item, maybe to deal with custom URLs or wildcard items. Since this pipeline runs for every single request, there are plenty of reasons to customize here.

Most often I’ve seen , you plug in after the Sitecore.Pipelines.HttpRequest.ItemResolver processor with whatever your custom requirements are. However, if you are using Sitecore MVC (and I hope you are) then you may find that your custom logic has not been applied and the Sitecore.Context.Item has been reset back to default Sitecore logic.

This has come up a number of times on Slack and caught a few colleagues out. It also caught me out a while back when I was doing some wildcard work with MVC:

Read More

Advertisement

Creating a custom Sitecore-like Context

Posted on by jammykam

Often when working in Sitecore we extend the solution using pipeline processors, one of the most common being the httpRequestBegin pipeline. This is also where a lot of the Sitecore goodness happens – site resolving, database resolving, device resolving, language resolving and item resolving – amongst many others.

Resolving things can be expensive. It takes up precious processing time and cpu cycles, so when you have to run a piece of code you only want to do that once. It’s the same reason that Sitecore puts a lot of data into the Context object for use throughout the request. So it would be handy if we could resolve our own code only once and make it available during the request as well.

Read More