Confluence 4 Editor FAQ

The content of this wiki page is a perfect example of where wiki markup is all that is needed to produce a very useful page of reasonable length. Wiki markup would suffice even for pages several times longer than this page. I would be curious to know how many pages on this website are less than five times the length of this page, and do not use any complicated formatting or complex layouts? Probably the vast majority.

Another consideration is that wiki markup is possibly more accessible for the impaired than rich text editing.

Wikimarkup saves users who are not graphic artists or publishing experts from being confused by a multitude of formatting choices. Consistency between wiki spaces is improved, and generally no one encounters wiki pages they need to edit where they say "Wow, how did they do that formatting?"  Even Microsoft Word can make some formatting issues a chore. Ever have an outline in Outlook or Word messed up by merging outline elements?  It can take a while to fix.   When editing wiki markup, it is difficult to encounter such a situation that makes an unexpected change.

There is no doubt that Confluence rich text experience has been very close to failure for years. Confluence 3.x improves the ability to cut and paste rich formatted text into the rich text editor, but it still makes a lot of mistakes, and these mistakes (such as malformed urls) is frustrating to fix in the rich text editing. For an example, try cutting and pasting a google results page into the current rich text editior. It is nearly impossible to fix.  Fixing such a page is much better done by returning to wiki markup, and then taking the wiki markup and putting in a real text editor (even notepad), using search and replace the repair the text, and then pasting back into Confluence wiki markup when finished.

Since wikimarkup is plain ASCII, it is very transportable. It has the vast advantage of being perfectly lossless when cut and paste-ed between any versions of Confluence. It is much more readable than HTML.

Because of how frustrating the round tripping from richtext to wiki and back to rich text is, we advise our thousands of users to graduate from depending on the rich text editor as soon as possible. And everyone who puts just a little effort into wiki markup is able to master the new skill, and they don't seem to miss the rich text. This is not just programmers, but even fairly non-technical users in departments such as finance, or customer service. We find very few users get to a point of complexity in their wiki pages where they report feeling overwhelmed by wiki markup. And in the cases where they do, it is almost always related to table formatting, which is not a very capable feature in Confluence so far.  For larger tables, it probably makes sense to put the table in a spreadsheet, and use excel macro for embedding. If that macro's rendering capability was further improved to understand cell formatting, it would answer most of the complexity complaints we have encountered.

Other complicated layouts, or content structures, can involve the use of includes. It is hard to imagine how rich text editing would not end up making layouts depending on includes more complicated.

One wonders at the additional complexity that might be required of writers of macros and plugins.  Some plugins, such as those that dynamically pull in data, may be difficult to display in wysiwyg, and probably won't display live data. They are likely to still require saving the page to see the actual result.

Forcing all simpler wiki pages into the complexity of rich text editing, and loss of wiki markup, this is probably not a "good thing".

What about the mobile browser editing experience? Confluence used to work very well with the less powerful browsers found in phones, but the recent versions of Confluence don't work so well. Confluence pages have become very dependent on javascrapt, and things like pull down menus are unavailable from mobile browsers, severely limiting usability. One of the premise of wiki used to be ability to edit from any browser without needing any special software, hence the simplified wiki markup language. For the majority of wiki pages which are not long and complex, wikimarkup is sufficient and efficient.

Are there any details on the API changes? We use the XML-RPC interface extensively in our organization for various product document builds (shippable doc), status update pages, etc. - this is extremely important to us.

Thanks,

-Greg

For those of you not following the Confluence Forum I would recommended reading this entire thread – Why is the wiki markup editor being removed in Confluence 4?

Will the Office Connector still exist?  I.e., will there be some way to edit a wiki 4.x page in Word?

One thought, have you guys considered implementing a Paste from Word or Paste as Plain Text feature?  I often will switch to the wiki text editor in order to paste text, because I know if I paste from Word or copied text from a website, it gets all garbled, and often I have to at least switch between the wiki text editor and the rich text just to get it to "reset" the display.

MindTouch, a growing competitor of yours using CKEditor and on their toolbar they have a button for each of those two scenarios (paste from word/plain text).  When I was on MindTouch I used those features all the time as a power user.

I voted on this issue as it seemed to be the closest to what I'm talking about, but its not quite the same: http://jira.atlassian.com/browse/CONF-4337?focusedCommentId=232733#comment-232733

Here is some more info:

What about the idea of adding a button on the editor to allow for "Paste as Word".  MindTouch does this, check it out here: http://developer.mindtouch.com/en/docs/MindTouch/User_Manual/Olympic_Documentation/CKEditor http://developer.mindtouch.com/en/kb/Improve_pasting_from_Microsoft_Word

Of course they use CKEditor and not TinyMCE, so the architecture would be different, but I cant believe its too hard.

Regarding the "Edit in word" functionality, it isn't used in our wiki. People are urged to make the transition from word docs to wiki pages, so if the new editor is more user friendly, all the better.

Really hope you improved the layout capabilities of the editor, it's not that simple to teach non-techies the usage of section and columns macro (especially when your customers don't speak english). So a RichText experience for easy layout of a page would be ace.

It's still not clear how this applies to the editor.

Accessing information is not the same as manipulating information. Editing is manipulating.

Any word on changes to the template editing?

I do a lot of templated work on our intranet and the fact that there's no template history already comes back to bite me sometimes but the plain-text w/ no proper preview is also somewhat painful at times. It makes the trip from minor edit to preview to the template list to go find it for editing to edit screen an all too common occurence.

I'd love to see the template editor folded into the regular editor so we can get the same experience all around.

What will happen to the WebDAV access? Will it continue to work with wiki markup?

According to End of Support Announcements for Confluence Confluence 4.0 will be released "in the middle of 2011". Yet in this FAQ I still see answers to questions worded without specific answers.  A couple of examples:

• Will you be able to edit the source XHTML code directly? We don't know the answer to this question yet.
• What does the new editor look like? The new editor is still evolving and changing.

I understand that when this FAQ was originally written you could not be specific about these issues – design decisions and their implications take time to think through. But now you're less than a month away from the middle of 2011.

Would someone from Atlassian please go over this FAQ and include more specific answers? I can only guess that design decisions about Confluence 4.0's editor are well past decided by now.

Thanks.

Will the new editor and/or Confluence 4.0 in general provide any progress in the pasting of images from clipboard as per https://jira.atlassian.com/browse/CONF-5587

It seems to continue to be a key feature that my internal clients and other customers want.

Milestone Release Notes indicate that this will be possible .

http://confluence.atlassian.com/display/DOC/Confluence+4.0-m29+EAP+Release+Notes

Does anybody know if there is a Sandbox to Test Confluence 4? Am not able to install M29 due to a ORA-01408 "such column list already indexed" error.

uf!

Your new RTE must be extremly good if you are going to take out the "Edit in Word" functionality. It's really easy right now to use it for non-tech guys, they love it, and I don't thing they will love your new RTE ....   

We use CLI to add/update Confluence pages. Will this still work with Confluence 4?

BR Stefan Lohrum

Are you planning on allowing plugin developers to hook into the image editor? I have spoken with Spartez, who develop the highly useful ScreenSnipe plugin... But highly useful only if the editing experience can be streamlined enough. Currently there are too many steps involved to make use of the plugin. This could be rectified with Confluence 4 though!

If I understand correctly, ScreenSnipe uses a png file for the image and an xml file for the annotations. Either file can be updated separately, but the result is rendered by displaying the image on the wiki page with annotations overlaid on top. Editing is currently done by clicking a placeholder icon hovering on top of each image. Editing is only possible outside the editor. Also, only images added by the ScreenSnipe plugin can be annotated - other images cannot.

One of two things is needed:

1. Either (preferably): allow plugins to open and edit image attachments from within the editor, so annotations (xml data) can be linked to images directly.
2. Or: allow plugins to open and edit image attachments outside of the editor, so annotations (xml data) can be linked to images in the first place.

This would allow copy & pasting screenshots into the editor quickly and later annotating images separately, keeping the content creation workflow streamlined.

Is #1 possible to implement in the near future? Is #2 possible already?

I have just downloaded/installed 4.0 Beta2.  In the short time I've played with it, the new editor shows great promise!  I have also managed to export/import a Space from our 3.0 production installation.  Attachments seem to have come over fine, but all direct page content appears as straight/simple text (e.g., macros/formatting are not recognized).  I'm guessing that this is what is expected.  Which brings me to my question/request: can you give us an update on what/how the above mentioned converison from markup to the new XHTML will be performed?  How much of markup on our 2000+ pages will be automatically converted?  How much hand work will we need to do?  Will the conversion happen "in place" (i.e., when our 3.0 is upgraded to 4.0)?  Will a test installation need to be involved?

Any further detail would be appreciated.

Thanks,

Al Mecklenburg

Will it be possible to use the new editor on iOS devices (iPad)?

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.

Wait What?... How does making it "Write only" not break the APIs existing contract?...

(How the hell do you quote in this new editor anyway? {quote} clearly doesn't work anymore...)

My orginization just began moving to confluence becuase of the many nice features it placed on top of a very simple wiki markup editor. We are now considering abandoning confluence because of the removal of the wiki markup editor. Confluence provides the superior features we need in a wiki but the wiki markup editor was one of the key features that any solution we moved to was required to have so that documents could be autogenerated from our software projects.

In our company Wiki is almost always used by developers. Within minutes it was possible for everyone to write their own pages. Learning curve is trivial.

For me personally, I loved it that when I copy something from Word or a Web Page e.g. the ridicoulous formatting was not copied. I was able to Copy Wiki Markup in my favorite Texteditor, use macros to change/modify reoccuring things. Just copy part of a table an use it for another table? There are so many use cases where a markup languaes wins so easily. Many of my command line programs were able to generate Wiki markup tables. Our company has many tools which created Wiki Pages automatically, so I'm not the only one. For every developer who understands somewhat Wiki markup it was trivial to write an application that outputs Wiki markup. Now all this advantages are gone, my whole workflow which was amazingly efficient compared when I write something with Word or so called What-You-See-Is-Sometimes-What-You-Get tools. This new editor is just a shame, new lines at the wrong places, spaces at the wrong places, ...

Thank you, everyone for your comments and feedback on the new editor in Confluence 4.0. We do value all your feedback but this page is intended to be an FAQ where existing customers can learn more about the editor changes introduced in 4.0. As such we've removed the comments that don't contribute directly to the goals of this page. If you have specific questions that aren't covered in FAQ please do comment here and we'll update the FAQ according. Otherwise, please see this page for how to most efficiently give feedback or request additional features.

Giving Feedback on Confluence Releases

I'm preparing my users for Confluence 4.0, and the page Matt mentions above has lots of great videos.  Unfortunately, they are all on YouTube, a site that is blocked inside our firewall.  There are many other videos on Atlassian TV, and we were able to view these with no issue.  Is there any chance of getting the 4.0 videos in this format?  

Thanks-

Jason

Help - Where is the wiki markup editor!

1. No Copy & paste between Confluence and JIRA
2. No search and replace!
3. No chance moving Gliffy diagrams
4. No quick & dirty page creation, based on another page
5. Goodbye {section} / {column} tag
6. ...

The "Confluence Wiki Markup Styler" plug-in https://plugins.atlassian.com/plugin/details/606145):

• does not display all markup codes
• does not allow copy and paste to another editor
• does not allow edit of wiki markup

I'm extremely disappointed that the markup editing has been removed.

In particular we use this to:

• quickly grab chunks of text to put into a rich text editor for regular expression editing or custom manipulation.
• reliably move chunks of formatted text around within a page or between pages
• an experienced user can work with the markup much faster than any click-based substitute.

Disappointing.

1. I'm struggling to adapt working without the markup possibility. Really do miss the spectrum of control via markup editing (at least for checking back in the case of layout probs).
2. @Matt: I did not manage to apply one of your answers

 What do you mean by this? "You can still copy content between pages – Tools > View Source"

How is this performed after seeing the source???  

My Situations is:

• • I have 2 pages (including macros like codeblocks) that i want to merge into a new one
  • i copy from one of the old pages into the new one 
  • all the text is copied ok with the right layouts/bold/headlines etc.
  • BUT: all the codeblocks are corrupt ??? not a codeblock anymore

Thanks for your help

&

I really hope that you guys might bring back a possibility to edit already existing content in markup.

That would be highly appreciated. The getting acquainted process is quite time consuming at the moment.

Regards

Chris

I represent 10+ organizations using confluence in bizdev, development, art, support etc processes. All of them will miss wiki markup a lot, all educated to use that.

However, one workflow that I miss even more is the templates after creating a page. We are using this kind of workflow with older wikis:

1. Generate "table of contents" kind of lists of links to non-existing pages
2. These act like checklists, responsible personnel will click on the link to create a new page
3. After clicking the link new page opens with correct title. We use "select template" feature to choose template
4. Then fill in the blanks and your done.

However, now the template must be selected "add using template" instead of "add new page" and then "select template". Anyone else missing this workflow creating pages using links and selecting template afterwards?

I've been a heavy user for 6 years and this is the fist major update since then that Atlassian really seemed to make a mistake. Sure, might be that under the hood things are better now. However many end users feel betrayed.

Confluence Customer and Community,

You're on the spot - your voice counts. Ideas and comments are more than welcome.

Confluence feature request:
occupy confluence markup: provide a WYSIWYG XHTML-Markup editor to edit the markup source of Confluence 4 wiki pages

https://jira.atlassian.com/browse/CONF-23914

-AM-

I am incredibly disappointed that there is no source editing. Event this "new "4.0" WYSIWYG completely redesigned to be the best of both worlds" makes it incredibly difficult to go in and make a quick change that would have taken me 30 seconds in source view, and here I am 15 minutes later posting a complaint.

To give a specific case, I have a page that has a header, some plain text, a source code block, next header. I wanted to copy the plain text and source code block, and duplicate it, to give another block of plain text, and another source code example. To help visualize.

[Header]
[description text]
[source code block]
[Header]

The problem is, that if I hit "return" after the source code block, the entire page screws up, my cursor jumps up to the top of the editor, and pushes the main page header down a line, so there's no longer a main header, and the main header is now in plain text.

If I try to select the plain text description text and source code block, then copy, paste, paste (to create a duplicate) the second paste ends up inside of the source code block macro.

I'm a programmer, I have a wiki as an instruction manual. I work with incredibly complex xhtml markup and even php code to generate this markup, I don't care if there's a potential to screw up my content, I want the ability to edit the source code directly.

Another vote to bringing some kind of wiki editor back. If there's a wiki markup macro surely building a wiki markup editor can be done that still conforms with the new XHTML scheme.

I spent a lot of time touting confluence's superiority to many folks and spent a lot of time trying to get people to use it over sharepoint which reigned supreme here previously. A day doesn't go by now that people in my department don't complain to me about the editor and wish they had stuck with sharepoint. These are technical and non-technical resources alike.

How can be a new page created converted into an space template? The template (browse>Advance>Template) doesn't have the editor and the page doesn't have the wiki markup, so. How can I copy an approved page to be used as template?

Wow. I actually really hate this new editor. I've been a longtime confluence supporter and was pushing confluence evaluation to my new shop but I'm going to hold off. It's currently not a product I'd even use. Without the speed and simplicity of wiki edit mode, how is this even a wiki?

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

How about for users that never touched the WYSIWYG interface? This is like trying to combine vim and msword / openoffice. Two completely different use case scenarios and completely different target audiences.

I'm extremely disappointed that my favorite wiki is now something I have absolutely no interest in using. Please please bring back wiki edit mode. I know there's a lot of work that went into this editor but honestly it feels like using forum editors like tinyMCE.

Guess I will check back in the 5 release to see if the wiki edit mode is back, so much for moving off mediawiki here 

Which smart guy decided that atlassian editor is as good as Word? You should have instead used the time to add more support to display inline comments. Imagine the plight of the reviewer who has to comment on a large document.

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

The answer to that question is really "yes". The text after it doesn't change that.

Ah, removing "edit in word" = total fail.  Here is our usage example ...

We have internal support team members who email us screenshots of errors and steps-to-resolve.  We then upload these stories and cases to our wiki and were able to previously use the "edit in word" to quickly upload the images.  Using the reverse of "import word document" meant an extra step of taking the entire article from the email, saving it, formatting it to our wiki page format and then importing it.  

Without the "edit in word", we've lost a major benefit of Confluence in terms of making our work flow efficient.  

Bring it back.  

DB

For what it's worth, coming from MediaWiki, I would have an extremely hard time recommending Confluence for any project I'd have to be involved on overwhelmingly because of the removal of a low-level feature as critical as source editing. It demonstrates a profound lack of care that exceeds that of Microsoft's decision to force everyone to use The Ribbon.  After all, at least The Ribbon retained every single feature previously available in the Office suites.  This, on the other hand, doesn't retain the same features. It's functionally a downgrade.

The Right Way(tm) should have been obvious and implemented, despite the greater workload:  you co-mingle for a major revision and allow translation bidirectionally–even if everything's going to be natively stored in XHTML. Yes, this means people must still be able to edit the source, because that's what they've expected of your product for 3 major revision cycles.

On a related note, let's be honest: nobody actually asked for the complete and total removal of source code editing functionality, because there's no reason for anyone to ask for it. Nobody hates their coworkers that much, and nobody has logical motive to completely disable source code editing without at least giving the option for advanced users to re-enable it. Furthermore, you guys should know better than to use marketing-speak to make it seem like you were doing it in response to demand. You weren't. It was easier and quicker this way. You – a moment of pause to prove a point: your WYSIWYG editor is, as I'm typing this, broken. I had emphasized (with asterisks) text, and it rewrote it as bold. I tried to backspace into normal text, and it still popped right back into bold after a couple of letters.

It's things like this that necessitate the ability for a user to temporarily work around it by using a source code editor. Imagine if I actually had to meet a deadline how quickly I'd start to despise your product.

FINALLY, I got it to disable the bold by having to double-hit CTRL-B without typing anything. It would have only taken 2 seconds to fix the source code, I might add. Thankfully, it was something simple. It still looks weird in the WYSIWYG, because it seems to be leaving bold-artifacts on the edges of bolded words, but I guess someone like me is out of luck until you (hopefully? maybe? surely?) release the patch that fixes this and the various other bugs at some unknown time in the future. Guess there's no workaround in the meantime, because you summarily decided to remove that ability.

...but your one saving grace is that you seem to have learned from this mistake, and the Confluence Source Editor is an excellent step forward.

Regarding the following text in the body of this page:

What format will Confluence use to store its page content? ... XHTML. ... the content will be stored as XHTML. Basically, XHTML is like HTML but complies with stricter formatting rules.

I realize that I am probably beating the same dead horse that I have bludgeoned on other pages of your website , but you (Atlassian) do know that XHTML is a W3C trademark, right?

The terms and conditions on the W3C website state:

W3C trademarks must be used only to describe or reference W3C specifications ... or describe non-W3C products that implement the required features and operations of W3C Products. Required features and operations are defined within specifications

I bring this to your attention because I know, and you know, that, although you might be forgiven (by, for example, the W3C) for saying that your storage format is based on XHTML, your storage format is not XHTML, because (any one of these reasons is enough):

• Your storage format includes your own proprietary markup.
• Your storage format does not support the full set of XHTML markup (I'm happy to discuss and clarify what I mean by "support" in this context).
• Although your storage format includes elements and attributes whose names match elements and attributes in XHTML, those elements and attributes in your storage format do not follow all of the same rules as those elements and attributes in XHTML (such as the contexts in which those elements can be used).

But perhaps you're still okay with your use of this term. I'm no lawyer.

While I'm at it: not your problem, but I've seen the term "Confluence XHTML" used on another website to refer to your storage format. Those W3C terms and conditions again:

No right to create modifications or derivatives of W3C Trademarks is granted pursuant to this license.

So, you might want to avoid adopting that particular coinage.

Feel free to ignore all of this. I'm just clearing my conscience by mentioning it.

Since Jira doesn't support the new editor, how do I cut & paste between Confluence & Jira?

Our workflow is to do software design and planning using Confluence, since that is a great place to draft things. We don't want to file issues that track our efforts until the plan is complete.  Yet we want the issues in Jira to have enough description in them to test against without having to link back and forth between the issue and (really obnoxiously hard to get right) anchors in the Confluence page we create.

But when I now want to take various bulleted lists of items from confluence, and cut and paste them into Jira to describe the work that needs to be done for a specific issue, there's no option except to reformat them using the native markup editor there.

This is the worst of both worlds: not only do I have to cope with the odd behaviors of bullet-lists in the new editor (adequately pointed out above, but it does make me curse every time I use it), but then I have to re-translate them back to what I wanted in the first place!

yes bulleted lists make a lot of trouble ... for instance you get a big space if you integrate notes (makro note) after a bullet...is there any way to optimize that

I just upgraded my organization from Confluence 3 to Confluence 4 and I have to voice my opinion regarding being force fed the confluence editor and having the Wiki Markup editor go away.

I find this to be highly unacceptable.  My biggest complaint about Microsoft every time they release a new security update, upgrade windows or office, etc. is that they remove or change functionality in their products and force feed this to their users.  Oracle does this as well.  Atlassian is acting the same way here.  We know what's best for you and we're going to force you to do things our way.  Reading through the hundreds of posts here it's quite obvious that there's a significant userbase, myself and my users included, that are extremely unhappy about Atlassian's decision to remove the wiki markup editor and their unwillingness to re-add that functionality back into confluence.  My users are having a tough time adjusting to this change.  Things that were previously very simple going into wiki markup require much more effort to perform in the RTF editor.

Two quick examples.

I'm creating a new page right now.  I want t copy and paste a bunch of values into a SINGLE-SPACED LIST.  Every time I do that, it pasts the text as double space so I have to type everything in manually hitting shift-enter. 

Second is during the conversion I have some tables that were not properly converted.  They were previously in macros.  I cannot figure out how to re-add them without deleting the table and re-adding.  If I had wiki-markup I could simply re-insert the {macro} statement and be done with it.

This is making our lives very much more inefficient.  The fact that you're unwilling to put this functionality back leads me to believe that you don't truly care about the wishes of your users, ie the people paying you for the privilege of using your product.  Is this really a smart business move?

Hi,

Now, i will try not to get to negative, cause for years Confluence has performed flawlessly and with ease!
Solved many a documentation problem in my company (10.000+ employees) and for our customers.

Here it goes: I regret to inform you, that introducing the new editor, which in my professional opinion is a disaster of epic proportions, now means that Confluence licenses wil NOT be renewed.
Our running Confluence instances will be converted to other Wiki's.. 

Reason: Edit in Word is a MUST HAVE, wiki markup is a MUST HAVE. Fine that you descide to create an editor on your own.. it's not to my or any of our customers linking, not even close.

Just a friendly advice: if you ever descide to change the main edit possibilities of Confluence again: let the users have the possibility to keep the old editor(s)!

Thank you for the years when confluence was a useful tool.. I will head over to my other lsptop and backup my companies two Confluence's, move them to Virtual machines, and convert them to MediaWiki and other formats that are useful. And then delete the Confluence production instances. 

Also, at the meeting I'm attending today with one of our largest customers (large governmental agency), I will not be recommending Confluence, allthough it would have been perfect. But the new forced editor is useless for them. We need speed, and ease of editing, without thinking about formatting and stuff like that. "Edit in Word" took care of that. And the wiki markup editor made it easy for specialists as my self to fine tune the content if needed. yes you can put in wiki markup, but you can't edit it in wiki markup. That decision is comprehensible to me. 

Sincerely
A very unhappy customer 

PS: post here if you descide to make Edit in Word and the Wiki markup available again.
We will then seriously consider buying new licences, and start recommending Confluence again.

Some half-baked (untested; at least, by me) ideas for Confluence 4 users who miss the wiki markup editor (some of these ideas are more practical than others, I'll admit, but there might be something useful here to someone)...

All of these ideas rely on plugins by Bob Swift: the wiki plugin, the SQL plugin, or both.

Replace migrated V4 XML with the original V3 wiki markup, wrapped in a {wiki} macro

Suppose you have an export file created from your Confluence 3.x installation, and an export file created from your V4 installation.

Develop an XSLT stylesheet that replaces the XML-ified (Confluence 4 format) page body content with the wiki markup from your V3 export file, wrapped in the following:

<ac:macro ac:name="unmigrated-inline-wiki-markup">
  <ac:parameter ac:name="atlassian-macro-output-type">BLOCK</ac:parameter>
  <ac:plain-text-body><![CDATA[{wiki}

Your wiki markup here

{wiki}]]></ac:plain-text-body>
</ac:macro>

(Note that, when you insert the code above into the <property name="body"> element in the export file, you'll need to avoid nesting the CDATA section.)

Or do the equivalent in SQL, directly between your V3 and V4 databases, without using export files.

You could apply this technique selectively: for example, only apply it to spaces used by developers who prefer editing wiki markup to using the rich text editor.

Yes, I realize that this results in a "schismatic wiki"; at least, from the editing perspective (viewing and navigation would still be seamless).

Access your original V3 wiki markup via a {sql-query} macro

Only slightly less mad (I might actually try this one sometime!)...

Resurrect your old Confluence 3 database as a JDBC data source for the SQL plugin. Write a SQL query (perhaps, wrapped in a user macro, or even a plugin) that returns the wiki markup of the "current" page (if it exists) from the old Confluence 3 database. You can then decide whether or not to ditch the V4 XML in favour of the original wiki markup (that you copy from the SQL query results, wrapped in a {wiki} macro).

For extra points, you could use "last modified" dates to avoid (or at least be aware of) losing edits made in Confluence 4.

Page administrator: feel free to delete this comment as the ravings of a lunatic.

It's just occurred to me that some Confluence 4 users might be editing tables in the rich text editor as sets of nested macro placeholders representing migrated {table} et al Confluence 3 macros.

If you are doing that, then you might be interested in my recent comment (offer) on the Migration page:

Does anyone want an XSLT stylesheet to convert macros (inherited from Confluence 3) into equivalent native Confluence XML?

I need wiki markup and this was a blunder our your part. That simple. I'll coerce my company to move off of your techonology. Missed the boat on this one.

A copy of a comment on the "Confluence 4 Editor - Customer Feedback" page (from July 9), for any users who watch this page but not that one (with cringing apologies to those who watch both):

Wikifier RT is a new web page that converts Confluence 4 rich text editor content to wiki markup.

To convert Confluence rich text editor content to wiki markup:

1. Copy content from the Confluence rich text editor to the clipboard.
2. Go to the Wikifier RT web page.
3. Paste (press Ctrl+V) the content under the Rich text heading. The corresponding wiki markup appears under the Wiki markup heading.

For more information, click the Help link on the Wikifier RT web page.

Shoot me for crossposting and boorish (self-)promotion of a spare-time project. I don't have any better ideas for announcing this (and I've asked).

If you would you like to display tag names (and some attribute values) while using the Confluence rich text editor, then you might be interested in the "Confluence rich text editor - show tags" user style that I've just added to my small collection of Confluence resources.

Requires the Stylish for Firefox add-on or Stylish for Chrome extension.

This user style currently covers a decent swathe of rich text editor markup, but as the process of adding new combinations of elements and attributes is tedious, I'll wait for specific requests to extend it. (Sorry, I do not know how to use this technique to display br or img elements; or to distinguish non-breaking space entity references from plain spaces.)

Atlassian, feel free to jump in and say that this is a really bad idea. It works for me, so far.

(Tested with Firefox 13.0.1 and Stylish 1.2.6 on Windows 7 with Confluence 4.2 and 4.3-m12.)

I'd welcome specific suggestions for a regexp to make this user style site-specific (that is, specific to pages that are using the Confluence rich text editor). Perhaps a regexp that matches URLs containing either "editpage.action?" (for editing pages) or "editComment=true" (for editing comments)?

Do you want to find out which pages on your Confluence site use a particular macro, or XML element, or combination of content and markup?

For example, do you want to search all of the pages on your Confluence site for the following XML source?

ac:name="panel"

If so, then you might be interested in the "Searching Confluence storage format XML for content or markup" page in the Advanced Confluence Tips space of the Confluence, Tech Comm, Chocolate wiki. That page presents a Run macro with a nested SQL query that searches your Confluence database.

Acknowledgment: Back in February 2010, Betsy Walker published an "Identify pages using particular string in content body" SQL query that did much the same thing.

I used to love working with Confluence. My documentation was elegant, well formed, aesthetically pleasing and I enjoyed writing it.

No more. Creating documentation in Confluence now is an exercise in utter frustration. The "best-of-both-worlds" editor is horrible, does a half-baked job at half the functionality and just drops the rest. I would not recommend Confluence for a collaboration platform for any customer at this point.

So long, and thanks for all the fish.

Hi

I want to share a page with a group, but the confluence only support share with one or more person. How can I share it with a group?

I want to  insert an interactive Microsoft Powerpoint presentation into the page with confluence 4.3, but the Microsoft Powerpoint can't presentation normally. What can I do?

This was very very sad to see. How can you call confluence a wiki without letting us use wiki markup. I'll be using it, but only because I'm forced. Please bring back a little button that lets us write in wiki markup.

TOC links are not working on this page. I am also having this problem when I have a heading that includes a question mark.