We’d like to configure the editor so that Markdown is not an available option**. Users should **not be able to select different editor types, and rich text should be set as the default.
I now have admin rights. What’s the best way to set things up?
7 Likes
I couldn’t find the relevant settings
I solved it using a MutationObserver
1 Like
Thanks for requesting this, there is no option at the moment but we are considering adding one
Maybe @renato or @david can help come up with a simple component to do this that does not rely on mutation observer, that feels fragile
4 Likes
Alternatively, you could simply hide the editor toggle switch with CSS. I imagine that’s a bit simpler than using MutationObserver.
To do so, simply install a new component here: https://discourse.yoursite.com/admin/config/customize/components
Then, add a little CSS snippet to the code for that component that looks like so:
.composer-toggle-switch {
display: none;
}
I used this to enforce the default Markdown editor, since the rich editor does not (yet) work well with the Discourse Math plugin.
4 Likes
The rich text editor mode is also now the default:
1 Like
The rich text editor is available on all sites, and you can use the default composition mode setting to determine what your members will see when they open the composer for the first time. It’s set to rich text by default.
Members, though, can decide to use the composer toggle to switch back to Markdown mode. The composer will then remember this as their preferred mode, so it will reopen in Markdown mode until if / when they switch back to rich text.
The idea here is that we want to let members write in the composer that works best for them — admins know their communities and can make a reasonable choice about which default makes the most sense, but members should be able to choose a different mode if it works better for them.
6 Likes
I believe that might seem like the reasonable behavior for most forums. I use my forum, though, as a Q&A site for my college students studying mathematics, statistics, and data science. Learning Markdown and LaTeX is part of the point.
I have no doubt that many of them want to use the rich editor. They really need to use the Markdown editor, though. So, I’m glad I can enforce this by setting the Markdown editor as the default and hiding the toggle switch with CSS. 
7 Likes
Sounds like you found a solution that works well for your community’s specific needs — that’s great!
2 Likes
I don’t understand. The update is overriding our previous defaults. This created issues with CSS for me.
I’m now trying to disable rich text completely for now at least.
@mcmcclur This worked for me to hide switch. Thanks!!
.composer-toggle-switch {
display: none;
}
I’m becoming so scared of updates now. Every time recently updating discouse results in extra work with these forced overrides/changes and additions. 
There is of course another route to choose — don’t paint yourself on the corner 
I mean, let users decide what they want and don’t do definitive rules. It takes away quite many reasons to be afraid.
Exactly. I agree, this should apply to forum owners as well. Didn’t get to decide. Updated and, boom… it’s changed for me and with an unintended css issue.
But yes, I will bring it back once that is solved. But not by changing it to the rich text editor for all users, but instead letting them know that they have a new option and can decide.
Hi Lindsey,
I understand your point of view, but let me explain why I think disabling this feature (or any other) could be useful at least until it is tested long enough to see it is stable and very few issues are reported if any.
This feature does not only affect the user who is writing their post, although they could indeed fix any issue before posting their message assuming they find a solution to post it correctly.
I think some users don’t even notice that they are in Rich Text mode. I didn’t notice it when I first started to write my previous bug report here. I’m not saying it is not noticeable, but when you don’t need a lot of formatting, it could look like any text. The asterisk (*) character could be confused with a bullet point in a rendered HTML on some screens, so users work on a long post, realize something was broken, switch to Markdown and could make it worse (as I noticed yesterday and mentioned in Rich Text editor in topics breaks white-space characters in multiple ways).
Then they don’t want to spend a lot of time on fixing their post so just send it hoping it will be understandable.
Then moderators, helpers work more to understand the question, ask the users to fix their post, explain to them that they should not use the Rich Text mode when sharing code. It means a lot of extra communication and time instead of helping, while we are waiting for fixed code blocks. It matters on a forum where most of the posts contain some kind of code blocks or if not, they should, but users were not familiar with Markdown (which was surprising to me, but this is the reality ). So the Rich Text editor could indeed be a great addition, and this is how we looked at it first even though I would still prefer Markdown, but why not let other users choose what they like. So yes, I agree.
But in some cases, moderators, or admins have to decide whether a feature makes more problems than it solves, so I believe they should be able to disable it temporarily until the feature is stable enough to activate again. Users coming for help will not necessarily know which editor mode is best for them, when they don’t know about the bugs.
Now I wouldn’t think of trying to disable the “bold” or “quote” buttons as these buttons do very little and it is very easy to notice if something is wrong. But I see that there were multiple reports about the Rich Text editor. It is a potentially great feature, but can also break a lot. People also had problems with MarkDown, but that is okay, we already know and can handle it as we did before.
In some cases moderators try to help with formatting and not just linking a formatting guide, but also fixing the message for them. It can be useful especially when they would not have time to fix their own post as new users or the one day already passed since they sent the message. If the Rich Text mode is not stable, I can imagine editing their post and breaking it instead of helping.
So I totally get the intention of letting users decide what they want to use to write their post, but there is another side of it. The fact that users might not know which editor they want or what issues they will cause, and they just make a lot more work for moderators and also get a bad experience on the forum which could have been solved by temporarily disabling the feature.
I read about the CSS-based solution. The problem is even though we use CSS for customization, I also know that CSS could also break things so I try not to use CSS unless absolutely necessary. This way I can avoid the feature appearing again after a Discourse upgrade or when someone adds an extra CSS for something unrelated not noticing that it breaks disabling a feature.
I hope I could describe it clearly enough
update:
When I came back after a notification, I realized I did not write about the exact same thing as the OP, but I believe the main point remains the same: I can imagine forum admins want to disable some features if that causes lot of problems. Whether it is MarkDown or Rich Text or the ability to switch between them after starting a post is less important.
3 Likes
Not to mention multiple functions don’t work yet which can be confusing to some people. I was just trying to figure out why [grid] (a function I’ve never even seen) was apparently no longer working for someone, and discovered it simply just doesn’t work in Rich despite not being mentioned anywhere. Plus the default buttons that are simply broken. Until all the functions actually work IMO it would be better as a turn off option. I wouldn’t personally use it but it’s clear some sites would want it
Well, the majority had a lot issues with markdown, because they don’t know how to use it. That’s the main reason why WYSIWYG was so badly needed. And you said, even basic tools are rarely used (but that came from the fact-like thing when even bold looked very scary in the editor).
From that point of view workload of admins and moderators is overrated and it isn’t important at all. They are for users, and forums are for users. Forums aren’t made to do living of staff more comfortable and at same time users are getting more harder time
But again. Do not enable that until RTE side is mature enough 
Which default buttons are simply broken? We have a bug report for code blocks, but I’m not aware of other issues from the default composer toolbar items, so unless they’re reported (preferably on separate topics) they’ll hardly be fixed.
2 Likes
I think you misunderstood me.
Moderators wouldn’t be moderators if they didn’t want to work for users. Moderators can spend all of their free time or a significant amount of their free time on helping users and moderating, including accepting or rejecting posts, reading long AI-generated posts to find out if they are AI-generated so they can make sure only real users’ posts get the deserved attention, and formatting posts so other users will at least try to help even if they can’t. They also help users so that next time they can write their posts better. So it is far from trying to get a comfortable environment for moderators while making things harder for users. Quite the opposite. But they can make things easier for users only if they have time and if they have working tools. Making things harder for moderators will eventually make things harder for users as well.
So my point is exactly that moderators see and understand why WYSIWYG could be a good feature, but if the overall effect is that posts are broken, unreadable, and helpers (including moderators) can only ask the users looking for help to format their posts because only they could know what the original content was and they have the file or terminal output where they copied it from, then people operating the forum have to make decisions that will get the most out of the features and at least temporarily disable what makes things worse and harder for everyone.
Users often ask a question, and if they see their post was broken and we ask them to fix it because they can do it only, they go to StackOverflow or anywhere else.
My comment on markdown that you quoted was only to say that it was the original problem that moderators could continue to handle until the Rich Text editor is fixed instead of having multiple new problems and still have to handle the old, original, since even if people started with the Rich Text, I saw signs that they switched back to Markdown and that broke the post.
So while focusing on helping users, I was talking about how that can be done and how sometimes admins may need to decide what is best for the community. Similarly, how you wouldn’t leave products in grocery stores that make people sick because you want to give them a choice. You would call the product back and investigate.
I did not It is hosted by Discourse and was enabled.
Turning on the new composer
The rich editor is enabled by default for all communities . When you or your members open the composer, you’ll notice a toggle in the toolbar. This lets you switch between the classic Markdown-only mode and the new rich text editor.
But this specific case is not important. It can be discussed in its own bug report. I just wanted to share my thoughts about when and why making a feature optional could be useful in general, even if it is disabling Markdown or Rich Text. I hope I could clarify it, and I’m sorry I confused you in the original post. 
