I’m trying to make a dynamic macro to be cacheable.
How do I get the macro parameters?
Before I was getting the macro parameters from the url, but now I can’t. The only way I found is to use the REST call ‘Get macro body by macro ID’
Using this approach creates an error in preview mode of the macro (in view mode everything works fine), because macroId parameter is not defined.
With these variables then I’m able to call ‘Get macro body by macro ID’ REST API to get macro parameters.
This approach works in view mode, but it is causing an error in preview mode in the macro editor because the variable macro.id is not defined.
@arosati, we identified this as a gap a while back. We initially intend to support the existing API AP.confluence.getMacroData() in view mode (ACJS-1025), not only in edit mode. I will make a note on that ticket to make sure we support preview mode as well.
@akashyap, I see that is not working in both cases.
In a single macro preview I see the error:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><status><status-code>404</status-code><message>null for uri: https://srtest9.atlassian.net/wiki/rest/api/content/249266188/history/1/macro/id/?_r=1539855248258</message></status>
As you can see from the error the macro id is not specified, because I think the macro id is still not available.
In the new editor (from a blogpost) when I load the blogpost in edit more I see this error:
{"statusCode":404,"data":{"authorized":false,"valid":true,"errors":[],"successful":false},"message":"No macro found on content id : ContentId{id=249266188} with version: 1 and macroId: 2310e8a2-91d9-4c17-862d-162df7c2122f"}
Here the macro id is specified, but still getting an error.
@rading, I cannot use the parameters from the URL because I’m using a cacheable macro.
Is it still in the plans to support cachable iframes for macros? They say they support it but if macros can’t access their macro parameters, usecases are extremely limited.
Our usecase is for customers with lists of requirements: They annotate each item, which means they could have hundreds of requirements per page. If our macros are cached by the browser, displaying them is instant. If not, the browser limits to 6 concurrent requests per page, so it takes a lot of time to display many macros.
I had the chance to talk to someone from the Confluence Cloud Ecosystem at the Atlassian Summit, because we have the same issue. He told me that accessing the macro properties will be available soon.
This really needs to be escalated and documentation updated to reflect that this is not ready for use by macros at all.
getMacroData() doesn’t work in view, so you need to do workaround hack of getContext() and then get /rest/api/content/{id}/history/{version}/macro/id/{macroId}.
That all works across view, preview and custom editor. But when you first save/insert a new macro and run saveMacro(), your subsequent call to the workaround hack fails with the same “No macro found on content id” 404 posted above.