The future of Macros

[hfloyd]

As someone who does think that Macros still have a place in Umbraco (even if just to help with site migrations from older versions), I figured I'd open a place for centralized discussion of the topic.

Inline-Macros

I have been working on a site this week where I have been building a nice set of Content blocks to allow Editors to reproduce the contents of a book into HTML on the website. In general, I'm loving the Content Blocks, and they are working well. However, there is something I cannot really do with Content Blocks - which is allow the addition of a footnote marker (*) which should render as a bootstrap Tooltip popup. It seems that a little macro in the RTE is the sensible solution here, but as has been the ongoing headache of RTE macros - It doesn't act as an inline item, and breaks the content flow. (In my case breaking the sentence with unwanted <p> tags.)

On the forum suggestions have been made that Macros should not insert with a <div> tag - which is what causes TinyMCE to "clean up" the HTML with extra <p> tags (due to it being invalid HTML). It seems to me that all we need in the addition on another option on Macro configurations along the lines of "Display": Block | Inline, and based on that, either a div or a span would be used to insert the macro into the RTE. A little CSS could make sure that any span macros were rendered wide enough and either outlined or colored in a way to make them clickable for editing.

I searched the Github Issues and couldn't find anything directly related to this, which is why I have opened a discussion here. Patrick van Kemenade posted his workaround, but I haven't been able to get it quite functional yet....

DataTypes /Element Types as Macro Parameters

There is a detailed discussion of this topic here, but it has gotten a bit buried.

I invite anyone who builds sites using macros to contribute additional thoughts/subtopics.

[V414]

I second that macros still have a place in Umbraco, as they let content editor repeatedly use hard coded functions where and how they want, and in a way that is simple to understand (since they are placed within the RTE structure).

I am currently using macros to insert Chart JS graphs within text articles, which works well, but there are mildly infuriating issues...

For example, there is a limited number of macro parameters (which in my case means instead of using the existing tag system, you have to type out plaintext strings separated by commas), and every macro can be used in any macro-enabled RTE - there is no way to disable some macros in RTE doctypes (that I know of).

As this thread suggests however, I have had particular trouble with inline macro's. They simply don't exist, and I think they would be really helpful.

I have found situations that require CMS control of text (especially if it needs translating) that needs variables saved from other places mid sentence, e.g. "Available at 16/12/2019 up until 02/05/2024" would be so much more reliable if it was "Available at (Macro.DateStarted) up until (Macro.DateEnded)". However, as pointed out, macros always use div tags, which break up existing p paragraphs, resulting in unwanted line breaks in the above sentence.

It feels like it would be really simple to just add a checkbox to a macro's doctype settings to toggle it being inline or not.

[onlinegroeicoach]

I agree completly with the above. I use Macros a lot but too bad you can't control the HTML placed around them properly. And because you can't display them inline you don't really have a WYSIWYG experience in the backend.

Another great improvement would be that parameters can be a selection like a dropdown or radiobuttonlist this is now only done by creating a plugin in which you define these types but think this also should be possible natively.

Now with the new Blocklist edit (great addition to Umbraco !) I use Macro's slightly less but still Macro's and having control of them is very important to me.

[c9mb]

Likewise, I've been using Macros to allow Blog-Editors to insert ad-hoc graphs & charts into their Blog-Posts. I wrote a series of macro-partials using the well known d3.js library to support this. So far I haven't needed to address the issue of upgrading these sites, but I know it will come. While Blocks are great at what they do, I'm not sure I see them as a replacement for Macros.

[patrickdemooij9]

Like the other people on this thread, I think macros are useful for a website. We use it on some websites for something like fancy buttons and some other things.

However, there are some things clearly lacking with macros that I would love to see changed:

• Ability to use all the property editors. Currently the data is just saved in the HTML (This is why we can't use all property editors). Ideally this should be saved in the database so we can have support for more advanced property types.
• Have a way to disable rendering in the backoffice. Sometimes we have macros that are so huge that they make it a lot more difficult to edit. Would be great to just show a small indicator that a macro is present.
• Have modelsbuilder create macro models. Now we have to use the GetPropertyValue (I believe) and it just feels so strange when we have the great typed properties from the IPublishedContent already in place.

And just generally some improvements to the UI would be great. Like making it more like the blocklist editor.

[onlinegroeicoach]

Hi Patrick (same first name as me :) ),

Agree with most you said except point 2, there is an easy way to do it, in the cshtml of you macro write this:

@if ((UmbracoContext.InPreviewMode || !UmbracoContext.IsFrontEndUmbracoRequest))) { // Render what you want to show on the backend (or nothing at all) } else { // Render what you want to show on front-end }

[skttl]

Macros should be block based IMO, so we can use all data types, and their value converters. I don't think it's necessary that they are saved in the db (at least until blocks in general gets saved in the db), as the values can work fine anyway.

In addition to that - it would be nice if we could mark a macro as rendering inline, when used in the RTE, like @hfloyd suggested.