U4-6206 - Macros inserted in RTE inside a grid don't render

Created by Douglas Robar 29 Jan 2015, 20:34:21 Updated by Claus Jensen 26 Apr 2018, 08:06:15

Tags: Gold partner

Seen in 7.2.1

Create a Partial View Macro file (use a snippet for breadcrumb or whatever, it doesn't matter)

Allow the new macro to be used inside the RTE

Create a grid datatype, accepting all the default configuration options.

Add the new grid datatype as a property on a document type, using bodyText as the property alias.

Update the template to render the grid with

On a content page, add a row and insert an RTE control.

In the RTE, enter some text and insert the macro using the macro button on the RTE's toolbar.

When viewing the resulting page in the browser you'll see: Lorem ipsum dolor sit.

Macro alias: Gallery

Sed quod proximum fuit non vidit.

The browser source will be:

Lorem ipsum dolor sit.

Sed quod proximum fuit non vidit.

{code}

Comments

Sebastiaan Janssen 02 Feb 2015, 07:18:25

Hmm this is weird, worked fine on the L1 course on 7.2.1. I'll double check.


Sebastiaan Janssen 02 Feb 2015, 08:22:19

Ah in the RTE, never mind. Not sure this even should be supported, the whole point of the grid is to get away from macros in the RTE (the macro button should really be disabled by default in the grid RTE IMHO).


Douglas Robar 02 Feb 2015, 09:23:48

While I tend to agree in general I can imagine some scenarios it might still be reasonable to have a macro in the RTE of a grid element. Time will tell how people use the grid (and RTE's in the grid), especially as the grid gets more powerful over time. For now, just turning off the macro button if the RTE is in a grid seems heavy-handed.

Is this a difficult thing to fix? If it really is then we could brainstorm options. For now it would seem best to make it work and later, with more use case info to hand, the behavior could be changed if that's appropriate.

My $0.02 (or £0.02, or 0.10DKK) worth.


Scott Sinclair 10 Feb 2015, 13:17:57

As a workaround, I am using Regex.Replace to get this working. Adding Macros to the RTE is still a useful to help clients maintain consistency in there websites.

public static class Fabric8Helper {

public static string RemoveMacroRemnants(string content)
{
    //THIS IS A FUNCTION TO REMOVE UNWANTED RTE MACRO LEFTOVERS. UMBRACO 7.2.1 HAS A BUG WHICH DOES NOT REMOVE THESE USING umbraco.library.RenderMacroContent


    string html_raw = Regex.Replace(content, "<div class=\"umb-macro-holder [^<]+<!--", "");
    html_raw = Regex.Replace(html_raw, @"--><ins>Macro alias:(.*)</strong></ins></div>", "");
    html_raw = Regex.Replace(html_raw, "<div class=\\\"umb-macro-holder(.*)conmceNonEditable(.*)\\\">", "");



    return html_raw;

}

}

Call like so:

@Html.Raw(TemplateUtilities.ParseInternalLinks(Fabric8Helper.RemoveMacroRemnants(umbraco.library.RenderMacroContent(Model.value.ToString(), Model.Id))))


Scott Sinclair 10 Feb 2015, 17:08:17

Actually guys, my code only works if there is only one macro in the RTE :(

Is there any work around at all to get umbraco.library.RenderMacroContent working again?


Scott Sinclair 12 Mar 2015, 12:31:22

Any news on weather of not this will be fixed? If this will not be fixed, I'll need to take a different approach for some clients.


Dan H 24 Mar 2015, 01:03:49

Would really like to see this feature fixed. Anytime you want the RTE to be embedded in some HTML, then having the macro in an RTE is useful. Only being able to put the macro alone in its own column in a grid layout feels too limited.

I'll be pasting the html from my macro straight into the RTE source. But it's complex HTML that needs to be repeated in other places. I'd really rather keep it as a reusable macro that I can edit in Visual Studio.


Tim Geyssens 21 May 2015, 08:17:41

Also an issue when you try out forms on the fanoe starterkit, you can add a form to the grid rte but then it fails to render on the frontend...


Chris Mahoney 22 May 2015, 02:40:41

I agree with Dan; having the ability to do "inline macros" is extremely useful. For example we're currently using Umbraco 6 for our intranet and the most frequently-used macro inserts a hyperlink to our document management system.

The editor just clicks on the Macro button, selects the macro, and copies/enters the document ID from the system. The macro automatically displays the document name, size and file type, and works out the correct URL for it.

It's great functionality when it's part of the RTE. Having to break the content up into separate chunks every time you want to link to a document would quickly frustrate many editors (probably including me). Please reconsider this restriction.


Dennis Öhman 16 Jun 2015, 15:00:00

Any news on this? I can see that it's "Due in version 7.3.0" but will it be implemented or should I look for a alternative solution? :)


Rasmus Eeg Møller 25 Aug 2015, 10:53:41

Bump. I too would like the this to work.

I made a script to handle multiple macros in RTE. Check it out here: https://gist.github.com/rasmuseeg/a1b3deed488e544ccc62


Dennis Öhman 30 Sep 2015, 07:35:35

I also made a solution for this, not as a helper in the view as @rasmuseeg did, but as a HtmlHelper-extension and as a static method: https://our.umbraco.org/forum/umbraco-7/using-umbraco-7/61527-macro-in-rte-only-show-Macro-alias-AliasName#

I think there should be a public method for this (and others like the locallink parser) in umbraco core? Or maybe a more dynamic approach is needed.


Dennis Öhman 30 Sep 2015, 07:38:17

I also made a solution for this, not as a helper in the view as @rasmuseeg did, but as a HtmlHelper-extension and as a static method: https://our.umbraco.org/forum/umbraco-7/using-umbraco-7/61527-macro-in-rte-only-show-Macro-alias-AliasName#comment-227811

I think there should be a public method for this (and others like the locallink parser) in umbraco core? Or maybe a more dynamic approach is needed.


Shannon Deminick 12 Apr 2016, 09:39:19

The reason this is not working is:

When the RTE persists data, the RTE property editor executes: MacroTagParser.FormatRichTextContentForPersistence to cleanup the markup that was passed from angular to the server side. This cleanup is required because the markup will contain the rendered macro markup! For example:

<p>Hello world</p>\n<div class=\"umb-macro-holder Helloworld mceNonEditable umb-macro-mce_0\"><!-- <?UMBRACO_MACRO macroAlias=\"Helloworld\" /> --><ins>Macro alias: <strong>Helloworld</strong></ins></div>\n<p>you are cool</p>

This value gets persisted which is incorrect. The persisted value should only contain something like:

<p>Hello world</p><?UMBRACO_MACRO macroAlias=\"Helloworld\" /><p>you are cool</p>

The problem here is that the Grid is not delegating execution logic to it's sub property editors (i.e. like the RTE). The bigger problem here is that Grid editors are not actually Property editors and logic is only borrowed from them.

Originally to fix this would have been quite simple, we modify the Rte.cshtml grid template to be:

@Html.Raw(
    TemplateUtilities.ParseAndRenderMacros(
            TemplateUtilities.ResolveUrlsFromTextString(
                TemplateUtilities.ParseInternalLinks(Model.value.ToString(), UmbracoContext.Current.InPreviewMode)), 
            UmbracoContext.Current.InPreviewMode))

which would perform all of the necessary logic to parse links and embedded macros and render them. Unfortunately due to the above info this doesn't work as expected. The first step to fixing this is to make sure the Grid property editor delegates the execution pipeline during it's property editor phases to the sub editors... but this will innevitably be a slight hack because grid editors are not actually property editors. The real fix will be making grid editors actual property editors.

I'll commit the changes I have now but this task will be pushed out for another release or two.


Shannon Deminick 12 Apr 2016, 09:41:08

The branch is here: https://github.com/umbraco/Umbraco-CMS/tree/temp-U4-6206


Jeremy Pyne 27 May 2016, 13:09:37

As for the idea that in grid's macro in Rte shouldn't be supported I disagree. There are just way to many edge cases where a the grid can't produce the desired framework. With full support then a developer can always insert a full with row and do whatever hay code they want with macros and such in that row.


Jeremy Pyne 27 May 2016, 13:12:35

Any update on this fix, it's hindering our migration and we need a fix or workaround/manual patch.


Sebastiaan Janssen 27 May 2016, 13:27:33

Workarounds have been listed above.


Jeremy Pyne 27 May 2016, 13:37:49

Yah, i was trying the branch you had created. I got it working. I added a Regex to the rte.cshtml to rewrite the broken html. Not the cleanest, but I got it working for our site.

@model dynamic
@using Umbraco.Web.Templates
@using System.Text.RegularExpressions
@{ 
    Regex FixMacroMarkup = new Regex("<div[^>]+umb-macro-holder[^>]+><!-- | --><ins>Macro alias.*?<\\/ins><\\/div>| --><ins>.*?<\\/ins><\\/div>", RegexOptions.Singleline);
}
@Html.Raw(
    TemplateUtilities.ParseAndRenderMacros(
        FixMacroMarkup.Replace(
            TemplateUtilities.ResolveUrlsFromTextString(
                TemplateUtilities.ParseInternalLinks(Model.value.ToString(), UmbracoContext.Current.InPreviewMode)),
            ""), UmbracoContext.Current.InPreviewMode))


Jeremy Pyne 20 Jun 2016, 19:20:37

Added second PR to fix the overlay dialog not properly displaying Textarea macro parameters. https://github.com/umbraco/Umbraco-CMS/pull/1341


Zac 27 Sep 2016, 14:55:51

@Jeremy.Pyne is your code above working for you? Would you be able to provide your code for TemplateUtilities.ParseAndRenderMacros? We're getting an error that Umbraco.Web.Templates.TemplateUtilities does not contain a definition for 'ParseAndRenderMacros'.

None of the other workarounds have worked for us either.


Jeremy Pyne 27 Sep 2016, 15:24:38

It's not my code, but you have to apply all the changes form this patch https://github.com/umbraco/Umbraco-CMS/commit/0fb2b06adc889fdbcf38304050629dc868dd204b and recompile and override your local umbraco.dll with the custom one.

Would love to get this fixed int he core but I believe the PR was declined form some architectural reason...


Priority: Major

Type: Bug

State: Open

Assignee:

Difficulty: Normal

Category:

Backwards Compatible: True

Fix Submitted:

Affected versions: 7.4.3, 7.5.7, 7.5.13, 7.10.1

Due in version:

Sprint:

Story Points: 1

Cycle: 9