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

[AM]

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

A-M

[briburt · Accepted solution]

Thank you, Matt.

I don't think we need further clarity on Atlassian's reasoning at this point. We just want a plain text editing option. If this feature is absolutely, unequivocally, no-arguments-to-the-contrary-accepted, gone forever from the product, just say so. The fact that many customers are not only calling for this feature, but actively seeking alternatives to Confluence because it is missing should be troubling to Atlassian at the very least. It is not our job to figure out how it can be done -- that's Atlassian's job -- and the fact that you are using some "XML dialect that looks like XHTML" sounds like a very limiting design decision, insofar as you are now limited in how you can deliver a feature that many customers are requesting.

On the other hand, it's not limiting if Atlassian's stance is that they utterly reject the feature now and in the future. If this is the case, I'd like the company to just come out and say it rather than trying to convince those of us who want the feature about how unreasonable we are being. I don't feel that wanting more granular control via text-only or "source-like" editing is unreasonable at all, and no amount of trumpet blowing from Atlassian in favor of the *wonderful* new WYSIWYG editor will convince me otherwise.

[Matthias Basler]

Not sure if this "question" is just a voting point, but if you need comments:

• As an advanced user I fell much quicker just writing wiki markup that using the mouse in the WYSIWYG editor. (I am aware that I can use wiki wiki syntaxt to insert makros, images etc., but correcting things this way is not possible.) For inexperienced users the WYSIWYG editor is better, althoug currently (4.0.3) it still has some reliability issues, that is, it sometimes doesn't produce the expected result and making the inexperienced user rather frustrated because of the lack of control for correcting it. (For example speaking about white spaces...)
• Example: I copied text directly from within a word document into the WYSIWYG editor. For whatever reason the whole text was inserted underlined, which first went unnoticed because the underlining it wasn't visible in the editor, only in the preview. It took me several minutes in the WYSIWYG editor to manage to get rid of this invisible, unwanted formatting. A typical user would have given up!
• Inserting an image with a caption next to it currently requires three makros: "area" ("Bereich" in German) and two times "column" ("Spalte"). The whole construct takes up a lot of space in the editor for a rather simple output. In wiki markup it would be way more compact. (A single (user) macro would probably be ideal.)

I'm not saying the new editor isn't nice, but having the choice would be definitely better.

Matthias Basler

[Shawn]

I have to say, I hate the new editor. Which is to say, I hate that I have to use it all the time. Being able to type wiki markup into the WYSIWYG editor is nice, but sometimes I want to *view* the markups in the text and currently I can't do it.

Also, when editing a link text you can't edit the link text, and the link editor window hovers over the entire page is is unmovable.

All of this wouldn't matter if I could enter the markup editor and just correct some syntax. I just spent 15 minutes trying to edit one link that would have taken me 5 seconds in the old version.

[Frederic Iterbeke]

For inexperienced users the WYSIWYG editor is better, althoug currently (4.0.3) it still has some reliability issues, that is, it sometimes doesn't produce the expected result and making the inexperienced user rather frustrated because of the lack of control for correcting it. (For example speaking about white spaces...)

Just wanted to support this statement as a new Confluence 4.x user, I spent way too much time on finding the right way to do things I need. Such as: linking to an anchor/heading in a page, inserting horizontal rules and some other round trip issues. These issues aren't nearly as easy to correct (if at all) as in the previous editor.

For example, I tried to do something similar to http://www.atlassian.com/summit/2010/presentations/collaboration-and-projects/building-a-kick-ass-confluence-page.jsp , but using the WYSIWYG editor. I found that inserting a second horizontal rule to finish a section automagically removes the first horizontal rule. Also, anchoring links does not work as stated in the documentation anymore. These kind of issues really impair my ability to work with the new editor.

So I think Atlassian should either make the new editor more correctable and more stable, or provide some way of bringing back or re-including the wiki markup.

[Matt]

@fiterbek – Were you referring to this documentation re: creating anchor links? http://confluence.atlassian.com/x/siAC If so could you let us know what does not work for you? I just tested this and it worked in Confluence 4.1.

You can inserting horizontal rules in the same way you would have in wiki markup - type ---- then press Enter. You can also insert a horizontal rule from the Insert Menu.

I was able to replicate the bug with adding a secomnd rule and have raised it with the development team for you.

[Frederic Iterbeke]

Matt, thanks for your reply, and for passing the horizontal rule issue to the dev team :)

I was referring to the documentation page you mentioned, albeit in Confluence 4.0 (but it has the exact same information). After trying this again just now I did succeed in linking to a heading (not an anchor, I forgot to mention that in my last post). I can't recall doing anything differently yesterday, but I guess I must have made a mistake then.

Thanks for the help!

[Matt]

No worries, @fiterbek. One thing to remember is that when creating your anchor link to a heading, it is case-sensitive. For example, if your heading is 'Introduction', your anchor link must be '#Introduction', not #introduction.

If your heading has multiple words, there should be no spaces in your anchor link. For example if your heading is 'Background Information', your achor link should be #BackgroundInformation

[John Fitzgerald]

Can't believe you've removed this, absurd.

[Matt]

A lot of customers have asked us why we don;t provide a method to edit the raw source of pages in Confluence 4.0. The main reason we don’t to allow end-user editing of the raw markup is that the editor markup is not really XHTML. It is an XML dialect that looks like XHTML so that it can be edited in a browser, but that embeds a lot of important semantic information so we can turn it back into the storage format when you hit save. Please see Why We Removed the Wiki Markup Editor in Confluence 4.0 for further clarity on this decision.

[Dustan Ashley]

As a side note from my issues with the Editor, I wanted to mention that I have just gotten around to installing the "Confluence Source Editor" plugin and I am pretty happy with it.

It's not as simple and obvious as the wiki markup was but it gives me what I really need most. The ability to remove the random formatting problems that occur through importing or editing in a GUI. There's also something wholesome about seeing the actual guts of the thing that I can't really explain...

All I can ask for at this point is that Atlassian commit to supporting the plugin so that I don't have to choose between it and upgrades and I will be satisfied.

Thanks very much for having this open thread on this subject. I was late getting to a 4.x having only upgraded from 3.x two weeks ago, and I'm glad to hear that Atlassian is already moving in the right direction on this.

[Matthias Basler]

I don't want a "raw XHTML" editor either, but in several times I felt the need to have the markup language editor back.

The document which you mentioned states:

Wiki markup as a storage format hindered our ability to add new features, like merge table cells, that customers had been demanding. This is because Wiki Markup is a very limited subset of XHTML and because any new editor feature had to be built twice

Well, I believe I understand this problem, but then 'd say: Extend your Wiki Markup in a way so that it can completely cover all the old and new features and allows full round tripping. Would this really be impossible?

One 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. (Support told me I could exchange raw XHTML using chrome or firebug, but hey ... this is so awkward, only wiki gurus will want to do this.)

If Confluence manages to make the WYSIWYG really stable and idiot-proof (people tend to copy/past all sort of stuff into the editor and expect it to cope with the content) and if there were a simple way of exchanging pages or pieces of content without loosing the formatting then I'd say we don't need a markup editor any more. But we're not there yet.

Matthias Basler

[Oliver Keim]

Absolutely agree! Give us our wiki markup back. I am author of 500 pages with more than 5000 printed pages. The WYSIWYG editor is for novice or intermediate users, for professional users the wiki markup is the only option.

Editing XHTML is a no go!

[Stephan Esposito]

Me too absolutely agrees! At least give people the possibility to use the old markup and pass out the new features if they want.. I definitively want!

[Andreas Gounaris]

My opinion, despite your decision to move away from markup, is that you don't have consistensy over the application any more. Custom templates demand the use of markup while there is no way of building a page and copy its markup. You simply destroyed the template functionality.

You declare you're giving the same opportunities to both developers and end-users but you forget the most important thing: developers drive the awareness, developers create the demand, developers are making your products shine. Nature is not playing with equal opportunities, that's why there is progress. Everything changes.

Here is a tip that I found, a small but highly effective way to edit the source and fix all those problems created with the editor. It is called WebDav. You edit the storage format directly and "voilΰ". Wow, all problems are gone.

Lastly, I want to say clearly that I love your products, robust, innovative and blossom. Keep up the good job.

Thank you

[Sherif Mansour]

Andreas. Sorry about that. We've got Templates on the roadmap ASAP https://jira.atlassian.com/browse/CONF-11744 might want to watch/vote that issue to stay updated.

[Jonathan Simonoff]

I hope you are reconsidering this. If not, you need to come up with some solution. Your editor does the wrong thing at times, and it is AFAIK impossible to fix some problems from within the editor. This isn't surprising to me -- I've never yet seen an HTML editor that produces glitch-free code.

So far (only using the 4.0.4 editor for a few hours at most) most of the frustrating problems have been related to tables -- I've got one situation where there is a series one one-row tables; the first one looks like it should, while the next two look like a row of separate one-cell tables instead of a table row. The appearance in the editor is identical.

Not good at all -- if my users can't get things to look the way they want them to look, they aren't going to be my users for very long. I'm reluctantly considering looking at other wikis.

[Bob Swift OSS (Bob Swift Atlassian Apps)]

While the new editing capabilities are really nice and an important advance for Confluence, for some use cases and integrations with other systems, keeping some sort of wiki alternative would be nice. Atlassian does continue to support compatibility mode (insert wiki markup) that is really important for migrating existing content and retaining wiki markup for legacy macros. Although they have indicated this support may be taken away at some point, hopefully not anytime soon. As long at that capability remains and the use case is restricted to existing (legacy) macros and editing, the wiki macro from the Confluence Wiki Plugin can be used to continue to edit wiki markup and prevent migration of the macros embedded in it. This might help some people especially those with complex wiki markup never intended to be edited with a rich editor. In this mode, you are restricted to legacy macro support and the limitations that imposes.

See also the discussion: http://confluence.atlassian.com/display/DOC/Confluence+4.0+Editor+FAQ?focusedCommentId=282175067#comment-282175067

[Graham Hannington]

This is not an answer, but if you're interested in this question, you might be interested in Wikifier RT (converts Confluence 4.x rich text content to wiki markup), which is one of a few Confluence resources that I have developed. (With apologies to any readers who are sick of seeing links to this. I don't know any better way to announce it.)

[DavidH]

I haven't had time to read all the comments related to editing, markup, and the desire for direct acess to markup in Confluence 4.0. But I will say I ABSOLUTELY WANT ACCESS TO THE MARKUP, and it better be a standard HTML/XHTML or a close flavor, or I will find Confluence increasingly difficult to use, and will eventually find alternatives.

I'm wasting far too much time trying to troubleshoot ridiculous formatting issues, both in the Wiki and in PDF export. I've worked on every type of publishing platform and typographic encoding scheme that has existed in the last 35 years or so, and I've never been so frustrated. I can hand-code everything from Linographic typesetting language to HTML, and while WYSIWYG is better in many ways, it's IMPOSSIBLE without the troubleshooting, customizing ability of having an underlying, low-level, code-based control mechanism.

I vote FIX THIS.

[Matt]

Hey @docpro we just released the first beta of the new Confluence Source Editor Plugin. See here for more details:

http://confluence.atlassian.com/display/DOC/Specification+-+Confluence+Advanced+Editor

[Karie Kelly]

I do concur with many of the comments provided. Having only the one editor is like having a developer use only a visual designer for creating code vs being able to actually type or write the code themselves. Once the developer knows the language, writing the code, or at least editing the code, is often quicker. Therefore, even if wiki markup is not a familiar language like html, people have learned the language and have become adepts and productive using it -- many times it was much easier to correct an issue directly in the markup vs trying to use the options in the current editor.

Example 1: The Note tags were incorrect and highlighting or encompassing all of my content as a Note. I could not remove only the note tag -- it you select remove, it removes the content as well. I had to copy and paste portions out of the note, into the page, and continue until all was out and then remove the note. If you select all of the note's content to copy or cut, when you paste, it pastes the notes tags back in -- so, you duplicate the note which is the issue that I was trying to resolve.

Example 2: Two tables created, each with two columns. I wanted them to actually be one table and needed to remove the white space between the two tables to join them. In wiki markup, I just removed the space and the rows joined together and I no longer had two tables. But, in the current editor, there is no way to remove this space and join. I've had to add the rows and copy/past the content from one row to the other until all were done and then delete the empty table.

Example 3: Because I learned the language, I could type out a formatted page much quicker than what it takes to highlight and use macros or select actions to apply the formatting. Thus, my productivity has reduced significantly and frustration has grown while trying to easily accomplish what I could using the wiki markup.

Yes, people will probably learn over time. But, this one change has affected the productivity, efficiency, and satisfaction level of much of the current user base. I'm just perplexed, trying to understand the value as to why the feature was removed vs choosing to enhance the rich text editor and still providing both. What is the cost to maintain both options? Or, what is the loss with choosing to remove one?

In this case, I'm using this product at a client's site and don't have a choice on whether to use or not. However, in my prior company, I was a decision maker on its use and ugprade and would have chosen to not upgrade due to removing this option. It will also affect my decision, should I have the option, at future companies or projects, in terms of utilizing the product or not.

[Matt]

Hi @kalynn

RE: Example 1 – This is the default behaviour. It is possible to edit the existing macro and change it using the Macro Browser as shown in this quick screencast – http://screencast.com/t/kYsLeew8g

There has been a feature request raised on our public issue tracker for the ability to remove a macro and retain it's contents. You may like to vote for and watch that issue.

RE: Example 2 – Did you know you can do this with Confluence's Cut and Paste Table Row Operations? See this quick screencast for a demo – http://screencast.com/t/dOpn4cincd

Could you please provide a little more detail on Example 3? Perhaps there might be something I can suggest to help.

[Matt]

Thanks for the reply @kalynn. RE: Example 3 – you can still do all of this without picking up your mouse and using the same wiki markup you already know thanks to Autoformatting. I recorded a quick demo to show you this in action with some of the content you provided above – http://screencast.com/t/sajXwtwGzC

[Karie Kelly]

I'll review the feedback provided above regarding the first two tips. However, as with example 2, instead of the one action that I had to do on the wiki markup (remove the blank line space), I have to highlight my rows, select cut, then paste, then delete the second table which is several more actions and alot of pointer movement.

Example 3: Once learning the format, I could just write 'code' for my formatting. For example:

h3. This is my Header

I can type this *while bolding my text* or _underlining_ my text and never have to leave my keyboard or use my pointer to take action or format. I could then type my own tags,

{note:title=My Note Title}

To create my note, again, without invoking a macro or using my pointer for that action.

{note}

As well as easily create my tables without using the insert feature and ensure that they were formatted the way I prefer:

||Priority||Description||
|P1|This is my first feature:\\
* First one\\
* _Second one is optional_|
|P2|This is a next feature set.|

I'm not a developer but am very keyboard-centric; previously, I managed our Confluence installation, developed templates, and encouraged our team to push all content to the wiki and manage it there for a single location of information. I was a heavy user of the wiki there and am here while at my client site -- I use it for documenting all of our product requirements and end user product documentation, with lots of images, macros, and attachments -- formatting and ease of use is important and I create or edit a significant amount of content each day. Therefore, it's been quite noticeable for me, as a heavy user, on how much more time I am having to spend to create and edit content than I was when I could previously utilize the wiki markup directly.

[Matt]

You're most welcome @kalynn :) I'm glad I could help. You might also want to make use of this guide our Tech Writers put together to help with the transition to the new editor: Confluence 4.0 Editor - What's Changed for Wiki Markup Users

[Karie Kelly]

Matt,

Thanks for taking the time for the quick replies and putting together the screencast. That was quite helpful and something that I will definitely use going forward.

Much appreciated!

[Jonathan Simonoff]

Given the design decision (to let the xhtml be such that you don't want to allow source editing), you really need to be VERY proactive and responsive about formatting problems. If people are constantly spending time trying to make pages look like they weren't done by a kindergartener, they will find some other tool, and our wikis will die.

[Matt]

you really need to be VERY proactive and responsive about formatting problems

That's exactly what we are trying to do, Jonathan. We've recently shipped Confluence 4.1 with a number of fixes and improvements and 4.1.2 is not far away with more bug fixes and improvements like Autoformatting of wiki markup support for macros – something many people on this thread have asked for.

We're also actively encouraging customers to give us specific feedback that we are responding to here – Confluence 4.0 Editor - Customer Feedback

[daviderickson]

Matt this is not sufficient, there will always be a time delta between when a problem is reported and Atlassian fixes it (if ever, looking at the patch I've submitted that has never been merged), and in this interim there should be a way to fix whatever issue exists by looking at the raw code of the page. If the syntax is ugly, fine, people will only be heading into this editor when it is absolutely necessary and they know what to expect.

[Mark Hrynczak]

David, have you seen this plugin?

https://plugins.atlassian.com/plugin/details/918877

The plugin is called Invisible Ink, and gives you the ability to edit the Storage Format for a page.

It allows you to configure which groups have access to use it - I'd recommend restricting this as much as possible to save yourselves headaches as admins.

[daviderickson]

Hi Mark- That looks like exactly what we need, but built into Confluence as it was in the 3.X series.

[Jonathan Simonoff]

Matt: I think that is great, but upgrading can be a big hill -- on a production installation, it isn't something you just do casually for small reward. Better would be a way of fixing the editor without an upgrade -- perhaps a plugin that could be released frequently and installed easily and safely.

[Chris Walker]

A couple of things.

Please provide an official schema for your XML variant (like this one: http://www.amnet.net.au/~ghannington/confluence/readme.html)

Also, for complex pages, the editor as it is now can get very cumbersome. This is even true if you edit the XHTML directly. My users have complained that they would be able to create a big, tricky table in not too much wiki markup. Now, the same table is unwieldy and hard to edit.

I don't think they would mind sticking to the new editor, but it should be streamlined.

[Graham Hannington]

I and other users have added many comments related to this question on the following Atlassian Documentation web pages:

http://confluence.atlassian.com/display/DOC/Confluence+Storage+Format

http://confluence.atlassian.com/display/DOC/Confluence+4.0+Editor+-+Customer+Feedback

If you're interested in the markup source of Confluence 4 wiki pages, you might be interested in some of those comments.

In particular, you might be interested in the following:

• Wikifier (uses XSLT to convert Confluence 4 XML to wiki markup)
• The XML schema (DTD/XSDs) that I have developed to describe the Confluence 4 XML vocabulary, and the corresponding schema documentation

For more information, including links to Wikifier and the schema (I think it's useful to read the related comments, which is why I haven't provided direct links here), see those pages.

[Scott Asire]

Wow, is this difficult. All I want to do is update the content of my TOC that was added with a {toc} macro. No idea how to do that in the new editor. I can edit | remove the macro, but change it to add a new link? Completely un-intuitive. If I could just get to the markup I'd be done. But now I have to wade through docs, examples, blogs, forums, ask colleagues, etc. and after an hour I have given up.

Probably really, really simple....if you know the "trick".

Please provide a way to view/edit the markup again.

[Matt]

Hey Scott - are you trying to change the paramters of the TOC macro? I'm unsure from your description about what you are trying to do.

[Scott Asire]

Wow, is this difficult. All I want to do is update the content of my TOC that was added with a {toc} macro. No idea how to do that in the new editor. I can edit | remove the macro, but change it to add a new link? Completely un-intuitive. If I could just get to the markup I'd be done. But now I have to wade through docs, examples, blogs, forums, ask colleagues, etc. and after an hour I have given up.

Probably really, really simple....if you know the "trick".

Please provide a way to view/edit the markup again.

[Dustan Ashley]

4.1.6 and I still hate the editor. I spend so much time attempting to hold it's hand through the simplest of formatting operations that would have taken seconds in the wiki markup editor.

At this point I am seriously considering moving to alternatives as I expect the "unsupported plugin providing essential functionality" aspect of this to cause me untold misery in the future.

I need a simple and fast way to edit the markup vomit produced by the WYSIWYG much more than I need JIRA integration.

Why Atlassian!? We geeks were good to you!

[Matt]

I spend so much time attempting to hold it's hand through the simplest of formatting operations that would have taken seconds in the wiki markup editor

Could you please provide an example of something that's still not working for you in 4.1.6? There's a chance we're aware of the bug and a fix is on the way but it's hard for us to let you know without specifics.

[Dustan Ashley]

Sure. Just off the top of my head, I regularly number my headings manually (again, not fond of unsupported plugins like "Numbered Headings" for forward compatability).

If I type " 1. " (That's "1" "." [space]) the editor, being smarter than I am, converts to a numbered list which uses paragraph style rather than my heading style. If I then click to unselect the "Numbered List" formatting button that it magically selected, my "1. " now vanishes. Repeat until you're so irritated you find this page.

There may be a special editor trick to get around this but I couldn't find it. I know what the trick would have been in 3.x though.... break out the wiki editor, change two or three chracters and go home happy.

[Matt]

Gotcha. You can just press Command/Control + Z (Undo) to get around this.

[Dustan Ashley]

Thanks for that Matt, I had discovered that quirk as well by slamming my face down upon the keyboard, but it's not even remotely intuitive.

Is this intended behavior then, or is it a bug?

I also find it nearly impossible to make formatting changes across a large document. For example I imported a large word document (the import went swimmingly by the way, very impressive) and while it maintained the heading structure, it lost the indentation.

I could not find any way to say "Indent all h1 by 1, all h2 by 2, and so on". In the past I would have loaded the wiki markup in VIM and a quick :%s would get this fixed up in no time. Last night I spent two hours doing nothing but fixing indentations in a single document.

Oh! Which reminds me. There is some really weird stuff going on when changing the indent of a large selection which contains lists (bullets). If you select a block of text which contains a bulleted list and try to indent, it will work for level 1, then start getting a bit funny at level 2 and so on. It seems that none of the indent changes after level 2 will be applied to the area below the bulleted list, regardless of what was selected. Again, no problem with wiki markup EVER.

Maybe it's just us neurotic folks that don't like the editor, but it really makes things painful for me.

[Dustan Ashley]

As a side note from my issues with the Editor, I wanted to mention that I have just gotten around to installing the "Confluence Source Editor" plugin and I am pretty happy with it.

It's not as simple and obvious as the wiki markup was but it gives me what I really need most. The ability to remove the random formatting problems that occur through importing or editing in a GUI. There's also something wholesome about seeing the actual guts of the thing that I can't really explain...

All I can ask for at this point is that Atlassian commit to supporting the plugin so that I don't have to choose between it and upgrades and I will be satisfied.

Thanks very much for having this open thread on this subject. I was late getting to a 4.x having only upgraded from 3.x two weeks ago, and I'm glad to hear that Atlassian is already moving in the right direction on this.

[Matt]

Is this intended behavior then, or is it a bug?

Yes, it's Autoformatting in action – http://www.atlassian.com/software/confluence/whats-new/?tab=confluence-40

I could not find any way to say "Indent all h1 by 1, all h2 by 2, and so on

Sounds like this is solved by the Source Editor plugin.

There is some really weird stuff going on when changing the indent of a large selection which contains lists (bullets). If you select a block of text which contains a bulleted list and try to indent, it will work for level 1, then start getting a bit funny at level 2 and so on. It seems that none of the indent changes after level 2 will be applied to the area below the bulleted list, regardless of what was selected. Again, no problem with wiki markup EVER.

Thanks for this. I'll check with our QA team to see if this is a known issue.

[John Masson]

Hi Mate,

All I can ask for at this point is that Atlassian commit to supporting the plugin so that I don't have to choose between it and upgrades and I will be satisfied.

We'll definitely be maintaining the source editor so you won't need to make that choice.

Thanks,
John

[Mark Hrynczak]

There is some really weird stuff going on when changing the indent of a large selection which contains lists (bullets). If you select a block of text which contains a bulleted list and try to indent, it will work for level 1, then start getting a bit funny at level 2 and so on. It seems that none of the indent changes after level 2 will be applied to the area below the bulleted list, regardless of what was selected. Again, no problem with wiki markup EVER.

I've raised a bug report for this - see https://jira.atlassian.com/browse/CONF-24943

[AM]

Sometimes it helps to raise your voice in a constructive way ... and be patient ...

Message from the founders of Atlassian:
"We're building a source editor!"
http://confluence.atlassian.com/display/DOC/Confluence+4.0+Editor+-+Customer+Feedback

Contribute here here to help to get the best of both worlds.

[John Masson]

Hi All,

You might like to like to read the update on our Editor Feedback page from the founders on what is happening on this, including the creation of a new, Advanced Editor for accessing source.

John

[Sven]

Don't forget to vote here, the template-question is NOT solved with this new 3rd party plugin:

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

[Matthias Basler]

Having now worked several weeks with confluence 4.0.5 and 4.1 on mostly Firefox 8.x and 9.0.1 respectively I can only say that I can not recommend the combination of Confluence 4 and the latest Firefox browser. It feels like beta status, not more. Within the last days and weeks I had to file a dozen of bug reports, mostly concerned with copy/paste, working with tables other odd behaviours of the new editors. Too ofthe the only "solution" of correcting the problem is to do an undo and entering the text manually.

(Using IE8 is slightly better, IE9 is not working at all for us and is not officially supported yet. I have no idea what those editors will do that have Win7 and therefore use IE9 by default, because it was installed by the admin.)

Better have a stable plain text (markup) editor than a feature-rich WYSIWYG edito that drives the editors mad!!!

I am *really* considering downgrading to Confluence 3.5 before our wiki goes live so that the editors can have hassle-free content editing sessions, even if they have to learn wiki markup. Or maybe we should stick with MS Office and send documents back and forth ... I'm stuck between a rock and a hard place.

[Frederic Iterbeke]

For inexperienced users the WYSIWYG editor is better, althoug currently (4.0.3) it still has some reliability issues, that is, it sometimes doesn't produce the expected result and making the inexperienced user rather frustrated because of the lack of control for correcting it. (For example speaking about white spaces...)

Just wanted to support this statement as a new Confluence 4.x user, I spent way too much time on finding the right way to do things I need. Such as: linking to an anchor/heading in a page, inserting horizontal rules and some other round trip issues. These issues aren't nearly as easy to correct (if at all) as in the previous editor.

For example, I tried to do something similar to http://www.atlassian.com/summit/2010/presentations/collaboration-and-projects/building-a-kick-ass-confluence-page.jsp , but using the WYSIWYG editor. I found that inserting a second horizontal rule to finish a section automagically removes the first horizontal rule. Also, anchoring links does not work as stated in the documentation anymore. These kind of issues really impair my ability to work with the new editor.

So I think Atlassian should either make the new editor more correctable and more stable, or provide some way of bringing back or re-including the wiki markup.