Migrating a macro module from Connect to Forge is now available

We are excited to announce that the ability to migrate a Connect macro to a Forge macro is now generally available! Thank you to all the developers who signed up to the EAP and provided feedback.

This change allows your app to render existing Connect macros in Confluence pages as Forge macros, when you adopt a Forge macro with a key matching the Connect macro.

See Migrate a macro module from Connect to Forge to get started.

3 Likes

Thank you for providing an update path.

Are there also plans to allow something similar to a static Connect macro in Forge, i.e. providing Confluence XML to Atlassian for a direct render instead of using an iframe?

Hi @marc

Thanks for your interest. I have gone ahead and created FRGE-1495 to track interest in this feature request.

I am curious to hear more about what your requirements for a static macro feature in Forge are. I have left a short proposal on the FRGE ticket describing how it might work - following the precedent set by the adfExport macro feature.

Are you mainly interested in:

  1. Having the content render inline in Confluence instead of in an iframe?
  2. Having Confluence handle the presentation of the content for you, instead of needing to handle styling yourself?
  3. The caching features of static macros - avoiding unnecessary function invocations?
  4. Would you be satisfied to embed only “basic” features such as lists, tables, images, etc, or do you require access to other macros such as expands?

Feel free to add your thoughts on the ticket so we can learn more about the needs of your app.

Hi @SamLeatherdale ,
Thanks for creating the Forge ticket. Here are the answers to your questions:

  1. For some of our macros, inline rendering seems faster and smoother. These macros need to render only one or two words of text usually.
  2. This is the most important reason for us. When Confluence takes over the rendering, export to PDF etc works automatically. This is very hard to do with Forge macros.
  3. The caching is not very important for us.
  4. We do need the “full xhtml”, because some of our static macros contain other macros.