U4-8964 - Should back office Macro's be removed/deprecated from v8?

I like the way you can vary the caching of a macro via the back office without an app pool recycle, and I like the way parameters can be taken from the querystring or doc type alias with the shortcut syntax [@aliasName], [#aliasName], [$aliasName] and I like the functionality of editors being able to insert a macro into rich text editor or grid, and supply parameters; finally I like the fact you can configure how errors are thrown, so they don't blow up on the screen, but you can catch the macro error and log accordingly - oh and in the Uk North, Macro rhymes with Umbraco.

As I see it, the only viable alternative to macros is grid editors. It can be done somewhat well with nested content, but you lose the freedom to put them in individual columns. Less experienced developers might even start adding a checkbox for each "function" the page should display. Oh the horror...

With macros, we can quickly create functionality without having to add the appropriate package manifest, editor views, scripts etc. It's faster and cheaper, and the best approach in low-budget projects or slim use cases.

What I think sparked @JimbobSquarePants tweet though, is macros in RTEs, and how the RTE might mess up the markup and inclusion of macros. In his case it was two overlapping macros or something? To me, this states that the real problem lies in macros being possible to use in RTEs. (And general RTE headaches) The way to fix it is to split the "use in grid and rte" option in two, so we can disallow it in RTEs. And of course you can just disable it in the RTE config itself.

I say what should be removed for v8 is the option to use macros from RTEs at all.

A macro is really handy for an editor to be able to insert into a rich text editor to provide a piece of functionality customised by the editor - eg insert an image gallery or a responsive image (eg special classes around) or the markup for a video, that doesn't support oembed - so I would say +1 for the distinction between RTE and Grid for the use of the macro, the functionality may only make sense in one of those context and not the other - but I wouldn't remove the functionality of inserting a macro into a rich text area (the implementation may be improvable) but the concept is very useful - unless there is a further argument for removing rich text editors entirely from V8, and going grid only :-)

We need RTE in the grid. But yes, improved. And they should be stripped for options as much as possible.

I think this discussion is missing that the purpose of macros was to empower editors to do things beyond what a developer did when the site was built. Just like Umbraco itself.

It was never meant to be a developer feature as such.

@hartvig The developer still has to facilitate that for the editors. And if it just creates headaches, then the outcome you aimed for has not been achieved. So the discussion should really be whether it could be made even more empowering and less crippling.

@lars-erik that's the direction we're heading with Grid Layouts and how the replace (misused) RTEs. I'd love to see that the RTEs in v8 is extremely barebone with very limited formatting and that people will use great configured Grid Layouts for more complex yet flexible content (or Nested Content depending on the type of page).

I'd actually like to see "Display as grid-editor" as a macro option. That way we could configure a specific macro as it's own grid-editor instead of having to select functionality twice. (Insert>Macro>Thing vs Insert>Thing)

@lars-erik that's a great idea!

@hartvig :)

@hartvig thats essentially putting Doctype Grid Editor in core :)

Just remove/ignore the "isParameterEditor" setting so all property editors can be used in macros? Remove the macro parameter data types completely. Not even sure the "isParameterEditor" option for property editors is documented? It's shown pretty well here: http://24days.in/umbraco/2014/grid-macros/

[edit] or just up the visibility / documentation for "isParameterEditor". :)

The new "Schema Types" ('''TBC''' ''- to be introduced with core's version of Nested Content''), could be used as a replacement to the Macro's Parameter tab? Then Macros would be working with configured data-types, rather than raw property-editors.

Why complicate it? I like having the freedom to mix and match parameters and their types in my macros. No need to specify a concrete schema / doctype for each.

@lars-erik My trouble with current Macro parameters is that they can't be configured (as a data-type), they can only be used with native property-editors (that don't require any configuration).

@leekelleher NC might make it to core before Schema Types. Per and I love NC already and don't feel any reason to delay it further :)

@leekelleher Not true. You can add "isParameterEditor" to a property editor in package.manifest, then you can use it as property editor in a macro.

@hartvig Cool!

@lars-erik How would you configure said property-editor? Let say you wanted a dropdown list or approved color picker?

@leekelleher in package.manifest

@leekelleher see https://our.umbraco.org/forum/umbraco-7/using-umbraco-7/53887-Custom-dropdown-macro-parameter-editor#comment-187219 and the link I posted above

@lars-erik I think we're confusing points here. I know about the isParameterEditor option. The example in the forum post has the dropdownlist values hardcoded within the property-editor's view. Which isn't an ideal scenario.

The point I'm getting at is, it would be nice to reuse data-types (as opposed to raw property-editors) in macro parameters. (I mention this as Schema Types, but that seems future-speak now - so lets ignore that) :-)

@leekelleher Yes, you'd duplicate a lot of info in package manifests and probably clutter the editor list. Would be nice to lift them one level. So why not just remove the "walls" instead of introducing new kinds of "wheels" to get around? Let macros use data types instead of property editor defs and macro parameter types.

[EDIT] You'll not clutter the editor list. ;) See PR for grid editor docs.
https://github.com/lars-erik/UmbracoDocs/pull/2

I thought I best comment here since the conversation was misconstrued on Twitter and I just seem to be digging a hole there.

@lars-erik has captured the use case I was specifically talking about - Macros in the Rich Text Editor. I have zero experience with macros in the grid since I don't use the grid over end-user-experience concerns (Let's not continue a conversation about that here).

Macros were a great solution at the time of their inception but I believe we can do much better.

These are my main gripes, I appreciate that everyone has a slightly different approach to development:

'''They are extremely brittle and difficult to debug:''' HTML is not a language that cannot be parsed well [via regular expressions|http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454]. And Umbraco uses regular expressions to find and match the macro tags.

I've seen first-hand where this parsing fails leading to duplicate opening tags in the markup caused by everyday use. This, in-turn, throws an exception deep in the bowels of System.Web which, while it gets logged, does not contain any information that points to the failing node nor property. No information is fed back to the user either with only a disabled submit button as any indicator of error.

This, to me, presents a poor experience for the editor which we should try to mitigate. '''One of my clients was afraid to use the CMS due to issues caused by macros and asked me to remove them when rebuilding the back office.'''

'''They are restrictive:'''

As @leekelleher pointed out they can only be used with existing data types as macro parameters, extending that requires extra work and adds clutter to the editor selectors. Plugin publishers already have a lot of work to do now what with preview and search configuration and it could potentially put plugin developers off to add more on their plate.

'''They are not traceable'''

As @peteduncanson said Macros work entirely outside source control. If someone decides one day to add caching then I have no way of knowing when or who did that. That, to me, represents not only an opportunity to have awkward conversations with the client but also a security risk.

'''So what would be a better choice?'''

Like everyone, I'm a huge fan of Nested Content and also looking forward to schema types coming to Core. I believe V8 would be a great opportunity for us to revisit the use case for macros and offer a better alternative based on those technologies.

I'm also very curious to see any numbers regarding the type of developer using Umbraco and what tools they use. The focus on content editors has made Umbraco, to me, a stand-out in the CMS market (Nothing come anywhere near when considering flexibility and ease of use) but I feel some of the focus on developers outwith Visual Studio or similar has harmed Umbraco, (I'm looking at you dynamics.) Some cold hard facts would certainly help clear the air somewhat.

Great summary, @JimBobSquarePants.

I guess I've come off as negative towards nested content replacing macros. I begin to see where you guys are headed, but I'd like to add a few more cents in order to get a clearer picture.

As you say, there's different approaches. While some do lists of nested content with "doctypes" and some do grids with editors, and some just do rtes with macros, we all add custom behavior in or in between rtes. Whether it's macros, custom grid editors, or custom nested content really doesn't matter, but the more options the worse. And the worst way to do it is in rtes.

There's also the UX. With nested content, we can add stuff in a list. With the grid, we do somewhat the same, but the right hand dialog is used more than I imagine it is with NC (I know you can). If we could use a "nested content document type definition" as the definition of what to show in the dialog, it's as good as all other options. Maybe even better. Provided previewing like with macros is as smooth.

But I kind of feel it should be conceptually different. When configuring nested content, I set up min, max and which types can go in there. With the grid, I set up rows, columns, settings, and which types can go where. (Never mind other ways to do things. :P)

I think something like leBlender for grid editors, only using NC doctypes instead might be an idea. So the developer tab would have something like:

• Data Types -* Heading -* Rte -* Picker -* Image
• Grid Editors -* Billboard (NC doctype def with) -# Rte -# Picker -*# Image
• Nested Content Lists -* Accordion -# NC doctype A -# NC doctype B -* Nested Content -*# Misc doctypes...
• Document Types ...

We'll have all (mostly) we like about macros, we can't use them in rtes, and editors can't mess up.
If this was what you all meant, then I'm sorry, I need to be spoonfed. :)