WYSIWYG Support and Different Wiki Syntaxes

I couldn’t directly find documentation regarding this - which page syntaxes support WYSIWYG editing in Xwiki?

I did some tests and it seems to work for pages using Markdown syntax, but it (mostly) does not seem to work for e.g. pages using MedaWiki 1.6 syntax.

The behaviour actually is a bit odd here:

  1. If you create a new article (which then has Xwiki 2.1 syntax by default), the WYSIWYG editor is opened.
  2. You can then switch the page syntax to MediaWiki while the CKeditor is still open and continue editing WYSIWYG.
  3. After saving, the page (mostly) seems to look as intended. So Xwiki somehow generated MediaWiki markup based on the information it got from the WYSIWYG editor. However, it’s not possible to open the WYSIWYG editor for the page in MediaWiki format again - after saving, only editing in text mode / MediaWiki markup mode directly seems to be possible.
    3.5. In addition, the wiki text editor complains that it could not load highlighting and code completion features for the MediaWiki syntax, so I assume that’s not supported.

Of course I had a look at https://extensions.xwiki.org/xwiki/bin/view/Extension/MediaWiki/MediaWiki%20Syntax/ and https://extensions.xwiki.org/xwiki/bin/view/Extension/MarkdownSyntax/Markdown%20Syntax%201.2 but there does not seem to be any information regarding WYSIWYG editing.

It’s documented here: https://rendering.xwiki.org/xwiki/bin/view/Main/WebHome#HSupportedSyntaxes

A given syntax will be editable in the WYIWYG editor when it has both a parser and a renderer (the reason is that you need to convert from original syntax to HTML (this requires a parser for the syntax, and we have a renderer for HTML) and back from HTML to the original syntax when saving (we have a parser for HTML and this requires a renderer to the original syntax).

This shouldn’t be allowed, unless the syntax has both a parser and renderer. Seems like a bug. You should open a jira issue for it.

I have no idea how that’s possible since https://rendering.xwiki.org/xwiki/bin/view/Main/WebHome#HSupportedSyntaxes shows that there’s no renderer for mediawiki. Note: I’ve checked quickly the code at https://github.com/xwiki-contrib/mediawiki/tree/master/mediawiki-syntax/src/main/java/org/xwiki/contrib/mediawiki/syntax/internal and didn’t see any renderer.

That’s good and normal :slight_smile: (since there’s no renderer).


I agree with you that we need to improve the documentation to make this explicit. I’m going to add it to https://extensions.xwiki.org/xwiki/bin/view/Extension/CKEditor%20Integration/

I’ve added https://extensions.xwiki.org/xwiki/bin/view/Extension/CKEditor%20Integration/#HSupportedSyntaxes

Let me know if it’s good.

Yes, it’s good if you look at the CKeditor page.

I googled and search on the Markdown and MediaWiki extension pages, where WYSIWYG and similar is not mentioned. I’d add a section / link to the table there as well, however this should probably be done consistently for all wiki syntax Extensions. Is there some kind of “default banner” which could somehow be included there, maybe as a Macro? Or is it possible to include blocks of text / sections from another page in a page? (I know that’s possible in some other wiki-like systems.)

Then I’d try to do something like this…

I think I was mistaken - you can switch the syntax to Xwiki 2.1 while CKeditor is open, but it will still generate Xwiki 2.1 text when saving - which then looks strangely. For my test I had only used minor formatting where the MediaWiki-rendering of the XWiki 2 output still looked plausible enough that I thougt CKeditor had generated MediaWiki syntax text… :wink:

Is it still a bug that the syntax can be switched during a WYSIWYG session? The result definitely is unexpected for the normal user…

Yes, that’s the {{include}} or {{fdisplay}}` macros, see https://extensions.xwiki.org/xwiki/bin/view/Extension/Include%20Macro

Hmm… I understand why you’d look there but OTOH this is something generic not related to any syntax at all. And you shouldn’t even need to look there since the UI will prevent you from doing it in the first place. You should get a warning modal box if you try that.

“doing it” - I don’t fully understand, the UI should prevent me from doing what exactly?

It’s a feature, see https://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/PageEditing#HConvertingbetweenSyntaxes

Why is it unexpected?


From converting to a syntax for which there’s no renderer. The syntax should not even be proposed in the syntax box when you edit (https://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/PageEditing#HChoosingaSyntax).

Ok, I think a get a clearer picture now:

With the information from below, I understand that it’s intended that the syntax can be changed later, but that it should only be possible to change it to target syntaxes the system can convert the current page to.

What I was referring to is that I can switch the syntax to “MediaWiki 1.6” while I’m in edit mode of a brand-new (never-saved) page, and while saving the page will happily generate the previous syntax (XWiki 2.1 in my case) and then display it with the MediaWiki parser - and that’s what I meant with “unexpected”. But that’s than just a bug in an otherwise useful feature, as …

… this does not properly seem to work for new pages. I’ll add a Jira issue.

It’s even worse: Looks as if the syntax can be switched to an incompatible one also for existing pages, and there is no warning and no information that this won’t work as intended whatsoever…

Here it is, with screenshots of a copy of the Sandbox page “converted” to MediaWiki 1.6:

XWIKI-17755 “Unsupported Article Syntaxes Selectable in Wysiwyg Mode”