-
Suggestion
-
Resolution: Won't Fix
-
None
-
None
Have seen:
http://confluence.atlassian.com/display/CONFDEV/Preparing+for+Confluence+4.0
http://confluence.atlassian.com/display/DOC/Confluence+4.0+Editor+FAQ#Confluence4.0EditorFAQ-WhyisAtlassianintroducinganeweditor%3F
And participated in discussion about the removal of the full-page wiki markup editor here:
http://forums.atlassian.com/thread.jspa?threadID=51646
I think I understand the reasons why the wiki markup editor for the full page's content is being removed.
I also understand that Atlassian is striving to make the new editor as faster or faster than using wiki markup.
I further understand that Atlassian is planning on providing a way to insert wiki markup via the new editor, but just not a way to edit the whole page in wiki markup.
However, I'd still like to see a way to edit all of a page's content in wiki markup, rather than just a way to insert wiki markup into the page. This could be done through an optional plugin, but it would be nice if it were provided by Atlassian and perhaps included by default in the Confluence release.
Even if this feature isn't included in the first version of 4.0, I think it would be a good (re)addition in a future release. In addition, it would be nice to enable this in other Atlassian products (not just as a Confluence plugin), since I prefer wiki markup in Jira as well.
- is duplicated by
-
CONFSERVER-23314 Wiki Markup Export or Editor
- Closed
Hi Guys,
I'm sorry to say but I can't see Atlassian implement this at all.
Not only will it be very costly to implement, we will not be able to represent all of the constructs from xhtml in wiki-markup. If we have to maintain such a plugin it will prevent us from doing more advanced things in XHTML in order to support it - removing any advantage of moving to XHTML in the first place. Also, this will move us into the same situation as we are now with two editors (RTE and wiki) and introduce a whole host of round-tripping issues (100's of bugs) that we just don't have the time or the bandwidth to deal with.
In saying this, we are totally open to plugin developers building this if that is something they see a lot of customer demand for and are happy to justify the effort spent on it the plugin.
Regarding Olivers concern:
That is really a separate issue. One solution to your problem is providing a wiki markup editor, but there are many other solutions we could consider. We are still thinking about this one and want to see what we can do in this area.
Being as open and frank with you all, I'm going to mark this as close, won't fix as it is something we cannot foresee us implementing.
Sherif