Macro Expression not working in Template Layout

That's the issue! I'm using an ASCX template type, I'll see if I can swap to the other.

Brenden do you have a link to the upside/downsides of using one template type vs the other I could read?

No documentation really on that, it's a preference. Some differences though:

ASCX allows you to use C# code in it, Text/HTML does not. Text/HTML allows you to use the K# Macro syntax in it, ASCX does not.

Some things are easier to write macros for while some things are easier to use straight C# for.

If you don't need to write C#, you could take advantage of the fact that HTML layouts do not require compilation, which means faster initial load and you can modify the layout on precompiled websites.

Can I input c# directly into the template on the front end or do I need to write code in the backend and add it to the project for that?

Cameron

Yeah, if you edit the layout with the Portal engine, you can always put C# code in the layout like this:

<% CMS.DocumentEngine.TreeNode node= DocumentHelper.GetDocuments(...); %>

@Dat - in some cases the code blocks <%...%> may work, or even the displaying expression <%=...%> like
<%= CMS.MacroEngine.MacroResolver.Resolve("{%CurrentDocument.DocumentName#%}") %> might work, but it depends on other controls/web parts on the page and the life cycle. So, in most of the cases you may hit this error. So, officialy the code block and inline expressions are not supported in Kentico, in the ASCX layout.

@Juraj - I've developed Portal engine sites using C# code and the Kentico API in ascx layouts extensively, and I've never experienced that error. (Kentico 10 and beyond)

Also, the documentation says this: ASCX layout type - This type of layout code supports both HTML and ASP.NET markup, i.e. the same syntax that you would use to edit a standard web form or user control, including inline code and embedded controls.

Well, may it was changed in later versions but I have seen issues on Kentico 10, 11 and 12 with this. So, maybe you are just lucky and are using it always in the same way. What I wanted to say is that it may not work in all cases and you need to know when are those inline code called and what is the page and control life cycle - so some data may not be accessible at given time. So, I would rather recommend using code behind as it is clearer, easier to debug and maintain.

I definitely think that business logic and presentation should be separate, and I don't particularly like putting C# code in the layouts. I've had clients that wanted all of the site to be implemented in Portal engine, so I know that it can be done. But like you, I also would not recommend it. Just answering Cameron's question about whether it can be done.