Documentation for Confluence 5.5.
Documentation for Confluence Cloud and earlier versions of Confluence is available too.

Skip to end of metadata
Go to start of metadata

FAQs

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

QuestionAnswer
Is there a 'Confluence 4 for Wiki Markup users' guide available?Yes, please see Confluence 4 Editor - What's Changed for Wiki Markup Users. If you have anything you'd like to see added to that page, please leave a comment there.
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.
Is there a way to search across the instance for where a macro is used in a page?You can do this with the use of the Confluence Macro Indexer plugin. Details on it's use are available 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. 
    • A Greasemonkey script for The Wiki markup toolbar button which selects the page contents and opens it in the Insert Wiki Markup Dialog for editing.


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.

Resolved

 Click here to expand...

Loading
T Key Summary Resolution
Bug CONF-33922 Editor cursor does not appear in Firefox 30 Fixed
Bug CONF-29048 Confluence fails to non-conflicting merge changes while editing page concurrently Fixed
Bug CONF-31163 Cursor doesn't appear in editor in Chrome 30 Fixed
Bug CONF-29537 Quick comment error messages are awful, scary and leak styling Fixed
Bug CONF-29942 Copy/Paste of Images does not work in IE11 Fixed
Bug CONF-31524 Embedding an attachment via the ! shortcut causes a storage format error Fixed
Bug CONF-31609 IE11 - Can not put a period dot after the last sentence Fixed
Bug CONF-22287 When Inserting Link Insert Button Not Clickable When Using Mouse Right-Click to Paste Fixed
Bug CONF-33978 Confluence Editor - Insert image dialog calles non-existing messenger function Fixed
Bug CONF-23575 Links to filesystem are lost after upgrade to Confluence 4.x or upon saving the page in the new editor Fixed
New Feature CONF-6482 Custom background colour for rows or cells in table Fixed
Bug CONF-24581 Inline macros with body default to block mode Fixed
Bug CONF-27226 Copy-paste data-uri based images works in edit mode, fails on save Fixed
Bug CONF-29799 Paste images into the editor from clipboard using Firefox 22.x and above does not work Fixed
Improvement CONF-29196 Cancel the comment editor without a page load Fixed
Bug CONF-28415 Editor is not full height Fixed
Bug CONF-24568 Confluence search is broken for data within content elements, such as URLs in links, parameters in macros, image names on pages Fixed
Improvement CONF-24409 Include User Name in Mention Autocomplete in addition to Full Name Fixed
Bug CONF-24095 Safari 5 support broken in new editor: cut and paste inside macro blocks is unusable Fixed
Bug CONF-24812 When using Shortcut links "edit" does not work in Confluence editor Fixed
Showing 20 out of 212 issues Refresh

Open

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.

Loading

Bugs (200 issues)

Key Summary Status
CONF-34171 Failure when converting editor format to storage format in 5.1.3 Open
CONF-34165 Page does know scroll when pressing pageDown in Editor For IE 9, IE 10 Open
CONF-34140 Confluence Insert Symbol function not working in IE 11 Open
CONF-34124 Deleting a selection that starts with a blank line in Firefox does not delete the entire section Open
CONF-34123 Editor search in IE makes style to get lost in all the search matches Open
CONF-34104 PageDown is not working correctly when editing page with Firefox on Windows Open
CONF-34086 Anomalous Editing in Confluence 5.0.3 Needs Verification
CONF-34083 Unable to Insert links by pasting them through mouse right-click Open
CONF-34073 Firefox line deletion leaves empty space after deletion when holding shift + end Open
CONF-34066 Bullet list keep extra space line after merged Open
CONF-34045 Editor cursor did not jump back to the right screen after undo the modification Open
CONF-34029 Find and replace cannot match a string that spans multiple DOM elements Open
CONF-34018 multiple Ctrl-shift-A lock edit page Needs Verification
CONF-33950 selecting search results in editor doesn't behave as expected Open
CONF-33839 Confluence: Change Color of Text in Outline format, Re-Arranges Lines in Outline Needs Verification
CONF-33814 Text in Edit Link wizard is broken Open
CONF-33643 Copy and pasting into Confluence from a text editor fails to retain indentation Open
CONF-33606 In the Requirements macro, table inital display sort differs from 'click' sort Needs Verification
CONF-33563 Copy/Paste picture with Firefox 29 Open
CONF-33532 Chrome - Table Editor - Pressing Ctrl + Right Arrow in table cell moves to the end of the document Needs Verification
Showing 20 out of 407 issues Refresh

Loading

Improvements/Feature Requests (56 issues)

Key Summary Status
CONF-34201 Saving External Web Images as Attachments when Copying from External Contents and Pasting into Editor Page New
CONF-34148 Disable or limit number of concurrent users editing page at a time New
CONF-34090 "Preformatted" text behaves annoyingly not like several lines of monospace text New
CONF-34002 Dates aren't sorted correctly Open
CONF-33405 Restore the tempate prompt when creating a new page from a red link New
CONF-33273 Save button partly hidden by Tooltip - prevents saving a page New
CONF-33175 Allow to start editing on header or section New
CONF-32856 allow Confluence admins to prevent WebDAV-incompatible characters in page names New
CONF-32818 Make full screen editor available in IE New
CONF-32474 The Confluence editor should strip markup and classes when it is pasted into the page Open
CONF-31736 Text color toolbar button not intuitive New
CONF-31730 Keyboard shortcut E start editing mode not necessarily on top of the page New
CONF-31512 Confluence to confluence autoconvert Open
CONF-31502 Page Layout & Sections Open
CONF-31263 Distinguish non-breaking spaces from regular spaces in editor and code New
CONF-31082 Page pauses while loading in Chrome Open
CONF-31029 Saved Draft Locally When Expired Session Cause Confluence Unable to Saved Page Draft New
CONF-30670 As a user I want to be warned about or prevented from creating a duplicate anchor in the same page Open
CONF-30563 Ability to show borders on specific page layouts sections Open
CONF-30549 Define default Ajax timeout on the editor page Open
Showing 20 out of 56 issues Refresh

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.

FromIdea
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.

Anonymous

(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.

----

Andrew

  • 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 - current wiki-markup macro converts markup on the fly. I would like the wiki-markup macro to not convert and retain the markup as it is Resolved
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

Icon

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:

"A recurring comment was on the WSIWYG editor used when creating pages / documents, the editor in Confluence is amazing." - Crucial Cloud Hosting Blog 

  

 

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.

Icon

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 https://jira.atlassian.com/browse/SOURCE

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]


  • No labels

200 Comments

  1. How to make use of this page
    Icon

    This is a modified version of my original comment, updated to reflect the way we've been using the page for a little while now to help those coming to the page for the first time

    Hi All,

    Thanks for the continued feedback and discussion. In particular PaulGraham and Shannon have been amazingly active across several of the related pages, a big thanks!

    For those new to the page, we previously found that when letting the page grow by maintaining all comments it became too slow and hard to find relevant info. To maintain it's usefulness we now do the following:

    • Above in the page you can expand to see the Open and Resolved JIRA issues that people have raised. If you are having an issue, check here to see whether it's been fixed in a newer version or already been raised by someone else so you can add a comment or Watch the ticket.
    • You can raise a JIRA issue in the CONF project here. Just add the 'WYSIWYG Editing' Component to your ticket and it will be displayed on this page. These tickets are actively triaged and can be linked together where they are related or are duplicates etc and gets them into the hands of the developers faster.
    • I actively curating the comments on the page. I'd stopped as people questioned whether we were trying to censor any negative comments, which isn't the case, but unfortunately in practice this just makes the page less useful. 
    • You can still leave comments though! (smile) If you still wish to comment here rather than raise a JIRA ticket just include details of:
      • The version of Confluence you're using
      • Your OS and Browser details (eg: Mac OSX, Chrome 19)
      • Steps to reproduce your issue
    • and I'll raise it for you.
    • For more generic questions about how to do something I'll add them to the FAQ list. 
    • If you just want to provide general feedback please do. It's been asked a few times and yes we do track all of the feedback even if it's not suitable for the FAQ or a JIRA Issue. As to the question, 'are you going to bring back wiki markup', I would draw your attention to the line in the note above from the founders that Wiki Markup is not coming back to Confluence. There's more details of the technical reasons why in the post as well.

    Thanks everyone.

    John
    Confluence Product Manager 

    1. Anonymous

      Please make it so that
      Bold

      does not look the same as

      h3 (not Bold)

  2. I continue to be amused at the constant feedback regarding the new editor. I, too, have given up providing any feedback as the product is not getting better.  Key issues, regardless of how many votes, remain unaddressed.  I've been working with this new editor ever since it has been introduced and have to deal with it on a daily basis - cringing every time I have to work with it.

    My users don't use it - it's just easier now for me to do the writing than force others too.  Good thing my doctoral in engineering is providing such as good career path ... instead of focusing on value add processes, analytical work, etc...I'm now down to writing documentation, figuring out how to create  something usable and not embarrassing to provide to our customers. 

    The introduction and lack of resolution is forcing me to consider completely different companies because of the career path this product has taken me...and not one that I want to pursue....

    Seriously, folks....this is supposed to be easy for writing and sharing...it should not take hours and hours to write a single page that can convey information in a meaningful way.  We work with lots of tables and images...formatting is critical for technical communications.  The editor, without markup capability, makes it impossible.  It's now easier to using Confluence as a document repository, attaching files, instead of building reusable content that is easy to create and manage.

    Having all macros take the entire horizontal width makes creating and editing anything of significant content unless I'm connected to a 60" screen.  Seriously, inputting a copyright symbol requires an inch of vertical space?????

    I recommended Confluence and implemented this product three times - three difference companies.  As I move on, I will never recommend this product ever again for anything other than elementary writing and a document repository.   The Atlassian team is more focused on "likes" than fixing real issues and providing real business value.

     

    BTW- on catpcha...it's not a matter of not being able to read it...it just doesn't work.  Not sure how any fix passed a QA cycle when the same behavior occurs. And, agree with other posts...if you're logged in, there should be no reason to input a captcha, regardles of whether it is working or not...on my fourth try now...now fifth...

  3. Don’t give up hope Atlassian — I’m considering moving our knowledge-base to Confluence and re-vamping efforts at documentation in our IT department exactly BECAUSE of the great RTE functionality in Confluence.

    Wiki syntax / Markdown are fine and good for a certain crowd – myself included – but I’ll never get even the most technical people in my organization to take the time to learn another language syntax just to format text. And the office integration and copy and paste of images is just what the doctor ordered. I know all of that is nearly impossible to get working right when you are trying to keep both a wiki syntax and an visual editor in sync. I watched that exact struggle sink my favorite wiki – ScrewTurn — into closing their doors. And their RTE didn’t have 1/10th the functionality Confluence provides.

    So, keep up the good work!

  4. Anonymous

    I like the new editor, my one complaint is the Edit/Remove popup. It covers my text while I am typing. I am forced to insert a bunch of white space to move it to the bottom of the screen. It is particularly annoying for me because of my extensive use of "numbered heading" blocks on pages that I edit- that means that all my pages are in a block, and so I see the edit/remove popup all the time.

     

    If you could make that block show up so it is not showing up on top of my text, that would be great.

    Here is a screen shot:

    http://postimg.org/image/hy634v5al/

     

     

     

     

     

    1. Hi Anonymous, thanks for reporting this one. Can you let me know what browser you're using, and whether this happens for all macros you use, or just one/some specific ones? Not something I've seen before, I'll raise a new ticket for it if you can give me those details.

  5. Anonymous

    What a complete pain.  The ability to consume Wiki markup easily was one of the things which made confluence acceptable for a number of uses where automated editing was needed.  XML, a fundamentally write-only format, should never have been considered as a substitute.

    Anyway, this kind of change imposed on the users even though you know most of your hardcore and most important fans would hate it, is exactly why programmers should never use proprietary tools that they can't take over if the vendor chooses to mess it up.

    What makes this worst of all is that our support just migrated us to this with no warning and now there's no way to recover or back out.  I had assumed, up till today, that Atlassian wouldn't betray us and there would be a hidden way of extracting wiki text;  just very difficult to find.  Now that I read this article I know never to trust you again. 

    Once again

    • Warn the users you are going to change it
    • Deprecate for three versions with a warning in the user interface
    • Lock the feature out by default but leave it functioning for two versions
    • Only then get rid of it. 

     

    1. Hi Anonymous, when you say

      The ability to consume Wiki markup easily was one of the things which made confluence acceptable for a number of uses where automated editing was needed

      If you are referring to scripts you have which send wiki markup into Confluence, these will still work fine, the API will accept markup and convert it.

      The steps we took to make everyone aware of the change before it happened are detailed above, unfortunately it sounds like whoever maintains your instance didn't let you as an end user know this was happening and I understand it's a big change to happen 'overnight' from your point of view when that's happened.

  6. Anonymous

    The new RTE is just to time consuming for me. I document in wiki markup, then transfer it to confluence, which works okay as long I don't ever have to edit that page again. If I do I am in for many a counter-productive minute struggling to not click in the wrong macro and muck it up. Undo does weird things at times and back spacing reeks havoc with bullet points, it's not a well polished product.

    1. Anonymous

      I used to use the old mark-up system. It was fine as long as I didn't switch modes, as it was quite buggy when switching. So Atlassian can't figure out how to do it, and goes completely RTF.

      The new RTF only mode is even WORSE!!!! Its completely unusable. I tell it to mark it as whatever heading 4, it will pick one at freaking random. Backspacing is a complete nightmare, i'm fighting it every minute of typing. I'm resorting to cutting/pasting from another editor, Confluence editor is a complete joke. I like Atlassian products, but this basically needs to be scrapped and rewritten (both the code, and my documents in it!)

      Very disappointed that we have a wiki (which is awesome), but its editor stinks. Don't bother telling me that there are "niggling" issues, it just isn't usable any way you slice it.
       

  7. Hey Atlassian, just wanted to give a little positive feedback on the RTE now that its been in use in our small (50+) organization for a month or two.

    I've been using it at our company to take Meeting minutes/notes in any meetings that I am in, and just about every meeting people say "what is this tool - do I have access?" and they come up with ideas on how they might use it.  Back when I was using my beloved ScrewTurn wiki, that never happened.  As soon as people saw the wiki markup, or they saw how badly things broke when you switch back and forth between wiki markup and RTE (again, the struggle that ultimately killed ScrewTurn IMHO), they just wrote it off in their minds as a tool for geeks. Even the most technical users (like others in the IT department) just didn't have the time to learn a "programming language" to edit documentation (I know wiki markup isn't a programming language, but as is often the case - perception is reality).

    You certainly have one of the best (if not the best) wiki RTE out there, and I understand the technical reasons why RTE and wiki markup living together in harmony is a pipe dream that can bog a dev team down hard and fast. However, I will agree with others comments here that it still has some annoying quirks, and I think your developers time would be well spent actually squashing some of these.  The Source Editor has come to my rescue in a few instances (like the bullet or numbered list that won't die), but unfortunately it is only available after saving the page in my experience.

    1. That is because external looks always sell well... But even the most beautiful egg can be rotten inside...

      Think of it, when your looking for a new tool/application, when you review them, what are you most likely to pick?... The one that looks like something written in the age of Windows 95, or the one that has the Anno 2013 user interface?

      It often doesn't matter if the one looking aged has the best feature set that hits all your bullet points, is the most bug free and gives the best productivity, while the new shiny app is bug filled and imposes workflows that can break down any productivity... 9 out of 10 are bound to choose the one looking good...

      And the new editor DOES LOOK GOOD... It's shiny, beautiful with an elegant design... If it just worked ½ as well as it looked it might even be tolerable... Sadly that isn't the case...

      But fear not... Confluence is always ready with new existing experiences for you when you copy/paste content around, like the latest thing i experienced:

      CONF-28561 - Confluence Page Layout Duplicated Open

      1. Anonymous

        Very well stated! However,...I think you responded to a Fanboy,...so I doubt your excellent comments will get through to Fanboy or to this obstinate company.

        1. LOL - well, I do like Confluence so far, but being a user for a month hardly qualifies me as a fanboy I'm afraid, but I can see how you would think so.

          To be frank, I think the thing that most interests me in this debate and makes me want to defend Atlassian in it is that my favorite wiki (ScrewTurn) was, in my opinion, completely crippled and eventually had the the plug pulled on their company because of the intense effort required to maintain both a visual and a wiki editor side-by-side.  They never could get it right, especially with all the flavors of web browsers out there.

      2. While I think your comments ring very true, especially of generation Y and the millennials (30 and under folks, myself included), I don't think it really applies to my comment - we are talking about two different things.  You are speaking of choosing a product before-hand based on curb appeal.  I am speaking of getting a company to adopt a product that has already been implemented.

        As I have said, we had a very decent, wiki and rich text editor-enabled wiki solution (ScrewTurn) at my company for years, but I was the only one who ever used it - even though I gave presentations and training to several groups.  I actually tried to push its adoption.  It was a losing battle - not because it lacked merit or potential, people saw the potential, but because it was perceived as a technical tool, not an end user tool.  Even the IT department folks didn't want to learn wiki markup - I had one programmer/developer in the group actually create a few pages using straight HTML and images manually uploaded to the web server, rather than having to learn another syntax.  (Now, if this sounds ridiculous to you, my guess is that you work with a different technical skill level of users than the rest of us)

        Fast forward to today, where a month after installing Confluence 5, I have people in the company coming to me and my boss and asking if they have access to Confluence and how they might be able to use it.  And I've actually been trying to downplay Confluence so far, since we only have a 10 user license and money is tight.

        I know almost nothing about Atlassian as a company, but my perception of this whole thing is that they switched gears to target a certain market (I can only imagine their biggest one, or biggest target one, based on their "customer feedback" comments) and the folks that are now crying foul just don't 100% fit into that market.  And I'm not saying I blame you for complaining - maybe Atlassian should have forked Confluence into two products, or continued to release bug fixes for versions 3.X.

        It does point out a question that has been in my mind - probably a question that has strongly motivated Atlassian in this transition.  If you and your users are strong in wiki markup and want to live in that space, why choose to pay top dollar for Confluence when there are numerous quality, free, even open source wiki alternatives saturating that market space?

        1. we are talking about two different things.  You are speaking of choosing a product before-hand based on curb appeal.  I am speaking of getting a company to adopt a product that has already been implemented.

          Not entirely, you can make a Wiki markup editor look neat as well, although your right that it will scare them of easily... Problem is that my comment was just as well targeted at the RTC vs. Wiki, But there was a clear reason why I was one of the many fighters for changing from Word (a much better working RTE than Confluence 4.X/5.X) over to a Wiki, an my recommendation back then was Confluence 3.X... (We had Wiki syntax then)... And that was Productivity.

          What people don't realize was is that they will lose much more time fighting with an buggy RTE than learning a simple Wiki syntax. And I think Confluence presented a much better option for a Wiki back then than ScrewTurn did in terms of markup and the "in editor" help the provided, it was mostly due to the Space feature we choose Confluence over e.g. ScrewTurn but other factors was involved as well. Jive was scrapped as a competitor because it only had an RTE editor (as far as our investigation could tell).


          If you and your users are strong in wiki markup and want to live in that space, why choose to pay top dollar for Confluence when there are numerous quality, free, even open source wiki alternatives saturating that market space?

          Because, when confluence had wiki markup, it was simply the best of breed, hands down... Why don't we migrate over?... Due to migration cost... Another fantastic thing about confluence was all those neat macros, but they also makes it difficult to migrate, not to mention... it's all in the new format now so I can't even begin to think that thought...


          I know almost nothing about Atlassian as a company, but my perception of this whole thing is that they switched gears to target a certain market (I can only imagine their biggest one, or biggest target one, based on their "customer feedback" comments) and the folks that are now crying foul just don't 100% fit into that market.  And I'm not saying I blame you for complaining - maybe Atlassian should have forked Confluence into two products, or continued to release bug fixes for versions 3.X.

          The funny thing about customer feedback, is you don't just have to look at the raw number, given an example... Say you have a product with 2.000.000 customers, now you have 200.000 customers complaining about your Feature X, you ask those 200.000 if they are OK with you removing Feature Y in order to provide you a better Feature X, 90% of those say "Hell yes"... so 180.000 seems to not care about Feature Y... Will you now jump to the conclusion than you will only make 10% unhappy?... well I am now here to tell you that those 1.800.000 other customers that didn't complain about your Feature X in the first place... Might not even have used it because they instead used Feature Y?... Or might have been satisfied?...

          I am not saying that those are the numbers, but while Atlassian said they had allot of Pre-warning and EAP out for this happening, I doubt that it reached 10% of all their users, if even that many... We, the users, don't really have the time to sit looking at their website to catch these things and give our feedback, we come here if we are unhappy or looks for a new product... Which is kind of evidented by all those that feel they didn't have warning on this...

          Then in the wake of all this mess, some of their statements along of this has been extremely poor and completely biased, like the "Customers love the new Editor" section above, lets filter our all the good responses and not mention that there is allot of people that think otherwise, at least be honest and have the guts to say: "Some Customers love the new Editor, some doesn't" and give a few example of it's issues for some people... I have also seen some appalling responses from Atlassian over the time this feedback thread has been active... (good thing you can delete that stuff)...

          What would serve them well was if they allowed an "Bring back the Wiki markup" issue to stay open, and every-time people complained they said "Go Vote for it"... That would reveal just which camp was bigger.

          But what really bugs me allot is that they seem to spend allot of effort in putting new features in rather than actually resolving the bugs that has existed since 4.0 first arrived... Even the JIRA Team has is holding back on bringing in the new editor as they don't seem to see it as being mature: JRA-8943 - WYSIWYG / Rich Text Editor Open ... And what does that say about it? o.O...

          For what it's worth, I am far more impressed by Google and Microsoft attempt at a Web based RTEs with Google Docs and Office 356... So I am not just a hater on RTE's... If they work I am ok with them, I still think a pure text based simple markup language would allow me to write faster, but if they don't get in my way then ill take them...

          Confluence has a habit of getting in my way though and making me spend hours fixing broken pages...

          And STILL with the broken Crapcha (CAPTCHA)... And again I ask... WHY when I am a verified user?...

          1. Anonymous

            LOVE your response to their misguided product decision.

            This has got to be the most worst company for actually listening to their customers. Just check out how many bugs are either; quashed, deferred, closed and blamed on a 3rd-Party issue or out an out, just plain ignored.

             

            I also totally agree with your suggestion to:

            What would serve them well was if they allowed an "Bring back the Wiki markup" issue to stay open, and every-time people complained they said "Go Vote for it"... That would reveal just which camp was bigger.

             Oh I'd love to see that voting response!!! They are scared to listen because it would mean they were wrong to remove the WME,.....and their egos just could not handle that!!!

            Oh and by the way,....have you noticed that this format of commenting is pretty close the what was in Confluence!!!!!! Why not use the RTE for these comments,....at least then no one will be able to complain!

             

            1. Anonymous

              There's a non-scientific poll in the Confluence Users Group on LinkedIn. It's not a very large group. 58 people have responded to the question 'How much do you miss wiki markup?' The results so far are:

              What's Wiki Markup?  3 (5%)
              Not useful anymore   14 (24%)
              I liked the granular control it gave me.  18 (31%)
              Can we please have it back?  23 (39%)

              So, unscientifically, it looks like 17 out of 58 don't miss it, but the rest do. 

               

              Captcha - try 1, try 2, try 3

  8. We have very few users that now use anything but the basics in Confluence.  We used to use it to create much more enriching documentation that we could provide to end users and prospects without concern.  Without the WME, we no longer have the ability because the RTE and then PDF export issues introduced with the new version.  If you attempt to do much customizing, it is extremely difficult to troubleshoot and fix - macros take up too much of the vertical space making it very difficult to look at a lot of content on one page.  The Source editor is like reading an XML file  - much different than reading what was more like html code that you could have some organization to.

    So, is it good for creating minutes, overviews, basic instructions - yes.  But, we need it for much more complex tables, formatting, and image control to create the documents we started using confluence for.  Now, we are forced to attach as word documents and lose the collaboration and reuse capabilities that a wiki can provide.  And, please don't say 'go purchase a plugin'.  We already invested in the confluence licensing and had what we needed...then, it was taken away. 

    I too, was one who promoted the products - introduced now to 4 companies.  Won't ever do so again until the RTE and PDF options are significantly improved or the additional WME option (something similar) is provided.  The fact that you replaced vs added as another editing option is what seems to have been infuriating folks. (especially since you have a macro that still supports the creation and others have been helpful enough to try to provide a similar solution).

    1. I'm a little confused by something you say - they took away the WME and so now you create documents in Word documents and attach.  Do you have a plug-in for Word that accepts wiki markup?  Or is it just because of the PDF export issues that you use Word?

      1. We have to use Word to meet our formatting/style needs.   We then create pdfs from that Word document for our customer and prospect facing material.

        When we have the WME, we used Confluence.

        1. So what formatting / style do you get from Word, that you had in the WME, but you don't have in RTE now?

          1. Anonymous

            Adam - it is not what formatting is available, but the ability to get consistent results.  The difference is that in Word, you are able to precisely control the available formatting options.  That was possible with Confluence when the WME was available, and is no longer possible (without 100X more effort) with latest Confluence release.

  9. It was much easier in the WME to control any types of formatting (font/style/weight/color), especially in tables; RTE is limited in the options provided.  Once you start to have an issue with formatting, especially in table content, it's nearly impossible to clear.  We have issues where we have copied content from one page to another and strange formatting comes across that is not in the original page.  I have to go to the source editor to discern what might be going on and cannot do anything...but, it's difficult to read. 

    There are several bugs introduced in the PDF export that affect how tables and text display and wrap, table content, and image location.

    Trying to position text to the exact position that we want is very difficult in the RTE because so much vertical real estate is applied to the begin and end tags.  We work on 15" screens - you can see a section and maybe 2 columns, if you're lucky, of content. 

    We have issues where extra spaces get added between punctuation marks.  It's difficult to compress the vertical real estate and ensure you have the specific number of breaks between lines - the macros tend to input additional blank lines that we don't want.

    I try using the shortcut keys, but they are often ignored - in WME, I didn't have to worry about my h3, h4, or — being ignored.  Macros didn't just refuse to display when I inserted them - in the RTE, I can type these and they are treated as literal text or paragraph style, and macros you just input don't disappear.   It didn't take me multiple clicks to open a macro editor to change the properties.

    All of these issues have been reported through support and are on the original feedback pages.   My point is that the RTE and PDF export have not been stabilized nor improved to provide functionality that users had back to something that we had - it was easy to control, troubleshoot, and edit. It didn't require a developer to understand.  I realize not everyone has html capabilities - but, it was still easy to read.  

  10. Anonymous

    Our company (Fortune 100 company) upgraded from Confluence v3 to v5,....there has been an immense uproar by everyone here. The common consensus is that Confluence is absolutely impossible to use now! The templates are of no use,..and the loss of the wiki markup editor has caused all of the stir.

    After being pointed to this page, I thought I'd find a reasonable explanation,...but all I find are similar complaints from other companies,..as well as a response from the Atlassian founders that borders on the insane. I have never seen a company that depends on its customers for success, come out and ignore, curse, and practically stamp their feet in disgust at what the customer expects from their product.

    And then I find no response from the founders to any of these comments!

    While I do not have direct say over how my company handles all of these complaints over the upgrade,...I do have an opportunity to collect these complaints from my colleagues, as well as the complaints I'm finding from other users and companies,...and forward them on to the CTO of our company. He does make the decisions and I don't think Atlassian will be happy with the results.

    Atalssian: I implore you to consider these complaints.

    P.S. What ever happened to the old adage, "The customer is always right"?

     

     

     

  11. Anonymous

    Migrating over "#" users (number withheld because company would be recognized) is a hell of a task. However the subset of those users that are actively using Confluence Wiki have great concern over this upgrade, and is probably in part reason why the migration to the new version did not yet happen. As a smaller sub-team, we used this Wiki to do all of our document writing in favor over MS word, or other "Rich Text Editor".

    The simple syntax forced our contributors for a simple manageable layout, and made layout much more consistent than it ever could be. We were quite happy by "not being able to merge cells". It forced the contributors to write in a simpler flow, and resulted in easier to read documents.

    Breaking with this "original native wiki" syntax, and the response to it, appears to be an unapologetic showmanship of ... well ... something. The many promises so far only resulted in a buggy editor, even simple autocomplete for bullet lists do not seem to work consistently ... after that long? And with hard to learn keyboard shortcuts for beginners, how do I explain contributors to type "{" to start a macro ... 

    If xhtml was so important ... why not {xhtml} to embed those advanced layouts (merged cells etc). Now all we have are people crying, and the other party saying that we are only going ahead with it, probably hoping it will die out.

     

    If only you could give all those other neat features without breaking the original native wiki syntax.

    Next thing I will hear is that the unix community will kill vi ...

     

     

    1. Anonymous

      That is absolutely brilliant. Wonderful idea. Also, you could spawn a RTE window inside the WME. Great idea and perfectly doable. Unlikely they will but still a great idea.

      Right now I am playing with creating pages all inside {wiki} tags. The only drawbacks are the page resolution and no macro browser. Having a 3.5 handy to create pages then copying the code across makes it a lot easier. Also set your screen resolution to 90% or 70%. Makes using the version 5 editor and viewing version 5 pages much easier.

      Captcha fails: 1, 2

  12. I have an idea. Why not release Confluence 3.17 as open source and let the developer community carry on with it?

    I would be happy to give people like Bob Swift some money for plugins. Those of us who really want to keep wiki markup will be happy and Atlassian won't have to support it.

     

    (captcha try 1. Try 2. Try 3. Try 4. 

    1. Thanks for the suggestion Kathleen but we don't have any plans to open source it.

      1. John, since you're here and active on the thread again, the real burning question is whether Atlassian has considered my suggestion, +1ed by many people here, that you simply continue support for 3.5.x indefinitely rather than expiring all support for 3.5.x in August or September of this year. If Atlassian were to provide indefinite support for at least rendering problems as the major browsers move forward, my organization with a 500-user license would consider renewing our maintenance again. But there is no chance in hell that we'll be moving to 5.x any time soon. Not with the RTE and the PDF exports in the current buggy, clunky state it's in today.

        Captcha attempt 1, 2

        1. Anonymous

          annnnd,...it sure seems like they are ignoring you, as well as ignoring others.

          That really burns me up,.....they have no idea what customers are going through when using the latest Confluence. I saw some place where they stated that it was impractical for users to edit using the Rich Text Editor, only to have to switch over to the Wiki Markup Editor......what a pile of crap.

          They simply can't understand just how important the wiki markup editor was!!! The wme was all that me and my colleagues used every day. Put simply, the new editor sucks! It is HORRIBLE!

          Just because Atlassian keeps trying to sell the new editor as the best thing since sliced bread,...just doesn't make it so!

           

           

           

      2. BTW, I'm willing to bet that if you offered 3.5.x for sale to new customers "as is" with only a promise of ongoing support for browser rendering issues as the major browsers move forward, you would still sell an appreciable number of entirely new 3.5.x licenses. Frankly, 3.5.x is perfect. It is rich, has depth to do very sophisticated things, exports to PDF nearly flawlessly, and just gets the job done in 99% of use cases.

        In the Austin, TX software community, I routinely tell peers "Confluence 3.5 is the perfect tool for the job. It's a shame you can't get it any more, and I cannot recommend Confluence in its current state at all."

        Just pitch 3.5.x as "Confluence Classic, for die hard wiki syntax fans", and it would make sense to offer it along side your current 5.x product.

        Capcha 1

        1. Anonymous

          If the known issues with 3.5 were patched I would seriously be on that bandwagon. Nothing wrong with 3.5. The features are well worth having Confluence as opposed to the other options available. Here we have competition from a variety of wiki technologies including wikimedia sharepoint drupal twiki as the main contenders and Confluence so far has stared them down. 5.x has some nice features to offer, one of which is a much better RTE, however the only reason we would consider upgrading is to patch known issues. Otherwise 3.5 would be perfect.

          Atlassian. Will you fork Confluence? 

          Give us Confluence Classic and Confluence New.
          Yes, that was a direct reference to New Coke. For obvious reasons. 

  13. Anonymous

    Why have you removed the ability to edit wiki markup directly?

    The "rich" text editor is not good enough to do the job on its own. It is buggy. Tables are a pain. It keeps mangling them, giving me no confidence that I can edit a document without destroying it.

    I completely understand the desire to make the text editor 'good enough' that people do not need to edit the markup. But taking markup away before it is good enough is idiotic.

    Either you failed to test the editor sufficiently or you don't care about your customers. Either way you are bad.

     

    Captcha: 1, 2

    1. Why have you removed the ability to edit wiki markup directly?

      You can learn more about the decision and new add-ons that provide source editing capabilities in Confluence 4.x and above, here: Why We Removed the Wiki Markup Editor in Confluence 4.0.

  14. Anonymous

    Matt, you assume people have not already read those lame excuses! People are just dumb-founded that a company would take away something that makes perfect sense. Is everyone at Atlassian just too stubborn? There's no shame in giving the customer what they want!! Microsoft just buckled under customer pressure and removed the restrictions on their new XBox One.

    In fact,..read this article by James Dominguez that begins with:

     

    "Have you ever heard or read about a big corporation making a really bad decision, and said to your friends, "They really need to just change their minds on this. They won't, of course, but they really should."

    Well, in defiance of all convention, Microsoft has changed its mind."

     

    SO, it seems Microsoft can back down,....Atlassian, get a clue! Customers WANT their Wiki Markup Editor back. NO BULLSHIT! (just using the founder's offensive phrase they used on their customers)

    I'm about to type the captcha,..and the word is: shated

    Hahaha,..that's exactly what Atalssian did to their customers,..they shated on us.

     

    1. Anonymous

      Can Atlassian clarify the following point for us all ?  

      * A customer wants to integrate Confluence with Jira v6.0.1

      * If that customer is in production with Confluence 3.5.17 with Wiki Markup and that customer wants to integrate Confluence with Jira v6.0.1 , does the customer have the option to continue running with Confluence 3.5.17 and Wiki Markup after the integration with Jira ?

      1. I asked the same question in regard to JIRA 5 at an Atlassian Roadshow earlier this year. The answer was 'yes', it should still work. But it would be good to have clarification for JIRA 6 as well. 

        Captcha 1, 2

  15. Anonymous

    Looks like some posts are being conveniently deleted by Atlassian.

    Really!? What's the matter Atallasian,...afraid to let customers speak up and say that they are unhappy with the current state of the product,..or your decision to remove the excellent Wiki Markup Editor?

    You can't have it both ways,.... you can't post sweet sugary positive comments,.....but hide customers that have a legitimate beef with your decision to remove the WME.

    Gee,...I wonder why the "flounders" had to start their justification with the words:

    "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."

    Really? Open company, no bullshit???? Let me clue you in on something,....there are not a "few customers" are you try to believe. This will not go away until we see the WME back in the product. Oh and by the way,....that's NO BULLSHIT!

  16. Anonymous

    The fact that you had to write an entire document on why you felt you had to do this, and to justify why you did it in the face of customer backlash, is really telling. I've said it before, and I'll say it again: You need to fire the guy that came up with this nonsensical idea.

    1. Anonymous

      Probably the best advice I've seen regarding the decision to remove the Wiki Markup Editor!

      I guess they think they know better than their actual customers.

      Sure the sycophants and toadies will always love what you do,..but do they really listen the critical comments?!?! Doubt it!

  17. Anonymous

    My company just migrated to the version (5.x.x), which took away the wiki markup editor. After experimenting with the new page editor,  I am giving up. Editing existing pages and adding is major pain. Inability to see content in its native format is another drawback. In its arrogance Atlassian decided to remove the essential part of wiki functionality, turning Confluence into a non-a-wiki knowledge management product. Many of us who are using wikies for ages, have instinctive knowledge of markup, making us useful and effective. This removes this advantage. Under the pretense of not having other users (management types) upset for seeing source editor button when they add or change pages. Congratulations Atlassian, you just wen the Microsoft way. 

    As result I will be taking my team off this wiki solution and move it to Confluence-like XWiki. This one is still the true wiki engine (i.e. supports wiki markup).  It even supports Confluence's original markup.

    1. Would be lovely if you cared to share your experience with that migration process...

      But I suspect you still have a backup of your old installation as is to migrate from so that you aren't converting from Confluence Markup back to Wiki syntax?...

      And what Plugins have you been using in your installation?

      As XWiki the only maybe viable contender so far for us, it would be nice to hear about others experience in going from Confluence to XWiki.

  18. Anonymous

    My company converted from 3.5 to 4 last winter (we are currently on 4.3.2, and trying to avoid even looking at 5 at this point). Uproar regarding the loss of wiki markup aside, I have encountered a problematic bug. I have a documentation space that is organized using labels, with extensive use of the "Content by Label" macro throughout. This space was set up in Confluence 3 and converted over to 4. As part of a documentation update, I have to replace some labels, which would normally not be a problem except that when I edit a "Content by Label" macro, the labels applied are missing from the macro parameters. Meaning that I have NO WAY of knowing, aside from my best guess, what labels were used to generate lists of content. Somehow the information is still there, as the macros are generating correct lists of pages in View Page mode (which is why I didn't catch this problem months ago.) 

    If only I still had access to wiki markup... (sad)

    In general, I find editing any pages that were converted over from 3.5 and included any use of macros is incredibly frustrating and a waste of my time. (Editing nested macros? Replacing an image in a page? UGH.)

    1. Anonymous

      Your last sentence:

      "In general, I find editing any pages that were converted over from 3.5 and included any use of macros is incredibly frustrating and a waste of my time. (Editing nested macros? Replacing an image in a page? UGH.)"

      Hits the nail squarely on the Atlassian developer's heads! (and I also include the product managers!)

      What the heck were they thinking!?!?!?!?!

      I like what someone else said,....(and I may be paraphrasing),..

      "Removing the Wiki Markup Editor from Confluence,..is like Linux removing the command line interface,...can you imagine the uproar".

      Atlassian removing the Wiki Markup Editor is simply one of the stupidest moves I've ever seen a software company do! and, their explanation that "it was difficult for the developers to maintain this feature",..tough nuts!!!! That's your jobs!! Most of all,...developers just follow orders like sheep,...so I really blame the owners and product managers!!!!! Stupid,..really stupid!

    2. I'm not saying this is a solution to the problem, but if the data's still in there it should be visible in the source code XHTML-ish editor. https://marketplace.atlassian.com/plugins/com.atlassian.confluence.plugins.editor.confluence-source-editor  I haven't used this, but editing XHTML in general is horrible. If you get a ; wrong, it's going to fail (in a normal editor). I think this editor will toss out anything that will stop your edits from parsing, but that means it will probably also toss out other stuff that you really want to stay in. As I said, it's may not be a solution but it might help. 

      Captcha 1, 2, 3, 4

      1. Anonymous

        Thanks Kathleen for your suggestion.

        Unfortunately that source editor (xhmtl) is a joke.

        It is impossible (or nearly so) to find things you want to change,....and when you do change something,...inevitably, the formatting is incorrect and crashes the page.

        I have no clue why Atlassian blames the customers, saying,...we're just giving you something you wanted by removing the wiki-markup editor. They got it ALL wrong!

        Trying to modify macros, and ESPECIALLY nested macros is a JOKE (read: impossible) without the wiki markup editor.

         

  19. Anonymous

    The whole new editor has been a disaster for us.

    We thought going from 4.1 to 5.x would be an improvement.... and we were half right and fully wrong. Some 4.1 bugs were fixed, and a whole slew of serious new bugs bit us directly on the sensitive parts.

    God I miss the wiki editor.

  20. Anonymous

    You know what sucks the most for us since we lost the Wiki Markup Editor:

    • The ability to view the source of a page, select a section, copy it,..and paste to a new page. This was so easy to do with the WME,..and it is now impossible now in the latest version of Confluence. What used to take 2 seconds is impossible. Great Job Atalassian! Not!
    • The ability to quickly create a table via WME using the | symbols,....and the top row using ||,....again ridiculous that I MUST now use their table creation button,...or type {table  only to have it pop open a box asking which of the useless tables I want to use. Great Job Atalassian! Not!
    • The ability to view the source of someone's page as an example,..only to see deeply nested tables that are super ridiculous to understand. Great Job Atalassian! Not!
    • Plenty of other things have been lost since the WME was removed. You guys really suck!!! Why would you listen to some customers (biggest complainers),..but leave (what were) content customers out of the whole process??? So now,...what were your content customers, are now, your big complainers!!! Great Job Atalassian! Not!
    1. Hi Anonymous – it is still possible to do these things:

      The ability to view the source of a page, select a section, copy it,..and paste to a new page

      You can still do this using the View Source option in a page's Tools menu.

      The ability to quickly create a table via WME using the | symbols

      Click the image below for a quick demo:

      You can also still enter an entire table using the Insert Wiki Markup dialog (Control/Command + Shift + D):

      The ability to view the source of someone's page as an example,..only to see deeply nested tables that are super ridiculous to understand. Great Job Atalassian! Not!

      Using the View Source option in a page's Tools menu allows you to copy any table from one page to another.

      These are just a few of the ways you can still work with wiki markup in the new editor. I'd recommend taking a look at this guide for more tips: Confluence 4 Editor - What's Changed for Wiki Markup Users.

      1. You can still do this using the View Source option in a page's Tools menu.


        Not quite that easy, selection in the editor is still super buggy when you begin to have macros, and even when you manage to think you have the selection you wan't it ends up copying more than what you thought you had selected... On top of that it is far harder to hit the right selection in the "View Source" than the actual editor.

        It is often easier to select the entire document, copy that and then delete what you didn't wan't copied, although if you only wanted inner parts of a macro that can also be a quite difficult task as you may end up still getting the "outer macro" copied.

        Just try to view this simple example where I try to copy something inside a panel, I succeed in the end, but it is absolutely not intuitive that I had to do it "like that"... 

        http://screencast.com/t/7uzZJfXsJ

        What really would help was if you "colored" the macro placeholder when it was "Selected", because there is such a small difference between having it selected and only having it's content selected.

        Like demonstrated here:
        http://screencast.com/t/SqLclghrQk02

        All that aside, "selecting stuff" has gotten somewhat better, but that really only says something about how horrible it was in the start.

         

        1. Anonymous

          Exactly Jens!! You put into words exactly the experience we are having. Like you said,...it simply is not as easy as they make it out to be,...especially when you're dealing with complex pages with tons of macros or nested sections.

          One thing that really frustrates me,..is when you view the source of a complex page,..and only want to copy and paste a small section,...it can be next to impossible to find that section.

          and,...Ctrl-F WILL NOT work in that window. Another thing that baffles me. Did they even think this through.

          Let me ask a question of Atlassian,...if the Wiki Markup Editor was so bad, that they simply had to remove it from Confluence,.....then why even bother adding support to "Insert Wiki Markup"?

          The "View Source" that I found helpful,...would show the Wiki Markup,...in plain markup context,....NOT the useless format it now shows! Prior to this debacle,..if you Viewed the Source of a complex page,..even a complex page,...you could search for things very quickly,..and the markup typically would fit in a page or two,....with the changed "View Source",...what you see is pages and pages and pages of nested tables, sections,......that is maddeningly insane to use.

          Shouldn't this tool be as simple as possible to use? I read in one of pages that they decided to make Confluence simple for EVERY user,...no matter the skill level. Big mistake. You've alienated a whole slew of users that were able to quickly modify pages,..even complex pages in a few minutes. NOW,...I find myself spending 2-4 times the amount of time adding or modifying pages.

          One other thing I just thought about,...modifying a complex page,..meaning removing a small section was so easy and lightning fast with the Wiki Markup Editor,...however,....in it's present state,...if I try to do that,...I usually end of breaking sections or the entire page because I've modified or accidentally removed more than I wanted.

          You also don't seem to be able to insert a picture within a table,....something that used to work.

          So,..Matt Hodges,..can you really keep defending or explaining away these comments?

          We can't all be disgruntled users out for vengeance. We Loved the way Confluence used to work. We really want your company to succeed. But to succeed,..you have to listen and understand what your customers are talking about. And that means listen to ALL your customers.

           

          1. Anonymous

            (I can no longer to log in to display my name - Shannon Greywalker - because like so many Atlassian things, the move to the new Atlassian ID has completely borked both my Confluence and JIRA logins)

            Re the post I'm replying to, YES, Ctrl-F within wiki syntax has always been a major part of authoring workflow for many different use cases, and it's one of the things that got severely broken by the removal of wiki syntax in 4.x. In general, you can no longer trust that you can find many types of things within Confluence pages any more when you need to to global revisions and global search and replaces. The basic Search box no longer finds everything, especially specific macros with specific parameters, or links that include syntax pointing to a target page in a different space. And it used to be that you could at least open up pages and use Ctrl-F within the wiki syntax of the page to find such things, but no more!

            I posted JIRA bugs on all this stuff more nearly 18 months ago, shortly after the move to 4.x, and I've seen no resolution of such bugs yet.

             

            Atlassian, this is critical workflow for authors that you are simply failing to support. Not just tech writers, either. I can point to several business departments within my own enterprise that do all manner of complex spaces, tables, links between spaces, heavy use of macros on every page, etc. Wiki syntax was not "just for a few technical types".

            ...annnnnnnnnd you still haven't fixed your captcha bugginess. There's one attempt. There's two.

            1. Anonymous

              "Atlassian, this is critical workflow for authors that you are simply failing to support. Not just tech writers, either. I can point to several business departments within my own enterprise that do all manner of complex spaces, tables, links between spaces, heavy use of macros on every page, etc. Wiki syntax was not "just for a few technical types"."

              Thank you, thank you, thank you! We are in the same position,..but I was having trouble trying to put it into words. Thanks again Shannon.

               

        2. Re: Jens http://screencast.com/t/SqLclghrQk02

          2:00 - 2:20

          "Hmmm what will happen now?"

          I think that sums it up.

          When trying to figure out how to use the IME, it really helps to be a power user who can poke and prod until you get things to work.

          1. Anonymous

            Excellent examples Marco!!!

            They keep saying that they wanted to make Confluence simpler for people to use, and that's why they removed the Wiki Markup Editor. Yeah right!

            If they were truly honest,..they should say,..that they wanted to make it easier for their developers,...and to save themselves money.

            Seems to me,..cutting and pasting in the Wiki Markup Editor was for every user:

            • Fast
            • Easy
            • Simple

            Now,...it's:

            • Slow
            • Complex
            • Confusing

            HOW in the world could they argue with this!!!!

            If Atlassian had a version of Linux,..they'd probably remove the command line. They'd say that they just wanted to make sure that their version of Linux was open and easy to use for all. The GREAT thing about Linux IS the command line AND the fact that it also has a GUI interface.

            I have a colleague, that says from time to time, "If it's difficult, don't do it".

            He's one of our software architects, and he's not speaking about developing code,...he's talking about the UX (user experience). Too often developers want to trim, obfuscate, delete, remove portions of code that THEY deem difficult to maintain. Fortunately my colleague has the final say,..and has the customer's user experience in mind.,..to which 9 times out of 10, he will veto those kind of changes that impact the user experience.

            Marco: My hats off to you for that example,....there are so many others that can also be shown!

            1. Anonymous

              Sorry Marcos,..I dropped the 's' in your name: Meant Marcos

              1. Thanks. FYI, the example belongs to Jens. I was merely responding to it.

  21. Anonymous

    "Seems to me,..cutting and pasting in the Wiki Markup Editor was for every user:

    • Fast
    • Easy
    • Simple

    Now,...it's:

    • Slow
    • Complex
    • Confusing

    HOW in the world could they argue with this!!!!"

     

    And Atlassian's response is,....well,.....the sound of crickets chirping.........

     

  22. Anonymous

    What a relief to find that other people feel the same way about the removal of the wiki markup editor. after reading all the comments above,it seems that this company could care less about what their customers want.not sure i've ever seen a company not want to make their customers happy,or remove functionality with complete and utter disregard to the wants and needs of customers.perhaps the aol ceo should step in here and fire someone.

     

  23. Anonymous

    It's interesting what most people seem to fail to realize; when a product has probably millions of users, and less than a hundred vocal complainers, it doesn't make a decision even remotely wrong, it just shows that it was a difficult one to make.  This is the sort of behavior I'd expect from children, but not professionals.  If you all put a small portion of the effort you've used to complain and sulk into suggestions to make the product better (feature requests), you might find a product you really love.

    If you actually read the above, you 'll see that Atlassian was listening to their customers when they made this decision.  The bottom line is that the RTE has most of the functionality of wiki (plus additional), and is easier for the vast majority of people to use.  

    Take a lesson from Atlassian and "Be the change you seek" - provide some constructive criticism and let them help make the product easier for you.

     

    1. Your comparison of negative feedback to childishness is uncharitable, and likely to either discourage honest discussion or incite unkind responses.

      Your generalization overlooks the numerous professional comments by Jens, Shannon Greywalker, Kathleen James, Todd Day, Greg Whitfield, etc.

      Graham went so far as to reverse engineer the RTE format and make a validator and wiki markup to RTE translator (the "wikifier").

      Each of these people has gone above and beyond the call of duty by using their time and energy to give constructive feedback to Atlassian.

      The typical commenter will not invest that amount of time and energy beyond their REAL jobs, nor should they be expected to.

    2. Anonymous

      Just because the "millions of users" are not complaining on this page doesn't mean they're happy  about the change. 

      1. Anonymous

        EXACTLY!! and I think the generalization of "millions of users" is far too generous for most companies,..let alone Atlassian. Be that as it may,...the problem what the commenter says is this,..

        To think that (as they write) "millions of users" are the happy ones is ridiculous. Most were not given a choice to upgrade to the next version. And, once they were upgraded,..they took their grief out on the local Network Operations team that performed the upgrade. It happened here at this company. So, of the hundreds in this location, most has resigned themselves after complaining and misdirecting their grief. They ARE NOT happy users,...only beaten down and resigned to use what is forced upon them. 

        And as the poster also states "Atlassian listened to their customers,...I mean,..didn't you read what they wrote above,...". Sure,....and I can say that I speak with Angelina Jolie everyday. Just cause I say it doesn't make it so,...nor does it mean the Angelina Jolie you're thinking about. What the poster faisl to also mention is the obscene way in which Atlassian basically blames us, the customers,..and also telling us off by saying, go find something that will make you happy. Hmmmm,..doesn't sound like a very charitable thing to say to your customers. I might be wrong but,...as a business, wouldn't you value EVERY customer? Wouldn't you value all of your customer's opinions and suggestions.

        As Marcos stated,..there are plenty of valuable opinions, suggestions, and ideas that are being shared here. That poster seems to have taken all these comments too personally, and I'm only guessing here, but it sure seems that it probably is by an Atlassian employee,..an employee's spouse, or something similar,...

        I say that because I've never taken offense to the Microsoft haters,...even though I'm a big fan. Heck,..I've even slammed them too. Sometimes those detractors actually make sense and get through the haze that fans sometimes create which blocks them from the truth. Ever see or hear of Microsoft ME??? Sheessh,..what were they thinking. Did you see the price they tried to sell the Microsoft Surface??? Insanity!

        And their suggestion to put our time to good use by opening issues that might actually help move forward positively. And I'd say exactly as Marcos has said,..we have, and we're currently are doing that very thing. BUT, have you also seen the age of some of the issues that are opened and still unassigned?? Have you seen the number of votes on these issues, and yet they languish?

        One last question,...what is this whole thread for, if not to add comments, good or bad! I actually respect Atalssian in that one regard,...they've allowed people to rant, complain, request change,...and have left these comments up. They could very easily have locked this thread a long time ago. Kudos to them! Just wish they add the Wiki Markup Editor back. I'm not asking for them to remove any other feature, nor make any other change,...just want the WME back......and NO, the RTE CANNOT do all things for all people.

  24. Having read some of the passionate feedback on this page, I just wanted to say that I am very pleased with the Confluence editing UI. It is not perfect, but it is better than anything I've used to date, and I LOVE the priority placed on keyboard shortcuts. As I tried Confluence out, it was just natural to use it as my primary editor to type out documents, share things, create todo items, etc. - it actually motivated me to document and write since the editor was so cool to use!

    I have no experience with previous versions of Confluence and can see how it would be painful to transition from full control over the markup to a wiki editor. However, Atlassian is making a strong statement by enforcing the use of their editor - now they must make the UI work to keep the product alive. I appreciate knowing that this level of commitment to usability is behind a product that I'm using.

  25. Anonymous

    JoshL: It's great that you're having a good experience,..and that you've never used the prior versions,..and that you want to state Atalssian's "level of commitment",...but one small problem,.....what is it that you're bringing to this conversation. "Walk a mile in our shoes" and then you might fully understand the passion that people feel for having the wiki markup editor ripped out from under their feet.

    Take this Twitter post as an example of passion:

    You have to understand,...other companies have made changes that their customers abhorred,..only to have the change reverted. Think Coke, Pepsi, Microsoft,....and the list goes on. For me personally,...I just don’t understand why Atlassian puts up a wall on this issue. Yes,...people are passionate,...they want WME back,....doesn't that say something about the QUALITY the WME brought to the product???? No one seems to be asking for a removal of the new RTE,...just bring back something that plenty of users find so useful,....that to use Confluence is simply a CHORE.

    I'll give you an example of something that was soooo simple with the WME. You used to be able to "steal" content you found useful from other pages by editing the page with the WME,...selecting what you wanted,..and cutting and then pasting into the new page. With RTE,....it is utterly a disaster. For one thing,..you're looking at nested sets of tables that can run onto multiple pages. Try figuring out what it is that you want. Then,...even if you do take your mouse to highlight the area you want,...if you move the mouse to far, everything that was just highlighted is now, Not highlighted. Doubt me,..try it for yourself and you'll see what a pain that can be.

    1. Anonymous

      Exactly. Here's another example of weak "level of committment". This bug was filed 18 months ago, describing the most "broken" aspect of the new RTE editor in exhausting detail. The workflow that this bug describes is one of the most common tasks in writing wiki content. 18 months, and the only action they've taken on it is to keep pushing back the fix version further and further. Or taking off the fix version entirely, just stranding the bug in the middle of no where. Seriously, try out some of the typical workflow described in this bug report. See for yourself. Meanwhile, I have no idea how or why the product managers for Confluence prioritize anything.

      CONF-24760 - Copy and Paste problems with list and macro selections. Open

      1. Anonymous

        BTW, in case anyone has trouble viewing CONF-24760 as linked above, the gist of the problem is that attempting to cut or copy (then paste) selections that involve parts of a list or  parts of a typical mixed set of nested macros, sections, and paragraphs results in hilariously unpredictable and undesirable results. This was reported in detail 18 months ago and the behavior today in this regard has not improved in any manner. Every functional test detailed in CONF-24760 (reported in 4.1) still fails today in 5.2. 18 months later. For fundamental, frequent, typical editing workflow.

        Here's just one of the functional tests reported in that bug ticket that you can reproduce for yourself in 5 minutes to see why so many of us bitterly complain about the RTE editor even now, nearly 2 years after its introduction. Do this in Word or Outlook first to see that Microsoft clearly understands the concept of basic editing workflow and ensures that their RTE editor can successfully meet intuitive user expectations. Then try it in a comment below and see for yourself just how bad the Confluence editor mangles this very typical example.

        Create a simple list like so:

        1. Step 1
          1. Step 1.a
          2. Step 1.b
          3. Step 1.c
        2. Step 2
          1. Step 2.a
          2. Step 2.b
          3. Step 2.c
        3. Step 3
          1. Step 3.a
          2. Step 3.b
          3. Step 3.c
          4. Step 3.d
        4. Step 4

        Now select the lines for steps 3, 3.a, 3.b, and 3.c. Cut those lines out. Now place your cursor at the start of step 2 and paste.

        Try it in Word or Outlook and you'll see what every user would expect to have happen. Try it in Confluence and then have fun trying to fix the mess that ensues. THIS was a task that was dirt easy and intuitive with Wiki Markup in 3.5 and earlier. Now? It's maddening to work with any sort of page that comprises anything more complex than a simple set of headings and paragraphs.

         

         

    2. I'll give you an example of something that was soooo simple with the WME. You used to be able to "steal" content you found useful from other pages by editing the page with the WME,...selecting what you wanted,..and cutting and then pasting into the new page. 

      This has not changed and you can still do this by selecting View Source from a page's Tools menu. The only difference now is that we render the rich text view of the contents (inc. macro placeholders) in place of the legacy wiki markup.

      1. Anonymous

        No offense Matt,...but now I think you're just busting our balls here with that example.

        THAT in no means is the same as the example that was given,...in fact,..you're supporting that argument.

        View Source is a JOKE! You can't be serious Matt,...you didn't even read what was explained,..otherwise you would not have put written what you just did.

        Take a look at CONF-24760 and then tell me that RTE is better than WME. I know you're going to do that anyway,...but for once stop for a second and at least listen to what people are saying.

        1. Anonymous

          True that! View Source and Edit a page show the exact same thing in the RTE.

          Why the heck would he say that that's a solution to the cut-n-paste disaster in RTE.

          I don't think he read the whole thread explaining the problem at all.

          Why are they so passionate about telling us the customer, what it is that we want.

           

        2. Copying from the View Source view and then pasting into a wiki page seems to work fine for me... Styles, tables, etc. are copied right across!

        3. The 'view source' facility was designed right from the inception of the XHTML/RTE work to support the exact work-flow you describe (as Matt is explaining). It renders a slightly tweaked version of the page which is suitable for copying and pasting into the RTE. The biggest difference you will notice is in the rendering of macros.

          So if this facility isn't working for you we would be very interested in hearing how we can improve it. It only has one purpose and if it isn't serving it then it needs to be addressed.

          1. FIRST OF ALL... Sorry for the TL/DR post...

            Paul Curren [Atlassian]

            That you slightly tweaked the view compared to the RTE actually makes it harder, Macros in macros are far more difficult to select in the Source View because they are "clammed" together.

            Then there is the matter of "When do I have the macro selected, and when do I not have it selected"... This part is not obvious in the Source View nor the Editor... As I mentioned a some posts up, coloring the macro placeholder while selected and otherwise not seems like "the least to expect"...

            Also... Try to scroll 2 page up and there is the first bug you could begin to look at before you ask... And in no Offense, but Why should we provide you with new issues when 18 months old ones doesn't seem to get solved (and I have some dating back to October 2011).

            Rather you keep power-packing the RTE with new features that only brings new bugs as well?... And here I am not talking about new features like "templates" etc, as those are not new features, those are "bringing back old features" which in turn then was really just "bugs" with the new confluence... But rather the Page Layout thing, the overhaul in the design, workbox, likes and even freaking image borders was more important for Atlassian than fixing issues with the RTE. And don't get me wrong, some of those new features are GREAT! AWSOME! SUPER FANTASTIC!... But... they could have waited...

            It seems like an awful waste of our time to provide feedback, not to mention that it will probably just delay the issues there are already there further as someone at Atlassian will have to use time on the new ones just for registration and clarification...

            In any case..... I actualy wanted to comment on the Anonymous response to @JoshL (Who is a user not found... wtf? o.O... Guess that is another bug in a feature that could have waited?)

            Anyways, Some users will be happy, and you can boil it down to some things...

            They don't know better... 

            If you have only had experience with what is worse, then obviously the Confluence RTE is fantastic... If you been use to driving a old Rusty Bike, a Puch Maxi is the best driving experience you will ever have, when your use to that the upgrade to a Traband is AWSOME... What you realize along the way is that the Puch Maxi was actually Awfull, and when you go from the Traband to a Fiat you realize that the Traband wasn't all that great either...

            We had the same thing happening in house... Some developers hold so tightly on to ClearCase and ClearQuest because it was just awsome tools, their only reference was CVS, but just because CC and CQ had some better features etc. than CVS, didn't mean they where the best tools, but some here refused to believe otherwise... Then we switched to Rational Team Concert (Which by comparison to Git is still CRAP)... What all those CC/CQ evangelists realized was just how Crap CC/CQ was because RTC is miles better... Now they know that, but now RTC is obviously their new found love because they have only ever tried CVS, CC/CQ and now RTC... Some of us have tried SVN, Git, HG/Mercurial, TFS on top of that... and we Know that RTC is far from the best tool...

            I do know the feeling my self... I am having such a hard time letting go of Visual Studio/MSBuild, VS is a great IDE for .NET development and it even fairs very well in Web Development, but there are certainly tools like WebStorm etc. out there than competes overly well on the Web side of things... MSBuild is crap though, it is still hard to get out of my bones though, but grunt have somewhat replaced a part of it, and grunt is fantastic by comparison, grunt may not be the best thing ever for JavaScript, but it is certainly the best thing I have encountered for it so far...

            We don't like "syntax"... 

            Some people will always value the most Bugged RTE over any sort of syntax, we are inherently flawed in the way we write content weather we are Engineers, Tech Writers, Assistants etc... The ONLY ones who got it right is Book Authors... If your an author writing Novels, Thrillers or Mysteries, you make due with the most simple text editor there is, because you KNOW what matters, and that is not how the text stands on the page, it is the story... the content...

            The rest of us are just dumb fouls who doesn't understand what matters (Yes we are, even I am to focused on how things look, and I can't help my self when it comes to it)... But basically we are ever as clueless as we can be on exactly what is the best way to highlight a Quite, how to Emphasize, hell we even invented "bold" because we didn't understand "strong", "emphasize" as terms... but FAT FUCKING TEXT was very clear to us... And we cared little on what it meant to the reader, and we use it in all the wrong places... That is how dumb we are... Sometimes I actually Laugh at my self when thinking of these things...

            And that isn't to say that "how it looks" isn't also important, but that's what designers and layout specialists do, they know how the reader reads things, some of them are far more into how our brain works than we will ever be... So let them do their job and focus on yours... the content!...

            That doesn't make positive feedback wrong...

            On the contrary, there are some that think the RTE are the way to go... And we have to respect that they are out there... So @JoshL's positive feedback belongs here JUST as much as the negative, If he likes the editor as is, and doesn't have the same issues with it as many of the rest of us do, then MAYBE he writes more simple documents, doesn't use as many macros... MAYBE he uses a different workflow that doesn't strike as many as the issues as the rest of us run into... And ofc. there is also the possibility that over time he will face more and more things and in the end get tired of it...

            But no matter what, hes feedback about he likes it is just as important than anything else...

            And as I have said at some point before... Personally don't mind an RTE editor, if it is able to stay out of my way... Word and Word 365 are not one of those, nor is Google Docs... But those 2 examples are still light-years ahead of Confluence in terms of editor experience, and that says most about Confluence... No Offense...

            1. It's a long post, but we read them all Jens, and I appreciate your effort (smile)

              I'm really sorry you feel that leaving feedback is a waste of time. It isn't but I understand your frustration. Regarding this particular issue - I have moved the issue from our internal project to the externally accessible CONF project:  CONF-30493 - Make it more obvious when a macro placeholder is included in a text selection Open . You should watch the issue for updates and feel free to vote or comment to offer some words of encouragement (wink)

              1. Anonymous

                Paul, what about  CONF-24760 - Copy and Paste problems with list and macro selections. Open ? I filed that detailed bug report 18 months ago to clearly describe both the meta issue that we all had with the horrid copy/cut/paste behavior in the RTE back then, along with clear functional tests to show you what to strive for and how to test that you accomplished it. 18 months. And I've watch it sit either unattached to a fix version at all, or assigned one fix version, then later pushed to another fix version, then unassigned again, and on on on.

                This bug still clearly describes the MAJOR meta issue with the RTE today. All the specific things people cite, even the one that you just created a new bug for 10 minutes ago, are covered by this meta issue.

                Simple question to you or any of the PMs: do you EVER expect to fix this basic problem with the RTE, and if so, WHEN, exactly?

                And when are you going to fix or replace your seriously broken captcha? I'm on attempt 4 now. Really, it's been like 9 months that that brokenness has plagued us too.

                1. Hi Shannon, funny you mentioned that ticket actually, I was (re)reading thought it in detail today when collating some issues.

                  Not withstanding what I mentioned in reply to Jens, there are definitely some open tickets that are still not completely addressed, although small pieces may have been, and I believe this is one of them.

                  To give you, Jens, and others who've given feedback both good and bad I wanted to give some insight into the Editor team and what we'll be focused on during 5.3 and 5.4 -  improving reliability though expanded test coverage with a more intricate set of "day to day" use cases and fixing the bugs that these highlight.

                  Our current thinking is basing this around the new 'Blueprints' which include a number of key elements like macros, lists, tables, tasks, mentions etc and will extend into creating, editing, deleting, moving etc.

                  We already have a lot of automated testing for various things, but by picking some broader end to end scenarios I believe we'll be able to deliver a more stable editing experience in the real world - in particular it will help with the subtle changes that Browsers make which can wreak havoc for us (a recent Chrome bug with lists because they changed the way they use spans is a good example).

                  This is the reason I was looking at CONF-24760 actually, because I expect we should shake out quite a lot of the issues there in some detail, particular with it's emphasis on lists.

                  For anyone who does come across an existing bug, please do feel free to comment or vote on it, and if you hit something new, please raise it. Far from being a waste, knowing what people are impacted by most is invaluable for us when prioritising.

                  I really believe the Editor is in a much better place than it's ever been, but we can and are going to invest further in it's reliability, robustness and predictability, hence out focus for the next two releases along with our recent expansion of the dedicated Editor team inside of Confluence.

              2. CONF-30493 - Make it more obvious when a macro placeholder is included in a text selection (Open). You should watch the issue for updates and feel free to vote or comment to offer some words of encouragement (wink)

                Can you see the Irony in that response your self?... Created:12. Apr 2011 3:13 AM

                I honestly feel that you just helping me to prove my point. And with the fine release notes here: Confluence 5.2 Release Notes there are even more feature and feature improvements which properly took allot of time, time that could have been well spent on bugs...

                Examples:

                • Better Search?
                • Decisions blueprint?
                • Multiple layouts sections?... (I can't wait to see the countless bugs this will add)
                • Distraction free editing?... (What we also call gold plating, not to mention the title is clearly a lie, bugs are way more of a distraction than that toolbar ever was)
                • Smarter JIRA Issue Linking?...
                • Collaborate on the Go?...
                • ...

                Actually I will stop here... As you see the pattern... NON of the additions made in 5.2 can be seen more important to me than fixing all those long overdue Issues...

                And its really funny that you mention the following thing as a good thing you got out of moving from the WME/RTE combo to a single format:
                 

                massive improvement in feature development velocity,

                 

                Do you know that really brings a massive development velocity?... Working in a code-base that does not have thousands of issues you need to do workarounds for... workarounds that will take time to add, introduce new oddness in the code, and often also add new bugs, or become bugs when the root cause bug is fixed...

                I have tried the above, having a project with a huge backlog filled with bugs and then daring to change policy and go for a 0 defect policy... It was a costly process at the time where we did it, but the ROI was incredible...

                I'm sorry... But don't tell us that you listen, Don't tell us you care... Show us... Because as long as you don't show us, everything you say is just air... 

            2. Jens, thanks for the post. I want to echo Paul's comment that we do continue to read these and action things behind the scenes. I know there are a lot of seemingly untouched tickets, but we actually work internally in another project and I suspect quite a number of the open CONF tickets have actually been addressed, especially the older ones.

              For that reason I want to do a full review of them, and will commence shortly. Ongoing feedback is still very helpful as it helps highlight an existing issue that still exists and may indeed need it's priority raised.

              1. Anonymous

                (Shannon Greywalker) John, that's why I'm still here trying to fight the good fight even though my 500-user license is staying on 3.5.x and stopped paying maintenance entirely. Some day I would like to give the green light to upgrade to the newest version because there are tons of new features since 3.5 that I'd love to take advantage of. But right now it's impossible because I'd have the entire company up in arms if we upgraded. Trust me.

                Want more indication of financial impact? We stopped paying maintenance on JIRA/Greenhopper too, even though we'd love to take advantage of some new features there as well. We even would like to strongly consider using OnDemand for all of these products. But frankly, across the board, our faith in Atlassian to be responsible to critical issues that negatively affect us is quite low at the moment. To us, it seems you're far more interested in prioritizing new features than you are in fixing critical issues that affect mainstream workflow. Perhaps you need to allocate more budget to QA resources and prioritize more backlog bug tickets to be fixed in each sprint/release?

                And please, please, fix your broken captcha. It's beyond annoying.

                1. See my reply just above, I should have perhaps combined the two points into a single post.

                  I'll look into captcha, there was work done on it, but clearly not enough if you're still having problems.

                  1. Anonymous

                    yep, the number of my captcha re-entries went down from 4 per average to 2.  ONE should be possible ...

  26. Anonymous

    Paul: The RTE does NOT support copying and pasting as the prior posters have described. Have you personally tried to cut and paste a section of a Confluence page that scrolls to many pages? Me thinks you have not,....otherwise you'd agree and understand what has been described. There is also no method to do a Ctrl-F to find something on a page, but now I'm just echoing what others have been describing is one of the silliest problems with the RTE. WME was easy in that respect, and would allow searching.

    Something that irks me, is the description at the beginning of this page that says, "our customers love the new RTE",  and then a bunch of Twitter posts are shown. Come on, really? No one here that I work with uses Twitter. And yet, Twitter is the measuring stick used to see if all customers are happy with the decision to remove WME and use only RTE? Very skewed sense of reality.

    Paul: You're asking us to supply examples of how you can improve Confluence. Let me turn that around and ask you to take 60 minutes and read this whole thread. You'll find many many many examples, complaints, suggestions that we are experiencing every day. My colleagues are at their wits end when using Confluence without the Wiki Markup Editor. They don't have time to register a bug with Atlassian, and when it comes down to it, it's not their job to create an account, open a bug, and track whether it has been fixed or whether it will just sit there like all the other open issues regarding the problem with using the RTE, as opposed to the WME.

    I'll try to help you, look at these issues:

    1. macros take the entire horizontal width
    2. Edit/Remove popup. It covers my text while I am typing. I am forced to insert a bunch of white space to move it to the bottom of the screen. It is particularly annoying for me because of my extensive use of "numbered heading" blocks on pages that I edit- that means that all my pages are in a block, and so I see the edit/remove popup all the time.
    3. The new RTE is just to time consuming for me. I document in wiki markup, then transfer it to confluence, which works okay as long I don't ever have to edit that page again. If I do I am in for many a counter-productive minute struggling to not click in the wrong macro and muck it up. Undo does weird things at times and back spacing reeks havoc with bullet points, it's not a well polished product.
    4. Backspacing is a complete nightmare
    5. CONF-28561 - Confluence Page Layout goes FUBAR ( Open)
    6. What people don't realize was is that they will lose much more time fighting with an buggy RTE than learning a simple Wiki syntax.
    7. What would serve them well was if they allowed an "Bring back the Wiki markup" issue to stay open, and every-time people complained they said "Go Vote for it"... That would reveal just which camp was bigger.
    8. But what really bugs me allot is that they seem to spend allot of effort in putting new features in rather than actually resolving the bugs that has existed since 4.0 first arrived... Even the JIRA Team has is holding back on bringing in the new editor as they don't seem to see it as being mature: JRA-8943 - WYSIWYG / Rich Text Editor ( Open) ... And what does that say about it?
    9. Confluence has a habit of getting in my way though and making me spend hours fixing broken pages...
    10. This has got to be the most worst company for actually listening to their customers. Just check out how many bugs are either; quashed, deferred, closed and blamed on a 3rd-Party issue or out an out, just plain ignored.

    11. If you attempt to do much customizing, it is extremely difficult to troubleshoot and fix - macros take up too much of the vertical space making it very difficult to look at a lot of content on one page.
    12. we need it for much more complex tables, formatting, and image control to create the documents we started using confluence for.  Now, we are forced to attach as word documents and lose the collaboration and reuse capabilities that a wiki can provide
    13. The fact that you replaced vs added as another editing option is what seems to have been infuriating folks.
    14. It was much easier in the WME to control any types of formatting (font/style/weight/color), especially in tables; RTE is limited in the options provided.  Once you start to have an issue with formatting, especially in table content, it's nearly impossible to clear.  We have issues where we have copied content from one page to another and strange formatting comes across that is not in the original page.
    15. There are several bugs introduced in the PDF export that affect how tables and text display and wrap, table content, and image location.
    16. Trying to position text to the exact position that we want is very difficult in the RTE because so much vertical real estate is applied to the begin and end tags.
    17. We have issues where extra spaces get added between punctuation marks.  It's difficult to compress the vertical real estate and ensure you have the specific number of breaks between lines - the macros tend to input additional blank lines that we don't want.
    18. I try using the shortcut keys, but they are often ignored - in WME, I didn't have to worry about my h3, h4, or — being ignored.  Macros didn't just refuse to display when I inserted them - in the RTE, I can type these and they are treated as literal text or paragraph style, and macros you just input don't disappear.   It didn't take me multiple clicks to open a macro editor to change the properties.
    19. upgraded from Confluence v3 to v5,....there has been an immense uproar by everyone here. The common consensus is that Confluence is absolutely impossible to use now! The templates are of no use,..and the loss of the wiki markup editor has caused all of the stir.
    20. simple autocomplete for bullet lists do not seem to work consistently
    21. If only you could give all those other neat features without breaking the original native wiki syntax.
    22. there is no chance in hell that we'll be moving to 5.x any time soon. Not with the RTE and the PDF exports in the current buggy, clunky state it's in today.
    23. They simply can't understand just how important the wiki markup editor was!!! The wme was all that me and my colleagues used every day. Put simply, the new editor sucks! It is HORRIBLE!
    24. The "rich" text editor is not good enough to do the job on its own. It is buggy. Tables are a pain. It keeps mangling them, giving me no confidence that I can edit a document without destroying it.
    25. My company just migrated to the version (5.x.x), which took away the wiki markup editor. After experimenting with the new page editor,  I am giving up. Editing existing pages and adding is major pain. Inability to see content in its native format is another drawback.
    26. when I edit a "Content by Label" macro, the labels applied are missing from the macro parameters. Meaning that I have NO WAY of knowing, aside from my best guess, what labels were used to generate lists of content.
    27. In general, I find editing any pages that were converted over from 3.5 and included any use of macros is incredibly frustrating and a waste of my time. (Editing nested macros? Replacing an image in a page? UGH.)
    28. Removing the Wiki Markup Editor from Confluence,..is like Linux removing the command line interface,...can you imagine the uproar
    29. Trying to modify macros, and ESPECIALLY nested macros is a JOKE (read: impossible) without the wiki markup editor.
    30. We thought going from 4.1 to 5.x would be an improvement.... and we were half right and fully wrong. Some 4.1 bugs were fixed, and a whole slew of serious new bugs bit us directly on the sensitive parts.
    31. I miss the wiki editor.
    32. The ability to view the source of a page, select a section, copy it,..and paste to a new page. This was so easy to do with the WME,..and it is now impossible now in the latest version of Confluence. What used to take 2 seconds is impossible.
    33. The ability to quickly create a table via WME using the | symbols,....and the top row using ||,....again ridiculous that I MUST now use their table creation button,...or type {table  only to have it pop open a box asking which of the useless tables I want to use.
    34. The ability to view the source of someone's page as an example,..only to see deeply nested tables that are super ridiculous to understand.
    35. selection in the editor is still super buggy when you begin to have macros, and even when you manage to think you have the selection you wan't it ends up copying more than what you thought you had selected... On top of that it is far harder to hit the right selection in the "View Source" than the actual editor.
    36. when you view the source of a complex page,..and only want to copy and paste a small section,...it can be next to impossible to find that section.and,...Ctrl-F WILL NOT work in that window
    37. modifying a complex page,..meaning removing a small section was so easy and lightning fast with the Wiki Markup Editor,...however,....in it's present state,...if I try to do that,...I usually end of breaking sections or the entire page because I've modified or accidentally removed more than I wanted.
    38. You also don't seem to be able to insert a picture within a table,....something that used to work.
    39. you can no longer trust that you can find many types of things within Confluence pages any more when you need to to global revisions and global search and replaces. The basic Search box no longer finds everything, especially specific macros with specific parameters, or links that include syntax pointing to a target page in a different space. And it used to be that you could at least open up pages and use Ctrl-F within the wiki syntax of the page to find such things, but no more!

      I posted JIRA bugs on all this stuff more nearly 18 months ago, shortly after the move to 4.x, and I've seen no resolution of such bugs yet.

    40. cutting and pasting in the Wiki Markup Editor was for every user:
      • Fast
      • Easy
      • Simple

      Now,...it's:

      • Slow
      • Complex
      • Confusing
    41. Most were not given a choice to upgrade to the next version. And, once they were upgraded,..they took their grief out on the local Network Operations team that performed the upgrade. It happened here at this company. So, of the hundreds in this location, most has resigned themselves after complaining and misdirecting their grief. They ARE NOT happy users,...only beaten down and resigned to use what is forced upon them.

    42. have you also seen the age of some of the issues that are opened and still unassigned?? Have you seen the number of votes on these issues, and yet they languish?
    43. Just wish they add the Wiki Markup Editor back. I'm not asking for them to remove any other feature, nor make any other change,...just want the WME back......and NO, the RTE CANNOT do all things for all people.
    44. This bug was filed 18 months ago, describing the most "broken" aspect of the new RTE editor in exhausting detail. The workflow that this bug describes is one of the most common tasks in writing wiki content. 18 months, and the only action they've taken on it is to keep pushing back the fix version further and further. Or taking off the fix version entirely, just stranding the bug in the middle of no where. CONF-24760 - Copy and Paste problems with list and macro selections. ( Open)
    45. Every functional test detailed in CONF-24760 (reported in 4.1) still fails today in 5.2. 18 months later.
    46. Here's just one of the functional tests reported in that bug ticket that you can reproduce for yourself in 5 minutes to see why so many of us bitterly complain about the RTE editor even now, nearly 2 years after its introduction. THIS was a task that was dirt easy and intuitive with Wiki Markup in 3.5 and earlier. Now? It's maddening to work with any sort of page that comprises anything more complex than a simple set of headings and paragraphs.
    47. Macros in macros are far more difficult to select in the Source View because they are "clammed" together.
    48. Then there is the matter of "When do I have the macro selected, and when do I not have it selected"... This part is not obvious in the Source View nor the Editor.
    49. you keep power-packing the RTE with new features that only brings new bugs as well?
    50. the Page Layout thing, the overhaul in the design, workbox, likes and even freaking image borders was more important for Atlassian than fixing issues with the RTE.

     

    "Jens, thanks for the post. I want to echo Paul's comment that we do continue to read these and action things behind the scenes. I know there are a lot of seemingly untouched tickets, but we actually work internally in another project and I suspect quite a number of the open CONF tickets have actually been addressed, especially the older ones.

    For that reason I want to do a full review of them, and will commence shortly. Ongoing feedback is still very helpful as it helps highlight an existing issue that still exists and may indeed need it's priority raised."

    I say,...I'll try not to be sceptical,...but will wait to see what comes about from your review.

     

     

  27. Anonymous

    Clap. Clap. Clap. Clap. Clap. You rock. (to the Anonymous above)

    I want to specifically highlight the PDF issues mentioned in that list, too (Shannon Greywalker here again). The ONE thing that has kept us on Confluence 3.5.x all this time, and that keeps me here exhorting Atlassian to do the right thing, is that I have not found a single Wiki engine (yet) that does a multi-page PDF export as cleanly as your 3.5.x release does it. Even if you were to magically fix the RTE to solve the issues with everyday mainstream editing (as summarized well in the above list), I still would not give the greenlight to an upgrade until the multi-page export to PDF in 5.x or 6.x, lol, worked at least as well as in 3.5.x.

    It is critically important to a LOT of shops that you be able to produce clean, professional multipage PDF exports of wiki content. CRITICAL. IMO, you should spend the next 6 months fixing the PDF export issues with 5.x and fixing the RTE issues with 5.x and just not roll out any new features. You have no idea how much word of mouth from long-time Confluence users who were formerly evangelists (not any more, quite the opposite) are affecting your revenue. I think the community would cheer if you said "no new features for a while: we're going to put our noses to the grindstone and go bug-hunting for a while."

    1. Great 'summary' of the issues.  One critical business need is to generate documents from the wiki since the wiki allows us to utilize the include and excerpt include to create multiple types of documents from the same source.  However, the PDF export errors are numerous and we are now going to migrate to a new tool.  Yes, I report all the errors encountered; No, none of them have been resolved since the RTE introduction; yes, the most common response is 'well, we don't really support it because anyone can put anything in the stylesheet', and even though common CSS styles are input, but they do not work; yes, we are now having to look at other documentation managers because PDF export functionality is an extremely critical business function.  I concur with others in the fact that features, bells and whistles, continue to be introduced without focusing on making the existing features work - making the product much more stable and usable across all browsers (as they state it should).  Users would feel like they gained much more if existing items just worked as expected.

    2. Anonymous

      you won't have luck with your suggestion. Atlassian developpers want to have fun. That's what they said at their open house event. New features are fun.  Fixing bugs is not fun. That's why they so rarely fix bugs.

  28. For what it's worth, I still bump into a bunch of RTE bugs that I logged in 2011 when I go about my daily editing. Most of them are still issues, including the following which I retested today with Firefox 23.0.1 against Confluence 5.1.5.

    • CONF-24118 (it was marked as "Cannot repro". The top part is fixed, but I can still reproduce the bug listed with the "different sequence of operations" bit at the bottom)
    • CONF-24119 (there is still some sort of extra, invisible character between the superscript and non-superscript text that requires you to use the arrow keys twice to step over)
    • CONF-24292 (still broken - but now adds an extra bullet too)
    • CONF-24293 (marked as not a bug–I guess I can understand Atlassian's position, although this now means that WYS in the editor is not WYG. What if I want to leave an empty bullet to indicate that a list isn't done? Also, this impacts any list anywhere in the page, not just those at the end of the document.)

    I just now filed a new one:

    • CONF-30497 (for an editor issue that has been bugging me for months)

    ...but I admit that having a non-public background project for doing the real development work certainly tempers my enthusiasm for filing new issues. Assuming that this is expected to continue, is there any chance of getting some sort of automated process set up (like with remote issue links and some fancy scripting) so that the public issue tracker can be kept in sync with the real development status?

    Otherwise, it's difficult for stakeholders to know where things stand. If a publicly-filed issue was fixed in the private issue tracker, but it never had its public status updated, and it then gets re-broken in a subsequent release, nobody will be the wiser and the poor issue reporter will think that his/her issue was simply ignored.

  29. Anonymous

    No direct response regarding the concise list of issues!

    and let's not get distracted gentlemen,....the heart of the issue is the removal of the wiki markup editor.

    In my honest opinion,..if the WME was left in the product,..I don't believe more than 1/2 the issues described above would even be a concern. Why,....because almost no one would be using the RTE at all.

    I can just see everyone reading this and shaking their heads up and down in total agreement.

    P.S. I can see that even the assertion that the Capcha has been fixed, is a fairy tale. I'm on my 5th word now.

     

  30. Anonymous

    No direct response regarding the concise list of issues!

    and let's not get distracted gentlemen,....the heart of the issue is the removal of the wiki markup editor.

    In my honest opinion,..if the WME was left in the product,..I don't believe more than 1/2 the issues described above would even be a concern. Why,....because almost no one would be using the RTE at all.

    I can just see everyone reading this and shaking their heads up and down in total agreement.

    P.S. I can see that even the assertion that the Capcha has been fixed, is a fairy tale. I'm on my 5th word now.

    now, it's seven tries

     

    1. No direct response regarding the concise list of issues!

      Thank you for taking the time compiling that list. We do already have them all tracked though in our JIRA instance. (It's a tool well suited to tracking issues (wink))

      It may be worth me re-iterating here that the old wiki markup editor will not be coming back to Confluence. There are various reasons why we continue to believe we have made, on balance, the correct decision with our switch to RTE only but I fear that listing them here would simply lead to a continuation of a fruitless argument.

      We do recognise that the RTE needs more development, and we have a core team (which we continue to expand) who are dedicated to fixing and enhancing the RTE. So please do continue with the feedback - it is always heard and always recorded.


  31. Anonymous

    "Paul Curren [Atlassian]

    The 'view source' facility was designed right from the inception of the XHTML/RTE work to support the exact work-flow you describe (as Matt is explaining). It renders a slightly tweaked version of the page which is suitable for copying and pasting into the RTE. The biggest difference you will notice is in the rendering of macros.

    So if this facility isn't working for you we would be very interested in hearing how we can improve it. It only has one purpose and if it isn't serving it then it needs to be addressed."

    This facility (RTE) is not working for me (us).  It is NOT serving its purpose. One only has to read this entire thread for examples how you can improve, make that restore functionality.

    Yes! I'm going to say what you expected,...give us back the Wiki Markup Editor.

    All I know is that if my company (yes, it's a software company) received the amount of grief Atlassian is receiving for removing functionality (removed the WME),.....someone here would surely be held accountable, and the problem would be addressed. We care about our customers and their opinions. They pay the bills,..they pay my salary.

     

    1. Anonymous

      The problem with this is that we're keeping the conversation in their nice little walled garden where nobody else will ever see it. If you really want to foment change, take your discussion to the world. Share how poorly Confluence works now with as many people as you can so that when people search for "Confluence", they see in the SERPS all these problems, front and center.

      Despite their promise not to, they have obviously launched the RTE far before it was even usable for a great many needs. All sorts of usability bugs remain unaddressed...and for some people, these make it impossible to even use for its intended purpose.

      Let's help the world see that Atlassian doesn't even abide by it's own promise to be a no bullshit company, and how it abrogated its pledge to not release the RTE before it's ready, etc...

      Keep the conversation going, on more and more channels. The day that Atlassian has to deal with the repurcussions of its decision publicly...The day that they have to defend their decision on StackExchange, or in Slashdot, in a twitter feed...that is the day you may start to see change.

      Until then, you're nothing more than a simple marketing problem that can be dealt with by spending a couple minutes of a marketer's time every day.

      -Anon

      PS: Would you really trust a company that can't get it's CAPTCHA to work correctly with your critical corporate infrastructure?
      Take 2 on CAPTCHA
       

       

    2. All I know is that if my company (yes, it's a software company) received the amount of grief Atlassian is receiving for removing functionality (removed the WME),.....someone here would surely be held accountable

      What if your software company received negative feedback from less than 1% of it's existing customers? And the rest were either silent or positive. And on top of that, the customer base continued to expand?

      Now to qualify that -

      1. I plucked the number 1% from the top of my head - it's a hypothetical statement after all, designed to bring some reason to the argument (smile)
      2. This does not mean we ignore or disregard the unhappy customers. It is not our goal to disappoint.

       

       

      1. Anonymous

        (Shannon Greywalker here)

        Paul, I think you're overlooking four important things regarding your comment above:

        • Every one person posting feedback in this thread is probably the Confluence point person for their organization. For example, I represent a 500-user license. My comments are based on how my enterprise feels.
        • This feedback thread was always somewhat hard to find, and is especially hard to find now that it's buried under an old 4.x heading instead of being more prominently located under a 5.x parent.
        • A lot of shops with Enterprise licenses are slow to upgrade. I have colleagues in Texas and California that are still on 2.x. You have to remember that IT admins and most business users think like "if it ain't broke, don't fix it.". This is why we still see fresh outrage here in this thread, 18 months after 4.x was first released. Somebody finally upgraded (or moved to OnDemand) and realized to their dismay what they're dealing with now.
        • Word of mouth among the types of people who are typically responsible for evangelizing, setting up, and maintain/promoting Confluence does not flow through Twitter and Facebook. If that's your pulse check, that's a big problem, IMO.

         

        1. Hi Shannon.

          I fear discussing this too much further will annoy you and the other commenters further than you already are, and I don't want to do that. I'll give it a try though - please don't consider any offence I might cause as intentional! (smile)

          For my hypothetical example I should note that internally we count 'customer' as a license purchaser. So while the 500 unhappy users you represent is a significant and disappointing number, it still represents a single customer in our sales/renewal figures.

          The main point I want to re-iterate though is that a wiki markup editor will not be coming back as a core part of the product. It's possible that a partner or plugin developer may implement something but we won't be bringing it back in the core Confluence product. I don't re-state this to annoy, just to try and save us all time and effort. Hearing everyones feedback here is vital however requesting the return of wiki markup is fruitless.

          Moving to a single editor has provided us -

          • massive improvement in feature development velocity,
          • an increased range of features we can consider implementing (e.g. we would never have implemented Page Layouts if we had to support wiki markup and round-tripping between formats, nor task lists)
          • massively reduced the number of bugs we had (and would have continued to introduced) around round-tripping between editable HTML and wiki markup)

          We know (largely thanks to the efforts of the people on this page) of a large number of bugs in the Rich Text Editor. In most cases these bugs were already present they just weren't so painful because people with the necessary know how could avoid the editor, or switch to wiki temporarily to fix the problems. We need to fix these bugs. Fixing the bugs has become easier, but is still not trivial. There are quite a range of differences in how Chrome, Firefox IE (8,9,10) and Safari implement HTML editing and each fix needs to work across these cases. We no longer need to ensure that the same fixes work across round-tripping and wiki markup.

          1. Anonymous

            (Shannon) No worries, Paul. I understand the business/product mgmt rationale even if I don't agree with it or agree with the so-far prioritization of new features over bug fixing of core workflow issues.

            Honestly, I don't care about the speed of WME versus a Rich Text Editor. I would be happy to greenlight my enterprise to move to some future version of Confluence IF you could actually make the editor do one simple thing:

            • Support all the same basic editing, search, and revision workflow that the WME could support.

            That's it. That's all that MOST of the people coming here to give negative feedback are really asking for. 

            IMO your product managers for Confluence are focused on the wrong priorities. Your reputation is bleeding because of it. Make the new editor support the same editing, search, and revision workflow without serious and unfixable bugs like you currently have, and you'll see this thread quiet down and eventually word of mouth among doc professionals and wiki consultants will improve again.

            And ya, Captcha and login authentication is still pretty broken. That's why I don't even bother trying to log in any more to post these.

             

            1. We are on 4.x and now 5.x for 18 months now. (On 5.2.3 now)

              We can assure you that:

              -- the RTE has lots of bugs, including bugs that have been in it since 4.1

              -- The overall regression rate (not editor per se, but also export related) has been high and painful to us , and we are a small team, using a smaller subset of features than a larger org would.

              -- Essentially the entire Atlassian position ultimately amounts to a kind of smokescreen. There are macros available that:

              -- prevent pages from migrating to xhtml  (oh, how I wish I had them in place before we went to 4.1!)

              -- keep pages in wiki markup mode forever, so you can use plain wiki markup

               

              But there is no macro that makes the RTE as fast and issue-free as the old WME.... 

          2. Atlassian would help itself greatly if it would stop talking about "round trip issues" and related.

            I bet almost none of us care. For example, my org doesn't need to flip back and forth between rich edit and WME. It would be fine to force a user into one mode or the other (or to only allow a switch if there was no edit).

            There are aspects to Atlassian's position that focus on the most complex flow. WME centric users would be happy to lose features in order to keep WME (and with the wiki macro, we do just that!).

          3. Anonymous

            I would MUCH rather see Atlassian fixing the existing bugs, both the RTE and the PDF export, than continuing to provide these 'rich features' you are providing. However, things like Page Layouts doesn't save anyone time if they know sections and columns as a workaround – yes, it is cleaner; but, for us, is still quite limiting as you cannot copy and paste entire pages with the layout in tact. You have to copy all the individual sections individually.  With sections/columns with markup, it was VERY easy - no mistakes of hidden macros.  With the current RTE, you can at least attempt it with some luck. 

            So, I would gladly give up all your velocity on these new features because if bugs are fixed, we'll feel like we have new features because we can actually start using it!!!!

      2. Anonymous

        I don't recall getting the wiki markup removal satisfaction survey.  How are you measuring satisfaction in regards to this change?

        1. There is no point talking about methodology. The only thing that matters is:

          There is a very upset core of users, and this core may be growing with time (as older sites, which are by definition happy with the old platform \[or they would have migrated earlier\], migrate)

  32. Shannon and all:

    We upgraded to v4.x in May of 2012. (And have been on 5.1 for several months, and just went to 5.2.3)

    We continue to live in severe pain from the lack of wiki functionality.

    I can tell you: The pain does NOT go away. In certain areas it gets worse over time. We make heavy use of wiki sections in documents that keep wikitext in place. Many of us no longer take notes in atlassian and use text editors instead (and then we drop it into a wiki text block in confluence). There are many other pain points.

     

    Atlassian is unable to absorb the huge impact this has on customers, and insists on rejustifying themselves over and over. Part of how they do this is to say "hey, lots of people like it!"

    We aren't arguing with that.

    We are saying: Atlassian, figure out a path to the benefit that does not impose pain on users who used to love you.

    We all want to keep loving Atlassian. But after an experience like this, Atlassian can no longer be trusted as a company (why adopt and depend on a feature from Atlassian that they are so willing to yank?). (We rejected hipchat purely because it is an atlassian product, and we don't feel we can trust Atlassian to look out for our interests.)

  33. I've raised another bug against confluence for copy and paste issues within the editor resulting in a difference between what the editor shows and the final markup of the page (there now appears to be hidden macros that I can't see in the editor).

    If I was able to change the source I could fix this myself (and I'd have been copying and pasting source between pages so it wouldn't have happened in the first place). But I can't.

    CONF-30674 - Copy and paste from one page to another creates hidden macros Open

    We're yet another large organisation dissatisfied with the inability to change pages through the source - sure, for most users, for most of the time, the rich text editor mostly works fine, but when you hit a corner case, you're absolutely stuffed, far more so than ever before.

  34. Anonymous

    Paul Curren:

    "Moving to a single editor has provided us -

    • massive improvement in feature development velocity,
    • an increased range of features we can consider implementing (e.g. we would never have implemented Page Layouts if we had to support wiki markup and round-tripping between formats, nor task lists)"

    Ahhh,..the old "development velocity" excuse. As with all measuring and reporting tools,..they can be tweaked or "adjusted" to be whatever the management team is looking for as an example that their team is doing their job.

    A great example fro this article: http://www.infoq.com/news/2009/06/measuring-hyper-productivity

    "Roy Morien added that it is very difficult to measure personal or team productivity mathematically. Hence, instead of trying to achieve the measurement part, teams should focus on delivering useful, working software and try to improve on what they did in the last sprint.

    On similar lines, Adam Sroka mentioned that instead of wasting time in measuring productivity effectively and analyzing whether the teams have reached the hyper-productive state, teams should focus on the following

    1. Are we delivering working software that is valuable – continuously, every iteration?
    2. Are we expending effort in a manner which is sustainable? Can we continue to deliver at this pace indefinitely? Can we improve?
    3. Are we wasting effort on things which do not contribute directly to the delivery of value? How do we eliminate such waste?"

     

    Paul: Are you really going to tell us that you believe the Page Layouts was something to mention as a "shining star" example of something useful added to the product since the WME was yanked!?!?!?! You must be kidding right? The Page Layouts are a complete waste of time! No one here uses them,...and they actually asked if there was a way to disable that from showing up since it waste people's time.

    and again,...you try to explain away the people who ARE complaining and asking for the WME to be brought back by stating that we are the 1%ers. How ignorant! I am grateful to Shannon for calling you out on this!!! Reread her response to your comment!

    I'd also counter your confidence that you seem to believe you have a 99% approval rate, by takign a hard look at this thread. As Shannon stated,...this is buried in the 4.x area,...AND YET,....I see new people finding this thread,..and posting their comments. Perhaps you think that all those anonymous posts are from the same person,....how sad if you did.

    And to your assertion that (and I'll paraphrase) "our developers simply couldn't keep maintaining two different formats, RTE and WME". OH Please! Give it a break already,...as the other poster above stated,...if you had left the Wiki Markup Editor in,....all these complaints and issues would go away.

    By the way,..just because you get no feedback for the large majority of Confluence users DOES NOT mean they are content happy campers.

    I can't wait until slashdot, or one of the many other blogs pick this debacle up and run with the story. Maybe then you'll understand just how unsatisfied the vast majority really are.

     

     

     

    1. And to your assertion that (and I'll paraphrase) "our developers simply couldn't keep maintaining two different formats, RTE and WME". OH Please! Give it a break already,...as the other poster above stated,...if you had left the Wiki Markup Editor in,....all these complaints and issues would go away.

      That's not the case Anon. There were an immense number of bugs (and support cases) stemming from a user editing the page in the RTE and completely ruining the page that had been carefully crafted by an author using the wiki editor. We call these 'round-tripping bugs' as the page needs to round trip from wiki to HTML and back to wiki.

      One choice we could have made was to remove the rich text editor and only have wiki editing in the product. This would have completed eliminated round-tripping bugs but would not have been a clever choice for Atlassian to have made.

  35. Anonymous

    Here's some responses to, what was supposed to be a positive article, about Confluence:

    https://news.ycombinator.com/item?id=3929935

    We (25 people company) use Confluence, and we all truly hate it. The design is attrocious. It's ugly beyond the pinnacle of ugliness. We tried to use some custom styling to ease the pain, but Confluence uses so many badly designed elements that we had to capitulate.

    ---------

    If this incredibly crappy product sells itself, then it's only because there is nothing better. If you don't know what your next company should do - please consider creating a better corporate wiki. Confluence is truly an abomination.

    -----

    Amen. Last time I used it, it was a mess beyond belief. Code intermingling with presentation layer. Dependencies upon dependencies. A case study of bad software engineering.

    -----

    They recently removed wiki formatting from their wiki in JIRA. If you want to edit a page you have to use their in-browser rich-text editor.

    This (on top of a bunch of other friction I have with JIRA) makes it clear to me that JIRA is not a product they're building for hackers. It must be for program managers, or for check writers at enterprise companies.

    -----

     

    So Paul: How much more googling do we have to show you before you get it! My prediction is that the Wik Markup Editor WILL be restored into the product.

    on my 7th captcha now

    1. Anonymous

      (Shannon Greywalker here) I'll add that 15 months ago, in January of 2012, is when I first learned of the 4.x removal of the wiki markup editor. I discovered it when doing routine smoke testing prior to an IT-scheduled upgrade from 3.5.x to the latest version. Naturally, I threw up red flags and prevented our usual upgrade process. We're still on 3.5.x and stopped paying maintenance long ago.

      Point being, 15 months ago when I entered the "feedback discussion" here, There was no "Open company - no bullshit" statement in the feedback thread. That came very shortly after I entered the feedback fray. My immediate response at the time was to search twitter and point out that out of the many #confluence and #atlassian tweets, very few were positive. A far greater percentage were negative. I continued to monitor Twitter myself on and off for the next 5 months and never, ever, EVER saw any indication of a majority positive response. Quite the opposite. The great majority (of the very few tweets, really, given the time span) were negative.

       

      Just entering that into the record since my original feedback post here long long ago about the same thing has long been "cleaned up".  Long story short, there is in fact a lot of whitewashing that's been continually going on this thread.

      1. Anonymous

        th quoted article regarding Atlassian and Apple tells on the 2nd page that Atlassian is quick to respond on feedback and fix issues quickly.

        Not my experience. (look at the list of open issues in their Jira, some are unresolved since 2006)

        and as the most popular example  (no, not the wiki) - the capcha - on their on web pages. They don't even turn it off as they obviously can't fix it.

         

        1. Anonymous

          ...the captcha - on their web pages. they don't even turn it off as they obviously can't fix it.

          Careful, anon!  Atlassian is likely to see this, proclaim how much users love it, and insist that it will never be changed.

      2. Anonymous

        It is obvious that Atlassian would rather sanitize the truth and manage perception than simply be who they say they are. 

        • Still can't get reliable PDF generation out of anything past 3.5.
        • Still can't use WYSIWYG editor (which they released, despite their pledge not to, well before it was ready).

        Atlassian listens?  Fraid not.  They're doing for Confluence what Balmer did for Microsoft.  And they are damn proud of it.

        For the record, I have not heard a single positive response to the change from anyone who has gone through it...except for those that appear on this page.  Professional groups, nothing but bad experience...  I wonder just how they are collecting their feedback?

        -Anon 

        Capcha x 2


         

    2. Anonymous

      >> My prediction is that the Wik Markup Editor WILL be restored into the product.

      No way.

      Atlassian has spent 2 years or so promising WME is dead and gone.

      Some promises are kept.... this is probably one of em.

  36. Anonymous

    Appears Slashdot is covering this story: http://slashdot.org/submission/2941791/atlassians-confluence-debacle-and-the-fallout-from-users

    I'd suggest giving the story a +

    I'd also suggest post to twitter and facebook and any other media venue.

    1. Really - does this kind of anti-vendor rhetoric belong on a page like this? When I see stuff like this posted by "Anonymous", my impression is that Atlassian's competitors are concerned and launching attacks against the company. If you're going to publicly lobby for change, could you own up to it and preach the message clearly on your own site?

      1. There is a problem when a company says "we are the greatest, most customer-focused company" and then does something that even a small % of users feel is strongly anti customer.

        Removing a core feature (a defining feature, in fact), breaks the implicit customer contract: "We have a feature. Learn to use it. Embed it into your lives, and we, as a software company will take care of you as you invest your time and $ in our product."

        This whole issue is completely of Atlassian's making, as they made the choice to yank the feature. They had lots of choices (they could have kept the feature, degraded the feature, deprecated the feature, etc etc) but instead they yanked it and promised there would be no pain.

        So we feel pain, and it is a double bad on Atlassian (first the yank, and then the pain, neither of which is expected by a customer).

        Then it is a triple bad when Atlassian tries to explain it away "We couldn't handle the round trip problems" (not my problem! so degrade the feature and make round trip go away!) "Everyone loves it" (not relevant.) "We will fix any bug in the RTE" (not relevant, and worse because it has not been true so far.) "The product is moving faster now" (not relevant, not our problem, not necessarily good given the # of regressions I have observed).

        Bottom line: We, customers/users, experience pain.

        Instead of helping mitigate the pain, or even acknowledging the pain, Atlassian blames us for feeling pain.

        Such an environment poisons the well of good faith/good feeling.

        The world needs to know this story so they excersize huge caution before doing business with Atlassian.

  37. Anonymous

    I love how JoshL tries to shift the focus away from the validity of the customer's arguments by claiming, "well, this must be Atlassian's competitor". Hmmmm,..what's the matter hitting a little close to home.

    I read the article,...and I think it's spot on! JoshL: Instead of accusing all "anonymous" posters as "working for the other side", why don't you try to refute each point made. It's also very easy for us to accuse you of being someone that works for Atlassian, or of having close personal interests, say a spouse or family member that works for them.

    samjones6: You hit the nail on the head! We as customers, pay the salaries of this company. We have the right to ask for something we've found useful and which makes us productive when using Confluence. We also have the right to complain when things are broken, especially when the replacement tool is horrible and full of bugs.

    As a software professional myself, we would never remove one tool and replace with another and make the customers accept it cold turkey. We would introduce the new tool and then once the honeymoon was over,..say 2 releases later, only then would we deprecate the old tool.

    The route Atlassian took,...essentially makes us, the customer, their Quality Assurance team. You can't tell me that the Real Time Editor was fully tested that:

    • it provided the same functionality that the WME provided
    • it has no High Severity bugs before shipment
    • it was regression tested
    • it was sanity tested
    • it was unit tested
    • it was customer focus group tested

    I bet there's someone on the Atlassian QA team that threw up their arms when they started testing the RTE as the WME editors replacement. I bet they were extremely frustrated and wanted to sound off that this was a stupid move. I know, because I've worked for a few software companies that did the same thing, and I was that QA Tester wondering for the Product Manager was that decided to do something this stupid. and yes, I sucked it up and did my job, and got my paycheck, and heard customers complaining just like everyone here is doing. That is until I left that company once I found a better one.

    A good company doesn't mind criticism or complaints. That is how they listen to their customers so they can make the product better. The changes they make are not for themselves, it's for the customers. After all, they use the product. So when representatives say that they needed to make the job of the developers easy, but at the same time penalize the customer by removing a critical functional tool, well, that is something that SHOULD enrage every customer.

    and yes, I sign this Anon, I have that option, and I use it.

    As Shannon stated, it's more of a pain to sign in, and then the captcha doesn't even work correctly.

     

     

     

    1. Anonymous

      (Shannon Greywalker here) I was always happy to sign in despite the broken, annoying captcha issues, but at some point in the last few months Atlassian broke my old logins for Confluence and Jira. I can't even check on all my JIRA tickets now. Yet another way in which Atlassian seems to act like cowboy developers instead of like enterprise application developers. I would expect that if they did some recent move like a merging of separate logins to an SSO login across all Atlassian sites/services, I'd have received some email notice or at least would have that made clear upon first attempt to log in after such changes. Nope. Just like the sudden removal of WME in 4.x

      1. Anonymous

        Thanks for correcting me on the signing in part.

        Love your "cowboy developers" reference. I KNOW EXACTLY what that is. I work with them, and if you don't rope them in, they'll do what ever they want. They'll switch from svn, to git, to whatever source control is the flavor of the month, all without test trials or server/network implications. They'll pull features that they don't see as being important, and they'll commit code with amazing amounts of code churn, even though there's no time left to formally test. They'll ignore/close enhancements they don't like, and waste time arguing the finer points of the Unix/Linux/Windows never-ending battle.

        Cowboys, yup!

        5th captcha

      2. Anonymous

        Thanks for correcting me on the signing in part.

        Love your "cowboy developers" reference. I KNOW EXACTLY what that is. I work with them, and if you don't rope them in, they'll do what ever they want. They'll switch from svn, to git, to whatever source control is the flavor of the month, all without test trials or server/network implications. They'll pull features that they don't see as being important, and they'll commit code with amazing amounts of code churn, even though there's no time left to formally test. They'll ignore/close enhancements they don't like, and waste time arguing the finer points of the Unix/Linux/Windows never-ending battle.

        Cowboys, yup!

        5th captcha

      3. Anonymous

        Thanks for correcting me on the signing in part.

        Love your "cowboy developers" reference. I KNOW EXACTLY what that is. I work with them, and if you don't rope them in, they'll do what ever they want. They'll switch from svn, to git, to whatever source control is the flavor of the month, all without test trials or server/network implications. They'll pull features that they don't see as being important, and they'll commit code with amazing amounts of code churn, even though there's no time left to formally test. They'll ignore/close enhancements they don't like, and waste time arguing the finer points of the Unix/Linux/Windows never-ending battle.

        Cowboys, yup!

        5th captcha

        10th

        15th

    1. Anonymous

      For those that don't have time to check out slashdot, here's the comment:

      "You just expressed our sentiments perfectly. We (Fortune 100 company) are at a loss as to Atlassian's complete and utter disregard to what their customers want, and what we are begging for. Sure, I think everyone can understand that creating a software product is difficult and expensive. Then add the cost of maintining it, supporting it, and hopefully improving it. The cost can be staggering. But so what, that's nature of the business. They're acting as is they just realized these things. Then they have the GALL to try to broadcast that they're the best in breed, best in customer satisfaction, best in employee stisfaction, best in jump rope, etc. However, and as the article states, the whole reason for creating, maintaining, supporting and improving is for the customer! I am puzzled as to why they would remove a tool used in the product and replace it with soemthing that is less than ideal. Most software companies go to extremes to offer new ways to use their products. They usually add tools,...not remove them altogether. Can't see Microsoft stopping you from using options when creating an e-mail in Outlook. You're given the choice to create an e-mail using; Plain Text, Rich Text and HTML. They also allow the use of custom templates (stationary). If they removed any one of those options, there would be a similar uproar. We also use Jira and I'm beginning to wonder what functionality will they remove from Jira so it make the developers jobs easier. Boohoo them. Someone over there should get a pair of cahones and do the right thing for us, the customer!"

  38. Anonymous

    Well Ladies and Gents: We are another company that just upgraded from 3.x to 5.x and are in the midst of an avalanche of complaints over the missing wiki markup editor. You might ask, didn't they test this out and notify the masses. Yes and yes. The reasoning was that atlassian was no longer going to support 3.x, but especially for the supposed security updates. I am one of the sheep that came in on monday and found the upgrade version now in place. I'm confused by the new templates. Are they supposed to actually help us do our jobs? Not only are they confusing, but they stuff the new pages with things that need to be stripped out before it can be used. You waste more time doing that than creating a new page from scratch. One of the biggest complaints has been "where is the wiki editor". I'm not talking about a few people. I mean better than 90% had been using that exclusively. All these complaints fell on deaf ears with our upgrade team. Their job was to perform the successful upgrade. So then who can we turn to with these complaints. It took me days to find any type information regarding what other companies have done after this upgrade. Then I found this thread, and a few other blogs where people are or have experienced the same pain. I spent all of last night reading this thread as well as the other blogs. I have already sent an e-mail to let every here know about this thread. My conclusion, I am shocked, but at the same time, I thought this was a joke. I could not believe atlassians stance and remarks to their customers. How do you remove such a critical tool that we use every day to be productive when using the product. Every day since monday, people here have either stopped using confluence, or they are trying to use the new tool and only end up breaking the existing pages. We used to have 100's of new pages created every day. Since monday, only 10 new pages have been created. From what I have been reading last night, it seems that we are not alone in our misery. I am hoping that someone at atlassian can talk some sense and they can see this from our point of view. I wish they would send a rep out to see first hand the anger and utter frustration.

    1. Atlassian has made it very clear that they don't care what anyone on this thread thinks or feels.

      Get the slashdot thread voted up, to help others avoid this issue 

      http://slashdot.org/submission/2941791/atlassians-confluence-debacle-and-the-fallout-from-users

       

  39. Anonymous

    Wiki Markup is the reason we found a wiki useful for in the first place.

    Now that wiki markup is gone from confluence, let's consider the alternatives:

    For WYSIWYG editing, well, pretty much any word processor (word/google docs/whatever) beats the sh*t out of confluence.

    For raw source editing of HTML/XHTML/XML, well, pretty much any editor (sublime/vi/emacs/whatever) beats the sh*t out of confluence.

    At this point, i can only see two possible outcomes from this:

    1) Atlassian faces up to the fact that they made a bad decision, listens to their users and re-introduces WME, even if it means there has to be extra work done behind the scenes.

    or...

    2) Users like me will find another wiki that does what we need it to, and we will never, ever, ever again consider an atlassian product again because we know we will be burnt.

    I have now waited almost three years for the first to happen, my hopes are not high.

    1. Anonymous

      Exactly! I think some of these companies get a big head. They create an initial good product, get a substantial customer base, and then they lose their minds and think they know better than the customer.

      I'm at a loss as to WHY they would remove the Wiki Markup Editing tool, and replace it with,....well..nothing.

      and NO you can't tell me that the Real Time Editor is a replacement! It's another tool that's all,...and a pretty crappy one to boot. So now,...they won't add the WME back because they think they'll lose face. Actually, I'm being too nice,..I think the real reason they won't add it back is because they're a bunch of dump asses.

      If they did add the WME back,..I'll be the first to shout the loudest that Atlassian is a great company and that they listen to their customers,...but as I said,....they're all dumb asses.

      1. Anonymous

        now now, let's keep our anger civil. no need to tick them off so they won't return the wme out of spite.

        I am also wanting the wme back in confluence.

        It sure seems that atlassian is turning a deaf ear to all of these requests. I think if I produced a software product and my customers were dependant on a tool, I would never remove it. I might add an additional tool, but certainly not remove one.

  40. Anonymous

    There's still these issues which were never addressed, besides the removal of the Wiki Markup Editor:

     

    1. macros take the entire horizontal width
    2. Edit/Remove popup. It covers my text while I am typing. I am forced to insert a bunch of white space to move it to the bottom of the screen. It is particularly annoying for me because of my extensive use of "numbered heading" blocks on pages that I edit- that means that all my pages are in a block, and so I see the edit/remove popup all the time.
    3. The new RTE is just to time consuming for me. I document in wiki markup, then transfer it to confluence, which works okay as long I don't ever have to edit that page again. If I do I am in for many a counter-productive minute struggling to not click in the wrong macro and muck it up. Undo does weird things at times and back spacing reeks havoc with bullet points, it's not a well polished product.
    4. Backspacing is a complete nightmare
    5. CONF-28561 - Confluence Page Layout goes FUBAR ( Open)
    6. What people don't realize was is that they will lose much more time fighting with an buggy RTE than learning a simple Wiki syntax.
    7. What would serve them well was if they allowed an "Bring back the Wiki markup" issue to stay open, and every-time people complained they said "Go Vote for it"... That would reveal just which camp was bigger.
    8. But what really bugs me allot is that they seem to spend allot of effort in putting new features in rather than actually resolving the bugs that has existed since 4.0 first arrived... Even the JIRA Team has is holding back on bringing in the new editor as they don't seem to see it as being mature: JRA-8943 - WYSIWYG / Rich Text Editor ( Open) ... And what does that say about it?
    9. Confluence has a habit of getting in my way though and making me spend hours fixing broken pages...
    10. This has got to be the most worst company for actually listening to their customers. Just check out how many bugs are either; quashed, deferred, closed and blamed on a 3rd-Party issue or out an out, just plain ignored.

    11. If you attempt to do much customizing, it is extremely difficult to troubleshoot and fix - macros take up too much of the vertical space making it very difficult to look at a lot of content on one page.
    12. we need it for much more complex tables, formatting, and image control to create the documents we started using confluence for.  Now, we are forced to attach as word documents and lose the collaboration and reuse capabilities that a wiki can provide
    13. The fact that you replaced vs added as another editing option is what seems to have been infuriating folks.
    14. It was much easier in the WME to control any types of formatting (font/style/weight/color), especially in tables; RTE is limited in the options provided.  Once you start to have an issue with formatting, especially in table content, it's nearly impossible to clear.  We have issues where we have copied content from one page to another and strange formatting comes across that is not in the original page.
    15. There are several bugs introduced in the PDF export that affect how tables and text display and wrap, table content, and image location.
    16. Trying to position text to the exact position that we want is very difficult in the RTE because so much vertical real estate is applied to the begin and end tags.
    17. We have issues where extra spaces get added between punctuation marks.  It's difficult to compress the vertical real estate and ensure you have the specific number of breaks between lines - the macros tend to input additional blank lines that we don't want.
    18. I try using the shortcut keys, but they are often ignored - in WME, I didn't have to worry about my h3, h4, or — being ignored.  Macros didn't just refuse to display when I inserted them - in the RTE, I can type these and they are treated as literal text or paragraph style, and macros you just input don't disappear.   It didn't take me multiple clicks to open a macro editor to change the properties.
    19. upgraded from Confluence v3 to v5,....there has been an immense uproar by everyone here. The common consensus is that Confluence is absolutely impossible to use now! The templates are of no use,..and the loss of the wiki markup editor has caused all of the stir.
    20. simple autocomplete for bullet lists do not seem to work consistently
    21. If only you could give all those other neat features without breaking the original native wiki syntax.
    22. there is no chance in hell that we'll be moving to 5.x any time soon. Not with the RTE and the PDF exports in the current buggy, clunky state it's in today.
    23. They simply can't understand just how important the wiki markup editor was!!! The wme was all that me and my colleagues used every day. Put simply, the new editor sucks! It is HORRIBLE!
    24. The "rich" text editor is not good enough to do the job on its own. It is buggy. Tables are a pain. It keeps mangling them, giving me no confidence that I can edit a document without destroying it.
    25. My company just migrated to the version (5.x.x), which took away the wiki markup editor. After experimenting with the new page editor,  I am giving up. Editing existing pages and adding is major pain. Inability to see content in its native format is another drawback.
    26. when I edit a "Content by Label" macro, the labels applied are missing from the macro parameters. Meaning that I have NO WAY of knowing, aside from my best guess, what labels were used to generate lists of content.
    27. In general, I find editing any pages that were converted over from 3.5 and included any use of macros is incredibly frustrating and a waste of my time. (Editing nested macros? Replacing an image in a page? UGH.)
    28. Removing the Wiki Markup Editor from Confluence,..is like Linux removing the command line interface,...can you imagine the uproar
    29. Trying to modify macros, and ESPECIALLY nested macros is a JOKE (read: impossible) without the wiki markup editor.
    30. We thought going from 4.1 to 5.x would be an improvement.... and we were half right and fully wrong. Some 4.1 bugs were fixed, and a whole slew of serious new bugs bit us directly on the sensitive parts.
    31. I miss the wiki editor.
    32. The ability to view the source of a page, select a section, copy it,..and paste to a new page. This was so easy to do with the WME,..and it is now impossible now in the latest version of Confluence. What used to take 2 seconds is impossible.
    33. The ability to quickly create a table via WME using the | symbols,....and the top row using ||,....again ridiculous that I MUST now use their table creation button,...or type {table  only to have it pop open a box asking which of the useless tables I want to use.
    34. The ability to view the source of someone's page as an example,..only to see deeply nested tables that are super ridiculous to understand.
    35. selection in the editor is still super buggy when you begin to have macros, and even when you manage to think you have the selection you wan't it ends up copying more than what you thought you had selected... On top of that it is far harder to hit the right selection in the "View Source" than the actual editor.
    36. when you view the source of a complex page,..and only want to copy and paste a small section,...it can be next to impossible to find that section.and,...Ctrl-F WILL NOT work in that window
    37. modifying a complex page,..meaning removing a small section was so easy and lightning fast with the Wiki Markup Editor,...however,....in it's present state,...if I try to do that,...I usually end of breaking sections or the entire page because I've modified or accidentally removed more than I wanted.
    38. You also don't seem to be able to insert a picture within a table,....something that used to work.
    39. you can no longer trust that you can find many types of things within Confluence pages any more when you need to to global revisions and global search and replaces. The basic Search box no longer finds everything, especially specific macros with specific parameters, or links that include syntax pointing to a target page in a different space. And it used to be that you could at least open up pages and use Ctrl-F within the wiki syntax of the page to find such things, but no more!

      I posted JIRA bugs on all this stuff more nearly 18 months ago, shortly after the move to 4.x, and I've seen no resolution of such bugs yet.

    40. cutting and pasting in the Wiki Markup Editor was for every user:
      • Fast
      • Easy
      • Simple

      Now,...it's:

      • Slow
      • Complex
      • Confusing
    41. Most were not given a choice to upgrade to the next version. And, once they were upgraded,..they took their grief out on the local Network Operations team that performed the upgrade. It happened here at this company. So, of the hundreds in this location, most has resigned themselves after complaining and misdirecting their grief. They ARE NOT happy users,...only beaten down and resigned to use what is forced upon them.

    42. have you also seen the age of some of the issues that are opened and still unassigned?? Have you seen the number of votes on these issues, and yet they languish?
    43. Just wish they add the Wiki Markup Editor back. I'm not asking for them to remove any other feature, nor make any other change,...just want the WME back......and NO, the RTE CANNOT do all things for all people.
    44. This bug was filed 18 months ago, describing the most "broken" aspect of the new RTE editor in exhausting detail. The workflow that this bug describes is one of the most common tasks in writing wiki content. 18 months, and the only action they've taken on it is to keep pushing back the fix version further and further. Or taking off the fix version entirely, just stranding the bug in the middle of no where. CONF-24760 - Copy and Paste problems with list and macro selections. ( Open)
    45. Every functional test detailed in CONF-24760 (reported in 4.1) still fails today in 5.2. 18 months later.
    46. Here's just one of the functional tests reported in that bug ticket that you can reproduce for yourself in 5 minutes to see why so many of us bitterly complain about the RTE editor even now, nearly 2 years after its introduction. THIS was a task that was dirt easy and intuitive with Wiki Markup in 3.5 and earlier. Now? It's maddening to work with any sort of page that comprises anything more complex than a simple set of headings and paragraphs.
    47. Macros in macros are far more difficult to select in the Source View because they are "clammed" together.
    48. Then there is the matter of "When do I have the macro selected, and when do I not have it selected"... This part is not obvious in the Source View nor the Editor.
    49. you keep power-packing the RTE with new features that only brings new bugs as well?
    50. the Page Layout thing, the overhaul in the design, workbox, likes and even freaking image borders was more important for Atlassian than fixing issues with the RTE.
      1. While I agree with the article itself, there are a number of childish comments on that thread. Atlassian staff have never been abusive. IMO they're unfailingly polite in the face of some (at-times) quite strong abuse from disgruntled users. 

        I disagree wholeheartedly with the removal of the wiki editor, but I don't think it's helpful or appropriate to abuse the staff. 

        Captcha 1, 2, 3, 4, 5

        1. The article exaggerates much on the matter, but saying that they have been unfailingly polite is also wrong... However those comments has been deleted since then.


          When people first came here, the reason for their initial rude tone was probably mostly founded in what seemed to be their approach to the matter, that "all the users who complain here must be those that have not tried the new editor yet". Which indicated a strong internal belief inside atlassian that all the complaints was actually based on speculation and not experience... And so all people who was providing negative feedback had already been judged negatively...

           

          This is close to a accurate quote from back then: "Have you even tried the new editor yet?... take it for a spin, trust me you will love it"... And that was seen several times in response to several comments here... And while it is not abusive... it is certainly not polite either when people comes with actual issues.... 

           

          But it didn't take long after that to uncover the first great many bugs, and so within no time they where proven wrong in their assumption... People complaining here had actually tried it, and they had actually run into countless bugs or degradation's compared to the old Wiki editor... And the new RTE wasn't as great as Atlassian first made it out to be...

           

          So while the language didn't contain any negative or foul words, the underlying tone was certainly not polite in the beginning...

          1. Anonymous

            Jens: Very well stated!!! Perhaps you should have been the one that wrote the Slashdot article. I think most of the frustration from the detractors is probably due to the sheer and utter frustration of trying to use Confluence without the WME tool to do your job. What used to be a 10 second edit of a page,...turns into a 30 minute adventure in futility. Then you end up having to "roll back" or restore the page as it was before you touched it.

            I'll give the author of the slashdot article this much credit,.....at least they wrote something outside of this "black hole" where only a slim minority ever find it.

             

          2. Anonymous

            Jens is spot on.  The increased frustration is less with the technical issues of the Poor Text Editor and more with Atlassian's arrogant handling of the problem.  

            Does anybody know if it is possible to downgrade Confluence to get back to using wiki markup?

            I was recommending our documentation team use Confluence to publish our company's support manuals.  That was viable in the previous version, but not now.

             

            1. You could return to 3.5x, but they have discontinued support for it. My client is still using it even though we have now received several security bulletins about it.  The only feature that I've seen in the later versions that impresses me is the ability to use {excerpt-include} across spaces. (In 3.5, it only works inside the current space). 

              I'm looking at XWiki as an alternative. I really wish I didn't have to, and like Shannon Greywalker has asked many times here I would be enormously grateful if Atlassian would continue to support "old" Confluence indefinitely. 

              1. Anonymous

                Thanks, Kathleen.

                Atlassian - which costs less: losing a long-term customer or providing 3.5.x support?

              2. Anonymous

                Kathleen,...we're also looking at XWiki.

                In fact, I just installed a copy and am amazed at the amount of available plugins.

                So far, and this is just a quick review, XWiki is pretty amazing. It has everything we're looking for, LDAP, WME, Charts, Columns, and the list goes on. AND all FREE! We have some very smart people here, so administering it will not be a problem. And as far as support goes, why should we be paying for support to Atlassian when we only ever get brushed aside.

                Really too bad for Atlassian, since we would stay with Confluence, but the removal of the WME was the straw that broke our backs. I think the developers there like to play with shiny things, easy things. Why else would they decide they know better than us, and tell us what it is that we want.

    1. Thank you very much for this list. I agree, and experience every one of those issues, but have never taken the time to write every one down. My users also suffer from the same thing. All new pages we create we use that \{wikimarkup} macro to preserve the wiki formatting, but it is still horrible because the RTE messes up the plain text in the \{wikimarkup block! It is the best we can do, unfortunately.  (Running 5.2.3)

  41. Tables are a common issues and I continue to be frustrated by them...I've been working with several pages utilizing the feature and it really ruins my day.  Here's my latest:

    We had a page where several tables were created, each with their own headers.  After doing so, we wanted the information to appear in alphabetical order.  Remember, each section has 1 heading and 1 table.  To move the heading and the table to a new location (in Firefox), in wiki markup it was:

    1. Highlight the text to move
    2. Cut
    3. Scroll and Position cursor to the new location; although, because the content takes minimal space, you may not even have to scroll
    4. Paste

    In the current RTE it is:

    1. Highlight table to move (challenging in itself to highlight the full table).  Can only do the table as you cannot highlight anything outside of the table like the header.
    2. Cut
    3. Scroll and Position cursor for table.  Because macros take so much space (we have section, expand, include, column macros in almost every page, you have to scroll quite a ways usually to get to the location that you want)
    4. Paste
    5. Scroll back to the original table location as the actual table remain - the content was cut and created a new table - the actual table itself doesn't move
    6. Select the table
    7. Delete
      1. You may have to actually repeat trying to select and delete the table; often, once you have done this a few times, it stops working. So you have to:
        1. Save
        2. Edit
        3. Locate where you were at
        4. Try again
    8. Select the header text
    9. Cut
    10. Scroll and Position cursor for the header text
    11. Paste
    12. Remove the additional line it creates between the header text and table
    13. Go back to the header that you actually removed the header and text from and delete the additional lines that still remain because the content was really never cut and the associated space removed due to the table left behind.

    Now, increase these steps by several if that header text or table were in a macro such as a column or expand because you have to usually cut and paste those separately because often you cannot highlight the full content.

    So, 13 vs 4 steps - doesn't seem very efficient.  And, when I have to move several tables in one page, this is very significant in terms of time and frustration.

     

    Please don't say to use the source editor either.  Because of all the tags that are put in there make it difficult to locate only the information you need to cut/paste without breaking any other layout/formatting and, with everything on one line, it's difficult to read.

    1. Hi Karie, can you let me know which version of Confluence you're using, and your browser + version? We're having trouble reproducing at the moment, being able to select a header + table ok.

      1. Hi John,

        It has actually been a issue for me for quite some time in that I cannot select anything outside of the table unless I am trying to select the entire page.  We are currently on 5.1.5 and I am using FF 21.0.  I can send a quicktime movie if needed.  Thanks, Karie

        1. Karie: You described our biggest problem here. Not sure why Atlassian is having a hard time reproducing. It's very annoying to our users here. Your description in #12 and 13 about the extra space is one of the most frustrating for us! We used to have very professional looking pages, but now people have given up altogether.

          The whole formatting of these tables in the RTE is a complete mess, and as you say, it is impossible to edit or modify in the source editor.

  42. Anonymous

    I am really annoyed by the removal of the WME editor as well. Basically, I'm just inserting everything as wiki markup and using containers to make sure they stay that way, since it's a lot easier to go back and edit or copy/paste the markup. The markup is much more feature rich, easily manipulated, and allows for more powerful document creation. If you want to keep the markup on your document, you can do so by enclosing everything within a container. The drawback is for some stupid reason if you choose to Preview then the RTE will reformat your wiki markup inside the container, breaking your markup. So I never use Preview anymore, only Save and then go back to edit fixes.

  43. Anonymous

    Hurray,.....

    We just got the go-ahead to run trials on other wiki solutions as a replacement for Confluence.

    Everyone here got so fed up that management decided, it was time to switch to a real wiki that still uses a wiki markup editor. When the e-mail went out, notifying everyone to be patient for a few more weeks as they run the trials and make their final decision, everyone started clapping,...it was awesome.

    I wish the best for everyone else here. Perhaps your companies will also hear the outcry and respond in kind.

    Bev

     

    1. I'm curious:

      • What was the other wiki solution(s) you are trialing
      • What is it that your company does - specifically, how do your folks use Confluence?

       

    2. Anonymous

      Bev,

      I am envious!

      (Atlassian would benefit enormously if everyone in this situation would decamp for a new wiki. Who wants unhappy customers hanging around?)

  44. Anonymous

    We've just upgraded to Confluence 4 and I am dismayed that the mark-up editing has been taken away.

    Previously, it was the only way to fix issues in pages brought in by the RichText editor. Now we don't have that option. I wouldn't mind, but the RTE just does not work properly. I've only used it to edit one page so far, but the formatting is totally broken - similar items with the same heading level come out formatted differently- some with bigger fonts and bolder and "paragraph" text ending up bigger and bold. This just makes the pages look ugly - especially because this gets copied to the TOC (sub-items larger than headers).

    I wasted about an hour the other day fixing up entries that somebody had made, come back today and somebody else's changes need fixing, so that's going to be more wasted time.

    If you are going to force people to use a real-time editor, it needs to work properly for common things. I do not care about inserting a junit report or a task list, I just want simple editing - numbered lists, TOC, block text and the ability to insert images. To be honest that's about it, but this simple stuff just doesn't work! I am going to recommend that we downgrade to the previous version or find another tool that "just works".

    Bad news.

    1. Hi Anonymous,

      I've only used it to edit one page so far, but the formatting is totally broken - similar items with the same heading level come out formatted differently

      If you have the time, can you let me know a bit more about this? Here's what I'm assuming, can you confirm this is what happened, or let me know the actual scenario (mainly, did the formatting break as soon as you hit Edit, or while you were working?)

      • Upgraded Confluence
      • Viewed an existing page that was created from before the upgrade, and it looked ok in view mode
      • Hit Edit, and inside the Editor, the formatting was wrong

      Thanks.

      1. Anonymous

        Hey Atlassian,

        This thread is not a support thread. Folks don't come here to ask for support (Atlassian has lots of formal support channels, that do fine).

        It would be appropriate to engage in the conversation that is actually going on (rather than what Altassian thinks is going on).

         

        My 2 cents.

        samjones6

      2. Anonymous

        Hey Atlassian,

        This thread is not a support thread. Folks don't come here to ask for support (Atlassian has lots of formal support channels, that do fine).

        It would be appropriate to engage in the conversation that is actually going on (rather than what Altassian thinks is going on).

         

        My 2 cents.

        samjones6

      3. Anonymous

        Our support guys have raise this as an issue, so will be coming through formal channels soon if it has not already.

        Your supposition is wrong, though. I managed to do this on a brand-new page, just by typing. It looked as if it had inserted a style attribute that could only be cleared by using the source editor plug-in.

        <h2>
                <span style="font-size: 14.0pt;">My Item</span>
        </h2>

        I've also seen it make an un-editable bullet point - I'll post the source if/when I reproduce that one.

        Btw - your captcha handling on comment submissions also seems to be broken - it rejects correct answers.

        1. Anonymous

          RE captcha.... many of us have complained about it. Atlassian thinks it works fine.

          (Sound familiar?)

  45. Anonymous

    More than 2 years after the release that removed the Wiki Markup Editor, and was replaced by the Real Time Editor, and people are still unhappy, complaints still come in and Atlassian has yet to admit they made a mistake. This doesn't seem like it will go away anytime soon, and I think it's only a matter of time before they give us back the WME (leave the RTE in the product if you want,..it's a piece of crap anyway).

    Either that, or another vendor sees these complaints as a goldmine and launches their own customer friendly corporate wiki with a Wiki Markup Editor. One way or the other, time will tell.

    Atlassian: Time is running out. You have customers that found Confluence to be adequate to use because of the WME. If you bring back the WME, all will be forgiven. However, the longer this festers, the less forgiving customers will be, even if you listen to reason.

    There's no shame in admitting you're wrong. There is shame if you ignore customers.

    We're already seeing similar complaints about the removal of the WME on Reddit, on Slashdot, on Twitter, on forums as well as on blogs. Snowballing.....................

    1. Anonymous

      Does anyone know of a good site that evaluates wiki options? I've implemented Atlassian products in two companies; but, am headed to another and would like to reevaluate the marketplace to determine the best wiki to recommend.

  46. Anonymous

    New here, and I've read the whole thread, but can I ask how you're expected to manipulate the source, or a page directly with Wiki Markup?

    As one person had said, it gets impossible to modify a page, especially with columns or with numbering bullets. We have a lot of grief going on here and it isn't getting better.

    Can I also ask, why are the people that try to defend Atlasssian by dismissing complaints as either invalid, or making you feel like you're too stupid to use an awesome tool unless you use the Wiki Markup Editor.

    I also agree that the product mgmt should have stood up for the customers/users even if it meant that the developers had to do more work. Besides, they're excuse that it was too hard for them is rubbish.

    aha, now I understand what a captcha failure is

  47. Anonymous

    sorry,...meant to say:

    "New here, and I've read the whole thread, but can I ask how you're expected to manipulate the source, or a page directly without Wiki Markup?"

  48. Anonymous

    Excellent article that explains the anger over the removal of the Wiki Markup Editor:

    http://eikonal.wordpress.com/2013/07/02/intentional-loss-of-functionality/

     

  49. Anonymous

    The removal of the ability to use wiki markup seems to be a cop out.  The fact I am no longer able to quickly and reliably create an article formatted how i want is a huge step backwards.

    It is pretentious to think Atlassian knows best.  The fact an article is needed to justify removal is a strong indication removing it was a big mistake.

    Finally, due to this blunder that is being made worse by Atlassian continually trying to justify it, I no longer recommend Confluence.  Your agile abilities are being replaced with the big company mentality - some lame manager made this decision and the underlings are forced to go along with it.

  50. Anonymous

    Two Three examples why the removal of wiki markup is inefficient.

    This comment is one - so two was changed to three.

    An extra line was added above this (h4) comment even though one was not wanted.

     

    Unable to use other editors, such as Excel, to quickly create and generate tables.

    Something that took seconds to do, now takes many minutes.  After the long process of using the What You See Is NOT What You Get editor (note the additional lines that are being added to his comment by the editor - I am leaving them to stress the point), the formatting wars begin.  My nice, clean consistent articles are now getting whacked by the poor text editor.  Previously, Excel (which is the king of table editing) could be used to create the table i wanted, then simple Excel macros would crank out perfectly formatted wiki markup.  No mas.

    The rich editor is What You See Might Be What You Get.

    Formatting is hell.  I'll indent a line, and suddenly three sections below where I am editing is indented.  I'm unaware until much later, then the formatting wars between what I want and what Confluence thinks I should have, begin.

  51. Anonymous

    I am rather disappointed with the Poor Text Editor.  Atlassian's arrogance and inability to admit the mistake is the worse part about this debacle.  Instead of cajoling their customers to approve of their product, they should be looking for ways to address their concerns.  The options for addressing the concerns appear to be:

    1. Help customers downgrade to a version that provides wiki markup and is supported.
    2. Provide a plug-in.
    3. Add wiki markup to current and future versions.

    I've read number 2 is available for beta but have not tried it.  The potential problem with this solution is that it will not help with page formatting issues unless all pages are converted to content that is contained within that macro.  It may work, especially if Atlassian provides a way to bulk convert pages to content contained within the macro.

    Finally, discussing replacement products on this page is unfair and unprofessional. Other members of Atlassian's dwindling raving fans base are encouraged to show respect to what was once a great company.  Hopefully Atlassian will return to greatness by learning the valuable lesson about understanding your customers (who are not always right) is more important than listening to investors' greedy desires to accumulate more (short term) wealth.

    1. Anonymous

      To whom was the comment;"discussing replacement products on this page is unfair and unprofessional" directed, to Atlassian, or one of the other posters?

      I'm hoping it was directed at Atlassian since they are the ones that brought that subject up in the first place. If so, then I agree with you that it shows the arrogance of this company, in that they want the "trouble-makers" and "detractors" to just go away. Perhaps they think that if they do try other products, they will be left so unsatisfied that they'll come running back with their tails between their legs begging for mercy.

      Here's the problem though,....this product is typically in an enterprise environment where a select few make the decisions about what products the whole company will use. The actual users of these products are Atlassian's real customers, although Atlassian seems to only care who pays the bill every year.

      These complaints will not go away until Atlassian gives us back the WME, and the ability to modify pages in WME and not that crap RTE.

      Although Atlassian has denied this, I'm am beginning to believe this is their way of locking everyone into Confluence. I suppose they've idea is to make it virtually impossible for Confluence admins to export the data into another Content Management or wiki system.

  52. Jens, I hesitate to mention this - it is, frankly, risible - but you might be interested in some IE-specific CSS I've described in a comment on CONF-25942 - Highlighting of containers of macros that have bodies Resolved . In IE, it shows the word "Selected" in the title bar of selected macros. I would not describe this as a "solution"; it is, at best, a stop-gap if you really need it, and you're using IE (I tested it in IE9).

  53. Anonymous

    None of my users use IE, and I suspect on this thread there may be zero IE users....  I suspect none of us would have a problem if atlassian said "avoid IE"

  54. Anonymous

    Well now that's just silly. Just because you and your team don't use IE, doesn't mean the world follows suite.

    Not supporting IE and Firefox (and probably Chrome) at a minimum is downright stupid. I'll give you that specific versions could be sunset,...but the major browsers and latest versions should be supported and that includes IE.

    Besides, if Atlassian doesn't support a specific browser, they'll just tell you that that's value-added software.

     

  55. Anonymous

    Where's the WME?? Seriously.

    This rte is impossible to use and modify existing pages.

  56. Anonymous

    I wonder how Bev is doing on her company's transition to another Wiki?

    I wish she would have said which one she turned to since I am also looking for a Confluence replacement. Does anyone know Bev? If so, can you point her my way.

     

  57. When we are upgrading from Confluence wiki 3.x to 4.x/5.x, the wiki markup to xhtml conversion is not working well, especially for pages with nested macro / html codes / scripts etc, resulted in many formatting issues and user complaints.. is that a known bug in Confluence upgrade / code conversion process?  This is a big issue and have very bad user impacts.  Any workarounds that anyone may have?

    1. Sorry.

      There is no way out that I know of.

      We upgraded 1.5 years ago from 3.x to 4.x. We are on 5.2.x now.

      We still suffer from stuff that broke during migration. We create most new wiki pages with the wikimarkup macro so we can still "type in wiki speak" (Sadly, the RTE is horrible even for plain text and makes plenty of mistakes that 2.x and 3.x WME would never imagine making.)

      The atlassian answer to your issue is: "you should have done a dry run migration and reviewed all your content prior to a production upgrade."

       

      What you and I know is: If you (and I) had really taken the time to do that properly, we would have stayed on 3.x.

       

      But once over the hill, the cost to go back is so high (and we did not notice many of the migration issues for weeks or even months).

      No good news to share, sorry!

      1. Anonymous

        The atlassian answer to your issue is: "you should have done a dry run migration and reviewed all your content prior to a production upgrade."

        It is a nice idea and certainly worthy of attempting but how exactly do you do it?

        Let's say your confluence has hundreds of spaces say 557 and TB of attachments with over a million current pages.

        I agree that it should be done I just can not see how it could be. What has to happen is that all content from V3 needs to be rendered as V3 until it is migrated to V5 format. Otherwise there will be hundreds of thousands of pages with broken markup.

        Not having the old V3 preview function when entering code into V3 using the wiki macro really hurts.

        Having pages vanish on save hurts too.

  58. samjones6 or other community members.. how about the "Wiki plugin for Confluence", have anyone used that and can that be used as an option to preserve the more complicated macro codes / scripts that we have in wiki 3.x and avoid the large number of formatting issues after migrated to 4.x/5.x?

    1. John Kung Yes, we use "Wiki plugin for Confluence" it is a very important tool! 

  59. Anonymous

    Another Happy Customer! NOT!!!

    RTE Sucks

     

  60. Anonymous

    Wow, just wow.

    Our company just upgraded over the weekend, and we are now without the wiki markup editor. Staff here are in an uproar, not only because the wiki markup editor is gone, but they're also confused by the real time editor and making changes to existing and new pages. With the rte, every change causes mass churn and more work than as if you created the page from scratch.

    Wish I had found this page before the upgrade. It would have made the difference and we probably wouldn't have upgraded. My goodness, so many customers complaining about the loss of the wme, but Atlassian still turns a deaf ear. ?????

     

    1. Very sorry to see another mess!

      If your experience is anything like mine, here is what to expect:

      a) The pain will never (ever) go away. The old wiki way of doing things is built for speed. Your users will never get that speed again.

      b) You will make use of the wikimarkup macro, to give a small echo of what was lost (it is not really very useful, but it is all any of us have, so we use it)

      c) Over time, the wiki markup skills of your users will atrophy.

      I am 1.5 years in, and my users still ask me "when is the wiki markup editor coming back?"

      We have doc generators that auto-generate wiki pages from our build process.... but the knowledge of wiki markup itself is being lost, so this doc generator has no one to maintain it.

      It is like losing an arm.

      Sorry.

    2. Atlassian still turns a deaf ear.

      Atlassian listens to flattering tweets. (Sorry, Atlassian, I couldn't resist.) Anonymous, I empathize with your situation.

  61. Anonymous

    Our company barely uses Confluence anymore (hosted) – the "new" editor will never be as fast as the original WME and our programmers will never like it, period.  They can update it all they like, but until we get an option to use a pure WME, we won't be recommending it (just the opposite) to anyone.

  62. Anonymous

    When writing in a bullet list, on any bullet line do the following:
    1) <Shift> + <enter>
    2) type the character -
    3) Hit space bar

    and the bullet list will terminate.

    Is this expected behaviour? 

     

     

     

     

     

     

     

     

     

     





    ha
    wtf

  63. Anonymous

    How stupid is this? I can directly enter markup but I can't edit what I have entered. So if I make a mistake or if your editor makes a mistake and say adds or removes lines or spaces within a macro I can't simply remove the spaces. No I have to endlessly drag and drop bits the bits and pieces which overlap and push each other out of the way or delete themselves or otherwise mess up what would have been faster to edit as raw text. This process actually cost me both time and work. I had to revert the page to regain the lost work and then I had to redo the work I couldn't recover. How do you expect me to maintain a wiki if every time I touch it I run the risk of losing hours of work and will likely have to restore and restart the process several times? Your lame excuse for removing the editor is the most shortsighted poorly conceived marketing bullshit I have ever read. Anyone asking me if this is a good fit for their wiki needs will get a resounding NO. Find something else. Anything else! Using Confluence for a wiki page is like designing a website with word. Stupid, error prone, foolhardy, a waste of your time and money and the wrong F*cking tool for the Job.

    1. How stupid is it? Well, it is very painful for users!

      But remember: Atlassian does not care about user pain. They have other priorities.

      The only partial solution is: https://marketplace.atlassian.com/plugins/org.swift.confluence.wiki

      Note that the RTE is so messed up that even this plugin has issues. Sometimes a blank line in the wiki macro is lost on rendering. Sometimes a blank line appears that is not in the wiki markup. (This all seems to be due to invisible formatting codes that are in the editor but not apparent to the user.)

       

  64. Anonymous

    Hi Sam: If Atlassian screwed up the RTE so bad that even a 3rd-Party addon offers no help,...what choice do users have at this point? We are experiencing the "invisible formatting" you mention and it is killing us.

    1. >> what choice do users have at this point?

      Two choices:

      a) Leave atlassian and migrate to an actual wiki (many have done this)

      b) Remain on confluence and live in pain. (many have done this). There are tens of millions of adults who live with pain. It is possible to live with pain. It is unfortunate for humans to do this to each other, but it is possible to continue to live, and even to accomplish things, while living in significant pain.

      I know of no third path.

      We are, so far, stuck on 'b' We have helped ourselves, a bit, by killing internal initiatives to adopt hipchat and fisheye (out of fear of future pain caused by atlassian). But we live, every day, all day, with significant, chronic, confluence-v4-v5-created, pain.

    2. Hi Anonymous,

      I cannot offer you a solution, but for what it's worth (not much), the user style "Confluence rich text editor - show tags" will, within limits, make the invisible formatting visible.

      This is, admittedly, of limited practical use, but it does enable you to observe the "quantum foaminess" (wink) of the RTE markup.

      I've found it useful to understand how the position of the insertion point, relative to the underlying start and end tags of the RTE markup, affects the editor behavior when you press, say, the Enter key, Backspace, or Del. This understanding sometimes helps me to avoid stepping on the cracks.

  65. Anonymous

    The new editor is not ready for Production use. It still can't take acceptable 3.5 wiki markup and render it properly in the new RTE.

    Double Bar Does Not Create TH

    Here is an example:
    Wiki markup of:

    should result in a table with two columns the first being a TH and the section being a TD. What actually comes out is this:

    first cell  

    If you are  interested, I did not put the words 'first cell' in there.

    Numbered Lists With Bullets

    Let's have a look at those bullet lists again. This time, we'll see if we can use wiki markup to create a numbered list with bullet points. I use these all the time. 

    Here is the code in wiki markup:

    and here is what it looks like when inserted using the wiki markup mode:

    1. Parents
    • Father
    • Mother
    1. Siblings
    • Sister
    • Brother
    1. Other
    • Cousins
    • Aunts
    • Uncles

     We'll call that an epic fail and move on.

    Delete before and the Image goes in the table not after it

    Create a table. Move cursor down to next line. Insert an image. Put cursor on left side of the image. Hit backspace. 
    The image is moved inside the last row of the table where it should be outside the table to the right.

    Where Are The Invisible Objects and Guidelines

    A lesson learned from Dreamweaver and the like is that when coding you can align your code to visualise where the invisible objects and code blocks are. When using a graphical user interface the objects and blocks are invisible so the editor needs to provide some clues. Dreamweaver, Microsoft Word and other WYSIPWYG editors have this so why doesn't Confluence? A button to show and hide hidden objects and show markup would be very useful. 

    Microsoft word is a good example of this.

     

    There are lots of reasons why WYSIWYG editors are a bad idea or poor solution at best. Those who do not learn from the past are doomed to repeat it. If this silliness must continue then at least do something like introducing a dual pane that shows in real time the page preview.

     

    If anyone has pointers on a replacement product for Confluence then we are listening.
    SharePoint: Has separated 'sites' and a similar group security to Confluence. It is an awkward step backward to HTML style editing with folders instead of single page links within a space. RTE and code editing for pages.

    Next? 

    1. Indented bullets require a second level of syntax.

      It works with the 2nd level syntax if you have no newlines between wiki markup.

      1. first number
        • first number bullet 1
        • first number bullet 2
      2. second number
        • second number bullet 1
        • second number bullet 2
      3. third number
        • third number bullet 1
        • third number bullet 2

      but it fails if you have newlines

      1. first number 
        • first number bullet 1
        • first number bullet 2
      1. second number 
        • second number bullet 1
        • second number bullet 2
      1. third number 
        • third number bullet 1
        • third number bullet 2
    2. a button for displaying invisible objects (namely carriage-returns and such) exists in the WYSIWYG Editor. Possibly your system administrator needs to enable it globally. The "how to" is available somewhere in answers.atlassian.com or CONFKB.

  66. Anonymous

    I just found that the editor is doing something completely unexpected. I have just spent the day bashing my head against the wall. Good luck actually getting work done. Tools - View Storage Format shows the xhtml markup. Perhaps Atlassian could add a Edit Storage Format option to edit the markup directly. Add a verify button so the user can check their code before saving.

    The new editor reduces Confluence down to its competition. I can no longer say that it is better than sharepoint or any other wiki.

      1. Anonymous

        Adam: Seriously!?!?!, I know you're trying to help, and that you love Atlassian, but that source editor SUCKS BIG TIME!

        What are you supposed to do with that anyway. It's useless.

  67. Anonymous

    Creating a page with the new editor is taking a lot more saves than previously. I used to be able to construct a whole wiki page from the WME and now it is taking several edits. If I saw someone do this in 3.5 I'd be telling them to use preview! It may be me getting the hang of this new editing experience but so far I am finding that there is no good work flow.

    Previous comments have related to 'round tripping'. I can tell you that this is not a problem for most cases. Once people learn wiki markup they only ever go back when what they are doing is either too hard or complicated in wiki markup. Killing wiki markup due to 'round trip errors' is a cop out. We teach people to edit pages in one or the other and never switch between them - and if you do then clean it up before saving. If that is the problem here then kill the ability to save pages marked up or write a better parser for loading markup into the rich text editor.

    Meanwhile, in Chrome Ctrl-Shift-V is the key combination for paste special text only. This function is seriously needed when using the new editor as in many cases the previous formatting is not required. Unfortunately Ctrl-Shift-V does not work in the new editor. It just does not work. There is a workaround: right-click then paste as plain text. Awful I know but still it is slightly better than pasting into the url bar, copying out the result, then pasting into the editor (which is what I have been doing for a long time) 

  68. Anonymous

    Hey, what do you know. It looks like they fixed the Captcha. Perhaps there's hope that they'll also fix Confluence by adding the wiki markup editor back! Obviously Captcha was broken, and similarly, Confluence is also broken.

    Sure, you could have let customers hit the Save button 10 times and enter a new captcha each time, and then argued that it was a feature intended to make sure the submitter really wanted to post the comment.

    In like-wise fashion, stop telling us that you actually helped US by removing the WME. Add the WME back into Confluence!

  69. Anonymous

    Riddle me this batman: wiki markup used to be very portable - you could code anywhere any paste it in and it would work - but now there is no code that can be copied and pasted between confluence editor sessions just something on the clipboard - so how can code be copied from one place to another

    this question is asked due to the extreme annoyance of losing changes when a page does not save any there is no place to store it while you wait to see if your recent changes will be saved or if you are going to spend yet more time doing the page over again

    1. Robin, you have identified one of the many (very many) "hidden costs" Atlassian incurred when dropping wiki markup. To this day, I type wiki markup in text editors, and drop into confluence, but the wiki markup knowledge is dying. Without the wme, the knowledge dies.

      My team asks me periodically, "when do get a wiki back"  And it is 18 mos since we (unknowingly at the time) lost the wme.

    2. No place? I can offer you some place.

      You're going to think I'm a joker (you might say: the answer is a joke), but here goes anyway:

      1. Select your Confluence RTE contents (in Windows, press Ctrl+A) and copy it to the clipboard (Ctrl+C).
      2. Paste the contents (Ctrl+V) into Wikifier RT.
      3. In Wikifier RT, click Show HTML.
      4. Copy the ("plain text") source from the HTML pane to a text editor (for example, Notepad), and save it (say, in a .txt file).
      5. Later (seconds, days, whatever), copy the saved HTML source back into the HTML pane of Wikifier RT.
      6. Click Update rich text.
      7. Copy the contents of the Rich text pane into the Confluence RTE.

      You didn't say it had to be a tightly integrated solution (wink).

      You don't have to save the HTML source to a disk file if you only want to store it for a few seconds, and you're confident your browser won't crash before you've saved the content in Confluence. Just use the Rich text pane of Wikifier RT as temporary storage (only slightly less temporary that the clipboard).

      If you don't want to use Wikifier RT, take a look at the Wikifier RT source for the above functionality. There's very little to it. Just a frame with contenteditable="true" (where you paste your Confluence RTE content), and some trivial JavaScript to expose the source of that frame as plain text. Very easy to roll your own similar code. There are also apps for managing "multiple clipboards" that I think you could probably use to do more or less the same thing.

      You could also use the Confluence XML source editor plugin (if you have access to it): copy the XML (I want to write: XML fragment) into a text editor (why not an XML editor? go ahead, ask me!), and again, either use that editor as your temporary storage, or save it to a file.

      As you say, wiki markup used to be very portable...

  70. we are already discussing going back to media-wiki - sorry the dont like the rte

  71. Anonymous

    The ability to insert macros by typing { and waiting is quite good. I question though why {Table of Content Zone} appears above {Table of Contents}. 

    Unsure about anyone else but I never use Table of Contents Zone. Actually, I don't know what it is. When I want a TOC, which is on most pages, I hit { type to then enter.. and get a Table of Contents Zone macro.

    I can see that the macros are alphabetical order. Is there a way to not show TOC Zone? Or move it to be after TOC so that the key combination {to ENTER inserts a {TOC} ?

  72. It's almost 2014, I'm still irritated by this change (throwing developers & technical users under the bus for the benefit of managers etc.), as apparently are many other people.  I was a big time confluence booster before you went and took away the tool that made editing easy & enjoyable for programmers.  I'll admit using the RTE has become less painful over time, but I'd still jump ship to another product in a second if it provided the WM editing like Confluence Classic.

    Anyway I found this article when searching for a notepad++ syntax file for confluence flavored wiki markup.  Can you create/release/maintain such a one please (for NPP, Vim, & Sublimetext/Textmate ideally)?  Now that this is the only way to create/edit wikimarkup for confluence for users like those in this thread that don't want to use an RTE, it would be a nice gesture.

    1. That ship has sailed. Atlassian has said many times that they are never going to support wiki markup again.

      I've investigated Xwiki - www.xwiki.org - which supports Confluence wiki markup, and various other forms of markup such markdown and mediawiki, as well as an RTE. It's not for the faint-hearted. To install the enterprise version requires the same skill set as for an own-hosted Confluence (eg. *nix gurus and Java experts, and support is pretty much via a community forum unless you hire consultants). They do offer a hosting option for educational or charitable organisations. 

      1. Anonymous

        No offense Kathleen because I know that you also hate the fact that Atlassian removed the Wiki Markup Editor,...but,.....to just give up the fight by saying "That ship has sailed." is a defeatist attitude.

        We (the customer) drive what should be in products!!

        Any GOOD Product Owner, Product Manager,...COMPANY recognizes this and, for the most part, gives the customer what they are asking for from a product. What Atlassian has told us, is that they removed the WME because it was "too hard for our developers to manage". Well BOOHOOHOO!!!! Who cares,...that's their job.

        We as customers should not let Atlassian off the hook! We want the WME back,...and as Sequoia pointed out,..as soon as another competitor introduces a similar product WITH wiki markup editor,....watch as everyone jumps ship.

        I also like how Sequoia used the phrase "Confluence Classic". Remember the disaster that happened when Coke tried to change the recipe (taste) of their flagship product! As a result of millions complaining that they wanted the original back,...Coke gave the customer what they wanted. Sure they gave it back as "Coke Classic",..but eventually they stopped producing the changed product, and "Coke Classic" went back to being just "Coke".

        There is NO reason to stop voicing your opinion that you HATE the removal of the WME. Perhaps other companies may read this thread and realise that to ignore customers is a mistake because they are relentless!

        So Atlassian,..play your little game of "We're sticking with what we said, and not bending to customer pressure",...and see just how far that gets you in the long run! As a result of the removal of the WME here at my company, we have stopped moving forward with purchasing ANY other Atlassian product for fear that they'll make further ignorant changes.

        Sure, we continue to use Confluence, but it's only because we're entrenched with it. How sad that a company bases their product change model on this fact.

        Don't worry Atlassian, your time will come. Being a cocky Aussie company only gets you so far!

         

      2. >> That ship has sailed.

        Two ships have sailed. Atlassian has said "we are out of the wiki business, now we make Word for the web" and I have said "We will never implement another atlassian product, of any kind, ever." (We had been evaluating JIRA and hipchat and fisheye)

        We will be happy to reconsider our position if Atlassian reconsiders theirs.

      3. >> That ship has sailed.

        Two ships have sailed. Atlassian has said "we are out of the wiki business, now we make Word for the web" and I have said "We will never implement another atlassian product, of any kind, ever." (We had been evaluating JIRA and hipchat and fisheye)

        We will be happy to reconsider our position if Atlassian reconsiders theirs.

  73. I've just used the Confluence 5.1 editor in Firefox on Windows 7 to annotate the planned outline for a new document. I formatted the outline as nested lists, using different colors to highlight various types of information. Some headings are preceded by icons:

    • (plus) Heading (comment about this heading)
      • Another heading (another comment)
    • (tick) Another heading (another comment)

    Atlassian, I invite you to try the same; some formatting at the start of a list item, some (or none) in the middle, and some (different from the start) at the end. Clearing unwanted formatting (yes, I'm aware of the "Clear Formatting" button in the toolbar) - just the unwanted formatting - can be maddening, especially at the start of a list item. Perhaps I just need to work on my Confluence editor-specific fu. I use many other editors to do similar tasks; none has as many quirks as the Confluence editor.

    If you don't see problems immediately (I suspect you're not trying), let me know, and I will try to get the time to step through some of the issues that I am observing, one key press at a time.

    Nit (more or less inconsequential, as far as I'm concerned, but worth mentioning briefly): when Confluence inserts color formatting, it uses decimal color values, whereas, when I copy'n'paste formatted text from one location in a Confluence topic to another location in the same topic, the color values are in hex (a browser/platform clipboard-specific thing, perhaps?).

    Independent of these editor usage issues: how I miss the ability (in other "HTML-based" editors) to assign class attribute values that refer to my own CSS.