How to convert macro body in the preview of a dynamic content macro?

Hi, I couldn’t find any info on this issue but do let me know if it’s already documented somewhere.

Dynamic content macros live in an iframe, thus developers have to use this REST API to retrieve macro body for rendering, where you need to pass in content id, content version, and macro id: https://developer.atlassian.com/cloud/confluence/rest/#api-content-id-history-version-macro-id-macroId-get

However, that wouldn’t work in preview of newly added, unpublished macros because the macro does not exist in the published version. There seem to be some form of autosaved version / draft of the page though since users can resume after closing without publishing and macro ids are generated for the unpublished macros, so I wonder if it’s possible to retrieve the macro body with the REST API using some form of draft version? Or is there any alternative to render dynamic macros in preview?

4 Likes

I would love to know the same - as it might help to solve the issues described (and seems to be ignored now :frowning: ) here [CONFCLOUD-64923] New Confluence Editor gives random macro id for dynamic content macros - Create and track feature requests for Atlassian products.

1 Like

Any new findings here? I am experiencing the same issue…

I came up with 2 solutions to not having access to the macro body during preview.

Solution 1 - before you close the macro editor, do an ajax post request, sending your updated parameters over as json. I’m using expressJS to handle everything - so I have a route there that updates a global “params” variable. Then the macro editor closes on completion.

When Confluence returns to the preview and tries to get the macro body via macro id and fails, I have a conditional statement that retrieves the global params set from the step above, thus I don’t need to retrieve the non-existent macro body anymore since I am now using the updated global params instead.

Solution 2 - if you don’t want to play around with Ajax and using a global params to store the temporary edited macro values, then in your atlassian-connect.json file, call your dynamic macro with every single possible parameter that could end up being set. This isn’t ideal because the more params you add, the more you’ll have to tack onto that params list. This is what I was doing at first until I decided to hack it with an Ajax solution in lieu of Confluence providing access to the maco preview body

Thanks for sharing this

I am using a similar approach, but utilizing the confluence.syncPropertyFromServer and confluence.setContentProperty to store (temporarily) the JSON for the macro.
This requires to have custom editor and could not be used with standard macro parameters editor provided by Confluence (as you need to make couple of extra calls before calling confluence.saveMacro)

https://developer.atlassian.com/cloud/confluence/jsapi/confluence/

The problem is, if a user adds more macros and there is still nothing stored in the page storage
Also, we still experience issues with a new editor when a user attempts to put second 3rd party macro on the page - the new editor just fails to work :frowning:

2 Likes

The new editor has been an ongoing source of pain in virtually every way for us, across all of our connect apps. We are having similar problems with connect apps that have worked for years being partially or completely broken in the new editor. In this case, the following issues seem to be related:

https://jira.atlassian.com/browse/CONFCLOUD-65717
https://jira.atlassian.com/browse/CONFCLOUD-66858
https://jira.atlassian.com/browse/CONFCLOUD-65861

1 Like