MVC DisplayTemplates convention broken after Edit UI update to 7.

MVC DisplayTemplates convention broken after Edit UI update to 7.1

Tobias Lund

Vote:

Hi,

After upgrading AddOn store platform and/or Edit UI from AddOn store the convention to look for templates in DisplayTemplates seem broken for ContentAreas. When trying to render a ContentArea by using Html.PropertyFor the only template being used is the one in [CMS_Installation_Directory]\Application\Util\Views\Shared\DisplayTemplates, not the one I created (~/Views/Shared/DisplayTemplates/ContentArea.cshtml).

Placing a file named String.cshtml in ~/Views/Shared/DisplayTemplates let me render the string however I want using Html.PropertyFor(x => x.MyString)

Any ideas what might be wrong?

#70216

Apr 15, 2013 12:26

Tobias Lund

Vote:

Ok, I've found a solution, but have no idea why it works...

[ModuleDependency(typeof(Web.InitializationModule))]
public class CustomizedRenderingInitialization : IInitializableModule
{
public void Initialize(InitializationEngine context)
{
ViewEngines.Engines.Insert(0, new RazorViewEngine());
}
}

Does this mean that EPiServer doesn't initialize the RazorViewEngine by default?

Before updating to EPiServer Edit UI 2.0.79 it worked without this initialization.

#70225

Apr 15, 2013 14:32

Ben McKernan

Vote:

This would have been my suggested solution. The reason this is necessary after the update is because we've added a new route specifically for a new ContentArea template. This new route is evaluated before the default view engine. I will create a bug to address the route order since there is no reason why the default route shouldn't be first. But in the mean time I suggest using the fix that you have currently.

As an aside: this new template is what adds the block personalization support. If you are overriding the ContentArea template please be aware that you will break the personalization support for blocks.

#70241

Apr 16, 2013 9:48