Confluence 4.0 Editor FAQ

Confluence 4.0 will introduce a new editor. We first made this announcement at Atlassian Summit in June 2010.

People are already asking important questions, which we will answer below as soon as we can and in as much detail as is available. We are publishing these FAQs as early as possible, as soon as we have information that will be useful to you. The content is not final, but it is as correct and authoritative as we can make it. We will update it on an ongoing basis, as we get closer to the release date of Confluence 4.0.

How can I stay informed about the progress of the new Confluence 4.0 editor?

Here are some things you can do to keep up with the news about the Confluence 4.0 editor:

Watch the Confluence 4.0 Editor FAQ page, and any other pages you like, if you would like Confluence to send you an email when we update the page.
To watch a page, sign up for a username on this documentation wiki if you do not already have one, then open the 'Tools' menu on the page and click 'Watch'.
Sign up to the Confluence User Task Force.
The purpose of this user task force is to give you the opportunity to provide a more detailed level of feedback on Confluence as a product. This will help us learn more about our market and better meet your needs. Members of the task force would be asked to participate in such things as:
- General surveys on Confluence use cases, features and ideas.
- Feedback on early releases of the product.
- Usability and user experience testing.
How often would you be asked to participate? As a general rule we won’t be asking you to participate any more than once a month.
We will notify all members of the Confluence User Task Force once the new editor is available for feedback. You can sign up here.

Why is Atlassian introducing a new editor?

The editor is the single most important feature in Confluence. Currently, Confluence has two editors: the rich text editor and the wiki markup editor. Each has its strong points and its weak points.

The rich text editor in particular has problems in stability and consistency, because it has to convert all content from rich text to wiki markup before storing content on the database. This leads to the so-called 'round-tripping' problems, where the page looks different in display mode than when created in edit mode.
Many people find the wiki markup editor hard to use, particularly for long pages and complex layouts. We often hear from customers that the number one barrier to wiki adoption in their organisation is that people have to learn wiki markup.

Many customers have given us great feedback on the shortcomings of the current editors and the things they would like to see in a Confluence editor. We are introducing a single new editor to replace both the wiki markup editor and the rich text editor. The new editor will help us to solve the problems mentioned above and will provide a stable platform on which we can build high-demand features in future releases.

On this page:

What about features that were previously available only in wiki markup?

We have identified these features and will add support for as many as possible in the new editor. For example, the new editor will include superscripts and subscripts, which are currently not available in the existing rich text editor. We will update this page as soon as we have a list of features that will be supported.

So you are basically eliminating the wiki markup editor and keeping the rich text editor?

No. While the new editor is WYSIWYG like the current rich text editor, the new editor has a completely different architecture based on XHTML and is thus faster and significantly more reliable. Our goal is to incorporate the strengths of wiki markup with the richness and intuitiveness of the WYSIWYG editor to produce a rich, hybrid editing experience. In particular we are introducing options that offer the speed of the old wiki markup editor, via new features such as autocomplete and shortcut keys.

Will you be able to paste wiki markup into the new Confluence editor?

There will be multiple ways to insert wiki markup in the new editor.

For those of you that have learnt wiki markup and are used to the speed of wiki markup we are really excited to let you know that you will still be able to write wiki markup in the new editor. This wiki markup will convert 'on the fly', providing one of the fastest editing experiences yet. Stay tuned for a demo of this feature.

For those of you that have scripts that produce wiki markup, or often write wiki markup in meetings, the new Confluence 4.0 editor will introduce an 'Insert'>'Wiki markup' dialog which will let you paste wiki markup for a one-way conversion.

Will Confluence 4.0 support the Office Connector, including 'Edit Page in Word' functionality?

Most of the features of the Office Connector (the viewfile macros, import from Word) already work in 4.0. However, we'll need to completely rewrite the 'Edit in Word' functionality in order to make it work in Confluence 4.0. At this stage we are deciding whether to ship Confluence 4.0 with most of the Office Connector functionality (excluding 'Edit in Word') or to hold up the release in order to ship with the 'Edit in Word' feature.

Why has Atlassian not yet made a decision on this?
When speaking to customers about the use of the 'Edit in Word' functionality the primary reason for using this feature is 'familiarity'. Business users in organisations have found the editor and wiki markup hard to learn. The 'Edit in Word' functionality is required to make this transition easier. Other reasons include increased reliability as well as the spell check functionality of Word.

In Confluence 4.0, we have greatly simplified the new editor user interface. With extensive usability testing, we are confident the new editor will be easier to learn and more reliable to use. We also have a large majority of customers who do not use the 'Edit in Word' functionality. Holding back the release of Confluence 4.0 to rewrite the 'Edit in Word' functionality would not benefit that group of customers. With that in mind, we welcome any feedback from your business users on how true this is for them. We are trying to deliver public development releases of Confluence as soon as possible to get your feedback on this matter. We will update this page once we have our first public development release available for you to try.

Please Note: We are referring to the "Edit Page in Word" functionally - not the "Edit Attachment in Word" functionality. Editing attachments in Word will still work fine.

In Confluence 4.0, will you be able to merge and split table cells?

Yes, you will be able to merge and split table cells.

When will the new editor appear in Confluence?

The new editor will be in Confluence 4.0, scheduled for release in 2011. We will give as much notice as possible before the final release and will provide further updates when we can.

What does the new editor look like?

Confluence 4 is currently available through our Early Access Program. You can download and try the new editor for yourself. This is a great opportunity to provide early feedback to us. More details about this here.
You can also watch a video preview of Confluence 4 from our Atlassian Summit in June 2011. Watch the video at this link.

Will Confluence still have a wiki markup editor?

No. We plan to incorporate the best parts of the wiki markup editor into the new editor.

Will you be able to edit the source XHTML code directly?

Confluence 4.0 will not have an "edit XHTML source" mode. More sophisticated macro placeholders, images and link handling in Confluence 4.0 entail a lot of custom XHTML which make the new storage format much more complex than standard HTML. Editing this storage format by hand too easily results in corrupt content and the loss of page data. Source editing will still be editable via the APIs and the WebDAV client.

What format will Confluence use to store its page content?

XHTML. Up to now, Confluence has stored its content in the database as wiki markup. In Confluence 4.0, the content will be stored as XHTML. Basically, XHTML is like HTML but complies with stricter formatting rules. Where HTML is based on SGML, XHTML is based on XML, which is a subset of SGML. Because XHTML documents need to be well formed, they can be parsed using standard XML parsers.

Will there be a tool to convert existing content from wiki markup to the new XHTML format?

Yes. Where possible, Confluence will automatically upgrade existing content into the new XHTML storage format. There will be some API changes but we are trying to keep them to a minimum and we will provide facilities to convert wiki markup to XHTML. We will document and publish the API changes well before the release of Confluence 4.0, to give developers enough time to give us feedback about the changes and to adopt the new APIs.

Will there be any API changes?

See the answer to the question above.

How many Confluence 3.x releases will you have before 4.0?

There will be no more 3.x releases before 4.0. 3.5 is our last 3.x release.

Will the remote XML-RPC API still work in Confluence 4.0?

We currently plan to keep the existing XML-RPC API but only allow write access which will automatically convert wiki markup to XHTML. This will allow you to create new pages or update existing pages as usual. We can't allow read access, however, because we can only return XHTML, which will break the existing APIs contract of returning wiki markup. To cover those use cases and to have a fully XHTML capable API we will introduce a new API available through a separate URL which will also have a new method to migrate wiki markup to XHTML.

Developers should read Preparing for Confluence 4.0 to learn more about API changes.

Will the new editor be included in JIRA?

At the moment we don't have any plans to do this. However, we are open to this idea and would seek any customer feedback in this area.

Page tree