Virtual Happy Hour this month, Jun 28, we'll be getting a sneak preview at our soon to launch SaaS CMS!

Try our conversational search powered by Generative AI!

BUG: FilterTemplate can have wrong implementation for templateresolver (prerelease 11.1.0)

Vote:
 

Hi,

I was testing the Episerver prerelease 11.1.0 with Alloy demo site and noticed that sometimes the container pages were displayed in the top navigation (they shouldn't be).

Steps:

I debugged the code and believe I found the reason why this might happen. To me it looks like the injected property template resolver in FilterTemplate class can get the wrong implementation (not the same that the Alloy CustomizedRenderingInitialization has hooked event handler to). So in short I think the EPiServer.Web.Internal.TemplateResolverImplementation and EPiServer.Web.Internal.DefaultTemplateResolver registration are competing in the registration order randomly and that is why the FilterTemplate might get the "wrong" implementation.

Debug logging when working incorrectly:

CustomizedRenderingInitialization, registering for templateresolver (type: EPiServer.Web.Internal.TemplateResolverImplementation, hashcode: 40517777).

FilterForDisplay, templateFilter templateresolver type: EPiServer.Web.Internal.DefaultTemplateResolver, hashcode: 23615301

// eventhandler in [Alloy].Business.Rendering.TemplateCoordinator.OnTemplateResolved
Set SelectedTemplate = null, templateresolver hashcode: 40517777, type: EPiServer.Web.Internal.TemplateResolverImplementation

So as you can see from above log entries the menu creation used FilterForDisplay method used TemplateFilter is using another implementation for the templateresolver => no events for the registered handler that would set the template to null for container pages.

Debug logging when working correctly (the container pages are not shown in the menu):

CustomizedRenderingInitialization, registering for templateresolver (type: EPiServer.Web.Internal.TemplateResolverImplementation, hashcode: 62773796).

FilterForDisplay, templateFilter templateresolver type: EPiServer.Web.Internal.TemplateResolverImplementation, hashcode: 62773796

// event handler in [Alloy].Business.Rendering.TemplateCoordinator.OnTemplateResolved
Set SelectedTemplate = null, templateresolver hashcode: 62773796, type: EPiServer.Web.Internal.TemplateResolverImplementation

Here you can see that the TemplateFilter is using the same implementation and instance as the registered handler and the pagecontainer templates are correctly set to null and not visible in the menu.

Looking at the code I can see that the DefaultTemplateResolver has no module dependency when it is registered just with the ServiceConfiguration-attribute and the TemplateResolverImplemenation is registered using dependency to CmsCoreInitialization (EPiServer.Initialization.Internal.TemplateInitialization).

Might be that this is already fixed in mondays bits :)

#184814
Nov 05, 2017 21:03
Vote:
 

Thanks for helping us testing out the pre-release packages. The issue you are refering to have been fixed in later builds, and you correctly identified the root cause.

ITemplateResolver was though correctly registered in the container both when it was working and when it was not working, problem was that there was a missing registration of ServiceAccessor<ITemplateResolver> and for whatever weird reason StructureMap ends up with different answers every time.

#184857
Nov 06, 2017 13:24
Vote:
 
<p>Thanks for fast answer and for the clarification.</p>
#184905
Nov 06, 2017 21:06
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.