how much longer will atlassian support 3.x wiki markup

Bob Swift has provided a Wiki Markup Plugin which allows 3.x wiki markup to "exist" within a 4.x environement. - https://bobswift.atlassian.net/wiki/display/CWP/Confluence+Wiki+Plugin;jsessionid=DC0FBC42EFF57A72FEF891C1561A606F

In the limitations section of the plugin's documentation page, Bob notes:

Limitations

Only Confluence 3.x wiki style macro is supported. This means that only macros that support 3.x legacy mode can be used inside the wiki macro. At some point in the future Atlassian may withdraw 3.x legacy support.

I would like to use this wiki markup plugin to provide a quick way to migrate my 3.5 Confluance instance to 4.2, however, before I do this, I would like to know what Atlassian's plans are regarding the continued support of 3.x wiki markup.

From my perspective, if there was no further development work from Atlassian to support this, I would be voting for indefinite support (well maybe until the next major disruption in editing styles comes along) but certainly for the life of 4.x I would hope.

Comments Atlassian?

4 answers

1 accepted

This widget could not be displayed.
Joe Clark Atlassian Team Jun 28, 2012

As far as I know, we have no plans to remove wiki markup as a programmatic input method for Confluence.

Thanks Joseph.

Any chance this question could be posed to "those in the know" within Atlassian like @sherif mansour to see what the thoughts are?

Discussions at Summit also indicated same as Joseph's comment!

Why do you think Joseph is not "those in the know" ? :) This is something echoed for a long time now. I am sure you will know it first here if something changes!

@jobin kuruvilla, it was Joseph's choice of words "As far as I know" that prompted me to ask for more clarity on this topic.

I appreciate there are no guarantees, but if a conscious decision has been made by those responsible for making such decisions (and maybe Joseph makes these decisions?) then it would be nice to hear from those decision makers.

It seems though, based on Joseph's response and Bob's comments from Summit this should be a Non-Issue for the foreseeable future.

I am happy with that and will proceed to plan my companies upgrade to Confluence 4.0 with the expectation that the {wiki} plugin will continue to work for all 4.x releases.

I'd say there are definitely no guarantees.

Bill Arconati plainly says in this ticket https://jira.atlassian.com/browse/CONF-23895 "we don't intend to support wiki markup as a storage format forever."

However, that was last year and there has been a fairly constant flow of shock, horror and outrage at the loss of wiki markup on the Confluence 4 Editor Feedback page. Maybe they've reconsidered, especially given all the work Graham Hannington has done on the Wikifier for them.

Thank you for the kind words, Kathleen. I do wonder whether I've done the right thing by making Wikifier and Wikifier RT publicly available. They cover the formatting that is used at my site (and I'm willing, time allowing, to extend that coverage as users report gaps/errors), but I do not pretend that they offer comprehensive coverage for all combinations of formatting, or that perfection is attainable.

I believe that Atlassian could provide higher fidelity XML- or rich-text- to-wiki-markup conversion than is currently provided by Wikifier or Wikifier RT without even looking at my work. Certainly, Atlassian is better placed to do this work than me. As an outsider, much of the work that I have done has been, in effect, reverse engineering (guesswork backed up by laborious analysis).

It occurs to me (although I have no evidence, so it's probably entirely in my own head) that Atlassian might be perfectly happy to leave this (tinkering around the edges) to outsiders.

It would not surprise me if someone else develops a solution that blows Wikifier out of the water. I would welcome it. It seems wrong to me that the only solution in this area is someone's spare-time project.

However, without a clear, detailed answer from Atlassian to the question "how much longer...?",
I can see that developing a solution in this area might be a risky investment for a commercial developer. And I can understand that Confluence users might bristle at paying extra for something that has been taken away.

I think that Atlassian is the right organization to do this. It just chooses not to. And I wonder whether providing Wikifier has taken a little of the pressure off Atlassian in this regard. And also whether, because it's not as complete as it could be with more effort, Wikifier serves to demonstrate Atlassian's argument that conversion is impractical. However, despite these concerns, I think it's better to have done something, and have something, rather than nothing.

I also note that Joseph did not write "no plans to remove wiki markup as an input method for Confluence".

Nor did Joseph write "no plans to remove wiki markup as an input method for the Confluence rich text editor".

No, Joseph wrote (with my highlighting) "no plans to remove wiki markup as a programmatic input method for Confluence".

Is the "programmatic" qualifier significant?

Does the presence of this qualifier imply that there are plans to remove wiki markup for "non-programmatic" input methods?

What does Joseph mean by "programmatic" in this context?

Can one refer to the Confluence rich text editor as a "programmatic" input method? I would characterize the editor as a "human" input method (user interface) rather than a "programmatic" input method. (Although I do understand that the editor itself is a program.)

Call me paranoid, but it occurs to me that this qualifier might be there to expressly exclude the rich text editor from the "no plans" statement.

Some detailed clarification would be helpful here.

I think Joseph's comments are genuine and devoid of any deceptive intentions. I appreciate his response to my question.

However, in light of the contradicting comments found here https://jira.atlassian.com/browse/CONF-23895 (thanks Kathleen) I think clarification from Atlassian on this subject would be beneficial.

Joe Clark Atlassian Team Jul 15, 2012

Hey all, sorry for the confusion! It certainly was not my attempt to deceive anyone with my reply.

It's true that I'm not a "decision maker" on the wiki markup front, but I am privy to the Confluence development roadmap. So, I can say with certainty that there are no current plans to remove the wiki markup renderer from Confluence.

However, as Bill mentioned on CONF-23895, it is likely that eventually, at some indeterminate point in the future, wiki markup will cease to be available as a feature for users.

On the other hand, I think others will agree with me when I say that being able to generate and inject wiki markup as a plugin developer is extremely valuable and much easier than trying to generate Confluence Storage Format XHTML. Therefore, I think it is highly likely (and I will argue for this internally, if necessary), that wiki markup should remain as a valid input method for Confluence's various content APIs - either perpetually, or until there has been some improvement to the ease at which developers can produce valid Confluence XHTML.

Hi Joseph,

Thanks for the follow-up.

I do mean to be friendly - I realize that I sound like a curmudgeon - but I cannot resist commenting on this:

some improvement to the ease at which developers can produce valid Confluence XHTML.

A schema/DTD (published and maintained by Atlassian) might help with the "valid" part of that.

That, and a validating XML source editor. For example, in Confluence 4.2 you can enter the following markup into the XML source editor:

<bogus myattr="rhubarb">Hello world</bogus>

The editor will happily accept it, and quietly convert it into a paragraph with no attributes.

Having Confluence serve (and perhaps even store) the XML of a page's body content as an XML document rather than a snippet might also help. (Slightly more recent discussion here.)

"Confluence XHTML"? Sigh. I'd hoped we were over that.

Thanks again for the insight into the current plans, much appreciated.

Joe Clark Atlassian Team Jul 15, 2012

Hey Graham,

No worries - thanks for being passionate about our products (even if that leads to be at odds with our product managers on occasion, we still appreciate you taking the time to talk to us :-)).

My comments about making it easy for developers to 'produce' the storage format for Confluence was directed mainly at the verbosity of XML in general, compared to wiki markup, but your comments about the "well-formed-ness and validity" of the content developers provide is also a good point.

"Confluence XHTML"? Sigh. I'd hoped we were over that.

Sorry! I haven't been keeping up to speed on the official lingo - force of habit means I still call it by its original 'in-development' name. Do we have an official name now? I guess it's just "Confluence Storage Format"?

Hi Joseph,

Do we have an official name now? I guess it's just "Confluence Storage Format"?

Sorry, I don't know. I toyed briefly with coining an unauthorized name (since I'd already coined unauthorized namespaces and corresponding URIs for the schema), but I have not revisited that idea for some time.

I'd probably stop foaming at the mouth if you dropped the HT from XHTML, whatever other terms you use ;) .

we still appreciate you taking the time to talk to us

It's nice to hear that you do not see me as a nuisance; I am (without irony) grateful for that.

Hallo Joseph and Graham :)

I'm commenting on this bit:

Do we have an official name now? I guess it's just "Confluence Storage Format"?

I do so love conversations on getting the terminology right. It's so important!

We've decided to call "it" the "Confluence Storage Format". Here are a couple of examples in the documentation:

Careful scrutiny of the above documents (which I know you'll give them, Graham, or probably already have ;) ) reveals this paragraph:

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.

I've put the above paragraph in a handy reusable chunk, so that I can change it easily:

https://confluence.atlassian.com/display/DOC/_StorageFormatNote

In the more technical documents, especially the developer-focused documents, we should refer simply to "XML". I'm doing that whenever I get the chance.

Cheers, Sarah

This widget could not be displayed.

If you're interested in this question, you might also be interested in Wikifier RT (converts Confluence 4.x rich text editor content to wiki markup).

Thank you for your thoughts on this subject Graham, I think it adds some valuable questions which would benefit from a detailed response from Atlassian.

Thank you also for your links to the Wikifier RT tool - I haven't used it yet - but it looks like a handy option if you need an alternative to the new C4 editor.

This widget could not be displayed.

Seriously? No comment?

Even a comment saying ... we don't know would be good.

This widget could not be displayed.

A hugely valuable conversation here, on top of the valuable plugin.

In a side discussion with Atlassian, I finally grokked the reason, or at least a reason, they have so avoided the wiki support. If there are dueling formats on a site, full interoperability requires everyone to be able to use both readily. If Atlassian can move everyone to rich-text editing using a single supported editor, it unifies the platform and precludes dissatisfaction with how one editor breaks another.

While I'm not sure they foresaw the fervor with which us technophiles will continue to dissect their editor, I'm sure the vision is a primary editor sufficiently elegant and bug-free to satisfy all users. At that point life gets simpler for Atlassian and (most of) their Confluence users.

From this background, the editor comments page, the above thread, and the existence of the plugin itself, I'm pretty confident they appreciate the value in supporting the wiki text as a legacy format, and we could expect the plugin to stay through v4. Just one view, but I'm willing to stake my team's upgrade on it. Now there's just the matter of those bugs in the RT editor....

Suggest an answer

Log in or Sign up to answer
Atlassian Summit 2018

Meet the community IRL

Atlassian Summit is an excellent opportunity for in-person support, training, and networking.

Learn more
Community showcase
Published Tuesday in Confluence

Add-on evaluation with confluence templates

Atlassian market place contains number of Apps/Addons which improves the capability of out of the box Atlassian products. It is good to follow a plugin evaluation process before install add-ons. So t...

81 views 10 6
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you