إدراج قائمة منسدلة جديدة لإجراءات محرر "نوع المنشور"

إعادة تصميم المحرر خلف enable_new_composer_actions

يُقدّم هذا تحديثًا لتجربة المحرر المعاد تصميمها ويُطلقها خلف تغيير تجريبي جديد (alpha upcoming-change). مع إيقاف العلم (الافتراضي)، لا يحدث أي تغيير مرئي. يمكن للمسؤولين الاختيار للانضمام عبر صفحة التغييرات القادمة في لوحة الإدارة.

التغييرات عند تفعيل العلم

  • قائمة منسدلة موحدة للإجراءات. تم استبدال قائمة composer-actions القديمة المبنية على SelectKit بمكون Glimmer/DMenu جديد (composer-actions-new.gjs). لا تزال تعرض جميع صفوف تبديل الوضع نفسها (الرد على الموضوع، الرد كموضوع جديد، إنشاء رسالة خاصة، إلخ) مع تسميات وأيقونات أوضح.

  • التبديلات تظهر مع الإجراءات. تُعرض خيارات «همس» / «بدون تنبيه» / «غير مدرج» الآن كعناصر <DToggleSwitch> في أسفل القائمة المنسدلة نفسها — بدون قائمة أزرار مركبة منفصلة. تبقى حالة التبديل ثابتة عند تبديل الوضع (مثلًا: تفعيل الهمس → التبديل من «الرد على موضوع» إلى «الرد على منشور» → لا يزال الوضع همسًا).

  • شارة مؤشر الهمس. يوجد زر صغير على يمين زر القائمة المنسدلة يعرض حالة الهمس الحالية في نسختين بصريتين: --public (لون ثانوي، أيقونة عين، «سيظهر الرد») و --whispering (خلفية باللون المتوسط/المنخفض جدًا للون الأساسي، أيقونة عين مشطوبة، «في وضع الهمس»). عند النقر عليه يتم تبديل وضع الهمس — عبر نفس مسار الكود المستخدم داخل القائمة المنسدلة، مما يضمن تزامن الحالتين. كما تتغير أيقونة الزر نفسه إلى far-eye-slash عند تفعيل الهمس.

  • تجربة تحرير المنشورات. عند تحرير منشور، تنكمش القائمة المنسدلة لتصبح تسمية ثابتة بدون سهم (أيقونة قلم + «تحرير المنشور»). زر «إضافة سبب التحرير» الذي كان موجودًا سابقًا في مكان آخر ضمن واجهة المحرر تم دمجه في هذا الزر الثابت كزر قابل للنقر باسم «صف تحريرك»؛ عند النقر عليه، يتم استبدال التسمية بحقل إدخال نصي مرتبط بـ composer.editReason مع التركيز عليه تلقائيًا.

    • editing
  • واجهة المحرر. تم إزالة النص/الـ span المسمى .action-title — حيث يعرض زر القائمة المنسدلة نفسه الوضع الحالي.

  • روابط المنشورات/المواضيع ستظهر فقط عند الضرورة. سيظهر رابط الموضوع عند التنقل بعيدًا عن الموضوع، وسيظهر رابط المنشور عند التمرير بعيدًا عن المنشور أو التنقل بعيدًا عنه.

ملاحظات لمطوري الإضافات

المكون الجديد ليس فئة فرعية من SelectKit، لذا لا تصل إليه واجهات البرمجة القديمة للإضافات. لدعم كلتا الحالتين (مع العلم مفعّل أو معطل) خلال هذه المرحلة التجريبية، يجب على الإضافات تسجيل كلا الواجهتين:

واجهة قديمة (تعمل على المكون القديم فقط) واجهة جديدة (تعمل على المكون الجديد فقط)
api.modifySelectKit("composer-actions").appendContent(...) api.registerValueTransformer("composer-actions-content", ({ value, context }) => { value.push(...); return value; })
api.modifyClass("component:composer-actions", { fooSelected(options, model) { ... } }) api.registerBehaviorTransformer("composer-actions-on-select", ({ context, next }) => { if (context.actionId === "foo") { ...; return; } next(); })

شكل الصف ({ name, description, icon, id }) متطابق في كلتا الحالتين. يستلم محوّل السلوك { actionId, options, model } في سياقه.

:double_exclamation_mark: الإضافات التي تسجل فقط الواجهات القديمة ستختفي صامتًا من المحرر بمجرد تفعيل المسؤول للعلم. أما الإضافات التي تسجل فقط المحولات الجديدة فستكون غير مرئية طالما العلم معطل (وهو الوضع الافتراضي للجميع عند الدمج).

المراجع:

  • discourse-post-voting/extend-composer-actions.js — مثال عملي على التسجيل المزدوج (ضمن النواة)

  • discourse-staff-alias — طلب سحب منفصل يضيف التسجيل المزدوج هناك

  • transformers.js — اسمَا محوّل السلوك الجديدين

ملاحظات التوزيع

  • حالة العلم هي تجريبية (alpha) — مخصصة للاختبار الداخلي فقط.

  • يجب على الإضافات التي تتكامل مع إجراءات المحرر إضافة التسجيل المزدوج قبل الترقية إلى beta/stable.

  • الاختبارات تغطي الحالتين: تغطي المواصفات الحالية للقبول/النظام حالة العلم المعطل؛ بينما تغطي ملفات *-new-test.js الشقيقة حالة العلم المفعّل (بالإضافة إلى محددات DOM للمكون الجديد الخاصة بالقائمة المنسدلة الموحدة، عناصر التبديل، شارة الهمس، وشرائح التسمية المنقسمة).

8 إعجابات