أنا فقط فضولي: هل هناك أسباب محددة لتعطيل إضافة “cakeday” هنا؟
إعجاب واحد (1)
إعجاب واحد (1)
إذًا، هل الحل لتعطيل الإضافة في المنتديات التي لم تستخدم “cakeday” من قبل، هو تعطيل “cakeday” في المنتديات التي كانت تستخدم “cakeday” لسنوات؟
إعجاب واحد (1)
أعتقد أن الأمور ساءت للتو.
إليك الترحيل رقم 1، والذي تم التعليق عليه 
. كيف يمكن للمرء أن يعرف ما إذا كان قد تم تشغيله على كل مثيل؟
لذا، قام هذا الترحيل بتثبيت SiteSetting.cakeday_enabled في قاعدة البيانات.
إليك ترحيل تنظيف يحذف هذا الإعداد إذا تم إنشاؤه في الوقت الذي تم فيه تنفيذ الترحيل رقم 1. وهو يبدو مشبوهًا بعض الشيء ولكن مهلاً، إنه يعمل تعديل: لا يعمل.
لذا، فإنه يعود الآن إلى القيمة الافتراضية وهي… إيقاف التشغيل؟
ساءت الأمور. كان الأمر مشبوهًا ولم ينجح.
لقد قمت للتو بتشغيل تحديث لموقع Discourse ولم أتمكن من تجاوز ترحيل التنظيف الذي تتحدث عنه.
هذا الترحيل يتعطل. discourse/plugins/discourse-cakeday/db/migrate/20251127125226_delete_old_default_values.rb at main · discourse/discourse · GitHub
عندما يقوم الترحيل بتشغيل migration_timestamp("20250717093505") و migration_timestamp("20250811132217") من الطريقة up، تحصل على قيم nil. هذه القيم nil تكسر استعلام SQL في الطريقة delete_settings في الترحيل.
سأقوم بنقل هذا إلى Bug على أمل أن يحظى بمزيد من الاهتمام
إعجاب واحد (1)
لم تسر عملية دمج d-cakeday في النواة (core) كما هو مخطط لها…
يجب تعطيل جميع الإضافات المجمعة افتراضيًا، وكان d-cakeday أحد الإضافات القليلة التي تم ترحيلها والتي كانت ممكّنة دائمًا.
كانت الفكرة هي أن المواقع التي كانت لديها الإضافة ممكّنة قبل الترحيل إلى النواة ستبقى ممكّنة، بينما تلك التي لم يكن لديها الإضافة من قبل ستستخدم القيمة الافتراضية الجديدة (إيقاف).
لقد فتحت الآن PR (طلب سحب) يستبدل أحدث عملية ترحيل (غير صحيحة) بأخرى جديدة تستخدم طريقة استدلالية لتحديد ما إذا كان سيتم تمكين cakeday/cakeday_birthday أو الاحتفاظ بالقيمة الافتراضية “إيقاف”.
5 إعجابات
تم إغلاق هذا الموضوع تلقائيًا بعد 4 أيام. لم يعد الردود الجديدة مسموحًا بها.