This page includes release notes and updates for Confluence Cloud app developers. Use this page to keep track of upcoming changes, deprecation notices, new features, and feature updates from Confluence Cloud.
For updates about changes to the Forge platform, see the Forge changelog in the Forge documentation.
You can also ask questions and learn from other Confluence Cloud developers on the Atlassian Developer Community.
Today we published a blog titled Taking the Ecosystem Forward: An Update on the Future of Connect, which shares an early look at plans to phase out support for Connect. This early announcement is intended for owners of business critical Connect apps, including partners and customers with custom apps, to provide ample time to explore requirements and arrive at a fair timeline for end of support, together.
We’re seeking your feedback to help us shape the next steps for Connect - you can provide your feedback via the survey linked in the blog post.
The blog post details the key stages of our plan, as we progress on this journey. By the final stage, Connect will enter an end of support state (defined in the blog post), where apps can continue to utilise Connect modules, but do so at their own risk. At this stage, we do not have definitive dates for each of these phases - determining a fair and appropriate end of support date will be a joint effort with our partners and other app builders. The purpose of today’s announcement is to start that conversation.
Many apps use bodied macros to allow Confluence users to add rich Confluence content inside of them while editing a page. Then, when the user publishes the page, the app applies formatting to the content and renders it in a “display” state on the published page.
Since live pages are designed to not need to be published, we have added a way to see a bodied macro’s “display state” directly while editing. Now, you can switch between bodied macros “editing” and “display” with a simple click in live pages. See More details for a GIF example.
We found that the user_followed
webhook event is defunct/no longer tied to any feature. As a result, we have decided to deprecate this webhook.
Timeline:
The event will be removed from our documentation onMar 3, 2025.
The event will stop being emitted on Jul 2, 2025.
Support of the blog_moved
Connect webhook has been added to Confluence. It’s triggered when a blog post is moved from one space to another.
In addition to the blog
field that represents a moved blog post, the webhook payload contains the originalSpace
and the currentSpace
fields that represent origin and destination spaces respectively.
As announced in the previous deprecation notice changelog, we are enforcing a size limit on bulk API endpoints when the export_view
and/or styled_view
content representations are requested through an expansion.
The endpoints will return at most 25 results if these content representations are present.
Following the EAP release, UI Kit’s Frame
component is now in preview. This means you can use the Frame
component in the production environments.
The Frame
component allows you to load custom resources within UI Kit, making it easy to import non-UI Kit components in a UI Kit module.
This update also supports Frame across all modules for Jira, Confluence and Compass.
For more information about how to use the Frame
component, see here.
To use the latest version of the Frame
component in your UI Kit app, install the @forge/react
latest version by running npm install --save @forge/react@latest
The AdfRenderer component provides a way to render a valid ADF document, using the same renderer that Atlassian uses internally to render ADF content in Confluence pages, Jira work items, and so on. See ADF renderer for the full docs.
The ADF renderer component also allows you to replace node types that are unsupported in the context of a Forge app with replacement content, or remove them entirely.
See Atlassian Document Format for information on valid nodes.
Run npm i @forge/react@latest
to install the preview version of the components and try them out now.
We have now removed the UI Kit @forge/react version 9 from the Forge platform. This UI Kit version was deprecated on Aug 28, 2024.
We recommend using the latest version of UI Kit (@forge/react10).
For more information, see our deprecation policy.
We're announcing a preview of rich-text bodied macros for Forge, allowing apps to define Confluence macros with a body in their manifest.
This also allows Connect apps to migrate their rich-text bodied macros to Forge.
Get started by checking out the macro module reference, or our tutorial on using rich-text bodied macros.
Rich-text body macros let users insert rich content, like images and tables, within a macro using the Confluence editor. Apps can access and render this content within their macros. Macros using a custom editor can also provide an initial macro body on the first macro insert.
To be able to deploy these changes to your manifest, you will need the latest version of the Forge CLI. Run npm install -g @forge/cli@latest
on the command line to install the latest version of @forge/cli
.
To learn more about migrating Connect macros to Forge, see https://developer.atlassian.com/platform/adopting-forge-from-connect/migrate-macro/.
We’re announcing a preview of custom config editors for Forge macros, allowing you to use a UI Kit or Custom UI resource for your macro’s configuration experience.
This gives you greater control over the presentation of configuration to the user and more flexibility with the storage of configuration properties.
Get started by checking out the macro module reference, or our tutorial on adding custom macro configuration.
The custom macro configuration will be rendered in a modal overlaying the page, offering a larger canvas for more complex configuration scenarios.
Macros using a custom config editor can also provide an initial macro body on the first macro insert.
To be able to deploy these changes to your manifest, you will need the latest version of the Forge CLI. Run npm install -g @forge/cli@latest
on the command line to install the latest version of @forge/cli
.
We are extending the deprecation period for all endpoints noted in Deprecation of v1 Confluence Cloud API endpoints and Deprecation of v1 Confluence Cloud API Endpoints to Mar 31, 2025.
The atl.footer
module was accidentally removed from some Confluence content types. This module has been restored for all Confluence content types and covers Pages, Live Pages, Databases, and Whiteboards.
We now accept bug and incident reports under a single new request type: Ecosystem Support Request. This change simplifies the process of reporting issues to our support team, so that we can handle your issue more efficiently, and ensure consistent handling for all critical issues, particularly incidents.
We’ve also detailed the scope of our Developer and Marketplace support, so you have a better understanding of supported issues and response times.
We’ve stopped injecting stylesheets for Connect apps via inline styles, in favour of loading from the Connect CDN. This affects the Theming API and dynamic content macros that supported the legacy Confluence editor.
We originally announced this 6 months ago, in line with our standard deprecation policy. It is now live for https://developer.atlassian.com/cloud/confluence/developer-canary-program tenants, and will roll out to all customers widely throughout this week.
If your app doesn’t use the above Connect features, or doesn’t use a Content Security Policy (CSP) for style-src
, no action is required. Otherwise, please read the details here or see https://developer.atlassian.com/platform/marketplace/security-requirements/#connect-apps on how to modify your CSP to support these changes.
To support these changes in your app, if you're using a Content Security Policy that sets the style-src policy, you must add the Connect CDN (https://connect-cdn.atl-paas.net
) to your policy to allow these stylesheets to be injected. It's safe to remove unsafe-inline
from your policy if you've been using it up until now.
The stylesheets mentioned here were included automatically via the Connect JS script, not manually by the app vendor. There are two circumstances under which Connect injected stylesheets into your app:
The first is only for apps which opted in to the Theming API.
The theme stylesheets previously loaded via an inline stylesheet, which forced vendors to adopt the insecure unsafe-inline
policy, and is the main motivation for this change.
The second location is only for dynamic content macros.
We injected a stylesheet with CSS classes representing colors from the legacy Confluence editor.
This happened without opt-in, to be backwards-compatible with macros created in the legacy editor.
This injection was done via CSSOM, not inline styles, and therefore isn’t impacted by style-src
CSP rules currently. However, it is also now being served from the CDN.
To summarise, all styles are now being loaded from the CDN, and the inline/CSSOM methods have been removed.
Rate this page: