(غير موصى به) تجاوز قوالب Discourse من خلال موضوع أو إضافة

في المثالي، عند تخصيص Discourse عبر السمات/الإضافات، يجب عليك استخدام CSS، أو واجهة برمجة تطبيقات JavaScript Plugin، أو فتحات الإضافات (plugin outlets). إذا لم تنجح أي من هذه الخيارات لحالتك، فلا تتردد في فتح طلب سحب (PR) إلى نواة Discourse أو بدء موضوع في Development هنا على Meta. نحن سعداء دائمًا بمناقشة إضافة فتحات/واجهات برمجة تطبيقات جديدة لتسهيل التخصيص.

إذا استنفدت جميع الخيارات الأخرى، فقد تضطر للجوء إلى تجاوز القوالب (template overrides). تتيح لك هذه التقنية تجاوز قالب أي مكوّن Ember أو مسار (Route) بالكامل من سمة/إضافة.

:rotating_light: هذا ليس الطريقة الموصى بها لتخصيص Discourse. التغييرات اليومية في نواة Discourse ستتعارض في النهاية مع تجاوزات القوالب الخاصة بك، مما قد يتسبب في أخطاء كارثية عند عرض المنتدى.

إذا قررت اتباع هذا النهج، فتأكد من وجود عمليات اختبار آلية كافية وعمليات ضمان جودة (QA) لكشف الانحسارات (regressions). إذا كنت توزّع سمة/إضافة تتضمن تجاوزات للقوالب، فيرجى التأكد من أن مشرفي المنتدى على علم بالمخاطر المتعلقة بالاستقرار التي تحملها سمتك/إضافتك.

:rotating_light: :rotating_light: :rotating_light: تحديث أكتوبر 2023: للميزات الجديدة، تتجه Discourse بشكل متزايد نحو استخدام المكونات المكتوبة باستخدام صيغة ملف .gjs الخاصة بـ Ember. يتم تعريف قوالب هذه المكونات بشكل مضمّن (inline)، ولا يمكن تجاوزها بواسطة السمات/الإضافات.

من الآن فصاعدًا، يجب تنفيذ جميع تخصيصات القوالب باستخدام فتحات الإضافات (Plugin Outlets)

أفهم أن هذا سيتوقف عن العمل في المستقبل القريب، لكن أظهر لي الوثائق على أي حال

تجاوز قوالب المكونات (Component Templates)

لتجاوز قالب مكوّن Ember (أي شيء تحت components/* في نواة Discourse)، يجب عليك إنشاء ملف .hbs بنفس الاسم في سمة/إضافة. على سبيل المثال، لتجاوز قالب مكوّن badge-button في نواة Discourse، ستنشئ ملف قالب في سمة/إضافة في هذا الموقع:

:art: {theme}/javascripts/discourse/templates/components/badge-button.hbs

:electric_plug: {plugin}/assets/javascripts/discourse/templates/components/badge-button.hbs

يجب أن يكون التجاوز دائمًا متداخلًا داخل دليل /templates، حتى لو كان للمكوّن الأساسي قالب “موضع بجانبه” (colocated).

تجاوز قوالب المسارات (Route Templates)

يعمل تجاوز قوالب المسارات (أي جميع قوالب غير المكونات تحت templates/*) بنفس طريقة المكونات. أنشئ قالبًا بنفس الاسم في سمة/إضافة. على سبيل المثال، لتجاوز discovery.hbs في النواة، ستنشئ ملفًا مثل

:art: {theme}/javascripts/discourse/templates/discovery.hbs

:electric_plug: {plugin}/assets/javascripts/discourse/templates/discovery.hbs

التفاعل بين السمات/الإضافات المتعددة

إذا تجاوزت سمات/إضافات متعددة مثبّتة نفس القالب، فإن “الرابح” هو الذي يحمل أدنى رقم ترتيب في هذه القائمة:

  1. تجاوزات السمة (ترتفع أولوية السمة ذات “المعرّف” الأعلى)
  2. تجاوزات الإضافة (ترتفع أولوية اسم الإضافة الأبجدي الأحدث)
  3. النواة (Core)

تعني هذه الأولوية أيضًا أنه يمكنك تجاوز قوالب الإضافات من السمات. تقنيًا، يمكنك أيضًا تجاوز قوالب السمات من سمات أخرى، وقوالب الإضافات من إضافات أخرى، لكن السلوك قد يكون مفاجئًا بسبب الاعتماد على اسم الإضافة ومعرّف السمة.

كيف يعمل هذا؟

تقوم Discourse بجمع القوالب وتحديد أولوياتها في فئة DiscourseTemplateMap. بالنسبة لقوالب المكونات الموضوعة بجانبها (colocated)، يتم استخدام تلك المعلومات أثناء تهيئة التطبيق لاستبدال ارتباطات القوالب الأساسية. لجميع القوالب الأخرى، تُستخدم الخريطة بواسطة المحلل (resolver) وقت التشغيل لجلب القالب الصحيح.


هذا المستند مُتحكم فيه إصداريًا - اقترح تغييرات على github.

17 إعجابًا

وماذا عن قوالب الجوال؟ ما هو هيكل الدليل لإعادة كتابة القوالب من النواة؟

يجب أن يعمل بنفس الطريقة تمامًا - أنت تطابق اسم القالب الأساسي. لذا إذا كان يحتوي على /mobile، فقم بتضمين ذلك في تجاوزك.

أحاول إعادة كتابة قالب تسجيل الدخول للجوال login.hbs ولا يعمل Imgur: The magic of the Internet هل أنا على المسار الصحيح؟

المسار الكامل غير مرئي في لقطة الشاشة الخاصة بك على حد علمي. هل يمكنك لصقه هنا كنص.

themeroot/javascripts/mobile/modal/login.hbs

أنت تفتقد discourse/templates من مسارك

لذلك في حالتك، سيكون {theme}/javascripts/discourse/templates/mobile/modal/login.hbs

إعجابَين (2)

هل هذا لا يزال هو الحال؟

أنا حزين بعض الشيء لإزالة القدرة على تجاوز الكثير من التعليمات البرمجية.

من المنطقي استبدال نظام الأدوات (Widgets) المخصص، إلى حد ما، ولكنه منحنا القدرة على الربط بالتعليمات البرمجية الموجودة على مستويات متعددة، مما قلل من الكثير من مخاطر التغيير المكسور حيث يمكننا استهداف كتل صغيرة فقط بطرق ذكية تسمح لنا بما يلي:

  • إضافة ميزات
  • عدم إزعاج أي شيء آخر.

لقد اضطررت للتو إلى إزالة ميزتين هامتين من Discourse Journal، على سبيل المثال، والتي كانت تستند إلى تجاوزات دقيقة للأدوات لأن الطريقة الوحيدة لإعادة إنشائها في Glimmer هي عبر زوج من تجاوزات القوالب (بما في ذلك محاولة تغيير ملف .gjs) وهو ما لم يعد مدعومًا على ما يبدو.

حتى لو كان هذا مدعومًا، فسنترك مع تجاوز أجزاء أكبر من التعليمات البرمجية مقارنة بإطار الأدوات، مع زيادة مرتبطة في مخاطر تعارض تغييرات النواة مع التجاوزات.

هذا ليس صحيًا لقابلية توسيع المنصة.

هل يمكن فعل أي شيء حيال ذلك؟

7 إعجابات

نعم، أسمعك - كانت هناك بعض الأشياء الجيدة في واجهات برمجة تطبيقات قابلية توسيع الأدوات.

لكن على الجانب الآخر، كان من الصعب للغاية علينا تعديل أي واجهة مستخدم قائمة على الأدوات في النواة، لأننا لا نعرف ما هي الطرق/الزخارف العشوائية التي قد يقدمها الأشخاص. لهذا السبب بدت تخصيصات الأدوات مستقرة نسبيًا - كنا خائفين جدًا من لمس تطبيقات النواة.

حلنا لهذا المضي قدمًا هو منافذ توصيل الأدوات المساعدة. تسمح هذه الأدوات للقوالب والإضافات بتجاوز أجزاء صغيرة جدًا من القوالب اختياريًا بتنفيذها الخاص.

على سبيل المثال، انظر كيف يقوم الدردشة بشكل شرطي بتجاوز شعار الصفحة الرئيسية باستخدام مكون مخصص. يعمل هذا مع رأس الأدوات الحالي، ورأس Glimmer الجديد (قريبًا! :tm:).

نحن سعداء بشكل عام بقبول طلبات السحب لإضافة منافذ توصيل أدوات مساعدة جديدة في أماكن مختلفة. إذا كنت غير متأكد من حالة استخدام معينة، فلا تتردد في فتح موضوع Dev مع التفاصيل!

10 إعجابات

حسنًا، هذا يبدو طريقًا للمضي قدمًا، شكرًا لك.

سأحتاج إلى استيعاب تداعيات ذلك والتكيف مع استراتيجية تتماشى مع ذلك.

أقدر الرد!

6 إعجابات