Forge migration gap: No equivalent for Connect's staticContentMacro rendering quality

[Fabian Sharifi]

We're migrating our Connect app to Forge and hit a fundamental platform gap.

The problem: Our Connect app uses staticContentMacro to display Confluence page content inline — with full rendering fidelity (tables,
panels, task lists, embedded diagrams, video embeds). This works because static content macros inject their output directly into the page
DOM, inheriting all Confluence CSS and JavaScript.

In Forge, the only option for complex rendering is Custom UI (iframe). But the iframe sandbox means:
- No Confluence CSS (panels, status macros, table styles all broken)
- CSP blocks nested iframes (embedded videos, document viewers gone)
- No script execution (interactive macros like diagrams, task checkboxes dead)

UI Kit's AdfRenderer is limited to simple ADF nodes and can't render arbitrary page content.

The result: Migrating from Connect to Forge means a massive regression in rendering quality for any app that displays Confluence content.
This isn't a bug in our code — it's a platform limitation.

What we need: A Forge rendering mode that can display Confluence content with the same fidelity as Connect's staticContentMacro — either:
1. A Forge-native staticContentMacro equivalent
2. A way to render storage-format content natively (not in an iframe)
3. An extended AdfRenderer that handles all ADF node types including macros

With Connect EOL approaching (Q4 2026), this is blocking our migration. We suspect many other developers face the same issue.

Has anyone found a workaround? Is Atlassian planning to address this gap?

[Arkadiusz Wroblewski]

Hello and Welcome @Fabian Sharifi 

What you describe is a real Forge gap, not a bug in your app. :(

In Connect, staticContentMacro returns storage-format that Confluence renders natively (not in an iframe), so you inherit Confluence CSS/JS and get “real” page rendering fidelity.
https://developer.atlassian.com/cloud/confluence/modules/static-content-macro/

In Forge, the platform essentially pushes you to Custom UI (iframe) for anything complex, and that’s exactly where you lose native rendering (styling + CSP + nested embeds). There isn’t a “render into the page DOM like Confluence does” mode for arbitrary Confluence content.

UI Kit’s ADF renderer is explicitly limited: it does not support core Confluence macros or Connect macros, so it can’t be a general “render any Confluence page content” replacement.
https://developer.atlassian.com/platform/forge/ui-kit/components/adf-renderer/

Atlassian’s own Connect→Forge equivalence docs call out that Forge does not support static rendering from a function (i.e., no real equivalent to static content macros).
https://developer.atlassian.com/platform/adopting-forge-from-connect/connect-forge-equivalences/connect-forge-capabilities-available/

Workarounds people actually use today:

None of these give you 1:1 parity, but they’re the realistic options:

Hybrid migration (keep Connect for this module)
If you must preserve “Confluence-native” rendering (tables/panels/task lists/macros/embeds), the only true way today is: don’t move that rendering macro to Forge yet. Migrate everything else first, keep the static-rendering macro on Connect until Atlassian ships parity.

Scope down to what Forge can render
If the content is your own ADF (e.g., rich-text bodied macro content you control), you can render that via Forge patterns but it still won’t render arbitrary Confluence macro output.
https://developer.atlassian.com/platform/forge/using-rich-text-bodied-macros/

Custom UI “best effort”
Possible for read-only views, but you’ll keep running into iframe sandbox + CSP limitations for embeds and interactive content.

Where to push for a real fix:

There’s already a tracking item for “static content macro equivalent” in Forge:

https://ecosystem.atlassian.net/browse/FRGE-1495
And the related dev discussion:

https://community.developer.atlassian.com/t/what-is-the-forge-alternative-for-the-staticcontentmacros-module/82667

This is a known limitation, and your requirements (“render Confluence content natively, not in iframe”) are exactly what needs a platform change.

[Fabian Sharifi]

Thanks for the quick and comprehensive response – this confirms exactly our issue!

We will definitely raise this topic with Atlassian too (FRGE-1495 + Community thread) and push for it.