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

Hi @DavidMichelson ,

Unfortunately, I cannot confirm this on my development page - when I am in edit mode, there is a glass pane, so I need to inform users here to go to the published state to be able to edit the macro. I just wanted to make sure that I can do this distinction for the users. Maybe this is already possible, I have not checked as this is a RFC, so I wanted to raise this.

Best,
Eckhard

1 Like

@EckhardMaass Thank you for reporting! There should not be a glass pane anymore, so I’ve brought this up with the team with to fix this. We estimate a fix to be in next week.

Update: The glass pane should no longer be on macros in edit mode.

(Tagging @EckhardMaass who commented on this specifically)

I have a non-bodied, non-configurable Confluence forge macro with a react-select field.
In page view mode the select works and looks like this:

I’m not sure what the ‘glass pane’ issue is …
In ‘live’ or ‘edit’ mode it’s not possible to click on the select element, but we want the same UX in view and edit mode. In ‘live’ or ‘edit’ mode it looks like this:


Any click action inside the rendered macro is blocked.

How can I get ‘view’ and ‘(live) edit’ mode to have the same behaviour?

2 Likes

Hello @DavidMichelson,

On our dev systems everything is like you described now! Thanks!

Best,
Eckhard

1 Like

@UlrichKuhnhardtIzym1 thanks for sharing. Will bring this to the team. Could you double-confirm if that is still happening for you at the moment?

1 Like

Thank you @DavidMichelson - the macro is responsive in page ‘edit’ and ‘live-edit’ mode. Thank you very much for the quick response.

1 Like

Hi all!

Thank you so much again for trying live pages with your apps. Please continue sharing any feedback as it comes up! I have a couple of updates for you all:

  1. Page version changes in live pages - We have made the update we mentioned to how page version changes happen with live pages. Now, 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.
  2. Letting macros/apps detect whether a page is live or not without having to make an API call - We heard your feedback, and we are now exploring how to enable this. Please let us know if you have any additional feedback.
2 Likes

Hi,
after playing around with the live editing with our Scroll Exporter apps I want to add two additional points of feedback. These are Connect specific, we’ll likely will be blocked from transitioning to Forge for a while.

  • From my testing, when switching from “Editing” to “Viewing” in the toolbar only dynamic content macros are reloaded and get a chance to re-render, but static content macros are not. This is an issue for us because we do have static macros that need to display additional information in the editing mode.
  • We’d also be interested in a way to detect this without an additional API call, especially in static content macros, so we don’t have to do this from our backend every time. Ideally this would be an URL parameter like the output.type parameter that already exists.

[edit] To clarify, we have both bodied and non-bodied static content macros. I do understand support for bodied macros is yet to come, but would have expected non-bodied static macros to already work.

5 Likes

Hi all! As promised, I’m happy to share that bodied macros are now supported and ready to be tested in live pages! Please try out your bodied macros and leave feedback.

Now, you can switch between bodied macros “editing” and “display” with a simple click in live pages

Bodied macro in live pages

When you insert a bodied macro, the macro will automatically start in “editing” mode, allowing you to add content. Once you’ve added content and are ready to see the “display” mode of your macro, simply click “Done editing.” To make any changes, just hover over the macro and click “Make edits” to switch back to the “editing” mode.

Any other viewers of the page will see the “display” state by default, and can enter the Editing mode if they like by hovering over the macro and clicking “Make edits.”

I’ve updated the original post in this thread, the corresponding changelog entry, and also created a new changelog update to announce this change.

2 Likes

Hi all,

great feature! However, as expected, our non-bodied macro does not yet work as expected. Is there any way to retrieve and update the live page source via REST?

For context: When you click one of the macro buttons, it launches an external component (a diagram editor similar to gliffy). Once you save the diagram in the editor, the page and more specifically the macro needs to be updated (don’t judge, just listen…) Since this happens outside of the macro editor, the only way we could make this work is to edit the macro body directly in the page source (if anybody has a better idea, please let us know)

For querying and updating the pages we use these REST endpoints:

/api/v2/pages/${pageId}?body-format=storage

and

/api/v2/pages/${pageId}

However in live pages, it can obviously happen that the necessary content isn’t there yet, and we’d need to query and modify the live page instead. Is this possible in some way?

Best regards
Jasmine Möller

1 Like

To confirm, this new “subtype” field has been added to the v1 rest api only? The same one that was marked deprecated some time ago?

1 Like