نود تهيئة المحرر بحيث لا يكون Markdown خيارًا متاحًا**. يجب **ألا يتمكن المستخدمون من تحديد أنواع مختلفة من المحرر، ويجب تعيين النص المنسق كإعداد افتراضي.
لدي الآن حقوق المسؤول. ما هي أفضل طريقة لإعداد الأمور؟
لم أتمكن من العثور على الإعدادات ذات الصلة
لقد حلت المشكلة باستخدام MutationObserver
إعجاب واحد (1)
شكرًا لطلبك هذا، لا يوجد خيار في الوقت الحالي ولكننا نفكر في إضافة خيار
ربما @renato أو @david يمكنهما المساعدة في ابتكار مكون بسيط للقيام بذلك لا يعتمد على مراقب التحويل (mutation observer)، هذا يبدو هشًا
5 إعجابات
بدلاً من ذلك، يمكنك ببساطة إخفاء مفتاح تبديل المحرر باستخدام CSS. أتخيل أن هذا أبسط قليلاً من استخدام MutationObserver.
للقيام بذلك، قم ببساطة بتثبيت مكون جديد هنا: https://discourse.yoursite.com/admin/config/customize/components
ثم، أضف مقتطف CSS صغيرًا إلى الكود الخاص بهذا المكون يبدو كالتالي:
.composer-toggle-switch {
display: none;
}
لقد استخدمت هذا لفرض محرر Markdown الافتراضي، نظرًا لأن المحرر الغني لا يعمل (حتى الآن) بشكل جيد مع المكون الإضافي Discourse Math.
4 إعجابات
وضع محرر النصوص المنسقة هو أيضًا الوضع الافتراضي الآن:
إعجابَين (2)
محرر النصوص المنسقة متاح في جميع المواقع، ويمكنك استخدام إعداد وضع التأليف الافتراضي لتحديد ما سيراه أعضاؤك عند فتح أداة التأليف لأول مرة. تم تعيينه على النص المنسق افتراضيًا.
ومع ذلك، يمكن للأعضاء اتخاذ قرار باستخدام تبديل أداة التأليف للعودة إلى وضع Markdown. ستقوم أداة التأليف بعد ذلك بتذكر هذا كوضعهم المفضل، لذلك ستُعاد فتحها في وضع Markdown حتى إذا/عندما يعودون إلى النص المنسق.
الفكرة هنا هي أننا نريد السماح للأعضاء بالكتابة في أداة التأليف التي تعمل بشكل أفضل بالنسبة لهم - يعرف المسؤولون مجتمعاتهم ويمكنهم اتخاذ قرار معقول بشأن أي افتراضي هو الأكثر منطقية، ولكن يجب أن يتمكن الأعضاء من اختيار وضع مختلف إذا كان يعمل بشكل أفضل بالنسبة لهم.
6 إعجابات
أعتقد أن هذا قد يبدو سلوكًا معقولًا لمعظم المنتديات. ومع ذلك، أستخدم منتدى الخاص بي كموقع للأسئلة والأجوبة لطلاب الكلية الذين يدرسون الرياضيات والإحصاء وعلوم البيانات. تعلم Markdown و LaTeX هو جزء من الهدف.
ليس لدي شك في أن الكثير منهم يريدون استخدام المحرر الغني. ومع ذلك، فهم يحتاجون حقًا إلى استخدام محرر Markdown. لذلك، يسعدني أن أتمكن من فرض ذلك عن طريق تعيين محرر Markdown كافتراضي وإخفاء مفتاح التبديل باستخدام CSS. 
8 إعجابات
يبدو أنك وجدت حلاً يعمل بشكل جيد لاحتياجات مجتمعك الخاصة - هذا رائع!
3 إعجابات
أنا لا أفهم. التحديث يتجاوز الإعدادات الافتراضية السابقة لدينا. هذا خلق مشاكل مع CSS بالنسبة لي.
أنا الآن أحاول تعطيل النص المنسق تمامًا في الوقت الحالي على الأقل.
@mcmcclur نجح هذا معي لإخفاء التبديل. شكرًا!!
.composer-toggle-switch {
display: none;
}
أصبحت خائفًا جدًا من التحديثات الآن. في كل مرة مؤخرًا، يؤدي تحديث discouse إلى عمل إضافي مع هذه التجاوزات/التغييرات والإضافات القسرية. 
هناك بالطبع طريق آخر للاختيار - لا ترسم نفسك في الزاوية 
أعني، دع المستخدمين يقررون ما يريدون ولا تضع قواعد صارمة. هذا يزيل الكثير من أسباب الخوف.
بالضبط. أتفق، يجب أن ينطبق هذا على مالكي المنتديات أيضًا. لم أتمكن من اتخاذ القرار. تم التحديث، وفجأة… تغير الأمر بالنسبة لي مع مشكلة CSS غير مقصودة.
لكن نعم، سأعيده بمجرد حل ذلك. ولكن ليس عن طريق تغييره إلى محرر النصوص المنسقة لجميع المستخدمين، بل عن طريق إخبارهم بأن لديهم خيارًا جديدًا ويمكنهم اتخاذ القرار.
مرحباً ليندسي،
أتفهم وجهة نظرك، ولكن دعني أشرح لماذا أعتقد أن تعطيل هذه الميزة (أو أي ميزة أخرى) يمكن أن يكون مفيدًا على الأقل حتى يتم اختبارها لفترة كافية لمعرفة ما إذا كانت مستقرة ويتم الإبلاغ عن عدد قليل جدًا من المشكلات إن وجدت.
هذه الميزة لا تؤثر فقط على المستخدم الذي يكتب رسالته، على الرغم من أنه يمكنه بالفعل إصلاح أي مشكلة قبل نشر رسالته بافتراض أنه يجد حلاً لنشرها بشكل صحيح.
أعتقد أن بعض المستخدمين لا يلاحظون حتى أنهم في وضع النص الغني. لم ألاحظ ذلك عندما بدأت في كتابة تقرير الخطأ السابق الخاص بي هنا. لا أقول إنه غير ملحوظ، ولكن عندما لا تحتاج إلى الكثير من التنسيق، يمكن أن يبدو كأي نص. يمكن الخلط بين حرف النجمة (*) كنقطة تعداد في HTML المعروض على بعض الشاشات، لذلك يعمل المستخدمون على منشور طويل، ويدركون أن شيئًا ما قد تعطل، وينتقلون إلى Markdown وقد يجعلون الأمر أسوأ (كما لاحظت بالأمس وذكرت في Rich Text editor in topics breaks white-space characters in multiple ways).
ثم لا يريدون قضاء الكثير من الوقت في إصلاح منشورهم، لذا يرسلونه على أمل أن يكون مفهومًا.
ثم يعمل المشرفون والمساعدون بشكل أكبر لفهم السؤال، ويطلبون من المستخدمين إصلاح منشوراتهم، ويشرحون لهم أنه لا ينبغي عليهم استخدام وضع النص الغني عند مشاركة التعليمات البرمجية. هذا يعني الكثير من الاتصالات والوقت الإضافي بدلاً من المساعدة، بينما ننتظر كتل التعليمات البرمجية الثابتة. هذا مهم في منتدى حيث تحتوي معظم المشاركات على نوع من كتل التعليمات البرمجية أو إذا لم يكن الأمر كذلك، فيجب أن تحتوي عليها، ولكن المستخدمين لم يكونوا على دراية بـ Markdown (وهو ما فاجأني، ولكن هذه هي الحقيقة ). لذلك يمكن أن يكون محرر النص الغني إضافة رائعة بالفعل، وهذا هو كيف نظرنا إليه في البداية على الرغم من أنني ما زلت أفضل Markdown، ولكن لماذا لا نسمح للمستخدمين الآخرين باختيار ما يحبونه. لذا نعم، أنا أتفق.
ولكن في بعض الحالات، يتعين على المشرفين أو المسؤولين تحديد ما إذا كانت الميزة تسبب مشاكل أكثر مما تحل، لذلك أعتقد أنه يجب أن يكونوا قادرين على تعطيلها مؤقتًا حتى تصبح الميزة مستقرة بما يكفي لتفعيلها مرة أخرى. لن يعرف المستخدمون الذين يأتون للمساعدة بالضرورة أي وضع محرر هو الأفضل لهم، عندما لا يعرفون عن الأخطاء.
الآن لن أفكر في محاولة تعطيل أزرار “غامق” أو “اقتباس” لأن هذه الأزرار تفعل القليل جدًا ومن السهل جدًا ملاحظة ما إذا كان هناك خطأ ما. لكنني أرى أنه كانت هناك تقارير متعددة حول محرر النص الغني. إنها ميزة رائعة محتملة، ولكنها يمكن أن تسبب الكثير من المشاكل أيضًا. واجه الأشخاص أيضًا مشاكل مع MarkDown، ولكن هذا لا بأس، فنحن نعرف بالفعل ويمكننا التعامل معها كما فعلنا من قبل.
في بعض الحالات، يحاول المشرفون المساعدة في التنسيق وليس فقط ربط دليل التنسيق، ولكن أيضًا إصلاح الرسالة لهم. يمكن أن يكون هذا مفيدًا خاصة عندما لا يكون لديهم وقت لإصلاح منشورهم الخاص كمستخدمين جدد أو عندما مر يوم واحد منذ إرسالهم للرسالة. إذا لم يكن وضع النص الغني مستقرًا، يمكنني أن أتخيل تعديل منشورهم وكسره بدلاً من المساعدة.
لذلك أنا أتفهم تمامًا نية السماح للمستخدمين بتحديد ما يريدون استخدامه لكتابة منشورهم، ولكن هناك جانب آخر لذلك. حقيقة أن المستخدمين قد لا يعرفون أي محرر يريدون أو ما هي المشاكل التي سيسببونها، وأنهم ببساطة يضعون المزيد من العمل على المشرفين ويحصلون أيضًا على تجربة سيئة في المنتدى كان يمكن حلها عن طريق تعطيل الميزة مؤقتًا.
قرأت عن الحل القائم على CSS. المشكلة هي أنه على الرغم من أننا نستخدم CSS للتخصيص، إلا أنني أعرف أيضًا أن CSS يمكن أن يسبب مشاكل أيضًا لذلك أحاول عدم استخدام CSS إلا عند الضرورة القصوى. بهذه الطريقة يمكنني تجنب ظهور الميزة مرة أخرى بعد ترقية Discourse أو عندما يضيف شخص ما CSS إضافيًا لشيء غير ذي صلة دون ملاحظة أنه يكسر تعطيل ميزة.
آمل أن أكون قد وصفت ذلك بوضوح كافٍ
تحديث:
عندما عدت بعد إشعار، أدركت أنني لم أكتب عن نفس الشيء بالضبط مثل OP، ولكنني أعتقد أن النقطة الرئيسية لا تزال كما هي: يمكنني أن أتخيل أن مسؤولي المنتدى يريدون تعطيل بعض الميزات إذا كانت تسبب الكثير من المشاكل. سواء كان MarkDown أو Rich Text أو القدرة على التبديل بينهما بعد بدء منشور أقل أهمية.
3 إعجابات
ناهيك عن أن العديد من الوظائف لا تعمل بعد، مما قد يكون مربكًا لبعض الأشخاص. كنت أحاول فقط معرفة سبب عدم عمل [grid] (وظيفة لم أرها من قبل) لشخص ما على ما يبدو، واكتشفت أنها ببساطة لا تعمل في Rich على الرغم من عدم ذكرها في أي مكان. بالإضافة إلى الأزرار الافتراضية التي لا تعمل ببساطة. حتى تعمل جميع الوظائف بالفعل في رأيي، سيكون من الأفضل أن يكون خيارًا يمكن إيقافه. أنا شخصياً لن أستخدمه، لكن من الواضح أن بعض المواقع ستريده.
حسنًا، واجهت الأغلبية الكثير من المشاكل مع markdown، لأنهم لا يعرفون كيفية استخدامه. هذا هو السبب الرئيسي الذي جعل WYSIWYG مطلوبًا بشدة. وقلت، حتى الأدوات الأساسية نادرًا ما تُستخدم (ولكن هذا جاء من حقيقة أن حتى الخط العريض بدا مخيفًا جدًا في المحرر).
من وجهة النظر هذه، فإن عبء عمل المسؤولين والمشرفين مبالغ فيه وليس مهمًا على الإطلاق. إنهم موجودون للمستخدمين، والمنتديات موجودة للمستخدمين. المنتديات ليست مصنوعة لجعل حياة الموظفين أكثر راحة وفي نفس الوقت يواجه المستخدمون وقتًا أصعب
ولكن مرة أخرى. لا تقم بتمكين ذلك حتى يصبح جانب RTE ناضجًا بما فيه الكفاية 
ما هي الأزرار الافتراضية التي بها خلل ببساطة؟ لدينا تقرير خطأ خاص بكتل التعليمات البرمجية، ولكنني لست على علم بأي مشاكل أخرى من عناصر شريط أدوات الملحن الافتراضي، لذا ما لم يتم الإبلاغ عنها (يفضل في مواضيع منفصلة) فلن يتم إصلاحها على الأرجح.
إعجابَين (2)
أعتقد أنك أسأت فهمي.
لن يكون المشرفون مشرفين لو لم يرغبوا في العمل للمستخدمين. يمكن للمشرفين قضاء كل وقت فراغهم أو جزء كبير من وقت فراغهم في مساعدة المستخدمين والإشراف، بما في ذلك قبول أو رفض المشاركات، وقراءة المشاركات الطويلة التي تم إنشاؤها بواسطة الذكاء الاصطناعي لمعرفة ما إذا كانت تم إنشاؤها بواسطة الذكاء الاصطناعي حتى يتمكنوا من التأكد من أن مشاركات المستخدمين الحقيقيين فقط تحصل على الاهتمام المستحق، وتنسيق المشاركات حتى يحاول المستخدمون الآخرون المساعدة على الأقل حتى لو لم يتمكنوا. كما أنهم يساعدون المستخدمين حتى يتمكنوا في المرة القادمة من كتابة مشاركاتهم بشكل أفضل. لذا فهو بعيد كل البعد عن محاولة خلق بيئة مريحة للمشرفين مع جعل الأمور أصعب على المستخدمين. العكس تماما. لكنهم يستطيعون جعل الأمور أسهل للمستخدمين فقط إذا كان لديهم الوقت وإذا كان لديهم أدوات عمل. جعل الأمور أصعب على المشرفين سيجعل الأمور أصعب على المستخدمين في النهاية أيضًا.
لذا فإن وجهة نظري هي بالضبط أن المشرفين يرون ويفهمون لماذا يمكن أن تكون ميزة WYSIWYG جيدة، ولكن إذا كان التأثير العام هو أن المشاركات معطلة وغير قابلة للقراءة، والمساعدون (بما في ذلك المشرفون) لا يمكنهم سوى أن يطلبوا من المستخدمين الذين يبحثون عن المساعدة تنسيق مشاركاتهم لأنهم وحدهم يمكنهم معرفة المحتوى الأصلي ولديهم الملف أو إخراج الطرفية التي نسخوا منه، فعندئذ يتعين على الأشخاص الذين يديرون المنتدى اتخاذ قرارات من شأنها تحقيق أقصى استفادة من الميزات وتعطيل ما يجعل الأمور أسوأ وأصعب على الجميع مؤقتًا على الأقل.
غالبًا ما يطرح المستخدمون سؤالًا، وإذا رأوا أن مشاركتهم معطلة وطلبنا منهم إصلاحها لأنهم وحدهم يستطيعون القيام بذلك، فإنهم يذهبون إلى StackOverflow أو أي مكان آخر.
كان تعليقي على markdown الذي اقتبسته فقط لأقول إنه كانت المشكلة الأصلية التي يمكن للمشرفين الاستمرار في التعامل معها حتى يتم إصلاح محرر النص المنسق بدلاً من وجود مشاكل جديدة متعددة ولا يزال يتعين عليهم التعامل مع المشكلة القديمة الأصلية، لأنه حتى لو بدأ الأشخاص بمحرر النص المنسق، فقد رأيت علامات على أنهم عادوا إلى Markdown وهذا كسر المشاركة.
لذلك، أثناء التركيز على مساعدة المستخدمين، كنت أتحدث عن كيفية القيام بذلك وكيف قد يحتاج المسؤولون أحيانًا إلى تحديد ما هو الأفضل للمجتمع. وبالمثل، لن تترك المنتجات في متاجر البقالة التي تجعل الناس مرضى لأنك تريد منحهم خيارًا. ستقوم بسحب المنتج والتحقيق فيه.
لم أفعل تم استضافته بواسطة Discourse وتم تمكينه.
\u003e ## تشغيل المنشئ الجديد
\u003e
\u003e محرر النص المنسق ممكّن افتراضيًا لجميع المجتمعات. عندما تفتح أنت أو أعضاؤك المنشئ، ستلاحظ تبديلًا في شريط الأدوات. يتيح لك هذا التبديل بين وضع Markdown فقط الكلاسيكي ومحرر النص المنسق الجديد.
ولكن هذه الحالة المحددة ليست مهمة. يمكن مناقشتها في تقرير خطأ خاص بها. أردت فقط مشاركة أفكاري حول متى ولماذا يمكن أن يكون جعل الميزة اختيارية مفيدًا بشكل عام، حتى لو كان ذلك يعني تعطيل Markdown أو Rich Text. آمل أن أكون قد أوضحت الأمر، وأنا آسف لأنني أربكتك في المنشور الأصلي. 
إعجاب واحد (1)