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

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

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

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

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

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

مستقبلاً، يجب إجراء جميع تخصيصات القوالب باستخدام مخارج الإضافات

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

تجاوز قوالب المكونات

لتجاوز قالب مكون 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).

تجاوز قوالب المسارات

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

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

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

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

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

  1. تجاوزات السمات (الفائز هو السمة ذات المعرف ‘id’ الأعلى)
  2. تجاوزات الإضافات (الفائز هو اسم الإضافة الأبجدي الأحدث)
  3. النواة

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

كيف يعمل هذا؟

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


هذه الوثيقة خاضعة للتحكم في الإصدارات - اقترح التغييرات على 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 إعجابات