Live pages are available for testing on sites in the Developer Canary Program

Announcements
, ,
1

All partners in the Developer Canary Program can now test their apps with live pages! Note that live pages are still in early access, and customers that opt in are aware that some apps may not be fully functional yet in live pages. Starting January 2025, we will start gradually rolling out the ability to opt in to the live pages beta to more customers (expecting to be available for opt in for all customers by April 2025).

To get started with testing live pages, follow the instructions here: Create and collaborate on live pages in Confluence

Here are some more technical details & things we recommend you try. Please feel free to leave comments here!

Page States

We recommend making sure that your app works in live pages that may never be published and always remain live pages. Keep in mind that live pages can still be published (e.g. for use cases like knowledge bases), so make sure that your app still makes sense with published pages–both while viewing & editing them.

Continue to consider permissions scenarios around who can edit / view pages, these continue to exist in live pages (e.g. a user may have view-only permission of a live page).

Extension Points

Live pages will support the following page extension points. If you are using any other extension points, we recommend you migrate so that your app is accessible in live pages. As stated on October 31, 2024, we will be deprecating other Confluence page extension points (note that extension points beyond pages are unaffected). Learn more about the extension points we are deprecating here.

  • Forge
    • confluence:contentBylineItem
    • confluence:contentAction
    • confluence:contextMenu
  • Connect
    • system.content.action/secondary
    • contentBylineItem
    • system.content.action
    • system.content.action/primary
    • atl.general
    • system.content.action/modify
    • page.view.selection/action-panel
    • system.content.action/marker
    • atl.footer (will not render a UI component, but can still be used for running background scripts)

Macros

Bodied Macros (COMING SOON)

In December, we plan to rollout changes that make Bodied Macros like Table Filters & Aura Tabs functional in live pages. Today while editing, bodied macros only display in their “Edit” state–a text box where users can enter rich Confluence content. Users must publish to see macros in their rendered “Display” state. We will be giving users the option to switch between these “Edit” and “Display” states freely within the Editor without publishing, making them functional in Live Pages.

  • When inserting a bodied macro, users will see the “Edit” state of the macro by default, so they can add content. They will need to exit the “Edit” state to see the “Display” state – now, they won’t need to publish & scroll around to see the “Display” content.
  • When viewing a page with a bodied macro, users (assuming they did not insert the macro themselves) will see the “Display” state by default. They will be able to hover on the macro and enter the “Edit” mode.

We will let you know when we release these changes and we recommend testing your apps then to make sure they work as expected.

Non-Bodied Macros

As discussed in RFC-50, we’ve made it so non-bodied macros like Gliffy and draw.io, are more easily interacted with AND configured in the Editor, both for live pages & classic published pages. This has also been referred to as “removing the glass pane” from macros while editing. We recommend that you test your non-bodied macros in live pages to make sure they work as expected.

Connect Webhooks / Forge Events

Since live pages do not have drafts and are not explicitly published, there are updated events for them. Note that live pages can still be published, which turns them back into standard published pages.

Webhook Key Forge Event Description
page_started avi:confluence:started:page Emitted at the end of the first editing session of a page. The page will have a user generated title and 1 version.
page_snapshotted avi:confluence:snapshotted:page Emitted at the end of every subsequent editing session.

Query if a page is a live page via API

Currently, Live pages and draft/published pages will be differentiable via the content API by the subtype field. Currently the subtype is not available on the v2 API. This is not considered a stable API.

In the near future, we will make the subtype field available on the v2 content API, making it a stable API.

Page Version Changes in Live Pages

A new version is created immediately once a user makes changes, but this version will remain in flux as users make changes, and only finalized 15 minutes after the editing session ends.

3 Likes
2

Hi @DavidMichelson ,

Thanks for the heads up. I have some questions:

  1. Does the page version change during live edit and page changes? It seems not?
  2. Can we query the api if a page is a live edit page?
1 Like
3

Hi @DavidMichelson,

Are you sure that live edit pages are only in “early access” and have not been shipped yet? Recently, we created a new Confluence site and noticed that live-edit pages were enabled, although we hadn’t signed up for the EAP. It includes the changes from RFC-63, which were not supposed to be shipped before April 2025. This was more than surprising to us.

4

Hello there,

Re-iterating the second point: we really need to behave differently on this two cases - when there is the glass pane covering, we need to inform our users that they can only interact from the published version. Please ensure there is an easy functionality for this!

Best
Eckhard

1 Like
5

Another question: Confluence has the page status feature. Many teams use this to set a page to the status “Verified”.
This is also possible in live edit pages, and thus a verified page can be edited. This contradicts the status “Verified”.
How are live edit pages supposed to interact with the Confluence page status?

6

Hi,

I am testing my Forge App with CustomUI and UI Kit (forge/react v10+) MacroConfig.

And it seems to work out of the box :rocket: Very nice :slight_smile:

The only thing I would like to see improved is: Could the edit button appear onMouseOver too?
Currently you have to click on the header-thingy above the macro so that the button shows up.
So two clicks to edit a macro. This seems a little cumbersome.

Here is what I mean:

Bildschirmfoto 2024-11-13 um 16.16.38
Bildschirmfoto 2024-11-13 um 16.16.38836Ă—474 25.1 KB

Bildschirmfoto 2024-11-13 um 16.18.12
Bildschirmfoto 2024-11-13 um 16.18.12836Ă—474 31.1 KB

And when having multiple macros on the same page and clicking on edit on multiple macros, then sometimes this error shows up:

Bildschirmfoto 2024-11-13 um 16.22.51
Bildschirmfoto 2024-11-13 um 16.22.51546Ă—594 24.7 KB

But I love the “view” rendering of my macro in page edit mode a lot. Makes the buttons accessible that usually are only accessible after page publish. Kudos to this feature :rocket:

7

Hi @EckhardMaass!

I’m assuming you’re talking about a macro here. In live pages, we remove the glass pane from macros in the Editor, so they should be interactive in the Editor! With that, is there still a reason you’d want to inform your users that they can only interact from the published version? You can also try this out right now with your macro in a live page.

8

Hi @marc - Good question! Funnily enough, this potential issue with Verified page status already exists with published pages (someone can still make updates to a published Verified page). But, I see what you’re saying. This would be exacerbated by live pages where edits are much easier to make. Thank you for the feedback, I will share this with the team.

9

Great question. Yes, live pages are still only in “early access!” A limited subset of net new customer sign ups may be enrolled in a live pages experiment (which you experienced). The experiment is set to end within the next two months. Live pages is not yet being shipped to all existing customers or all new customers.

10

@clouless

Thank you for the feedback around the edit button! Will share with the team. We do want to continue to make macros easier to consume & interact with in live pages.

Also, I wanted to ask about this. Are you referring to the proposal we made for Bodied Macros that is coming soon? Or is this something you are already experiencing in product?

But I love the “view” rendering of my macro in page edit mode a lot. Makes the buttons accessible that usually are only accessible after page publish. Kudos to this feature :rocket:

11

I am referring to the current state of my app. So not the bodied macros. But I am also looking forward to this, since I would much rather make my app a bodied macro :rocket:

1 Like
12

Hi @DavidMichelson ,

Yes, it’s a macro. But as you do a rolling upgrade, or have the old way still possible, we need to distinguish the two cases in order to show our users appropriate responses!

Best
Eckhard

13

Hi @DavidMichelson ,

Is there documentation available which shows:

When does the page version change with live edit?

How can a macro or app detect it is on a live edit page?

14

Hello,
Like Marc above, we need that our macros know if they are being displayed in Live edit mode or not, in our case, to adapted their style.

1 Like
15

Great questions @marc

  1. Does the page version change during live edit and page changes? It seems not?

Currently, a new version is created at the end of the “editing session”, which occurs 15 minutes after the users finish making changes.

In the near future, this logic will change such that the new version is created immediately once a user makes changes, but this version will remain in flux as users make changes, and only finalized 15 minutes after the editing session ends.

  1. Can we query the api if a page is a live edit page?

Live pages and draft/published pages will be differentiable via the content API by the subtype field. Currently the subtype is not available on the v2 API. This is not considered a stable API yet and may change. We will update you as this evolves.

16

But this then would be another REST call, yes? Wouldn’t it be possible to extend the context in view of the Forge bridge to include those details already? This would be less cumbersome to handle if you are already in the macro within the page.

Anyhow, please make it possible to differentiate this before rolling this out to a broader audience!

Best,
Eckhard

1 Like
17

Hi @DavidMichelson ,
Thank you for the clarification.

Our app renders differently, depending on the page version. So in order for our app to function, we need to know the current page version.

I believe the above is what user would expect. The first edit changes a version, and you would not expect that each keystroke generates a new version. !5 minutes after the edit session seems reasonable.

It would be great to add this to AP.context, because otherwise we’d probably need an extra API call, similar to @EckhardMaass said.
It is likely that we will allow users to use and view our app in live edit mode, and we will probably display a warning on use in live edit mode. Our app use case is for versioned pages (and I think there are many more apps were this is the case, think e.g. of quality management pages, approval pages, compliance documentation and similar).

1 Like
18

@marc @EckhardMaass Thank you for your continued feedback. Basically what I hear from you is: Can there be a way for apps / macros to determine whether they’re on a live page or not without making an API call? I will discuss this with the team.

19

An update on querying if a page is a live page via API:

Previously I mentioned that live pages and draft/published pages are differentiable via the content API by the subtype field. Currently the subtype is not available on the v2 API. This is not considered a stable API.

In the near future, we do plan to make the subtype field available on the v2 content API, making it a stable API. I’ve updated the original post and our changelog announcement to reflect this. We will communicate when this is available on the v2 API.

1 Like
20

@EckhardMaass I wanted to make one distinction here.

No matter where a user is editing - whether it’s a live page or a classic published page, the glass pane is already removed for macros to make them more interactive / useful in all cases. I also noted this in the original post.

With that, I think giving apps a better way to determine if they’re on a live page or not without API calls is helpful, and we’re discussing with the team the best way to do this. Are there any other cases you can think of where that information would be useful?