mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-05 00:29:48 +03:00
Changing from WYSIWYG to Markdown Messes With Existing Pages When Going to Edit #314
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Ethanb00 on GitHub (Apr 24, 2017).
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 commented on GitHub (Jul 3, 2017):
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 commented on GitHub (Jul 3, 2017):
not sure what you mean. My pages were originally created using WYSIWYG. Switch to markdown, breaks everything to HTML.
@simonsmiley commented on GitHub (Jul 3, 2017):
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 commented on GitHub (Jul 5, 2017):
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 commented on GitHub (Jul 7, 2017):
@simonsmiley apologies. I misunderstood you. Yes, that makes sense to me.
@ssddanbrown would something like StackEdit (https://stackedit.io/) work?
@ssddanbrown commented on GitHub (Jul 10, 2017):
@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 commented on GitHub (Jul 11, 2017):
No worries. Thanks for the explaination.
@ssddanbrown commented on GitHub (Jul 11, 2017):
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 commented on GitHub (Nov 8, 2017):
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 commented on GitHub (May 15, 2018):
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 commented on GitHub (Apr 24, 2022):
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:
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.