Changing from WYSIWYG to Markdown Messes With Existing Pages When Going to Edit

[Ethanb00]

• BookStack Version: v0.16.0
• PHP Version: v7.0.15-0ubuntu0.16.04.4
• MySQL Version: mysql-5.7

Expected Behavior

After changing from WYSIWYG to Markdown, I expect pages to be converted, or at least roughly approximated. When I go to edit, the editor panel should show converted Markdown

Actual Behavior

When I go to edit a page after making the switch from WYSIWYG to Markdown, I see HTML in the editor and preview windows. Saving the page loses all formatting that was present when WYSIWYG was enabled.

Example (page was originally written with the WYSIWYG editor):

[simonsmiley]

without looking at the code, I think the WYSIWYG editor should result in saved markdown not html. That way both input editors can be used at the same time.

[Ethanb00]

not sure what you mean. My pages were originally created using WYSIWYG. Switch to markdown, breaks everything to HTML.

[simonsmiley]

yeah. What I'm suggesting is that the WYSIWYG editor save everything as markdown. So you don't have the issue of incompatibility between the WYSIWYG and markdown editor. Then both could be supported at the same time. I would like to use markdown to edit the pages, cause it's faster than choosing something using the mouse. While others that are not familiar with markdown would prefer a more "office"-like experience

[ssddanbrown]

I agree that storing everything as markdown will be ideal for cross-compatibility. The issue is that markdown, By design, is limited in what can be done compared to HTML. I suppose you could always fallback to HTML within markdown for those cases. Still, We'd need a good WYSIWYG editor that works to markdown or a way to accurately convert the HTML output from TinyMCE to markdown.

[Ethanb00]

@simonsmiley apologies. I misunderstood you. Yes, that makes sense to me.

@ssddanbrown would something like StackEdit (https://stackedit.io/) work?

[ssddanbrown]

@Ethanb00 As nice as stackedit is, I don't think it will help in this situation. Stackedit is still editing markdown with an edit side and a preview side.

One of my main goals for BookStack was for it to provide a simple, Directly editable experience straight out of the box. Something that anyone that has used a word processor could pick up. Something like stackedit strays a little too far from that concept really.

[Ethanb00]

No worries. Thanks for the explaination.

[ssddanbrown]

Just seen that part of the original issue here (Preview rendering) was fixed as per issue #378 (Was an oversight when we changed the markdown library a few releases ago). Will leave this open though for conversations about HTML <-> markdown conversion.

[galaxyfeeder]

I would be nice to have this reverse compatibility when changing from WYSIWYG to markdown.

In my opinion, everything should be saved in markdown and the things that can only be done in HTML I would save it in HTML inside markdown (markdown supports html).

[lperruch]

Being able to switch between markdown and WYSIWYG editor would be awesome and make bookstack almost perfect for our use. Could something like https://github.com/leeoniya/reMarked.js be useful?

[ssddanbrown]

With the merged of PR #3387 the interoperability between Markdown and WYSIWYG is changing significantly. The editor type could now be changed while editing, at a page level (If permissions allow).

A preview can be seen here.

There are two choices when moving from WYSIWYG to Markdown:

• Stable - This retains existing HTML content in Markdown to avoid any potential functionality breakages or loss of formatting. This is similar to switching the global option now then re-opening a page for edit.
• Clean - This is a system-cleaned markdown output, which is much nicer but has potential for formatting loss and potential functionality breaks (Things depending on HTML attributes/IDs for example).

While some of the comments above propose a solution of primarily storing the content in Markdown with mixed in HTML, this does not really viable solve our issues since there would still need to be conversions along the way in our edit process, and the content features we support would mean content is almost always mixed in HTML. Then things can actually get quite complex when it comes to nesting Markdown within HTML. If we were building the platform from scratch, this would be more viable since we could work-around/predict the shortcomings of this storage option but we have almost 7 years of existing use & functionality to consider and support.

The code for this has been merged and is targeted for the next feature release (Likely v22.04), So I'll therefore close this issue off since I feel it covers the fundamental request here by offering a cleaner output option.