Wir möchten den Editor so konfigurieren, dass Markdown keine verfügbare Option ist. Benutzer sollen nicht in der Lage sein, verschiedene Editortypen auszuwählen, und Rich-Text soll als Standard festgelegt werden.
Ich habe jetzt Administratorrechte. Was ist der beste Weg, die Dinge einzurichten?
Ich konnte die relevanten Einstellungen nicht finden.
Ich habe es mit einem MutationObserver gelöst.
Vielen Dank für diese Anfrage, es gibt momentan keine Option, aber wir ziehen in Betracht, eine hinzuzufügen.
Vielleicht können @renato oder @david helfen, eine einfache Komponente zu entwickeln, die dies ermöglicht und nicht auf Mutation Observer angewiesen ist, da sich das anfühlt, als wäre es anfällig.
Alternativ könnten Sie den Schalter zum Umschalten des Editors einfach mit CSS ausblenden. Ich stelle mir vor, das ist etwas einfacher, als einen MutationObserver zu verwenden.
Installieren Sie dazu einfach eine neue Komponente hier: https://discourse.yoursite.com/admin/config/customize/components
Fügen Sie dann einen kleinen CSS-Schnipsel in den Code dieser Komponente ein, der wie folgt aussieht:
.composer-toggle-switch {
display: none;
}
Ich habe dies verwendet, um den standardmäßigen Markdown-Editor zu erzwingen, da der Rich-Text-Editor (noch) nicht gut mit dem Discourse Math-Plugin funktioniert.
Der Rich-Text-Editor-Modus ist jetzt ebenfalls der Standard:
Der Rich-Text-Editor ist auf allen Websites verfügbar, und Sie können die Einstellung Standard-Kompositionsmodus verwenden, um zu bestimmen, was Ihre Mitglieder sehen, wenn sie den Komponisten zum ersten Mal öffnen. Er ist standardmäßig auf Rich-Text eingestellt.
Mitglieder können jedoch den Komponisten-Schalter verwenden, um zum Markdown-Modus zurückzukehren. Der Komponist merkt sich dies dann als bevorzugten Modus, sodass er im Markdown-Modus wieder geöffnet wird, bis sie wieder zum Rich-Text-Modus wechseln.
Die Idee ist, dass wir den Mitgliedern erlauben möchten, im Komponisten zu schreiben, der für sie am besten funktioniert – Administratoren kennen ihre Communities und können eine vernünftige Wahl treffen, welcher Standard am sinnvollsten ist, aber Mitglieder sollten wählen können, wenn ein anderer Modus für sie besser funktioniert.
Ich glaube, das mag für die meisten Foren das vernünftige Verhalten sein. Ich benutze mein Forum jedoch als Q&A-Seite für meine Studenten, die Mathematik, Statistik und Data Science studieren. Das Erlernen von Markdown und LaTeX ist Teil des Ziels.
Ich habe keinen Zweifel daran, dass viele von ihnen den Rich-Text-Editor nutzen wollen. Sie müssen jedoch wirklich den Markdown-Editor nutzen. Daher bin ich froh, dass ich dies erzwingen kann, indem ich den Markdown-Editor als Standard festlege und den Umschalter mit CSS ausblende. 
Das klingt, als hätten Sie eine Lösung gefunden, die gut zu den spezifischen Bedürfnissen Ihrer Community passt – das ist großartig!
Ich verstehe nicht. Das Update überschreibt unsere vorherigen Standardeinstellungen. Das hat bei mir Probleme mit CSS verursacht.
Ich versuche jetzt, Rich Text zumindest vorerst vollständig zu deaktivieren.
@mcmcclur Das hat bei mir funktioniert, um den Schalter auszublenden. Danke!!
.composer-toggle-switch {
display: none;
}
Ich habe jetzt solche Angst vor Updates. Jedes Mal führt das Aktualisieren von Discourse kürzlich zu zusätzlicher Arbeit mit diesen erzwungenen Überschreibungen/Änderungen und Ergänzungen. 
Es gibt natürlich einen anderen Weg, den man wählen kann – male dich nicht selbst in die Ecke 
Ich meine, lass die Benutzer entscheiden, was sie wollen, und mach keine endgültigen Regeln. Das nimmt viele Gründe zur Angst.
Genau. Ich stimme zu, das sollte auch für Forenbesitzer gelten. Konnte mich nicht entscheiden. Aktualisiert und, boom… es hat sich für mich geändert und mit einem unbeabsichtigten CSS-Problem.
Aber ja, ich werde es zurückbringen, sobald das gelöst ist. Aber nicht, indem ich es für alle Benutzer auf den Rich-Text-Editor umstelle, sondern indem ich sie darüber informiere, dass sie eine neue Option haben und entscheiden können.
Hallo Lindsey,
Ich verstehe Ihren Standpunkt, aber lassen Sie mich erklären, warum ich denke, dass das Deaktivieren dieser Funktion (oder einer anderen) nützlich sein könnte, zumindest bis sie lange genug getestet wurde, um zu sehen, ob sie stabil ist und nur wenige oder gar keine Probleme gemeldet werden.
Diese Funktion betrifft nicht nur den Benutzer, der seinen Beitrag schreibt, obwohl er tatsächlich Probleme beheben könnte, bevor er seine Nachricht postet, vorausgesetzt, er findet eine Lösung, um sie richtig zu posten.
Ich denke, einige Benutzer bemerken nicht einmal, dass sie sich im Rich-Text-Modus befinden. Mir ist es nicht aufgefallen, als ich zum ersten Mal meinen vorherigen Fehlerbericht hier schrieb. Ich sage nicht, dass es nicht auffällig ist, aber wenn man nicht viel Formatierung benötigt, kann es wie jeder Text aussehen. Das Sternchenzeichen (*) könnte auf manchen Bildschirmen mit einem Aufzählungspunkt in gerendertem HTML verwechselt werden, sodass Benutzer an einem langen Beitrag arbeiten, feststellen, dass etwas kaputt ist, zum Markdown wechseln und es schlimmer machen könnten (wie ich gestern bemerkt habe und in Rich Text editor in topics breaks white-space characters in multiple ways erwähnt habe).
Dann wollen sie nicht viel Zeit mit der Behebung ihres Beitrags verbringen, sondern senden ihn einfach ab, in der Hoffnung, dass er verständlich ist.
Dann arbeiten Moderatoren und Helfer mehr daran, die Frage zu verstehen, bitten die Benutzer, ihren Beitrag zu korrigieren, erklären ihnen, dass sie den Rich-Text-Modus nicht verwenden sollten, wenn sie Code teilen. Das bedeutet viel zusätzliche Kommunikation und Zeit anstelle von Hilfe, während wir auf korrigierte Codeblöcke warten. Das ist wichtig in einem Forum, in dem die meisten Beiträge eine Art von Codeblöcken enthalten oder enthalten sollten, aber die Benutzer waren mit Markdown nicht vertraut (was mich überraschte, aber das ist die Realität ). Der Rich-Text-Editor könnte also tatsächlich eine großartige Ergänzung sein, und so haben wir ihn zuerst betrachtet, obwohl ich Markdown immer noch bevorzugen würde, aber warum nicht anderen Benutzern die Wahl lassen, was sie mögen. Also ja, ich stimme zu.
Aber in einigen Fällen müssen Moderatoren oder Administratoren entscheiden, ob eine Funktion mehr Probleme verursacht, als sie löst. Daher glaube ich, dass sie sie vorübergehend deaktivieren können sollten, bis die Funktion stabil genug ist, um sie wieder zu aktivieren. Benutzer, die Hilfe suchen, wissen nicht unbedingt, welcher Editor-Modus für sie am besten ist, wenn sie nichts von den Fehlern wissen.
Nun würde ich nicht daran denken, die Schaltflächen „Fett“ oder „Zitat“ zu deaktivieren, da diese Schaltflächen sehr wenig bewirken und es sehr einfach ist zu bemerken, wenn etwas schief geht. Aber ich sehe, dass es mehrere Berichte über den Rich-Text-Editor gab. Es ist eine potenziell großartige Funktion, kann aber auch viel kaputt machen. Leute hatten auch Probleme mit Markdown, aber das ist in Ordnung, wir wissen es bereits und können damit umgehen, wie wir es zuvor getan haben.
In einigen Fällen versuchen Moderatoren, bei der Formatierung zu helfen und nicht nur einen Formatierungsleitfaden zu verlinken, sondern auch die Nachricht für sie zu korrigieren. Das kann besonders nützlich sein, wenn sie keine Zeit hätten, ihren eigenen Beitrag zu korrigieren, als neue Benutzer oder wenn der Tag bereits vergangen ist, seit sie die Nachricht gesendet haben. Wenn der Rich-Text-Modus nicht stabil ist, kann ich mir vorstellen, dass sie ihren Beitrag bearbeiten und ihn kaputt machen, anstatt zu helfen.
Daher verstehe ich die Absicht, Benutzern die Entscheidung zu überlassen, was sie zum Schreiben ihres Beitrags verwenden möchten, aber es gibt auch eine andere Seite. Die Tatsache, dass Benutzer möglicherweise nicht wissen, welchen Editor sie wollen oder welche Probleme sie verursachen werden, und sie einfach viel mehr Arbeit für Moderatoren machen und auch eine schlechte Erfahrung im Forum haben, die durch vorübergehendes Deaktivieren der Funktion hätte gelöst werden können.
Ich habe von der CSS-basierten Lösung gelesen. Das Problem ist, dass, obwohl wir CSS für die Anpassung verwenden, ich auch weiß, dass CSS auch Dinge kaputt machen kann, also versuche ich, CSS nicht zu verwenden, es sei denn, es ist absolut notwendig. Auf diese Weise kann ich vermeiden, dass die Funktion nach einem Discourse-Upgrade wieder erscheint oder wenn jemand zusätzliches CSS für etwas Unrelated hinzufügt und nicht bemerkt, dass es die Deaktivierung einer Funktion beeinträchtigt.
Ich hoffe, ich konnte es klar genug beschreiben.
Update:
Als ich nach einer Benachrichtigung zurückkam, stellte ich fest, dass ich nicht genau dasselbe wie der OP geschrieben hatte, aber ich glaube, der Hauptpunkt bleibt derselbe: Ich kann mir vorstellen, dass Forenadministratoren einige Funktionen deaktivieren möchten, wenn diese viele Probleme verursachen. Ob es MarkDown oder Rich Text oder die Möglichkeit ist, zwischen ihnen zu wechseln, nachdem ein Beitrag begonnen wurde, ist weniger wichtig.
Ganz zu schweigen davon, dass mehrere Funktionen noch nicht funktionieren, was für manche Leute verwirrend sein kann. Ich habe gerade versucht herauszufinden, warum \[grid\] (eine Funktion, die ich noch nie gesehen habe) angeblich für jemanden nicht mehr funktionierte, und festgestellt, dass sie in Rich einfach nicht funktioniert, obwohl dies nirgendwo erwähnt wird. Dazu kommen die Standard-Buttons, die einfach kaputt sind. Solange nicht alle Funktionen tatsächlich funktionieren, wäre es meiner Meinung nach besser, sie als Option deaktivieren zu können. Ich persönlich würde sie nicht nutzen, aber es ist klar, dass einige Websites sie wollen würden.
Nun, die Mehrheit hatte viele Probleme mit Markdown, weil sie nicht wissen, wie man es benutzt. Das ist der Hauptgrund, warum WYSIWYG so dringend benötigt wurde. Und du hast gesagt, dass selbst grundlegende Werkzeuge selten benutzt werden (aber das kam von der Tatsachen-Sache, als selbst Fett in der Bearbeitung sehr beängstigend aussah).
Von diesem Standpunkt aus ist die Arbeitsbelastung von Administratoren und Moderatoren überbewertet und überhaupt nicht wichtig. Sie sind für die Benutzer da, und Foren sind für die Benutzer da. Foren sind nicht dazu da, das Leben des Personals angenehmer zu gestalten, und gleichzeitig haben die Benutzer eine härtere Zeit
Aber wieder. Aktiviere das nicht, bis die RTE-Seite ausgereift ist 
Welche Standard-Buttons sind kaputt? Wir haben einen Fehlerbericht für Codeblöcke, aber mir sind keine anderen Probleme mit den Standard-Toolbar-Elementen des Composers bekannt. Wenn sie also nicht gemeldet werden (vorzugsweise in separaten Themen), werden sie kaum behoben werden.
Ich glaube, Sie haben mich missverstanden.
Moderatoren wären keine Moderatoren, wenn sie nicht für die Benutzer arbeiten wollten. Moderatoren können ihre gesamte Freizeit oder einen erheblichen Teil ihrer Freizeit damit verbringen, Benutzern zu helfen und zu moderieren, einschließlich der Annahme oder Ablehnung von Beiträgen, dem Lesen langer KI-generierter Beiträge, um festzustellen, ob sie KI-generiert sind, damit sie sicherstellen können, dass nur Beiträge echter Benutzer die verdiente Aufmerksamkeit erhalten, und dem Formatieren von Beiträgen, damit andere Benutzer zumindest versuchen zu helfen, auch wenn sie es nicht können. Sie helfen auch Benutzern, damit sie ihre Beiträge beim nächsten Mal besser schreiben können. Es ist also weit davon entfernt, ein komfortables Umfeld für Moderatoren zu schaffen und es den Benutzern schwerer zu machen. Ganz im Gegenteil. Aber sie können es den Benutzern nur erleichtern, wenn sie Zeit und funktionierende Werkzeuge haben. Wenn es für Moderatoren schwieriger wird, wird es letztendlich auch für die Benutzer schwieriger.
Mein Punkt ist also genau der, dass Moderatoren sehen und verstehen, warum WYSIWYG eine gute Funktion sein könnte, aber wenn die Gesamtauswirkung darin besteht, dass Beiträge kaputt und unleserlich sind und Helfer (einschließlich Moderatoren) die Benutzer, die Hilfe suchen, nur bitten können, ihre Beiträge zu formatieren, weil nur sie wissen können, was der ursprüngliche Inhalt war, und sie die Datei oder die Terminalausgabe haben, von der sie kopiert haben, dann müssen die Leute, die das Forum betreiben, Entscheidungen treffen, die das Beste aus den Funktionen herausholen und vorübergehend das deaktivieren, was es für alle schlechter und schwieriger macht.
Benutzer stellen oft eine Frage, und wenn sie sehen, dass ihr Beitrag kaputt ist und wir sie bitten, ihn zu reparieren, weil nur sie es können, gehen sie zu StackOverflow oder anderswo hin.
Mein Kommentar zu Markdown, den Sie zitiert haben, sollte nur sagen, dass dies das ursprüngliche Problem war, das Moderatoren weiterhin handhaben konnten, bis der Rich-Text-Editor repariert ist, anstatt mehrere neue Probleme zu haben und immer noch das alte, ursprüngliche handhaben zu müssen, da selbst wenn die Leute mit Rich Text begonnen haben, sah ich Anzeichen dafür, dass sie zu Markdown zurückgekehrt sind und das den Beitrag kaputt gemacht hat.
Während ich mich also darauf konzentrierte, Benutzern zu helfen, sprach ich darüber, wie das geschehen kann und wie Administratoren manchmal entscheiden müssen, was für die Community am besten ist. Ähnlich wie Sie keine Produkte in Lebensmittelgeschäften lassen würden, die Menschen krank machen, weil Sie ihnen eine Wahl geben wollen. Sie würden das Produkt zurückrufen und untersuchen.
Das habe ich nicht getan Es wird von Discourse gehostet und war aktiviert.
Den neuen Composer aktivieren
Der Rich-Text-Editor ist standardmäßig für alle Communities aktiviert. Wenn Sie oder Ihre Mitglieder den Composer öffnen, sehen Sie in der Symbolleiste eine Umschaltfläche. Damit können Sie zwischen dem klassischen Modus nur mit Markdown und dem neuen Rich-Text-Editor wechseln.
Aber dieser spezielle Fall ist nicht wichtig. Er kann in einem eigenen Fehlerbericht besprochen werden. Ich wollte nur meine Gedanken darüber teilen, wann und warum es nützlich sein kann, eine Funktion optional zu machen, auch wenn es darum geht, Markdown oder Rich Text zu deaktivieren. Ich hoffe, ich konnte es klären, und es tut mir leid, dass ich Sie im ursprünglichen Beitrag verwirrt habe. 
