Documentation for Confluence 4.3. Documentation for earlier versions of Confluence is available too.

Skip to end of metadata
Go to start of metadata


Commonly brought up comments which may be of use to others who are following this page

How can I edit the source / storage format of a page in Confluence or in an external editor.You can download the Source Editor, a free plugin maintained by Atlassian and available here.
I have a script that generates Wiki Markup, can I still insert it into a page?Yes. You can use the Insert Wiki Markup Dialog, just choose 'Insert' then 'Wiki Markup' or use the shortcut "command/ctl + shift + D"
I have a script that generates Wiki Markup and writes it to a Confluence page using the API, can I still do this?Yes. You can still send Wiki markup to the API which will convert it to the new source format and save. See this Answers discussion for more.
I have a script that consumed Wiki Markup from Confluence, do I need to re-write it?Yes. Wiki Markup is no longer available as an output from Confluence. Unfortunately this means you will need to re-write any scripts which consumed Wiki Markup from Confluence (often via the API as an example) to instead read the new XML based Storage Format.
I take notes in meetings etc offline in a text editor, formatted with Wiki markup then add them to a page later, how can I do this now?Take your notes as before then insert them into a page using the Insert Wiki Markup Dialog, just choose 'Insert' then 'Wiki Markup' or use the shortcut "command(or ctrl)+shift+D"
How can I move the cursor outside a Macro (eg: a {code} or {column} macro) without using the mouse?You can just press the 'down' arrow until the cursor moves out of the macro and back onto the page.
A macro I wrote that worked in 3.x no longer works for Confluence 4See Upgrading and Migrating an Existing Confluence Macro to 4.0
Enter/Return gives me a new paragraph, how do I insert just a line break?Press Shift+Enter
How can I quickly turn already entered text into a linkYou can highlight the string you want to convert, press [ and wait until the autocomplete menu appears then select from the available options to Search for a page with the title of that text, insert a web link with that text as the clickable link or to insert a link to create a page with that title.
A short "how-to" from Shannon Greywalker for doing unbalanced tables, tables within tables, etc. in the new 4.x editor.Available here.
Why not make wiki-markup editor on top of XHTML storage? Just some engine, which would convert XHTML to wiki-markup and back on save.

Wiki markup can only represent a subset of what can be represented in XHTML. A wiki to XHTML conversion would be lossy meaning that when a 'wiki preferring' author made changes to the page of an 'xhtml preferring' author they would mangle (to some degree) the original author's page.

This is a reverse of the round-tripping bugs that used to be encountered when the storage was wiki but the editor was HTML.

One fairly typical example would be the case of merged table cells. Confluence Wiki markup cannot represent merged cells, whereas XHTML (and so therefore Confluence storage format) can.

I want to force something to stay as Wiki Markup on a page, not be converted.You can use Bob Swift's Confluence Wiki Plugin, details here.

External Resources

Contributors to this page have kindly collated the following useful references which may assist anyone transitioning from Wiki Markup to the new Editor

  • A short "how-to" from Shannon Greywalker for doing unbalanced tables, tables within tables, etc. in the new 4.x editor is Available here.
  • Advanced tips on the Confluence 4 editor, wiki markup and the XML storage format by Graham Hannington are available here: Advanced Confluence Tips. These include information about Wikifier, a tool for converting Confluence XML to wiki markup, and for converting Confluence rich text to wiki markup.

Bugs / Improvement / New Feature Requests

If you have feedback on a bug, a task you now find harder or are unable to do in the new editor then please leave a comment below and we'll incorporate it into this page (and remove the comment afterwards). Please note that these are usually only updated once completely fixed, we track progress separately on an internal queue.


 Click here to expand...

type key summary resolution

JIRA project doesn't exist or you don't have permission to view it.

View these issues in JIRA


Too add your issue, please raise a ticket in the CONF Project using the Component 'Editing' and specify the Affects Version. For bugs, please include your OS and Browser details.

 Click here to expand...

Please note that while JIRA issues have been raised for all these comments, I don't want to set unreasonable expectations so just be aware that being in this list is not a guarantee of something being implemented. As always our Implementation of New Features Policy and Bug Fixing Policy apply.

key summary status

JIRA project doesn't exist or you don't have permission to view it.

View these issues in JIRA

key summary status

JIRA project doesn't exist or you don't have permission to view it.

View these issues in JIRA

Require More Discussion

 Click here to expand...
Customer Feedback  Atlassian 
ThemeFromCommentNotesRelated Tickets
Removing HTML/CSS after Import/PasteAndreas Pfotenhauer...imported from a trac wiki, and the importer had left some strange inline css in place, setting some padding and margins, and i was not able to remove it using the new wonderful editor, so finally i edited the page directly in the database...

Andreas, Matthias, I wondered whether you tried to select all content and use the 'Clear Formatting' option and how well that worked?


Matthias BaslerFinding bugs in the source code  is difficult or impossible since one cannot see them in the WYSIWYG editor. (This includes invisible tags that should not be there, f.e. after copying content from a word document into the page) 
FormattingNils AndresenIf I have a table (or a note/warning) directly followed by a heading
  • previously I simply added a new line between them
  • now placing the cursor in the table and pressing enter does create a new line - but in the table
  • placing the cursor before the heading and pressing enter creates a new heading
    • so i'll have to use the mouse to "undo" the heading - then start typing

Nils, for a quick workaround of sorts, you can use the Keyboard Shortcuts to remove (and apply) the heading so you don't need to use the mouse when using your second approach.

Do you think instead of maintaining the heading format on the line you create between the bottom of the table/macro and the heading we should instead default it to a plain paragraph? I'm not sure which seems the more natural myself, interested in your thoughts.


Anchor Linkssanjay srikondaLinking within the same page is a nightmare in 4.0. I have to press CTL+K to bring up the link window, yet, NOTHING in that window seems to work for linking within the same page. I have to create the same link 3-4 times before it "sticks" in my page.Sanjay, I'll try and recreate this and raise a bug in JIRA for you. 
Inserting Imagessanjay srikondaInserting graphics through the UI is buggy because sometimes it will insert a graphic just fine and the next graphic it will NOT show up or even show in my attached dialog. And, sometimes, thumbnails are not showing up for some inexplicable reason.Sanjay as mentioned previously this definitely sounds like a bug, did you raise a support ticket? 
Working OfflinePeter BurkholderToday I had to work on several significant planning pages while on a trip with no network access.  With mark up this can still be done, but in 4.x that is gone

Peter, interested in whether you were creating new pages or editing existing? How often do you need to do either ? How did you do it 3.5? If you document in a text editor did you know you can use the Insert > Wiki Markup dialog to put it straight into a page, would this work for you?


Anonymous x3I often capture technical documentation in another editor before posting it to the wiki – this is in lieu of not documenting at all. What is broken is the ability to take these documents in wiki markup and work with it offline before reposting.Is the problem here then that you need to be able to work offline? 
Find & ReplaceDiego BallveSometimes I used to copy a page away, do replacements on it using wiki syntax on text editor (say most of the page was good some paths and variables in the content had to be changed to reflect a different environment), then insert it back as new page. No can do now.Diego, does the find/replace functionality in 4.1 solve your issue? 
Contribute without Access AnonymousSend a page by email in wiki-markup to a customer and they could update the documentationAre you able to provide any additional details of the use case behind this? Interested in the scenario you have where the user can't be given access to edit directly, maybe security etc? 
Matthias BaslerOne point that became important for us just now is that up to now the wiki markup allowed to easily exchange content between wikis. Since confluence 4 there's no easy way any more to just copy the content or parts of a page to a text editor, send to someone else and have it inserted into another confluence wiki.Matthias, interested in your use case as well and why it's not possible for you to just have access to the other Wiki if you need to contribute to it? If it's just an ad-hoc/one off thing, interested in how often you do this?  
Copy page structuresAnonymousCopy/paste of complex layout, even on a mobile device

What's the use case behind this? Not something copy page can do? Have you tried copying from the Editor or View Source page?

How often do you do this on a mobile versus desktop?

Mixed Listssanjay srikondahow do I make a bulleted/numbered list with either/or in between and then continue the numbering.Sanjay, I think CONF-23899 will be the beginning of the solution to this also. The next step will be allowing bullets to be included after the delete is done. Do you think that interaction makes sense? 
Behaviour of EnterNils Andresenthe "enter insert new paragraph"-feature makes me crankyNils is this in lists (like above) or other situations also? Did you know about Shift+Enter to get a new line instead of a paragraph? I've added this to the FAQ and will remove this entry shortly. 
Updating User Macroseddie connatser

I created my own Editable Table macro - which relies on saving its content by doing a form post with it's content as wiki-markup and html. The fact that wiki markup isn't processed in the new wiki editor breaks this macro.

Eddie, do the details on Upgrading and Migrating an Existing Confluence Macro to 4.0 help? 
Pasting textBrad Newmanit takes several button clicks and creation of whitespace to try and paste text in cleanly or fix errors in formatting (e.g. copy plain text, paste it and have it show up as bold, press return to separate out some whitespace, paste again, etc.)Brad, I'll take a minute later to see if I can recreate this. Do you have any other specific examples of whitespace problems? 
TutorialsGreg WhitfieldCan you do a comprehensive "New Editor for Hardcore Wiki Markup Users" tutorial/whitepaper/video, that explains how they would work around the limitations imposed by the removal of the wiki editor

Greg, can you let me know what limitations people are reporting?

Have you read Whats Changed for Wiki Markup Users? Very interested in your feedback if that didn't give you what you were after.


Shortcuts Helper

Diego Ballve

Jean-Yves Avenard

Shortcuts? I'm sure they are there.. but what about some simple list as the wiki markup list? And please don't tell me to click this icon or that icon, that is not what I'm after. Consider a help bar in the right side of the editor, for instance.

I can't remember all the keyboard shortcuts as there are so many of them

Diego, Jean-Yves have you seen the (question) icon at the top right of the editor bar? Click this gives you all of the shortcuts. Does this help, or do you mean that there should be a permanently displayed list of these while editing at all times? 
Bug when LinkingAnonymousCreate a link on one line, looks fine in editor but preview has the link extending to the rest of the text on the pageI'll try to recreate and document this in a bug ticket. 
Cursor PlacementDon GambleExperiencing issues with cursor placement / cursor not being present on the screen and also selection highlighting problemsJIRA issues to be created shortly. 
Whitespace in Sections/ColumnsMatthias BaslerWorking with lots of sections/columns (i.e. we use them to position images and their captions) causes very clumsy nested macro blocks having lot of white space. This reduces the amount of visible content in the editor and makes the page appear very large (in the editor), which makes it hard to find the pieces to edit. Having a more compact appearance (similar to the tables!) would be preferable.  
Cursor PlacementEddie FastCursor navigation doesn't behave as expectedComments below. Eddie, I'll update this soon, thanks for getting back to me. 
Paste ProblemsEddie Fast Copy/paste doesn't work as expectedAs above 
Paste ProblemsEddie Fast Pasting into a bulleted list causes the entire document to go bold

As above

Copy to/from JIRA

Alex (posted Anonymously)


We do sometimes copy over parts of the text from JIRA to Confluence and back, and earlier the wiki markup mode allowed to keep text formatting fully same across both systems without any additional effort.Right now you can copy formatted text from JIRA to Confluence, if you highlight and copy it from the issue details page, not issue edit. However, this is not that handy, because you can't use Ctrl+A to actually highlight all the description text instantly. And obviously - there is no way now to copy formatted text parts from Confluence to JIRA.


Alex, I'd love to hear more details on your use case for this. Even before when both editors were using Wiki markup, it seems like a lot of manual work.

Interested to know whether the new Remote Issue Links functionality that is coming in JIRA 5.0 would help you. You can see this working on right now, eg: because I've referenced CONF-24038 - Getting issue details... STATUS on this page there is an automatic issue link created to point back to here (as well as the obvious link from here to the JIRA case). I find this handy as then say a spec will be written in Confluence and easily linked to the JIRA case.

Seems to me the goal for us should be that we allow Confluence and JIRA to integrate in such a way that more value is created by using them together, and you wouldn't feel the need to copy/paste descriptions between them, so very keen to hear if Remote Issue Links helps or if it doesn't, more details on your needs.

(question)Jean-Yves AvenardIt's just not possible to concentrate on the content and focus on the aspect laterJean-Yves interested on more detail on this. Since you could just create text and format it later, I assume there is more to it than that? 
(question)Diego BallveNavigation is gone from the side when editor is on.. why?Diego, can you let me know what you mean by this one? 
(question)AnonymousThe new editor is nice, but is a pain. A lot of functionality is lost. A lot of productivity is lost.Love to get the details of the functionality and productivity 
(question)nicolas frankstill som bugs to fix, but I am sure it will progress through the next versionsNicolas, if you have any specific bugs you'd like listed please let me know 
(question) AnonymousI loved being able to focus entirely on the content and not to worry about the formattingDoes Wiki Markup Styler help with this? What is it that inhibits you from writing out your document then coming back through and formatting it afterwards? 

Additional Ideas

 Click here to expand...

While we want the focus of this page to remain specific and detailed feedback on the new editing experience that we can address, a number of people have put considerable effort into outlining their ideas for alternate editing strategies and we also wanted to capture these below.

Alexy KotenkoOkay, as the WYSIWYG abilities are wider than wiki markup allows - let it be. But you can still provide a solution similar to one implemented in JIRA search. In there you have a search form for rather simple requests, and direct SQL edit for complicated requests. And if directly edited SQL is too complicated to show it as a form - it just tells you "search query is too complicated" and doesn't allow to switch back to form.

As earlier you have claimed that implementing XML-to-wiki transformation is easy - I see no problem to still allow wiki edit, but with XML format on backend and disallow wiki if something too complicated was created through WYSIWYG.

This can easily be added as a plugin, to solve your problem with complains on the core software.


(In reponse to Alexy)

This sounds like a very good idea, and I hope Atlassian will take the time to investigate it. By definition, people who still want to use wiki markup will not be using the most complex WYSIWYG-only formatting, so it should be possible to convert almost everything such users write back to markup.

Another suggestion would be to extend the Wiki Markup Styler plugin to do the same thing.  Ideally, any content that can be converted back to markup, would be. And any complex elements that cannot be converted would just appear as they do in the normal WYSIWYG view. This would avoid the possibility of one complex piece of content causing a whole page to be marked as "too complicated to edit through wiki markup".

If Atlassian choose to do this, the other vital requirement (for me) is that we can copy the wiki markup from the editor. At the moment, the plugin displays markup elements on-screen, but if I try to copy them it just gives me the underlying text. In common with other commenters, sometimes I prefer to copy markup from a Confluence page into a text editor and edit it there, before pasting it back (either into a different page, or into another part of the same page). 

Todd Day

Andrew Spina

Keep wiki markup format by wrapping in a "wiki markup" macro


Todd - Ability to wrap entire pages in the Wiki Markup macro and not have them auto-convert to storage format. Additionally:

  • Macros that come from plugins I currently use in 3.5 continue to work the same way in the wiki code block.  I'm willing to wait for the authors (Adapatvist, Customware, and the guy who wrote the LaTeX plugin) to upgrade their plugins for 4.0, but the end result must be that I can write in 4.0 wiki code blocks the same way I currently write in the 3.5 wiki editor.
  • User macros I wrote for 3.5 need to also appear in the 4.0 wiki code blocks.
  • When upgrading from 3.5 to 4.0, I want the upgrade process to wrap every page in a wiki markup block instead of converting it to the new XHTML format.
  • Site and Space themes should be definable in terms of Wiki format.
  • It would be nice if the wiki code blocks had a button on them that would convert to the new XHTML format if you pressed it.  I understand this would be a one-time no-reversal operation, and that would be fine with me.



  • I haven't read through this post, but this page says to post requests here. I'm new to confluence (and like it a lot), but was wondering why wiki markup is translated into a wysiwyg format after entry. I was wondering if it made sense to allow people to make a container (like a new column) which would preserve wiki markup, but render it on the saved page as rich text? I know it's not as friendly to non-technical users, but it seems a bit closer to the middle ground. Just a thought...
  • See related issue at CONF-23895 - Getting issue details... STATUS
Don Gamble

Treat macros and all special editor objects (images, links, etc) the same - i.e. they would all have a frame.

Currently the new editor doesn't treat everything as equivalent. This results in issues with where the insertion point moves during editing, what is selected, what gets cut or pasted, etc. Treating everything special (i.e. macros, images, links - things with parameters and/or bodies) as a framed object allows everything to be treated as an object, just like a character of text. Providing the frame also now allows you to explicitly see what is inside and outside a special object and allows you to select the object. For example, there is currently no way to select a link. You can select text that is linked, you can select an image that is linked, but you can't select a link. Raised in CONF-24026.

Don Gamble

Display the associated parameters of the object (macro, image, link, etc) as text in the header of the objects frame.

With macros and special objects now having a frame, the hidden parameters of a macro/special object can now be displayed. Entering edit mode should expose all of the hidden information that is not visible when the page is rendered. Currently entering edit mode results in still having to enter a deeper edit mode (i.e. the macro browser or the special popups) to see the true values to edit. An edit mode within an edit mode is a huge productive hit. Simply seeing how a page was created is not currently possible while in edit mode.

A guiding rule should be "While in edit mode the user will be able to inspect the page and see all the properties effecting how the page renders without needing to do any further activities." If this rule was true a majority of the productivity hit of the new editor would be resolved. To do this requires displaying the parameters of macros and special objects in their frame. Raised in CONF-24026.

Don Gamble 

Allow the parameters in the frame to be edited as name value pairs and re-interpreted when focus leaves the frame.

The final hit to productivity of the new editor is the need to enter a sub-edit mode (the macro editor or the special popups) when making a change to a parameter that is already applied to a macro or a link/image. Allowing the name value parameter pairs in the frame to be edited would allow rapid changes to be made with a few keystrokes with no loss of user focus caused by having to visit a dialog.

Allowing new parameters to be added into the frame by just typing, for example "width" which is an obvious and easily remembered parameter on many macros, would allow common edits to occur quickly. Parameters that could not be parsed after the edit completes (i.e. after focus leaves the frame) could be handled by highlighting or in a similar way to how firebugs lets users change the parameters in the html editor window. Raised in CONF-24026.

Don Gamble & Eddie Fast

The confluence editor should behave very similar to every other commonly used editor. At a high level, today's user's expectations of how an editor reacts is common across all editors. If the editor doesn't behave as commonly expected then the user's experience is compromised (some would say the editor is broken or unusable). I see these expectations as (please comment - do others agree?):

    1. The focus of all activity occurs at the insertion point or selection.
    2. Pressing backspace or delete, removes what is to the left/right of the insertion point or removes what is selected.
    3. Typing or pasting inserts the contents at the insertion point or replaces the selection and leaves the insertion point after what is selected.
    4. Moving left, right, up, down with the arrow keys or page up/down in a document, if the same key presses are reversed, should place the cursor back in exactly the same location as it was before the first key press.
    5. Holding the shift key while moving left, right, up, down should extend (or start a selection from the insertion point). Pressing the opposite key should reduce the selection.

In general, the new editor doesn't respects these user expectations. This makes it slow, hard to use, and I would argue filled with special situations that while can each be individually explained as correct - as a whole make it wrong. An editor should be a simple experience - not complex.

Specifically with respect to what should happen when the insertion point is at the beginning of a macro, i.e. just inside the body. I would suggest:

  • Pressing the backspace key should do something, currently it does nothing when just within the body.
  • Pressing the left arrow moves to the outside of the macro (CORRECT), but starting at the same spot and pressing the left arrow, while holding the shift key, doesn't appear to do anything.
    • Unfortunately, it is more complex (in Firefox at least) continuing to press the left arrow while holding shift results in first the insertion point disappearing, with nothing selected, then nothing on the next key press. After some number of key presses the insertion point reappears with no selection. Reversing, i.e. pressing the right arrow with shift held, results in the insertion point appearing, then a selection appearing, then an insertion point, etc. Nothing is obvious as you attempt to select across a macro.

Open company, no bullshit


A Message from Atlassian's Founders

Hi there,

Most of you already know why we removed the wiki markup editor in Confluence 4.0. We pride ourselves on being an open company, so it should be no surprise that we were really upset to learn that a few customers felt we had 'betrayed them' with this decision.

Firstly, to those people, we are genuinely sorry that you did not know about this change. We want you to know that we fully understood the enormity of this change for our existing customers - hence why we began communicating our plans over a year in advance in order to give everyone ample time to prepare. We started this process 15 months before shipping Confluence 4.0. During this period we made many public announcements about our intentions, collected tons of feedback throughout our Early Access Program, and built a comprehensive set of resources including:

  • June 2010 - At Summit 2010 we publicly announced our plans to consolidate the wiki markup and rich text editors into one single editor in Confluence 4.0
  • July 2010 - Released an FAQ about the changes we had planned. Over the year we received a lot of questions and updated the FAQ very frequently
  • December 2010 - Atlassian began using Confluence 4.0 in production internally and began gathering feedback from heavy wiki markup users
  • June 2011 - Released a comprehensive Early Access Program ("EAP") where customers could download 4.0 and provide feedback. We received and responded to over 250 pieces of feedback during the Early Access Program
  • June 2011- Included with the EAP we released a comprehensive set of "change management" documentation including:
    • A comprehensive set of release notes describing every new feature and planned change in 4.0
    • A comprehensive planning guide for Administrators, End Users and Developers
    • quick-guide to help administrators prepare
  • June - September 2011 - Frequently updated EAP releases where we collected customer feedback and responded with changes / fixes
  • September 2011 - Released Confluence 4.0 with a microsite to help users discover new features and a complete change guide to help avid wiki markup users learn to be efficient in the new editor

If you did not hear about the new editor via all of these communiques, we're sorry. We will endeavour to communicate even more in the future, especially should there be another such major update.

Collective customer feedback drove this decision

We listen to our customers – a lot. The number one reason we made the decision to remove the wiki markup editor was the collective feedback we'd been gathering since we first released Confluence in 2004.

We've always encouraged you to publicly tell us how we can improve our products and make them work better for your organisation. We can't think of another company that is as open as Atlassian and we're proud of that.

Looking at the feedback we received and the things we heard time and time again in countless customer interviews, it was clear as day that the dual editing experience – Wiki Markup and Rich Text – was the number one hindrance to Confluence adoption.

The endless cycle of round-tripping bugs made the editor unreliable and unusable for the majority of users, and the lack of advanced features like the ability to merge table cells was stopping you from seeing the full value of Confluence.

You told us these things, we listened, and replacing wiki markup was the most viable solution to giving you what customers collectively asked for, a kick-ass editing experience with more powerful editing features.

Customers love the new editor

Has it been all bad news? No - far from it. We've been thrilled with the overall response from customers so far. Here's a sample of the feedback we've been seeing about the new editor in Confluence 4 – there's much muchmuch more. I didn't have time to list all of the tweets, emails and "Contact the CEO" submissions we've received:


Yet... there are two sides to every story

Up front communication and listening to users aside, we're not blind to the fact that there are customers who were completely happy with the wiki markup editor and don't see the need for a change.

Don't get us wrong, we do understand their point of view. They just want a wiki markup editor and we understand their frustration at our decision to replace it with a higher fidelity storage format.

We still believe we made the best decision based on the collective feedback we received from the majority of our customers over the years – but, being completely frank, wiki markup is not coming back. The new editor is our path going forward.

We've been listening to your feedback

Thanks to all of you who took the time to provide constructive feedback about the new editor. You've helped us highlight issues that we need to address. Our Confluence team has been working really hard to get the following features and fixes into your hands:

1. Find and Replace within the editor – shipped in Confluence 4.1
2. Wiki Markup Autoformatting for Macros, Links, and Images – shipped in Confluence 4.1.2 
3. WYSIWYG Page Layouts – coming in Confluence 4.2
4. WYSIWYG Page Templates – on our short-term roadmap

We're 110% committed to making the new editor an even more kick-ass, reliable editing experience. Truly the best editing experience in the world. We've made huge leaps in the last year - but we're not done yet.

We have a team of passionate, dedicated developers working full time to improve the editor and address niggles that arise.

We're building a source editor!

We've learned from your feedback that customers have a number of valid reasons for directly editing the source of a page: 

  1. They feel locked-in - Because people were no longer able to edit a text based version of their page directly, they felt they were locked into Confluence. While you could always still get your content out via the API or through WebDAV but people wanted to be able to see it directly. This was never our intention and we're rectifying it in two ways as you will see below.
  2. They want to fix formatting niggles - Unfortunately over the years we trained everyone on this - what do you do when you hit a bug in the RTE? Switch to wiki markup. This wasn't really acceptable then and definitely isn't now, but people have asked for it over and over.
  3. Content workflows - We underestimated how many people copy the source of their page out of Confluence to work with it in other ways, whether it be updating content offline, sharing with others via email, or using a preferred text editor for things like bulk changing of link properties.

Since we realise how important source access is to you, we're currently working on a free "Advanced Editor" plugin that will allow your users to edit your page's source amongst other advanced user editing. We hope it will address the major issues that some users have identified, like the ability to search for and update URLs and the file names of embedded images.

You can check out and comment on the spec at Specification - Confluence Advanced Editor.

The beta for this plugin is now available on the plugin exchange under the name Confluence Source Editor.

We welcome your feedback - please file issues in the JIRA project at

Storage Format

Some people have questioned whether this is a vendor lock-in play. It is not. The new storage format is based on XHTML with extension tags for Confluence specific functions. We've begun documenting it here so you can see exactly what is happening under the covers - to use in your plugins, remote applications, scripts, integrations etc. I think you'll agree this is pretty "standard stuff" and able to be understood by those who need to script it.

We refer to the Confluence storage format as 'XHTML-based'. To be correct, we should call it XML, because the Confluence storage format does not comply with the XHTML definition. In particular, Confluence includes custom elements for macros and more. We're using the term 'XHTML-based' to indicate that there is a large proportion of HTML in the storage format.

Why didn't we do this in the first place?

When we shipped Confluence 4.0 we decided to not offer a source editor for a number of reasons. First of all, the new XHTML-based storage format is more complex than wiki markup so it's not as readable to the average user. Secondly, we wanted to protect less technical users from breaking their pages by accidentally deleting a closing tag or entering invalid HTML. This is why we're proposing that the source editing plugin is only enabled for your advanced users - and the storage format is not meant for day-to-day human editing.

Just try it.

Seriously, I encourage you to give the new editor a go. Listening to your feedback we've seen that many of you have not yet tried the new editor. We spent a lot of time thinking about what most people use wiki markup for - why people love it - and we determined that it was speed. Speed to be able to create content without picking up your mouse. So we've built many features and made design decisions with this in mind.

If you haven't already, please give these editor features a try:

  • Autoformatting of Wiki Markup
  • Autocomplete for Links, Media, and Macros
  • Autoconvert for Pasted Links

If you still feel that you just cannot live without wiki markup, there are many other wikis which have it as their lingua franca. We're happy to provide a list of other wiki solutions, although I assure you none are as feature rich or flexible as Confluence.

We won't stop listening

As I mentioned, we'd love your feedback on the following:

And as per the original purpose of this page, we'd love your feedback on the editor itself and how we can improve it for you. Thank you to everyone who has contributed constructively so far.

We see Confluence changing the way a company works and collaborates. That amazing change is why we come to work every day. Please help us make it a reality for you at your company.

- Mike Cannon-Brookes and Scott Farquhar [Atlassian]

Another page available for further discussion

A new page is available as a place to continue discussions: Confluence 4 further discussion.

Please feel free to add your comments anywhere. We are not shutting down discussion on this page. We are supplying the new page to alleviate the problems caused by slow response on this page, due to the number of comments here.

  • No labels