أردت فقط أن أضيف شكرًا كبيرًا لفريق Discourse لتضمين المعلمة bypass_bump! إنها أداة صغيرة ولكنها قوية - تسمح للنصوص البرمجية والإضافات بتحديث المحتوى في الخلفية دون أن تظهر عن غير قصد الموضوعات القديمة في عرض “الأحدث”.
في حالتنا، نستخدمها لنصوص المزامنة الخاصة بـ ICS، وهي تضمن أن التغييرات الهادفة فقط هي التي تحدث ضجة في الموضوعات. إضافة مدروسة تحافظ على نظافة منتديات المجتمع وتجربة القارئ دون إزعاج - شكرًا مرة أخرى!
هذا ليس منشور إشادة مضلل، مثل منشوري الأخير🙈، لأن:
يدعم Discourse علامة bypass_bump عند مراجعة منشور؛ فهو يمنع تغيير تاريخ ارتفاع الموضوع حتى لو قمت بتحرير آخر منشور (أو المنشور الأول والوحيد). هذا مدرج صراحةً في خيارات PostRevisor (“- bypass_bump: لا تقم بزيادة الموضوع، حتى لو كان آخر منشور”).
يوجد موضوع الإشادة هذا ويذكر بالضبط حالة الاستخدام هذه.
تاريخياً، استخدم الناس الحل البديل /t/{id}/reset-bump-date لأن هذا الخيار لم يكن معروفاً على نطاق واسع / موثقاً في وثائق API، ولكنه لا يزال متاحاً إذا لزم الأمر.
ملاحظة عملية: عندما تقوم بـ PUT /posts/{post_id}.json مع raw الجديد وتضمين bypass_bump=true، فإن التعديل لن يظهر الموضوع في /latest. (لا توضح الوثائق الرسمية هذه المعلمة، ولكنها مرتبطة من جانب الخادم عبر PostRevisor.)
لست متأكدًا بنسبة 100% بعد من الحالة الرسمية لـ bypass_bump في وثائق واجهة برمجة التطبيقات — فهي لا تظهر في أي مكان واضح.
ولكن عندما أنظر إلى سجلات برنامج Python sync script الخاص بـ Ethsim12، فإنها مفيدة. يحاول البرنامج استدعاء واجهة برمجة التطبيقات باستخدام bypass_bump=true. إذا تم تجاهل هذا المعامل أو كان غير صالح، فإن الشيء الوحيد الذي سيمنع الزيادات غير الضرورية هو الحل البديل الذي أضافوه: استدعاء يدوي لـ
/t/{topic_id}/reset-bump-date
لذلك، يصبح ناتج السجل نفسه دليلاً قوياً. إذا أظهر السجل تحديث المواضيع دون الظهور في /latest (ودون الحاجة إلى الحل البديل لإعادة الضبط)، فهذا دليل جيد على أن bypass_bump نشط ويعمل. إذا كان السجل يلجأ دائمًا إلى reset-bump-date، فقد لا يكون كذلك.
بمعنى آخر: سجلات هذا البرنامج النصي تقطع شوطًا طويلاً نحو تأكيد ما إذا كان bypass_bump موجودًا ويحترمه الخادم بالفعل.
شكراً لمشاركة طلب السحب هذا، موين — سياق مفيد حقًا.
بالنسبة لمشروعي الجانبي (مستورد ics_to_discourse.py)، قمت للتو بتثبيت تغيير لإيقاف التحديثات المستندة إلى التقويم من “إزعاج” المواضيع:
يضيف هذا التثبيت بعض المنطق لتحديد ما إذا كان التعديل “ذا مغزى” (تغيير في الوقت/الموقع وما إلى ذلك)، ويستخدم bypass_bump بالإضافة إلى آلية احتياطية لإعادة تعيين تاريخ التحديث حتى لا تؤدي مزامنات ICS الروتينية إلى ظهور المواضيع بشكل غير ضروري.
لذلك، يتوافق طلب السحب هذا تمامًا مع ما كنت أهدف إليه — من الجيد رؤية النواة تتحرك في نفس الاتجاه. بمجرد دمج سلوك “عدم التحديث عند التعديل”، سأقوم بتبسيط وإسقاط الآلية الاحتياطية الإضافية، ولكن في الوقت الحالي، يحافظ التثبيت على هدوء الأمور في تثبيتات Discourse الحالية.
