CODEWITHSUNDEEP
c#asp.netsitecore
Chris Adams
Chris Adams

Reputation: 1018

Easy way to identify page requests in Sitecore

I'd like to identify requests for page in Sitecore from code running toward the end of the httpRequestBegin pipeline.

The reason is I want to redirect to an old browser page but I don't want the redirect to happen for media item requests or static content requests.

Here's what I was thinking of doing:

private static bool IsPageRequest(HttpRequestArgs args)
{
    return Context.Item != null &&
           Context.Item.Axes.IsDescendantOf(args.GetItem(Context.Site.RootPath));
}

But it looks suboptimal to me. Is there a more performant way to check this?

Upvotes: 2

Views: 1304

Answers (2)

OptimizedQuery
OptimizedQuery

Reputation: 1262

You could do:

private static bool IsPageRequest(HttpRequestArgs args)
{
    return Context.Item != null && Context.Item.Paths.IsContentItem;
}

This seems to be a little more performant. Using Reflector, IsContentItem returns true when the item's path starts with /sitecore/content/.

Upvotes: 4

jammykam
jammykam

Reputation: 16990

A suggestion not to annoy the hell outta your users: Why don't you show an overlay div with the upgrade notification and can cover all/some of the page that the user lands on. Add in a [X] to allow them to close and return to whatever they wanted to do?

You could add a static binding to the layout.aspx page and add a Sitecore rule which checks for the presence of your cookie to decide whether to output the message div/content:

There is some further information on the Sitecore httpRequestBegin Pipeline - In Detail if you still want to proceed down this route. It's really going to depend on your exact requirments. Do you want to redirect without any checks, i.e. invalid item, no layout set etc?

If so then after the relevant processor, or otherwise I would look to add your processor immediately after Sitecore.Pipelines.HttpRequest.IgnoreList or Sitecore.Pipelines.HttpRequest.FilterUrlExtensions (although this is deprecated and purely added for backwards compatibility) in <httpRequestBegin>.

Your media items should have been handled already at this stage by <preprocessRequest>.

Upvotes: 3

Related Questions