Version: Umbraco 14.1 With Macros being removed, we are switching over to utilizing Blocks/Elements to handle the ability for authors to add forms to their pages. We have created the form, the element (form and theme pickers) and render them out in a partial view with the proper name. If we just print out a tag, it does render, so we know the view is functional. When we try to output using the tag helper

<div><umb-forms-render form-id="@Model.Content.Form.Value" theme="@Model.Content.Theme" exclude-scripts="true" /></div>

It doesn't render anything. When we try to render out with the Component.InvokeAsync:

@(await Component.InvokeAsync("RenderForm", new { formId = Model.Content.Form, includeScripts = true }))

We get a system.stackoverflowexception error. We've also tried to hard code these values in

@(await Component.InvokeAsync("RenderForm", new { formId = new Guid("c875c7ff-1789-422c-8688-a1abae5bd707"), theme = "themename", ThemeincludeScripts = true }))

We get the same stackoverflowexception error. Has anyone run into this or is there a way to get a better/more informative error? The current documentation (https://docs.umbraco.com/umbraco-cms/fundamentals/backoffice/property-editors/built-in-umbraco-property-editors/rich-text-editor/rte-blocks) seems to be a clone of v12/13 which still references Macros (which should be gone now).

Out of interest @Rob Schall why add forms to RTEs rather than use block list or grid?

There are places the client should have the freedom to add a form where and when they like without having strongly type all of their options in a given layout. For example, if they want to add a form into a footer field that’s a rich text area, that’s up to them. It’s the same reason there used to be a macro and the recommendation was to replace those snippets with blocks. We do use blocklists for most of our content options, but there are some areas it doesn’t make sense and creates over engineering.

> For example, if they want to add a form into a footer field that’s a rich text area, that’s up to them. So this is why I was asking - why does that 'area' have to be a RTE rather than simply a layout area using block grid or block list that can contain an RTE or a Form or indeed both. To me adding content that "is not" rich text in a "rich text area" should be the exception rather than the rule.

Looks like your not alone in this issue Rob https://github.com/umbraco/Umbraco.Forms.Issues/issues/1268

Thanks Matt. Glad to hear it'll be fixed in the next release.

> It sounds like never I have seen some good use cases for blocks in RTE's (like smart buttons that contain logic etc…) hence saying "should be the exception rather than the rule" instead of 'never'. I prefer RTE's in blocks rather than blocks in RTEs' for sure but also watch editors get frustrated when blocks get nested too deep. I also understand there were many sites that have macros that would like to keep the functionality the same but was concerned, and I think rightly, that this would encourage lot's of blocks in RTE's that would be better in Block Grid and Block List. Extracting text from an RTE in the future is one thing but an RTE full of blocks may prove a lot more difficult. I could go on about editor experience as well but not without someone buying me a pint. So in summary sure, when it's the right tool for the job then of course use it.

I agree with your thoughts there. In general, we push most of our "dynamic" content into blocklists (which more or less simulate the block grid but with more control on our end). The Rich Text "blocks" are really an emergency pull handle in scenarios where there's already a rich text field and they need something quick they can sneak in (as you mentioned, a formatted output, or in our case, a 1 field form).