You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 123 Next »

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

T Key Summary Resolution
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.

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.

Bugs  (${entries.size()} issues)

Key Summary Status
Refresh

Improvements/Feature Requests  (${entries.size()} issues)

Key Summary Status
Refresh

Additional Ideas

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 - Getting issue details... STATUS
Don Gamble

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

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

Don Gamble

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

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

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

Don Gamble 

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

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

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

Don Gamble & Fast

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

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

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

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

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

Open company, no bullshit

 

A Message from Atlassian's Founders

Hi there,

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

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

  • June 2010 - At Summit 2010 we publicly announced our plans to consolidate the wiki markup and rich text editors into one single editor in Confluence 4.0
  • July 2010 - Released an FAQ about the changes we had planned. Over the year we received a lot of questions and updated the FAQ very frequently
  • December 2010 - Atlassian began using Confluence 4.0 in production internally and began gathering feedback from heavy wiki markup users
  • June 2011 - Released a comprehensive Early Access Program ("EAP") where customers could download 4.0 and provide feedback. We received and responded to over 250 pieces of feedback during the Early Access Program
  • June 2011- Included with the EAP we released a comprehensive set of "change management" documentation including:
    • A comprehensive set of release notes describing every new feature and planned change in 4.0
    • A comprehensive planning guide for Administrators, End Users and Developers
    • A 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 much, much more. I didn't have time to list all of the tweets, emails and "Contact the CEO" submissions we've received:

  

Yet... there are two sides to every story

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

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

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

We've been listening to your feedback

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

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

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

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

We're building a source editor!

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

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

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

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

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

We welcome your feedback - please file issues in the JIRA project at 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.

Unable to render {include} The included page could not be found.

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

Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 2.5 Australia License.