في أحدث إصدار من Discourse، أصبح استخدام ملفات .hbs في الثيمات والإضافات قيد الإهمال. سيتم إزالة دعم تنسيق الملف هذا بعد إصدار ESR التالي.
يجب استبدال قوالب Handlebars بتنسيق .gjs الأحدث، والذي يوفر تجربة تطوير أفضل بكثير، وسيمكّن من تحقيق تحسينات كبيرة في الأداء في الإصدارات المستقبلية من Discourse.
للحالات البسيطة، شارك الكود الخاص بك مع https://ask.discourse.com/ واطلب منه إعادة الكتابة بتنسيق .gjs.
للحالات الأكثر تعقيدًا، يمكن أتمتة التحديثات باستخدام أداة تعديل الكود هذه:
هل فهمت بشكل صحيح أن إصدار 2026.7 سيدعم ملفات hbs وأن إصدار 2027.1 سيكون أول إصدار ESR لا يدعمها؟
نعم، بالضبط.
من المرجح أننا سنوقف الدعم في الإصدار 2026.8.0-latest. ولكن من الممكن أن يكون ذلك في وقت لاحق، اعتمادًا على البيانات الواقعية وملاحظات المجتمع.
لقد صادفت هذا للتو، أعتقد أنه بحاجة إلى تحديث
شكرًا! نأمل أن يكون معظم الناس قد قاموا بالفعل بمعالجة تلك الأمور، نظرًا لأنها تم إهمالها مع وجود لافتة إدارية لمدة عام تقريبًا. تحسبًا لأي طارئ، أضفت هذه الملاحظة:
بالنسبة لي، لقد جربت إضافة المكون الإضافي الشخصي الصغير الخاص بي ونجحت بمساعدة ask Discourse الذي دمج ملفات hbs و js الخاصة بي في ملف gjs واحد.
أوصي بشدة باستخدام ask Discourse لحل هذه المشكلة لأولئك الذين مثلي يواجهون صعوبات في التطوير 
هذا رائع! لقد أضفت ملاحظة حول ask.discourse.com في الموضوع الأصلي أيضًا. إذا كان لديك عدد قليل من الملفات فقط، يمكن أن يعمل ذلك بشكل جيد جدًا 
ليس لدي أي فكرة عما هو ملف .gjs، ولا أملك الوقت لتعلمه وإعادة كتابة العديد من الإضافات. هذا أمر سخيف.
ما الغرض من وجود واجهة برمجة تطبيقات للإضافات أصلاً إذا كانت هشة مثل الموجودة في Discourse؟ إن صيانة الإضافات لهذا برنامج المنتدى لم تكن سوى متاعب.
إنها بعيدة كل البعد عن السخافة.
إذا لم يكن لديك الميزانية أو القدرة على إدارة التخصيصات، فإنني أحثك على تبسيط إعدادك.
في رأيي، هذا هو السعر (المعقول) الذي تدفعه مقابل البقاء على منصة متطورة وسريعة التطور تواصل الابتكار، وتحسّن الأداء، وتنشر تصحيحات أمنية متكررة، وتواكب المعايير المتطورة.
يبدو أن فريق Discourse يبذل الكثير من الجهد لضمان وجود رسائل تحذير بشأن الإيقاف المسبق قبل فقدان الوظيفة بوقت كافٍ.
هل تفضل أن تبقى عالقًا على منصة غير آمنة مع ميزات أقل؟
فكر في القيمة التي تحصل عليها من النواة المُحسَّنة جيدًا والتي يمكنك تنزيلها مجانًا؟
لا تحتاج حتى إلى معرفة ما هو ملف .gjs: Automatically updating themes and plugins to .gjs file format
لم ينجح الأمر مع إضافة بلدي الصغيرة. 
لكن بمساعدة ask.discourse.com، قام بقراءة كودي وتحويل ملفي من hbs وjs إلى .gjs، لذا لا تتردد إذا لم تنجح الطريقة الأولى.
أعتقد أن هذا السؤال قد تم الرد عليه هنا أيضًا:
أيضًا،
لاحظ أنني أفهم إحباطك؛ فكل من طوّر إضافات أو سمات أو مكونات هنا يواجه تقادمًا وتحديثات إلزامية.
كما عبر آخرون عن إحباطهم أيضًا:
لن أقوم بأي عمل إضافي على أي من إضافات Discourse الخاصة بي. الأمر ببساطة لا يستحق العناء.
نظرًا لأن أشخاصًا آخرين يستخدمون اثنين منها، فما هي العملية لحذفها دون التسبب في مشاكل للآخرين؟
لقد سئمت من تعطلها، وعادةً لأسباب سخيفة تمامًا، كل بضعة أشهر، ومن الوقت والجهد اللازمين فقط للحفاظ على عمل منتداي.
لا أريد أن أكون “على حافة التطور”. أريد فقط منتدى ويب يعمل بشكل مستقر.
“عدم التحديث” ليس خيارًا أيضًا، لأننا نحتاج إلى تحديثات أمنية. من الغريب أن يقترح شخص ما ذلك آخر مرة اشتكيت فيها.
يجب على فريق Discourse حقًا أن يهتم أكثر بالتوافق وعدم كسر المنتديات والأكواد الحالية. لا يبدون وكأنهم يفكرون في ذلك حتى. إنهم يقومون بإجراء تغييرات كاسرة فقط لترتيب الأمور قليلاً من جانبهم. هذه ليست الطريقة لإدارة منصة وواجهة برمجة تطبيقات (API) يستخدمها أشخاص آخرون، ولا أريد أن أكون جزءًا من ذلك بعد الآن.
أنا آسف جدًا لسماع ذلك!
إذا كنت ترغب في المضي قدمًا في هذا المسار، فإنني أوصي بإضافة ملاحظة إلى README وموضوع Meta، ووصفها بـ #broken، ثم أرشفة مستودع GitHub. بهذه الطريقة، يظل متاحًا للآخرين لعمل نسخة منه (بافتراض أن الترخيص يسمح بذلك).
نحن نهتم بالتأكيد بالتوافق والحفاظ على عمل الأشياء. وهذا هو السبب في وجود فترات إلغاء طويلة مع مسارات ترقية مؤتمتة بالكامل.
نحن نسعى دائمًا لتحقيق التوازن بين التخصيص والاستقرار - فسمات وإضافات Discourse قوية جدًا لأننا نمنحها وصولاً مباشرًا إلى واجهات برمجة التطبيقات الأساسية للمتصفح/الإطار. وهذه القوة الهائلة تأتي مع قدر معين من المسؤولية لمواكبة التغييرات الأساسية.
بالفعل - البقاء محدثًا أمر مهم. خلال الأشهر القليلة الماضية، استثمرنا بكثافة في خط أنابيب الإصدار الخاص بنا لجعل الأمور أفضل بكثير لمستخدمي ESR (المعروف سابقًا باسم ‘مستقر’). مزيد من التفاصيل هنا. لا يزال يتعين عليك التحديث، ولكن هناك مرونة أكبر بكثير فيما يتعلق بالتوقيت والضرورة.
أما بالنسبة لإلغاء هذا الإصدار المحدد، فإن الحل مؤتمت بالكامل. إذا كان بإمكانك إخبارنا بأسماء الإضافات، فسنكون سعداء بتشغيل codemod لك وإجراء طلب سحب (PR). لقد قمنا بذلك لجميع السمات/الإضافات الـ 600+ التي نديرها، لذا فهي الآن آلة تعمل بسلاسة.
في هذا المنشور، اقترحت إضافة وسم unmaintained أو وسم end-of-life.
أدرك أن الأمر ليس سهلاً إذا عاد شخص ما بعد بضعة أشهر ووجد أن الكثير قد تغير. قد لا يكون مواكبة التغييرات أمراً سهلاً، لكن في رأيي، إنه ثمن يجب دفعه مقابل برنامج منتدى متطور يحتوي على واجهة برمجة تطبيقات شاملة.
إذن لماذا تواصلون إجراء تغييرات مدفوعة بتنظيف بعض الأكواد القديمة الثانوية من جانبكم على حساب التوافق؟
هذه الأكواد القديمة جزء من ثمن الحفاظ على منصة أو واجهة برمجة تطبيقات (API). فهي لا تسبب مشاكل حقيقية. لكنكم تصرّون على تغييرها أو إزالتها، مما يجعل الآخرين يبذلون جهدًا إضافيًا ويجرون اختبارات إضافية نتيجة لذلك.
تدوم إصدارات ESR لمدة 9 أشهر فقط، وهو ما لا يُعد دعمًا موسعًا فعليًا.
واستخدام هذه الإصدارات يعني ببساطة أنكم ستضطرون للتعامل مع جميع التغييرات المعطلة دفعة واحدة، مع قائمة أكبر بكثير من الالتزامات (commits) التي يجب البحث فيها إذا كنتم تحاولون فهم سبب حدوث مشكلة ما.
إصدار ESR كما هو اليوم سيجعل هذه المشكلة أسوأ، وليس أفضل.
الحل الوحيد هو الاهتمام فعليًا بواجهة برمجة التطبيقات (API) والحفاظ عليها. اجعلوا التغييرات المعطلة الملاذ الأخير فقط، وليس لتنظيفات صغيرة “مرغوبة”. ولا تتخلصوا من إطار عمل بأكمله يستخدمه الناس لمجرد أنكم ترغبون في استخدام إطار آخر، أو لأي سبب آخر.
العملية هنا هي تشغيل الإنتاج على إصدارات ESR، بينما يكون الاختبار على الإصدارات الشهرية أو على الإصدارات التي اجتازت الاختبارات.
إذا قمت بتحديث بيئة الاختبار يوميًا أو أسبوعيًا أو شهريًا - بل ويمكنك أتمتة ذلك - فستتمكن من تحديث الإضافات والقوالب بشكل تكراري والحفاظ عليها في حالة عمل سليمة.
حقيقة أنك تبقي الإنتاج على إصدارات ESR تمنحك مرونة لا تقل عن ثلاثة أشهر لإصلاح الأمور.
يبدو أنك غير قادر على استيعاب المفهوم القائل بأن واجهة برمجة التطبيقات (API) المنشورة لا ينبغي أن تكون هدفاً متحركاً باستمرار.
تخيل لو أجبرت مايكروسوفت جميع مطوري ويندوز على تغيير أكوادهم كل 6 أشهر. هذا أمر غير قابل للتصور. يمكنك أخذ كود تم كتابته من أجل ويندوز 95 قبل 30 عاماً وجمعه وتشغيله على جهاز حديث اليوم دون أي تغييرات على الإطلاق.
لا يمكنك الادعاء بالاهتمام بالتوافق عندما يتوقف الكود المكتوب وفقاً لمواصفاتك عن العمل بسبب قرارات اتخذتها أنت حصراً.