شكرًا. كما يُرجى ملاحظة أن discourse-health-check v1.0.4 تم تحديثه الآن:
إصلاحان:
-
استبدل Discourse Unicorn بـ Pitchfork (افتراضي في الإصدار 2026.2، وتم إزالة Unicorn بالكامل في الإصدار 2026.4)، لذا فإن فحص خادم الويب يكتشف كليهما الآن. شكرًا لـ @RGJ على الإشارة إلى ذلك في يونيو الماضي.
-
كانت استعلامات الخدمة تطابق سطر الأوامر الخاص بها.
pgrep -f <name>بحيث كان pgrep يطابق نفسه، وبالتالي كان الفحص ناجحًا بغض النظر عما إذا كانت الخدمة تعمل فعليًا أم لا. كان Sidekiq يبلغ عن حالة “يعمل” بشكل غير مشروط منذ الإصدار 1.0.0. كان من الممكن أن تكون الخدمة متوقفة، ومع ذلك كنت تحصل على علامة خضرة وكود خروج 0 من cron. نفس السبب الجذري لخطأ الإيجابيات الكاذبة في Puma في الإصدار 1.0.1، والذي اتضح أنه تم إعادة تسميته بدلاً من إصلاحه.
أوه، وأيضًا يبلغ الآن عن الإصدار الرئيسي لـ PostgreSQL ويحدد أي إصدار أقل من 15.
أمر آخر يجب مراعاته أثناء الترقية، إذا كنت تضمّن مقاطع YouTube:
يرسل Discourse Referrer-Policy: same-origin بشكل افتراضي، وYouTube يرفض طلبات التكوين المضمنة التي تصل دون مرجع (referrer). ستحصل على الخطأ 153 ولن تعمل مقاطع الفيديو. واجهت هذه المشكلة في نوفمبر الماضي وأصلحتها باستخدام قاعدة تحويل Cloudflare التي تضبط Referrer-Policy: strict-origin-when-cross-origin:
تحققت من سجل التغييرات أثناء كتابة هذا المنشور. لا توجد أي عمليات التزام (commits) تتعلق بـ Referrer-Policy في أي مكان بين الإصدارين 2026.1.5 و2026.7.0، لذا فإن هذه المشكلة لا تزال غير مصلحة في النسخة الأساسية. إذا كان لديك حل بديل قائم لها، فلا تقم بإزالته أثناء الترقية.
بالنسبة لمن لا يستخدمون Cloudflare، فإن إدخال head في السمة (theme) يؤدي نفس الوظيفة:
<meta name="referrer" content="strict-origin-when-cross-origin">
لا يمكنني تعديل ذلك الموضوع، فهو مغلق. لذا يجب أن يكون “تعيين ثابت” (set static) وليس “إضافة” (add):
