Does this error occur just after your call to confluence.saveMacro() in both cases? If you’re not sure, are you able to add a debugger; statement to your code to determine which of your calls is the last to be executed before the error occurs?
One more question, do you have a parameters property in your dynamic content macro definition in your Connect descriptor. See also the documentation of the dynamic content macro module and macro input parameter.
It’s possible that there could be some other issue in the background of our setups, because I had another issue with saveMacro not behaving as expected (Confluence.saveMacro does not save macro body).
Would be interesting to see what the real problem is.
I believe the stack trace you provided is from the host frame and not your app iframe so it has nothing to do with your Handlebars setup or dependencies. It is a bug in the Confluence front end code because it incorrectly assumes a particular ADF attrs node has a child node parameters, but I need to gather a little bit more information to help reproduce this. Does this problem occur no matter where you insert your macro? Are you able to investigate a little further on your side.
Thanks for these details. at least we’ve solved the stack trace. Can you do a quick test to see if changing the bodyType to plain-text. i.e. "bodyType": "plain-text" .
So changing the bodyType to plain-text has granted access to the parameter “myParameter”:
the alert Function works now.
But for my Macro i will have to use the rich-text Format, because, for example, I want to enter formatted tables into the macro body.
The Uncaught ReferenceError also disappeared, after I injected some newer AUI.JS versions in the Layout Handlebar Template.
Thanks for confirming that @HendrikSchneider. From my own testing, I suspected the change of bodyType from rich-text to plain-text would make a difference, but I’m not sure why. You may be able to avoid changing back to rich-text if your macro view could be generated from the macro parameters rather than rendering the macro body directly.
One macro with a static ID parameter with the body that should be rendered directly and a second macro that will handle the view with a custom macro editor.
Maybe there will be a solution for the problem in the future.
I get the exact same error with a rich-text macro, is there any solution to this issue rather than changing the bodyType? My macro must have rich-text bodyType since it’s an element with a predefined style that users should be able to write their content inside.
Hi @TomKeidar,
i just found a workaround. The User has to create 2 Macros, one with Rich-Text and without a body. I store the Macro ID of the rich-text macro as a context property on the page and with the help of the REST API i can get the rich-text body of the macro and process it with the other macro…
But i hope the issue will be fixed someday, as i do not want the user to use 2 macros all the time.
Thanks for the quick response but unfortunately this isn’t a possible solution for me.
The macro I’m working on is part of an app we are developing and I can’t ask my users to use 2 macros for this solution.
I hope there is another solution for this issue