Vorremmo configurare l’editor in modo che Markdown non sia un’opzione disponibile. Gli utenti non dovrebbero poter selezionare diversi tipi di editor e il testo RTF (Rich Text Format) dovrebbe essere impostato come predefinito.
Ora ho i diritti di amministratore. Qual è il modo migliore per impostare le cose?
Non riuscivo a trovare le impostazioni pertinenti
L’ho risolto usando un MutationObserver
Grazie per averlo richiesto, al momento non c’è un’opzione, ma stiamo valutando di aggiungerne una
Forse @renato o @david possono aiutare a trovare un componente semplice per farlo che non si basi su mutation observer, che sembra fragile
In alternativa, potresti semplicemente nascondere l’interruttore del composer con il CSS. Immagino che sia un po’ più semplice che usare MutationObserver.
Per farlo, installa semplicemente un nuovo componente qui: https://discourse.yoursite.com/admin/config/customize/components
Quindi, aggiungi un piccolo snippet CSS al codice di quel componente che assomigli a questo:
.composer-toggle-switch {
display: none;
}
Ho usato questo per imporre l’editor Markdown predefinito, poiché l’editor rich text non funziona (ancora) bene con il plugin Discourse Math.
La modalità editor di testo RTF è ora anche quella predefinita:
L’editor di testo avanzato è disponibile su tutti i siti e puoi usare l’impostazione modalità di composizione predefinita per determinare ciò che i tuoi membri vedranno quando apriranno il compositore per la prima volta. È impostato su testo avanzato per impostazione predefinita.
I membri, tuttavia, possono decidere di utilizzare l’interruttore del compositore per tornare alla modalità Markdown. Il compositore ricorderà quindi questa come la loro modalità preferita, quindi si riaprirà in modalità Markdown finché non torneranno al testo avanzato.
L’idea qui è che vogliamo consentire ai membri di scrivere nel compositore che funziona meglio per loro: gli amministratori conoscono le loro community e possono fare una scelta ragionevole su quale predefinito abbia più senso, ma i membri dovrebbero essere in grado di scegliere una modalità diversa se funziona meglio per loro.
Credo che questo possa sembrare il comportamento ragionevole per la maggior parte dei forum. Io, tuttavia, uso il mio forum come sito di Q&A per i miei studenti universitari che studiano matematica, statistica e data science. Imparare Markdown e LaTeX fa parte dell’obiettivo.
Non ho dubbi che molti di loro vogliono usare l’editor rich text. Tuttavia, hanno davvero bisogno di usare l’editor Markdown. Quindi, sono contento di poterlo imporre impostando l’editor Markdown come predefinito e nascondendo l’interruttore con CSS. 
Sembra che tu abbia trovato una soluzione che funziona bene per le esigenze specifiche della tua community: è fantastico!
Non capisco. L’aggiornamento sta sovrascrivendo le nostre impostazioni predefinite precedenti. Questo mi ha creato problemi con il CSS.
Ora sto cercando di disabilitare completamente il testo RTF, almeno per ora.
@mcmcclur Ha funzionato per me per nascondere lo switch. Grazie!!
.composer-toggle-switch {
display: none;
}
Ho così tanta paura degli aggiornamenti ora. Ogni volta di recente l’aggiornamento di Discourse si traduce in lavoro extra con queste sovrascritture/modifiche e aggiunte forzate. 
Certo, c’è un altro percorso da scegliere: non dipingerti in un angolo 
Voglio dire, lascia che gli utenti decidano cosa vogliono e non stabilire regole definitive. Questo elimina molte ragioni di cui aver paura.
Esatto. Sono d’accordo, questo dovrebbe valere anche per i proprietari di forum. Non ho potuto decidere. Aggiornato e, boom… è cambiato per me e con un problema CSS non voluto.
Ma sì, lo riporterò una volta risolto. Ma non cambiando l’editor in editor di testo rich per tutti gli utenti, ma piuttosto informandoli che hanno una nuova opzione e possono decidere.
Ciao Lindsey,
Capisco il tuo punto di vista, ma lascia che ti spieghi perché penso che disabilitare questa funzionalità (o qualsiasi altra) possa essere utile almeno finché non sarà testata abbastanza a lungo da vedere che è stabile e che vengono segnalati pochissimi problemi, se non nessuno.
Questa funzionalità non influisce solo sull’utente che sta scrivendo il proprio post, anche se in effetti potrebbe correggere eventuali problemi prima di pubblicare il proprio messaggio, supponendo che trovi una soluzione per pubblicarlo correttamente.
Penso che alcuni utenti non si accorgano nemmeno di essere in modalità Rich Text. Non me ne sono accorto quando ho iniziato a scrivere il mio precedente bug report qui. Non sto dicendo che non sia evidente, ma quando non hai bisogno di molte formattazioni, potrebbe sembrare un testo normale. Il carattere asterisco (*) potrebbe essere confuso con un punto elenco in un rendering HTML su alcuni schermi, quindi gli utenti lavorano su un post lungo, si rendono conto che qualcosa si è rotto, passano a Markdown e potrebbero peggiorare le cose (come ho notato ieri e menzionato in Rich Text editor in topics breaks white-space characters in multiple ways).
Quindi non vogliono passare molto tempo a correggere il loro post, lo inviano sperando che sia comprensibile.
Poi moderatori e helper lavorano di più per capire la domanda, chiedono agli utenti di correggere il loro post, spiegano loro che non dovrebbero usare la modalità Rich Text quando condividono codice. Ciò significa molta comunicazione e tempo extra invece di aiutare, mentre aspettiamo i blocchi di codice corretti. È importante in un forum in cui la maggior parte dei post contiene qualche tipo di blocco di codice o, in caso contrario, dovrebbe contenerlo, ma gli utenti non avevano familiarità con Markdown (cosa che mi ha sorpreso, ma questa è la realtà ). Quindi l’editor Rich Text potrebbe effettivamente essere un’ottima aggiunta, ed è così che l’abbiamo vista inizialmente, anche se preferirei ancora Markdown, ma perché non lasciare che altri utenti scelgano ciò che preferiscono. Quindi sì, sono d’accordo.
Ma in alcuni casi, i moderatori o gli amministratori devono decidere se una funzionalità crea più problemi di quanti ne risolva, quindi credo che dovrebbero essere in grado di disabilitarla temporaneamente finché la funzionalità non sarà abbastanza stabile da riattivarla. Gli utenti che vengono per chiedere aiuto non sapranno necessariamente quale modalità di editor è migliore per loro, quando non conoscono i bug.
Ora non penserei di provare a disabilitare i pulsanti “grassetto” o “citazione” poiché questi pulsanti fanno molto poco ed è molto facile notare se qualcosa non va. Ma vedo che ci sono stati più segnalazioni sull’editor Rich Text. È una funzionalità potenzialmente eccezionale, ma può anche causare molti problemi. Anche le persone hanno avuto problemi con MarkDown, ma va bene, lo sappiamo già e possiamo gestirlo come abbiamo fatto in precedenza.
In alcuni casi i moderatori cercano di aiutare con la formattazione e non solo linkando una guida alla formattazione, ma anche correggendo il messaggio per loro. Può essere utile soprattutto quando non avrebbero tempo di correggere il proprio post come nuovi utenti o quando è già passato un giorno da quando hanno inviato il messaggio. Se la modalità Rich Text non è stabile, posso immaginare di modificare il loro post e romperlo invece di aiutare.
Quindi capisco perfettamente l’intenzione di lasciare che gli utenti decidano cosa vogliono usare per scrivere il loro post, ma c’è un altro lato della medaglia. Il fatto che gli utenti potrebbero non sapere quale editor vogliono o quali problemi causeranno, e semplicemente creano molto più lavoro per i moderatori e ottengono anche una brutta esperienza sul forum che avrebbe potuto essere risolta disabilitando temporaneamente la funzionalità.
Ho letto della soluzione basata su CSS. Il problema è che anche se usiamo CSS per la personalizzazione, so anche che il CSS potrebbe anche causare problemi, quindi cerco di non usare CSS a meno che non sia assolutamente necessario. In questo modo posso evitare che la funzionalità riappaia dopo un aggiornamento di Discourse o quando qualcuno aggiunge un CSS extra per qualcosa di non correlato senza accorgersi che rompe la disabilitazione di una funzionalità.
Spero di essere riuscito a descriverlo abbastanza chiaramente.
aggiornamento:
Quando sono tornato dopo una notifica, mi sono reso conto di non aver scritto esattamente della stessa cosa dell’OP, ma credo che il punto principale rimanga lo stesso: posso immaginare che gli amministratori del forum vogliano disabilitare alcune funzionalità se causano molti problemi. Sia che si tratti di MarkDown o Rich Text o della possibilità di passare dall’uno all’altro dopo aver avviato un post è meno importante.
Per non parlare di più funzioni che non funzionano ancora, il che può confondere alcune persone. Stavo solo cercando di capire perché \[grid\] (una funzione che non ho mai nemmeno visto) apparentemente non funzionasse più per qualcuno, e ho scoperto che semplicemente non funziona in Rich, anche se non è menzionato da nessuna parte. Più i pulsanti predefiniti che sono semplicemente rotti. Finché tutte le funzioni non funzioneranno davvero, secondo me sarebbe meglio come opzione disattivabile. Personalmente non la userei, ma è chiaro che alcuni siti la vorrebbero.
Beh, la maggior parte ha avuto molti problemi con markdown, perché non sanno come usarlo. Questo è il motivo principale per cui WYSIWYG era così disperatamente necessario. E hai detto, anche gli strumenti di base sono raramente usati (ma questo derivava dal fatto che anche il grassetto sembrava molto spaventoso nell’editor).
Da quel punto di vista, il carico di lavoro di amministratori e moderatori è sopravvalutato e non è affatto importante. Loro sono per gli utenti e i forum sono per gli utenti. I forum non sono fatti per rendere la vita dello staff più comoda e allo stesso tempo gli utenti hanno sempre più difficoltà
Ma di nuovo. Non abilitarlo finché il lato RTE non sarà abbastanza maturo 
Quali pulsanti predefiniti sono semplicemente rotti? Abbiamo una segnalazione di bug per i blocchi di codice, ma non sono a conoscenza di altri problemi relativi agli elementi predefiniti della barra degli strumenti del compositore, quindi a meno che non vengano segnalati (preferibilmente in argomenti separati) difficilmente verranno risolti.
Penso che tu mi abbia frainteso.
I moderatori non sarebbero moderatori se non volessero lavorare per gli utenti. I moderatori possono dedicare tutto il loro tempo libero o una parte significativa del loro tempo libero ad aiutare gli utenti e a moderare, inclusa l’accettazione o il rifiuto di post, la lettura di lunghi post generati dall’IA per scoprire se sono generati dall’IA in modo da poter garantire che solo i post dei veri utenti ricevano l’attenzione che meritano, e la formattazione dei post in modo che altri utenti almeno provino ad aiutare anche se non possono. Aiutano anche gli utenti in modo che la prossima volta possano scrivere meglio i loro post. Quindi è tutt’altro che cercare di creare un ambiente confortevole per i moderatori rendendo le cose più difficili per gli utenti. Tutt’altro. Ma possono rendere le cose più facili per gli utenti solo se hanno tempo e se hanno strumenti funzionanti. Rendere le cose più difficili per i moderatori finirà per rendere le cose più difficili anche per gli utenti.
Quindi il mio punto è esattamente che i moderatori vedono e capiscono perché WYSIWYG potrebbe essere una buona funzionalità, ma se l’effetto complessivo è che i post sono rotti, illeggibili e gli aiutanti (inclusi i moderatori) possono solo chiedere agli utenti che cercano aiuto di formattare i loro post perché solo loro potrebbero sapere quale fosse il contenuto originale e hanno il file o l’output del terminale da cui lo hanno copiato, allora le persone che gestiscono il forum devono prendere decisioni che otterranno il massimo dalle funzionalità e almeno disabiliteranno temporaneamente ciò che peggiora le cose e le rende più difficili per tutti.
Gli utenti spesso pongono una domanda e, se vedono che il loro post è stato rotto e gli chiediamo di correggerlo perché solo loro possono farlo, vanno su StackOverflow o altrove.
Il mio commento sul markdown che hai citato era solo per dire che era il problema originale che i moderatori potevano continuare a gestire finché l’editor Rich Text non fosse stato corretto, invece di avere molteplici nuovi problemi e dover ancora gestire quello vecchio e originale, poiché anche se le persone avessero iniziato con il Rich Text, ho visto segnali che sono tornati a Markdown e ciò ha rotto il post.
Quindi, mentre mi concentravo sull’aiutare gli utenti, stavo parlando di come ciò potesse essere fatto e di come a volte gli amministratori potrebbero dover decidere cosa è meglio per la comunità. Allo stesso modo, non lasceresti prodotti nei supermercati che fanno ammalare le persone perché vuoi dare loro una scelta. Ritireresti il prodotto e indagheresti.
Non l’ho fatto È ospitato da Discourse ed era abilitato.
Attivazione del nuovo composer
L’editor rich text è abilitato per impostazione predefinita per tutte le community. Quando tu o i tuoi membri aprite il composer, noterete un’opzione nella barra degli strumenti. Questo vi consente di passare dalla modalità classica solo Markdown al nuovo editor rich text.
Ma questo caso specifico non è importante. Può essere discusso nel suo proprio bug report. Volevo solo condividere i miei pensieri su quando e perché rendere una funzionalità opzionale potrebbe essere utile in generale, anche se si tratta di disabilitare Markdown o Rich Text. Spero di aver chiarito, e mi scuso se ti ho confuso nel post originale. 
