أودّ اقتراح إضافة حدّ أقصى للعمق المتداخل (nesting depth) لميزة [details] المدمجة، أو تقديم إعداد موقع يسمح للمشرفين بضبط هذا الحد.
المشكلة
مؤخراً، أنشأ مستخدم على منتدي Discourse منشوراً يحتوي على 24 مستوى من الأقسام [details] المتداخلة.
أدى هذا إلى عدة مشاكل:
- أداء المتصفح: أبلغ المستخدمون عن أن توسيع عدة مستويات تسبّب في بطء شديد أو عدم استجابة متصفح Firefox.
- انتهاء مهلة نقاط نهاية Markdown: أصبح الوصول إلى نقطة النهاية
.mdللموضوع بطيئاً جداً. لاحظنا طلبات تستغرق 19.8 ثانية و31.1 ثانية. - أخطاء الخادم: كانت نقطة نهاية Markdown تعيد أحياناً صفحة خطأ “Oops”. كما أظهرت سجلات Discourse تحذيرات انتهاء مهلة عامل Pitchfork أثناء تحويل Markdown.
- استنفاد الموارد المحتمل: نظراً لأن محركات البحث وروبوتات الزحف (AI crawlers) تطلب نقاط النهاية
.mdبشكل متكرر، فقد يتسبب منشور متداخل بعمق في تشغيل عمليات معالجة مكلفة بشكل متكرر واستهلاك موارد الخادم.
بعد إزالة المنشور المعيب، عادت نقطة نهاية Markdown إلى إرجاع HTTP 200 واستجابت في حوالي 1.7 ثانية.
كان الموضوع المتأثر هو:
https://meta.appinn.net/t/topic/87672
(تمت إزالة الرد المعيب بالفعل.)
التحسين المقترح
أعتقد أنه سيكون مفيداً إما:
- تقييد تداخل
[details]بعمق معقول، مثل مستويين أو ثلاثة مستويات. - إضافة إعداد موقع، مثل
details_max_nesting_depth، يسمح للمشرفين بضبط الحد الأقصى للعمق المتداخل.
من أجل التوافق الخلفي، يمكن أن يكون الإعداد الافتراضي غير محدود، مع السماح للمشرفين بفرض حد عند الحاجة.
إذا تجاوز المستخدمون الحد المهيأ، يمكن لـ Discourse رفض المنشور مع رسالة تحقق واضحة.
حل مؤقت: إضافة (Plugin)
أنشأت إضافة صغيرة تحدّ من تداخل [details] إلى حد أقصى مستويين:
GitHub - scavin/discourse-details-depth-limit · GitHub
تتحقق الإضافة من المنشورات على جانب الخادم وترفض المنشورات التي تحتوي على أكثر من مستويين من الأقسام القابلة للطي المتداخلة.
اختبرتُها بنجاح في بيئة تطوير Discourse المحلية لدي.
بالنسبة للمشرفين الذين يواجهون مشاكل مشابهة، قد تكون هذه الإضافة حلاً مؤقتاً حتى يتوفر حل رسمي.
أعتقد أن وجود حد قابل للتخصيص في إضافة Details المدمجة سيكون إجراءً وقائياً مفيداً ضد التداخل العرضي أو المفرط.