how much longer will atlassian support 3.x wiki markup

[Michael Roff]

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?

[Joe Clark · Accepted solution]

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

[Michael Roff]

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?

[Bob Swift]

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

[Jobin Kuruvilla [Adaptavist]]

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!

[Michael Roff]

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

[Deleted user]

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.

[Graham Hannington]

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.

[Graham Hannington]

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.

[Michael Roff]

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]

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.

[Graham Hannington]

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]

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

[Graham Hannington]

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.

[SarahA]

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:

• https://confluence.atlassian.com/display/DOC/Confluence+Storage+Format
• https://confluence.atlassian.com/display/DOC/Confluence+Storage+Format+for+Macros

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

[Graham Hannington]

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

[Michael Roff]

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.

[John Graybeal]

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

[Michael Roff]

Seriously? No comment?

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