Summary of Project:
We are implementing a bulk conversion capability on the space and site level for admins to bulk convert eligible pages from legacy editor to new editor. We would like to get the community’s thoughts on this process - whether it interferes with existing migration processes you have implemented, and any concerns you have about your macros.
- Author: 18 Apr 2023
- Publish: 20 Apr 2023
- Discuss: 12 May 2023
- Resolve: 26 May 2023
Problem
We have customers wanting to bulk convert pages from the legacy editor to the new editor in order to take advantage of the capabilities of the new editor -
Today there is only a single page by page conversion capability - but if a customer reaches out to support, they can enable a feature flag that converts pages eligible for conversion to the new editor. However, this may not be well understood by most of our users.
This is especially painful for migrators wanting to convert pages to the new editor, as all pages migrated begin in legacy editor.
This also aligns with our continued and future investment in the new editor and movement away from legacy editor.
Proposed Solution
We are proposing building the option in the UI for admins to bulk convert eligible pages from the legacy editor to the new editor both on a whole space and whole site level.
Eligibility mainly depends on if the page does not contain nested bodied macros, as they are incompatible with the new editor. There are also some minor changes during conversion to certain macros described here: Convert pages to the new editor | Confluence Cloud | Atlassian Support
At this time, we will also be excluding conversion of pages created in cloud using the legacy template or pages that were converted to the fabric editor but reverted.
From a user perspective - here is how the flow works on a high level:
-
Admin enables bulk conversion of eligible pages in the space or site.
-
For eligible pages, pages will render in the new renderer when users view the page.
-
Pages will also utilize the new editor if the user goes into edit mode and user will receive a notification of this conversion the first time this occurs (the editor property is not set for new editor until user publishes with the new editor).
-
Users will be able to revert the change from the dropdown menu if the page has not been published. If the page has been published, they will need to revert from page history.
-
This change is also able to be reverted at the space or site level, but will not revert pages that have been published.
Here is the flow from an architecture perspective:
At this point we are considering excluding pages containing vendor macros from automatic conversion while we collect further feedback from vendors as we are aware that there are vendor macros that were migrated from server that are not compatible with the new editor.
Actions
While we would appreciate any reactions you have to this RFC (even if it’s simply giving it a supportive “Agree, no serious flaws”), we’re especially interested in learning more about:
- If this interferes with existing server to cloud migration processes your app has. We are aware of app migration processes that involve conversion to the new editor.
- Your thoughts on initially excluding pages with vendor macros from bulk conversion. Would you like to be able to be able to contribute to this conversion process with your own rules for your macros?
Resolution
- What did we hear? We had limited feedback here but overall understand vendors would like to build for one editor - this tool will help facilitate that.
- What did we change? We will not be excluding any specific vendor macros from conversion given that this is opt in and reversion capability is present.
- What is coming next? Look out for the feature to roll out in Q3 2024.
As a Confluence user, the new editor is also nicer to use, IMO.