4

I have inherited a Sitecore website with a public class named GatedPageResolver that inherits the Sitecore.Pipelines.HttpRequest.HttpRequestProcessor class and adds code to look for a Boolean check box value on a Sitecore template.

The GatedPageResolver is wired into the execution pipeline so that it is called for every HTTP Request.

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <pipelines>
      <httpRequestBegin>
        <processor type="MyCompany.Framework.Pipelines.HttpRequestBegin.GatedPageResolver, MyCompany.Framework" patch:after="processor[@type='Sitecore.Pipelines.HttpRequest.ItemResolver, Sitecore.Kernel']"/>    
      </httpRequestBegin>
    </pipelines>
  </sitecore>
</configuration>

But, the code does not seem to get called.

I have verified the config file code using the Sitecore Config Builder tool.

Am I missing something?

Improve this question
5
  • 4
    Enable pipeline profiling, open the pipelines.aspx page, and check if your processor is there. Then clear the result set. Make an HTTP request to your site in another tab, then refresh pipelines.aspx. Check if all processors in the httpRequestBegin pipeline have the same execution counts. If some have fewer executions, you can figure out which processor aborted the pipeline before the execution got to your custom processor.
    – Dmytro Shevchenko
    Nov 2, 2016 at 6:58
  • Do you have any other custom pipelines? Can you post a sample of your code.
    – jammykam
    Nov 2, 2016 at 10:28
  • 1
    @DmytroShevchenko The GatedPageResolver pipeline is there and all the httpRequestBegin processors have an execution count of 4.
    – ADH
    Nov 2, 2016 at 11:35
  • @ADH this means that the processor is executed. Which in turn means that you didn't use a correct way of checking whether it was executed.
    – Dmytro Shevchenko
    Nov 2, 2016 at 11:36
  • I am running off a restore of my production database. Okay, thanks.
    – ADH
    Nov 2, 2016 at 11:41

3 Answers 3

Reset to default
9

The usual path I take when approaching these things is to use pipeline profiling.

  1. Open the pipelines.aspx page and check if your processor is there, at all. If it isn't, you'll need to review your .config patch file.
  2. Clear the result set by clicking "Reset".
  3. In another tab, make an HTTP request to a page on your site.
  4. Refresh pipelines.aspx.

The above steps will show you which processors were run for a single page request and how many times.

Check if all processors in the httpRequestBegin pipeline have the same execution counts. If some processors have fewer executions, that means that some processor has aborted the pipeline before the execution got to your custom processor. In this case, you'll probably need to insert your processor further up in the pipeline so that it is executed before the aborting processor.

If all processors were executed the same amount of times (that is greater than zero), that means that your custom processor was executed. Which in turn means that you didn't use a correct way of checking whether it was executed to begin with.

Improve this answer
2

If this is your complete config file, try to add this at the beginning:

<?xml version="1.0" encoding="utf-8"?>

Two another things you could verify:

  • Can you see the processor in /sitecore/admin/showconfig.aspx? if not, than your patchfile doesn't get loaded
  • You could put a breakpoint at the first line of your code, maybe there is a bug in it, preventing your code from being executed?
Improve this answer
0
2

Are you using Sitecore.MVC?

Sitecore.MVC.config patches itself in after the ItemResolver as well, and I'm thinking you may end up after the MVC patches. And if so, Sitecore might have decided it's an MVC request and aborted this pipeline.

  <httpRequestBegin>
    <processor type="Sitecore.Mvc.Pipelines.HttpRequest.DisplayFatalErrors, Sitecore.Mvc" patch:after="processor[@type='Sitecore.Pipelines.HttpRequest.IgnoreList, Sitecore.Kernel']" />
    <processor type="Sitecore.Mvc.Pipelines.HttpRequest.TransferRoutedRequest, Sitecore.Mvc" patch:after="processor[@type='Sitecore.Pipelines.HttpRequest.ItemResolver, Sitecore.Kernel']" />
    <processor type="Sitecore.Mvc.Pipelines.HttpRequest.TransferControllerRequest, Sitecore.Mvc" patch:after="processor[@type='Sitecore.Pipelines.HttpRequest.LayoutResolver, Sitecore.Kernel']" />
    <processor type="Sitecore.Mvc.Pipelines.HttpRequest.TransferMvcLayout, Sitecore.Mvc" patch:after="processor[@type='Sitecore.Pipelines.HttpRequest.LayoutResolver, Sitecore.Kernel']" />
  </httpRequestBegin>

This is the processor you need to get in before.

    <processor type="Sitecore.Mvc.Pipelines.HttpRequest.TransferRoutedRequest, Sitecore.Mvc" patch:after="processor[@type='Sitecore.Pipelines.HttpRequest.ItemResolver, Sitecore.Kernel']" />
Improve this answer
3
  • ItemResolver processor is always called, even in MVC, the transfer happens afterwards (when the item may get resolved again)
    – jammykam
    Nov 2, 2016 at 10:26
  • 2
    Yes. But OP patches "after" the ItemResolver. And MVC does the same, with a TransferRouteRequest call. I was thinking; if MVC config comes last in the patch chain, the TransferRouteRequest executes before OPs patch?
    – Mark Cassidy
    Nov 2, 2016 at 10:32
  • I see what you're saying. Yes true, I'm so used to putting my configs in a z folder so it always patches after Sitecore ones :D
    – jammykam
    Nov 2, 2016 at 10:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.