I’ve been getting a fair amount of complaints about our instance of Discourse being “too technical”. One case of this is the text editor window and the preview window next to it. Personally I see the utility in having it, however these members are requesting that it be only one editor window, similar to how email works. I’m aware there is an option to hide the preview, however what I’m hoping for is what we see in the preview window, to be what’s in the editor. Example of this would be when I make something bold, not have the 4 asterisks surrounding the text, and instead simply becoming bold. Hopefully this makes sense, goal is to make it less like someone is working in Codepen and more like they’re working in Word. Is such a thing possible?

This is my summary of the issues with selected posts for flavor. It might help others to understand why a WYSIWYG (What you See Is What You Get) editor is not going to be a development in core Discourse: The stated position is that Discourse will not be developing a WYSIWYG editor. This position has been unchanged since the first request for a WYSIWYG editor. There is not widespread support for changing this position. The current editor affects this topic in two ways: The Discourse editor is relatively complex. The Discourse editor is completely owned within Discourse. The primary issue is that WYSIWYG solutions will be extremely difficult to implement. No reliable solution currently exists. Attempts to develop a solution have all floundered. Replacement editors have been suggested but not pursued. FYI, some want the other extreme which is a plain text editor 1. The stated position is that Discourse will not be developing a WYSIWYG editor. 1.1 This position has been unchanged since the first request for a WYSIWYG editor. [image] Summary outcome of the debate on wysiwyg? Support There are zero plans for that in the forseeable future. If pure WYSIWYG is an absolute bedrock must-have requirement, the sooner you look elsewhere, the happier you will be. 1.2 There is not widespread support for changing this position. Many users, probably the vast majority, have no requirement or need for this to change. 2. The current editor. The current editor affects this topic in two ways. 2.1 The Discourse editor is relatively complex There are a lot of reasons for this complexity. One reason is that the current editor provides three methods to format text. It would be much simpler if only markdown had to be considered: CommonMark markdown e.g. **bold** gives bold BBCodes e.g.[b]bold[/b] gives bold HTML e.g. bold gives bold [image] Who would prefer a standard wysiwyg to markdown? Feature Oh that’s a good idea. Let me add that… ok added under Reply section: Your reply can be formatted using simple HTML, BBCode, or Markdown: This is **bold**. This is bold . This is [b]bold[/b]. Want to learn Markdown? Take our fun 10 minute interactive tutorial! 2.2 The Discourse editor is completely owned within Discourse. There is no external dependency for the software. This is not the case when proposing alternative editors even when they are open source. 3. The primary issue is that WYSIWYG solutions will be extremely difficult to implement. It will not be an easy or simple task to modify the existing editor, integrate a WYSIWYG editor or replace the current editor entirely. [image] Who would prefer a standard wysiwyg to markdown? Feature You got to have some perspective on the enormity of the problem. A forum that has been, from day zero, WYSIWYG is probably reasonably straight forward to build and would only take 2-12 weeks of development as a plugin, there are real challenges around quoting, but quite a few options to shop from and you can strip out lots of features. However, a WYSIWYG editor that co-exists with our Markdown hybrid editor is an impractical project to embark on. Going back and forth from Markdown to WYSIWYG i… 3.1 No reliable solution currently exists. This is a particular sticking point. There is no reliable solution for translating between the current editor and any WYSIWYG option. [image] Who would prefer a standard wysiwyg to markdown? Feature You can not go from markdown hybrid to wysiwyg and back reliably Anyway I feel we have said enough on this topic now, time to either build some proof of concept (which will not come from the Discourse team) or start talking about something else slightly_smiling 3.2 Attempts to develop a solution have all floundered. A number of people have started working on solving these issues and have not progressed to a solution. e.g. WYSIWYG Editor Plugin Here’s an early blue-sky estimate for markdown to wysiwyg: [image] Rethinking the Composer - lowering the bar UX It is extremely difficult, as the code makes deep assumptions about the Markdown pipeline throughout. I would estimate a budget of around $100,000 - $120,000 USD to make the WYSIWYG change and 1 year of full time developer work. (Or two full time devs for 6 months). If you would like to fund it, contact us directly. Another way to look at it — this is like saying I prefer MySQL, can’t you guys just switch your database from Postgres to MySQL? 3.3 Replacement editors have been suggested but not pursued. Replacement editors essentially have to meet the same requirements because they will otherwise permanently fork Discourse with no migration path. In other words, replacing the Discourse editor would break existing instances so we have the same requirement for reliable translation of existing posts. e.g. Who would prefer a standard wysiwyg to markdown? - #47 by Talin [image] More advance editor should be here? Feature Keep in mind, any WYSIWYG editor in a plugin would have to be introduced in day 0 and there would be NO migration path back to markdown. 4. FYI, some want the other extreme which is a plain text editor. Some sites would prefer plain text stripped of any formatting, preview and WYSIWYG. One option is to disable the composer toolbar to give the appearance of text-only input. [image] If not WYSIWYG, then how about disabling styles entirely? Feature Try this customization: #reply-control .d-editor-button-bar button { display: none; } #reply-control .d-editor-button-bar button.upload { display: block; }

This has been a subject of much debate over the years Search results for 'WYSIWYG' - Discourse Meta

It has been discussed over and over (even this last week) to replace the editor with something like TinyMCE or another WYSIWYG. They always close and point to other threads, so I’m guessing it isn’t gonna happen in the core project.

I see, is it not possible for this be toggle-able?

That’s unfortunate, thanks for the info though!

No, there is no WYSIWYG and likely never will be.

Maybe all you want is to turn off the preview? This might help: Auto-Hide Post Editor Preview - #2 by Johani

[image] lliddell: what I’m hoping for is what we see in the preview window, to be what’s in the editor. Example of this would be when I make something bold, not have the 4 asterisks surrounding the text, and instead simply becoming bold. Doesn’t sound like it.

If turning off the preview also made the normal editor into a WYSIWYG editor then yes, however that’s not the case. I hope at some point this can be a toggle between the two kinds of editors instead of forcing markdown. I know there are more benefits to markdown however we’re seeing a lot of abrasion to it and it’s impacting our UX

[image] Stephen: No, there is no WYSIWYG and likely never will be. [image] lliddell: I hope at some point this can be a toggle between the two kinds of editors instead of forcing markdown. Oh. Sorry. As Stephen said, that’s almost certainly not going to happen. If you want a WYSIWYG editor you’ll probably need to use something other than Discourse.

Understood, thanks for hearing me out!

How to use only one editor window

Product Support

pfaffman (Jay Pfaffman) January 22, 2020, 9:06pm 10

Oh. Sorry. As Stephen said, that’s almost certainly not going to happen. If you want a WYSIWYG editor you’ll probably need to use something other than Discourse.

Topic		Replies	Views
Convert text to "preview view" as you type? Feature	14	1370	March 13, 2025
Rich Text Formatting (WYSIWYG) Product Support	2	1958	March 12, 2025
WYSIWYG Plugin (again) Feature completed	27	10132	March 12, 2025
Enhancing appeal with image previews Product Support	10	533	March 13, 2025
WYSIWYG editor as a replacement Feature completed	2	2859	March 12, 2025

How to use only one editor window

Related topics