لم أتلق هذا الإشعار. لكنني اتبعت سجل الأخطاء وأزلت الأسطر. أقوم بإعادة البناء مرة أخرى الآن.
تعديل: بخلاف التسبب في أعطال و 20 دقيقة من عدم الاتصال بالإنترنت، إذا لم تتم إزالة أسطر هذه الإضافات هذه قبل الترقية؛ لماذا نحتاج حقًا إلى هذه الزيادة المضافة من الإضافات المثبتة مسبقًا؟
أنا مهتم بالصورة الأكبر. ما هو سبب تجميع هذه الإضافات افتراضيًا؟
شخصيًا، يبدو الأمر أشبه بالاتجاه الذي سلكته أنظمة التشغيل Windows وأنظمة تشغيل الأجهزة المحمولة وبعض البرامج بإضافة المزيد من المكونات المثبتة مسبقًا افتراضيًا (bloat) والتي نحاول جميعًا تجنبها بشكل عام.
أنا متأكد من أن هذا التغيير قد تمت مناقشته مع المجتمع قبل تنفيذه. إذا كان الأمر كذلك، فلا حاجة لرد متكرر، فقط قم بتضمين رابط للمناقشة أو الإعلان ذي الصلة حتى أتمكن من قراءة كيف ولماذا تم اتخاذ هذا القرار.
لذلك لم أضغط على زر الترقية بعد لأنني أستخدم بعض المكونات الإضافية التي تم تجميعها الآن. أنا لست خائفًا، لقد نجوت من ترقية قاعدة البيانات قبل بضعة أشهر.
هل من الأفضل تحديث ملف app.yml الخاص بي من القائمة الموجودة في الموضوع (بعد نسخه احتياطيًا بالطبع) أم سأحصل على رسالة خطأ ذات مغزى في واجهة المستخدم تخبرني بأيها يجب إزالته والتوقف عن القيام بذلك؟
هذا مجاب عليه إلى حد ما في عنوان الموضوع. غالبًا ما يعني “الشائع” أنه تم تثبيته واستخدامه بشكل شائع. تجميعها لـ Self Hipsters يعني أنك لا تحتاج إلى قضاء وقت في تثبيتها. تم دمج العديد من الإضافات و TC في النهاية مع البرنامج الأساسي.
تسمح فائدة وجود هذه الإضافات في البداية بوقت تطوير لاختبار تفضيلات المستهلكين وتطويرها بالكامل.
بالتأكيد ستكون هناك مجموعة متنوعة من المجتمعات التي لا تستخدم أيًا من الإضافات المجمعة حديثًا مع النواة. لكن المقياس الأكبر يظهر على الأرجح أن هذه هي غالبًا تلك التي يتم تثبيتها بعد الإعداد. ثم بالطبع لديهم أيضًا المقاييس من استضافتهم المدفوعة للإضافات المستخدمة وغير المستخدمة في المستوى الأساسي.
لقد فاتني مكونان إضافيان قبل إعادة البناء. ومع ذلك، تم تحسين سجل الأخطاء بشكل كبير لتحديد هذا بسهولة مقارنة بما كان عليه من قبل حيث كان عليك التمرير لأعلى وتحديد المشكلة.
أعتقد أن الموجه الذي ذكره ديفيد هو إما خطأ إعادة البناء أو قد يكون في صفحة الإضافات الخاصة بك للتحديث عبر الويب.
لا تقلق، ليس من السهل دائمًا رؤية الإجابة قبل طرح السؤال.
لقد قمت بتحديث ملف app.yml الخاص بي بنفسي.
باستخدام التعليقات، جعلت ملفي منظمًا حسب مزودي الإضافات لسهولة الفرز. ومع ذلك، كان الأمر لا يزال مزعجًا بعض الشيء. أعتقد أن شخصًا ما نشر قبل بضع مشاركات طريقة للتحقق قبل إعادة البناء.
بصراحة لا، لأن هذا كان خيط الإعلان، جئت إلى هنا وبدأت تعليقًا لأن التحديث فشل ولم أتلق إشعارًا بضرورة التعديل أولاً. ثم بمجرد حل ذلك، قمت بتعديل المنشور. ولكن إذا كان هذا هو نقاشك العام الوحيد، فشكراً لك.
أستطيع أن أفهم الإيجابيات ولكن هناك بالتأكيد سلبيات. لذلك أعتقد أنه لن يكون كل أصحاب منتديات Discourse متحمسين للإضافات. لذلك كان من الجيد ربما تقديمه كخيار. ربما أثناء التحديث مطالبة واحدة، أو ربما في منطقة المسؤول إعداد أو إشعار يذكرك بتعيين تفضيلك قبل التحديث التالي.
الفكرة على الأرجح هي أنها المكونات الإضافية الأكثر شيوعًا، ومعظم الناس يستخدمون بالفعل مزيجًا منها (كما تفعل أنت بنفسك). إنها ليست “bloat” حقًا لأنها لا تشغل أي مساحة تقريبًا، ولا يتعين عليك استخدام أي منها لأي شيء. هذا يختلف كثيرًا عن وجود 20 برنامجًا لا أريد تثبيتها على Windows، فهذه مفاتيح تشغيل/إيقاف (لن يراها معظم الناس، وستكون لديك كمسؤول في قائمة من 300 شيء آخر لا تستخدمه/تغيره بالفعل) وليست شيئًا يظهر باستمرار/يشغل مساحة فعلية/مُعَد للقيام بأشياء افتراضيًا. وجود برنامج ملاحظات مثبت افتراضيًا لا أريده يعني أنني سأحصل على اثنين. وجود مكون إضافي لا أريده يعني أنه مجرد خيار موجود في لوحة
كما أنه من الأسهل بكثير وجود مفاتيح تشغيل/إيقاف بدلاً من البحث في منتدى طرف ثالث (أو مستودعات GitHub لا حصر لها) عن شيء لا تعرف حتى أنه موجود في المقام الأول. كانت هذه في الواقع المرة الأولى التي كنت على علم فيها بمجموعة من هذه المكونات.
لقد حصلت أخيرًا على الوقت لتحديث إلى 3.5.0.beta9-dev (df03ef6d05)
أنا أستضيف بنفسي تثبيت قياسي
لقد قمت بتحرير ملف app.yml الخاص بي لإزالة أسطر الإضافات (حسب نصيحة دان أعلاه) ثم شرعت في بدء عملية التحديث. اضطررت إلى تحديث مدير docker قبل كل شيء آخر كالمعتاد ولقد سار ذلك بشكل طبيعي. بمجرد تحديث مدير docker، استقبلتني رسالة جديدة (بالنسبة لي).
لقد قمت بإعادة بناء سابقًا لذلك كنت أعرف كيف وبما أن putty كان لا يزال مفتوحًا لخادمي، لم يكن ذلك مزعجًا ولكني فوجئت قليلاً بعدم قدرتي على استخدام واجهة المستخدم لإجراء التحديث. أنا فقط أنشر هذا كتنبيه للمستخدمين الآخرين الذين يستضيفون بأنفسهم مثلي. بخلاف ذلك، سار التحديث بشكل جيد، كل شيء يعمل ويعمل. شكرًا للفريق والمجتمع.
أتمنى لو كنتم تهتمون أكثر بالحفاظ على التوافق وعدم جعلنا نضيع نصف يوم في كل مرة نقوم فيها بتحديث مواقعنا. تنظيف الكود الخاص بكم قليلاً لا يستحق كسر مواقع الأشخاص وإضاعة وقتهم.
بصراحة، بدأت أبحث عن بدائل لـ Discourse لأنني سئمت من تعطل موقعي بالكامل كل بضعة أشهر والاضطرار إلى معرفة كيفية إصلاحه عندما لا يكون أي من هذا في مجال خبرتي.
نأسف لسماع إحباطك - على الرغم من أنني لست متأكدًا من المشكلات التي واجهتها مع المكونات الإضافية المجمعة على وجه التحديد هنا؟
نحن نحاول جعل الترقيات سهلة/مباشرة قدر الإمكان، ولكن مع التحولات الكبيرة مثل هذه، فإنها ستتسبب حتمًا في بعض الاحتكاكات. في هذه الحالة، أضفنا مخرجات خطأ محددة حول كيفية تعديل تكوين موقعك لجعله بسيطًا قدر الإمكان لإصلاحه.
إحدى المشكلات التي أعتقد أنها قيد التنفيذ هي أن Discourse_docker ليس جيدًا جدًا في معرفة متى يكون إعادة البناء من سطر الأوامر مطلوبًا. وهذا يجعل من السهل كسر موقعك عن طريق النقر على الترقية في لوحة المسؤول. (على الأقل هذا ما أعتقد أنني أرى الناس يشتكون منه)
أعتقد أنني اعتدت رؤية التزامات تقول إنها فعلت ذلك وأعتقد أنني لا أراها كثيرًا الآن. أنا لا أستخدم discourse_docker (كثيرًا؟) بنفسي، لذلك لم أهتم عن كثب.
إذا كان هذا المستخدم قد قام بإعادة بناء ولم يقم بالترقية من واجهة المستخدم الرسومية، فيمكنهم ببساطة القيام بما يلي:
./launcher start app
وانتظروا للتعامل مع الترقية عندما يكون ذلك مناسبًا.
