ברצוננו להגדיר את העורך כך שאפשרות Markdown לא תהיה זמינה**. משתמשים לא אמורים **להיות מסוגלים לבחור סוגי עורך שונים, ויש להגדיר טקסט עשיר כברירת המחדל.
כעת יש לי הרשאות מנהל. מהי הדרך הטובה ביותר להגדיר את הדברים?
לא הצלחתי למצוא את ההגדרות הרלוונטיות
פתרתי את זה באמצעות MutationObserver
לייק 1
תודה שביקשת זאת, אין אפשרות כזו כרגע, אבל אנחנו שוקלים להוסיף אחת
אולי @renato או @david יכולים לעזור להמציא רכיב פשוט לעשות זאת שלא מסתמך על mutation observer, זה מרגיש שביר
5 לייקים
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 לייקים
The rich text editor mode is also now the default:
2 לייקים
עורך הטקסט העשיר זמין בכל האתרים, ותוכל להשתמש בהגדרת מצב ברירת מחדל של כתיבה כדי לקבוע מה חברי הקהילה יראו כאשר הם פותחים את עורך הכתיבה בפעם הראשונה. כברירת מחדל, הוא מוגדר לטקסט עשיר.
עם זאת, חברי הקהילה יכולים להחליט להשתמש במתג עורך הכתיבה כדי לחזור למצב Markdown. לאחר מכן, עורך הכתיבה יזכור זאת כהעדפה שלהם, ולכן הוא ייפתח מחדש במצב Markdown עד אם/כאשר הם יעברו בחזרה לטקסט עשיר.
הרעיון כאן הוא שאנו רוצים לאפשר לחברי הקהילה לכתוב בעורך הכתיבה שעובד הכי טוב עבורם — מנהלי מערכת מכירים את הקהילות שלהם ויכולים לבצע בחירה סבירה לגבי איזו ברירת מחדל הגיונית ביותר, אך חברי הקהילה צריכים להיות מסוגלים לבחור מצב שונה אם הוא עובד טוב יותר עבורם.
6 לייקים
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. 
8 לייקים
נשמע שמצאת פתרון שעובד היטב עבור הצרכים הספציפיים של הקהילה שלך - זה נהדר!
3 לייקים
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 לייקים
ולא לדבר על כך שפונקציות מרובות עדיין לא עובדות, מה שיכול לבלבל אנשים מסוימים. ניסיתי להבין מדוע \[grid\] (פונקציה שמעולם לא ראיתי) לכאורה כבר לא עובדת עבור מישהו, וגיליתי שהיא פשוט לא עובדת ב-Rich למרות שהיא לא מוזכרת בשום מקום. בנוסף לכפתורים ברירת המחדל שפשוט שבורים. עד שכל הפונקציות יעבדו בפועל לדעתי עדיף שיהיה כאופציה לכיבוי. אני אישית לא אשתמש בזה, אבל ברור שחלק מהאתרים ירצו את זה.
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 לייקים
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. 
לייק 1