Problem when using RenderMacro in template for root node
Hi Umbraco ppl,
I'm experiencing some weird behaviour using @Html.RenderMacro (Umbraco 7.1.2)
To get some quick n' dirty caching, I want to wrap all my pages in a RenderMacro call, so I can take advantage of the Per-Page caching.
This means that for each template I have the following elements (example):
This works fine for "Article" and a number of other similar templates. However as soon as I attempt this on the root node (the frontpage), I get this error in UmbracoTraceLog.txt:
2014-06-19 21:59:53,192 [66] ERROR Umbraco.Core.UmbracoApplicationBase
- [Thread 51] An unhandled exception occurred System.Reflection.TargetInvocationException: Property accessor
'parentId' on object 'Umbraco.Web.Models.DynamicPublishedContent'
threw the following exception:'Object reference not set to an instance
of an object.' ---> System.NullReferenceException: Object reference
not set to an instance of an object. at
Umbraco.Web.Models.DynamicPublishedContent.getparentId() --- End
of inner exception stack trace --- at
System.ComponentModel.ReflectPropertyDescriptor.GetValue(Object
component) at
Umbraco.Core.ObjectExtensions.ToDictionary[TVal](Object o, String[]
ignoreProperties) at Umbraco.Web.UmbracoHelper.RenderMacro(String
alias, Object parameters) at
ASP.PageViewsFrontpagecshtml.Execute() in
c:[censored]\wwwumbraco\Views\Frontpage.cshtml:line 16 at
System.Web.WebPages.WebPageBase.ExecutePageHierarchy() at
System.Web.Mvc.WebViewPage.ExecutePageHierarchy() at
System.Web.WebPages.WebPageBase.ExecutePageHierarchy(WebPageContext
pageContext, TextWriter writer, WebPageRenderingBase startPage) at
System.Web.Mvc.RazorView.RenderView(ViewContext viewContext,
TextWriter writer, Object instance) at
System.Web.Mvc.BuildManagerCompiledView.Render(ViewContext
viewContext, TextWriter writer) at
Umbraco.Core.Profiling.ProfilingView.Render(ViewContext viewContext,
TextWriter writer) at
System.Web.Mvc.ViewResultBase.ExecuteResult(ControllerContext context)
at
System.Web.Mvc.ControllerActionInvoker.InvokeActionResult(ControllerContext
controllerContext, ActionResult actionResult) at
System.Web.Mvc.ControllerActionInvoker.<>cDisplayClass1a.17()
at
System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilter(IResultFilter
filter, ResultExecutingContext preContext, Func1 continuation) at
System.Web.Mvc.ControllerActionInvoker.<>cDisplayClass1a.<>cDisplayClass1c.
If I create a child node of the exact same type using the exact same template, everything works correctly (so I have a frontpage as a child of frontpage, just for testing).
I have stripped all code away from the MacroPartial view, so it simply outputs "test", to rule out problems in the macro view code.
Is this an Umbraco bug, or am I missing something obvious here?
If it is a bug, are there any suggested workarounds?
Problem when using RenderMacro in template for root node
Hi Umbraco ppl,
I'm experiencing some weird behaviour using @Html.RenderMacro (Umbraco 7.1.2) To get some quick n' dirty caching, I want to wrap all my pages in a RenderMacro call, so I can take advantage of the Per-Page caching.
This means that for each template I have the following elements (example):
Views/Article.cshtml
Views/MacroPartials/ArticleMain.cshtml
(with an associated macro "RenderArticle")
This works fine for "Article" and a number of other similar templates. However as soon as I attempt this on the root node (the frontpage), I get this error in UmbracoTraceLog.txt:
If I create a child node of the exact same type using the exact same template, everything works correctly (so I have a frontpage as a child of frontpage, just for testing). I have stripped all code away from the MacroPartial view, so it simply outputs "test", to rule out problems in the macro view code.
Is this an Umbraco bug, or am I missing something obvious here? If it is a bug, are there any suggested workarounds?
Ok, problem is that homepage doesn't have a parentID, can you post your entire articlemain.cshtml?
Also do you know you can cache a partial view directly without using a Macro? See bottom of this doc for details
is working on a reply...