أجد أن الناس غالبًا ما يحاولون أولًا وضع الأمان (Safe Mode) عند حدوث أي خلل وهم يستخدمون تعديلات طرف ثالث. وهذا أمر منطقي، إذ لا تعرف من أين يأتي المشكلة.
ومع ذلك، فإن وضع الأمان يعطل فقط جافا سكريبت. أما إذا كان هناك أي كود يُنفذ من جانب الخادم، فعادةً ما يكون الحل الفوري هو إزالة علامة التعليق (un-comment) عن جميع الإضافات في ملف app.yml. وهذا مقبول، لكنه يتطلب إعادة بناء النظام ويعتبر أمرًا تقنيًا نسبيًا. فإذا كنت مستخدمًا غير تقني، فإن وضع علامات التعليق على عناصر في ملف app.yml ليس أمرًا تتخذه باستخفاف.
أتساءل عن جدوى طلب سحب (PR) يضيف إمكانية تعطيل الإضافات من جانب الخادم ضمن وضع الأمان. أفكر في شيء على غرار ما يلي في وحدة التحكم الخاصة بوضع الأمان:
find_opts = {
include_official: params["only_official"] != 'true',
include_unofficial: params["no_plugins"] == "true"
}
Discourse.find_plugins(find_opts).each do |plugin|
if plugin.enabled_site_setting.present?
SiteSetting.set(plugin.enabled_site_setting, false)
end
end
نعم، يمكن تحقيق نفس التأثير من خلال قيام المستخدم بالدخول إلى إعدادات موقعه وتعطيل الإضافات بهذه الطريقة، غير أنني أجد أن المستخدمين نادرًا ما يفعلون ذلك فعليًا.
أعتقد أن النقطة الرئيسية هي أن مدراء المواقع غير التقنيين يبحثون عن حل لإصلاح موقعهم عندما يتعطل. وغالبًا ما يُنظر إلى “الوضع الآمن” على أنه يحقق ذلك (سواء كان ذلك صحيحًا أم خطأ). ربما تكون إحدى الطرق لتحقيق ذلك هي إضافة عناصر تحكم إضافية للوضع الآمن في لوحة الإدارة.
يمكنك إضافة زر كبير في مسار /admin/plugins لتعطيل جميع الإضافات تلقائيًا بنفس الطريقة، لكنني أتساءل عما إذا كان سيكون له نفس التأثير. ربما يكون كذلك.
كما أن هذا الأمر يجذبني لأنه قابل للتنفيذ تمامًا ضمن بنية الإضافات الحالية في Discourse.
عادةً ما تكون الأشياء التي تكسر الإضافات هي تغييرات غير متوافقة في النواة، وغالبًا ما تفشل حتى في الإقلاع إذا قمت بتضمين إضافة مشكلة أو عملية التمهيد.
يجب أن تؤدي ميزة إيقاف جميع الإضافات إلى إعادة تشغيل التطبيق بطريقة ما لتكون صحيحة.
أعتقد أنني منفتح على تغيير في إضافة مدير Docker يسمح لك بتعطيل/تفعيل الإضافات بسهولة عن طريق نقل الأشياء داخل وخارج مجلد الإضافات وإعادة تشغيل التطبيق، مما قد يجعل عملية التصحيح أسرع.
ومع ذلك، ألاحظ أن عددًا لا يستهان به من الأخطاء ينشأ من الكود المضمن في واجهة برمجة التطبيقات (API) للمكوّن الإضافي من جانب الخادم، والذي سيتم التعامل معه عبر هذا الإجراء (أعتقد؟).
حاليًا، “الوضع الآمن” (أو ما يشبهه) ليس حلاً كاملاً للمشكلات التي تسبب تعطل النظام. إن إضافة ميزة تعطيل تلقائي للمكوّنات الإضافية ستجعل الحل أفضل قليلًا، مما يقلل من الحالات التي تتطلب إعادة تشغيل كاملة أو تغييرًا في الإعدادات، ويعكس بشكل أفضل كيفية نظر مدراء المواقع غير التقنيين إلى الأمر.
أظن أنني أبحث عن خطوات تدريجية وسهلة نسبيًا. ربما يكون تغيير مدير Docker بنفس البساطة من الناحية التقنية.
نعم، إذا كان ذلك ممكنًا يومًا ما، سيكون من الجيد جدًا وجود خيار منطقي واحد لـ “تعطيل جميع الإضافات” في إعدادات الإدارة، يعمل دون الحاجة إلى إعادة بناء الحاوية. ومع ذلك، وبما أنني لست مطورًا في Discourse (أملك عامًا واحدًا فقط من تطوير تطبيقات node.js وvuejs)، فإن غرائزي تخبرني أن هذا التغيير ليس سهلاً وسيكون تغييرًا كبيرًا جدًا في البنية.
كان لدينا في منتدانا القديم القائم على LAMP هذه الميزة، ولا نستطيع حصر المرات التي استخدمنا فيها هذا الخيار المنطقي لعزل الأخطاء المرتبطة بالإضافات بسرعة. ومع ذلك، فإن بنية البرمجيات مختلفة جدًا لدرجة أن المقارنة بينها ليست مفيدة حتى.
أنا شخصياً واثق من أن فريق Discourse سيبتكر حلاً. فالكثير من المستخدمين مدمنون على الإضافات، وستظهر تحديات جديدة مع مرور الوقت.
عامل كبير بالنسبة لي هو أن هذه الميزة ستكون مخصصة بالكامل لمن يستضيفون النظام بأنفسهم. لا أريد حقًا حمل وضع الأمان للإضافات في النواة، فهذا بالتأكيد ليس شيئًا سنستخدمه، فتنسيق إعادة التشغيل عبر 5 مجموعات أمر صعب.
مدير Docker هو الوسيط المناسب هنا، فهو يدعم بالفعل إعادة تشغيل التطبيق، وهو ما تحتاجه لكي يعمل مقترحك، ويمكنه القيام بكل ما يحتاجه دون الحاجة إلى تعديلات في نواة Discourse.