I am trying to patch the GenerateCacheKey processor of the mvc.renderRenering pipeline and for some reason my patch modifies the original processor (expected) but also adds a duplicate processor at the end of the pipeline section (unexpected). I'm using Sitecore 9.2.0 and my patch details are


<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
        <processor type="Sitecore.Mvc.Pipelines.Response.RenderRendering.GenerateCacheKey, Sitecore.Mvc" resolve="true">
          <patch:attribute name="type">MySolution.Project.HtmlCache.Pipelines.RenderRendering.GenerateCacheKey, MySolution.Project</patch:attribute>

Which results in the configuration (seen in ShowConfig.aspx)

<mvc.renderRendering patch:source="sitecore.mvc.config">
  <processor type="Sitecore.Mvc.Pipelines.Response.RenderRendering.InitializeProfiling, Sitecore.Mvc"/>
  <processor type="Sitecore.Mvc.Pipelines.Response.RenderRendering.StartStatisticRecording, Sitecore.Mvc"/>
  <processor type="Sitecore.Mvc.Pipelines.Response.RenderRendering.ResolveArea, Sitecore.Mvc">
    <param type="Sitecore.Mvc.Pipelines.Response.RenderRendering.ChainedAreaResolveStrategy, Sitecore.Mvc" desc="areaResolver">
      <Resolvers hint="list">
        <resolver type="Sitecore.Mvc.Pipelines.Response.RenderRendering.RenderingDefinitionAreaResolveStrategy, Sitecore.Mvc"/>
        <resolver type="Sitecore.Mvc.Pipelines.Response.RenderRendering.RenderingParametersAreaResolveStrategy, Sitecore.Mvc"/>
        <resolver type="Sitecore.Mvc.Pipelines.Response.RenderRendering.RenderingLayoutAreaResolveStrategy, Sitecore.Mvc"/>
    <param type="Sitecore.Mvc.AreaNamespaceRegistry, Sitecore.Mvc" desc="areaNamespaceRegistry"/>
  <processor type="Sitecore.Mvc.Pipelines.Response.RenderRendering.SetCacheability, Sitecore.Mvc"/>
  <processor type="Sitecore.Mvc.Pipelines.Response.RenderRendering.EnterRenderingContext, Sitecore.Mvc"/>
  <processor type="Spe.Integrations.Processors.ScriptedRenderRendering, Spe" patch:source="Spe.config"/>
  <processor type="MySolution.Project.HtmlCache.Pipelines.RenderRendering.GenerateCacheKey, MySolution.Project" patch:source="Project.HtmlCache.RenderRendering.config"/>
  <processor type="Sitecore.Mvc.Pipelines.Response.RenderRendering.RenderFromCache, Sitecore.Mvc" resolve="true"/>
  <processor type="Sitecore.Mvc.Pipelines.Response.RenderRendering.StartRecordingOutput, Sitecore.Mvc"/>
  <processor type="Sitecore.Mvc.ExperienceEditor.Pipelines.Response.RenderRendering.AddWrapper, Sitecore.Mvc.ExperienceEditor" resolve="true" patch:source="sitecore.mvc.experienceeditor.config"/>
  <processor type="Sitecore.Mvc.Pipelines.Response.RenderRendering.ExecuteRenderer, Sitecore.Mvc">
    <param type="Sitecore.Mvc.Pipelines.Response.RenderRendering.HttpExceptionWrappingRendererErrorStrategy, Sitecore.Mvc" desc="rendererErrorHandler">
      <param type="Sitecore.Mvc.Pipelines.Response.RenderRendering.ChainedRendererErrorStrategy, Sitecore.Mvc" desc="rendererErrorHandler">
        <Handlers hint="list">
          <handler type="Sitecore.Mvc.Pipelines.Response.RenderRendering.PageModeRenderingErrorStrategy, Sitecore.Mvc"/>
  <processor type="Sitecore.Mvc.Pipelines.Response.RenderRendering.AddRecordedHtmlToCache, Sitecore.Mvc"/>
  <processor type="Sitecore.Mvc.Pipelines.Response.RenderRendering.RecordStatistic, Sitecore.Mvc"/>
  <processor type="MySolution.Project.HtmlCache.Pipelines.RenderRendering.GenerateCacheKey, MySolution.Project" patch:source="Project.HtmlCache.RenderRendering.config"/>


As Alina Fodor mentioned in her answer, duplicate settings should only happen if there is a spurious config file lying around. In my case, this was due to a stale config file remaining in my docker container which was no longer in the solution (most likely renamed/moved).

  • I think the issue may be related to the fact that there is no resolve="true" attribute in your original processor (at least in showconfig you included in the ticket).
    – Marek Musielak
    May 17, 2021 at 12:32
  • @MarekMusielak there actually was the resolve="true" attribute (in my solution), but I somehow missed this when editing the code for the question. In any case this did not seem to change the outcome. May 17, 2021 at 13:00

1 Answer 1


I normally replace a Sitecore processor with a custom one using patch:instead rule. Example:

 <processor type= "[custom type]" patch:instead="processor[@type='[sitecore type]']"/>

The solution for patch:attribute should be (use value for your custom type):

  <processor type="[sitecore type]">
      <patch:attribute name="type" value="[custom type]" />

Also, please make sure you have the patched config only once under App_Config folder. I was able to reproduce your problem by having a copy of Project.HtmlCache.RenderRendering.config in another folder under App_Config.

  • For me, moving the element content (my new class/assembly name) to the value attribute did not make any difference. Patch:instead does patch, but then that processor moves to the end of the list :-( May 17, 2021 at 14:01
  • do patch:before and patch:after help? May 17, 2021 at 14:14
  • I've tried patch:delete to remove the original with patch:after in the new patch and its still going to the bottom! May 17, 2021 at 14:27
  • I have added your Project.HtmlCache.RenderRendering.config (inside \App_Config\Include\Project) into one of my Sitecore 9.2 solutions and it works as expected. Can you do a search for Sitecore.Mvc.Pipelines.Response.RenderRendering.GenerateCacheKey and make sure it exists only once in your App_Config folder, same for your ySolution.Project.HtmlCache.Pipelines.RenderRendering.GenerateCacheKey. Can you also provide the full path of your custom config file, sometime the name/paths impacts the order of the patches - for me it happened with site definitions. May 18, 2021 at 6:10
  • 1
    I suspect this last comment is right. That the file does indeed exist twice on the target environment. Perhaps it was moved from one Helix layer to another but target configurations not cleaned. Try renaming the config file you are editing, showconfig will then make this very clear.
    – Mark Cassidy
    May 18, 2021 at 7:27

Your Answer

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

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