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
@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:
How can I get ‘view’ and ‘(live) edit’ mode to have the same behaviour?
Hello @DavidMichelson,
On our dev systems everything is like you described now! Thanks!
Best,
Eckhard
@UlrichKuhnhardtIzym1 thanks for sharing. Will bring this to the team. Could you double-confirm if that is still happening for you at the moment?
Thank you @DavidMichelson - the macro is responsive in page ‘edit’ and ‘live-edit’ mode. Thank you very much for the quick response.
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:
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.
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.
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
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.
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
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?
Hi Tony - we are working on finalizing the best API design for live pages, and will make sure that is reflected in the V2 API. Will keep you posted!
Curious if you have any feedback on our current approach (or any other vendors) that is proposed? Thank you!
Silly question: How do enable Live Pages for developing? The link above goes no where. All other information seems to indicate that I’ve to sign up? https://community.atlassian.com/t5/Confluence-articles/Early-Access-Live-Edit-Pages-Create-and-edit-without-the-need-to/ba-p/2673118
Is that correct?
Hi @RomanStoffel - All sites in the Developer Canary Program should automatically have the ability to test live pages. You can learn more about opting in here: Developer Canary Program
I did enable the Developer Canary. I didn’t find the setting to enable the Live Pages.
The full guide:
I got a first spin in live edit mode. The issue we have with the macro is that the REST /rest/api/content/{pageId)/history/{version}/macro/id/{macro-id} always returns a 404 until the page is published.
So my questions are:
@DavidMichelson : after adding these events as triggers in the forge manifest, the app does NOT receive these events.
The space feature settings don’t show ‘Live pages’ like above in @RomanStoffel 's post. I never signed up to the canary problem… however every new page in my space is created as a live-edit page.
Why are the new events not sent to the app, even though live-pages work?
These events currently do not work with Connect either.
