This is what I learned so far when using Live Edits with some marketplace apps.
BTW, the header section is a mix of Editing and Viewing modes.
Space setting for Live Edits applies to NEW pages only.
Live Edits can be enabled for individual pages in any space. To me, that’s an oversight on Atlassian paths as it might have unexpected effects.
At Emplifi, we’re using Scroll Apps to power the processes and our doc website.
After the initial testing, you can use Live Edits as a page-based workflow control if you use Scroll Viewport for you content. With some caution.
In Viewport, a brand new Live Edit page appears in the change-log and is published to a Viewport site - WITHOUT CONTENT. The page appears in the tree but has no content.
A new Live Edit page’s heading does not always end up in the correct position. It happened to me several times but I could not replicate it when I tried.
Scroll Documents see the new Live Edit page. You can verify that via Page groups. A new Live Edit page behaves like a normal page)
When a Live Edit page is saved (Published), the content shows up in the Viewport site as expected.
Subsequent updates in a normal Edit mode behave as expected.
To prevent a new Live Edit page from appearing content-less in a Viewport site, use the scroll-help-center-exclude-page label.
A page with scroll-help-center-exclude-page label still shows up in the Viewport change-log but is not visible in the Viewport site.
removing the label results, of course, in the page making it to the Viewport site
Once you save (Publish) the page, the content will appear in your Viewport site.
When page is manually entered into the Live Edit mode:
Re-entering the Live Edit mode for a page results in changes nor propagating to Viewport and the page doesn’t register in the change-log.
Content is not published to the Viewport site until the page is ‘saved’ again.
Moving the Live Edit page in the tree is reflected in the Viewport side
Things get a bit trickier here.
Terminology such as status, approve, publishing refers to the apps, not Confluence unless otherwise stated.
A Live Edit page is ignored by Document Approval and, as a result, it has no bearings on Comala Publishing if you’re using Approval status change to trigger Comala Publishing
Once you save (Publish) the Live Edit page in Confluence, it falls into the Review (the initial state), Comala Publishing registers the page as New.
If you change the Approval status to Approve in the app, this triggers Comala Publishing and the page is synced to your target space (Synced)
If you edit the page the normal way, Approval and Publishing apps work as expected.
So far so good.
HOWEVER… re-entering the Live Edit mode will wreck things.
After you save (Confluence Publish) such a page, it will change status to Review…
Comala Publishing status will revert to NEW.
This breaks the connection between the page pairs (source space and target space)
When you Comala Publish such a page to your target space, it will delete the previously published page.
As a result, if you’re using Comala Document Approval and Comala Publishing, Live Edit works only for the initial iterations of your new pages. Avoid using Live Edits for your existing pages.
What I wrote is valid as of May 29, 2024. Apps get updated all the time, so is Confluence.
If I find something new, I’ll publish it here or in the comments.
Similarly, if you experience a different behavior, let me, and others know.
At the moment, I DO NOT recommend using Live Edit in workflow and compliance environments or if you're using 'presentation layer' apps to present your Confluence content.
Kristian Klima
Director of Technical Content, Emplifi
Emplifi
Prague, Czechia
187 accepted answers
5 comments