نظرًا لأنني تعرضت لمشكلة “فشل إعادة بناء المكون الإضافي” في وقت مبكر من استضافة Discourse بنفسي، يمكنني تقدير الرغبة في تجميع إصدارات معروفة وجيدة في النواة. وربما تقديم مجموعة أغنى من الميزات.
كان بإمكان منظمة تركز على العملاء إجراء استطلاع حول الاتجاه الأساسي للمكونات الإضافية، أو على الأقل التوقيت. ربما فاتني ذلك. بصفتي موفرًا لأدوات تكنولوجيا المعلومات لعملائي (أي المستخدمين النهائيين) الذين يحاولون إنجاز عمل حقيقي باستخدام تكنولوجيا المعلومات، فقد رأيت العديد من المنتجات التي تم تحديثها إلى تعقيد مفرط واستبدالها في النهاية. الآن سيكون لدينا مستضيفون ذاتيون يقومون بـ “rm -fr” للمكونات الإضافية التي لا يحتاجونها. أفهم هذا وقد أنضم إلى هذا النادي. في تجربتي، يزيد الكود الإضافي من تعقيد التكامل، وخطر أخطاء التكوين، وسطح الهجوم. ولكن عاجلاً أم آجلاً، فإن إزالة شيء يفترض مطور التطبيق أنه سيكون موجودًا، سيكسر شيئًا ما أيضًا.
كنت أفضل بكثير لو ذهبت جهود “جيداي” Discourse إلى العمل على طريقة قوية ومُصانة ومُبرمجة لتمكين التخزين السحابي للصور بما في ذلك تكامل شبكة توصيل المحتوى (CDN). تكامل البريد الإلكتروني SMTP بسيط بالمقارنة، وقد تعطل هذا مع التغييرات في MailGun وغيرها مما تسبب في معاناة المواقع المستضافة ذاتيًا.
بالفعل، أوصي بشدة بعدم استخدام rm -rf على هذه المكونات الإضافية. كما ذكرت، هناك مخاطر تتعلق بالاعتماديات المتبادلة غير المتوقعة في المستقبل. ولكن أيضًا، ستقوم بإنشاء اختلاف في مستودع git الأساسي، مما يعني أن تحديثات واجهة المستخدم عبر docker_manager ستفشل على الأرجح.
بالطبع، ترك هذه المكونات الإضافية في حالتها الافتراضية “المعطلة” مدعوم بالكامل، وسيضمن عدم وجود أي تأثير ملحوظ على الأداء.
بالنسبة للمستضيفين الذاتيين أو أولئك الذين مثلي يقدمون خدمات استضافة للعملاء، إليك أمر grep بسيط سيُدرج ما إذا كانت أي من المكونات الإضافية المجمعة الجديدة موجودة بالفعل في ملف containers/app.yml الخاص بك.
قد تفكر في تغييره للإشارة إلى containers.*.yml حتى يساعد ذلك أيضًا أي شخص قام بتثبيت قياسي من حاويتين حيث سيكونون بدلاً من ذلك في وضع الويب فقط؟ أنت حقًا لا تريدهم في أي من تعريفات الحاوية الخاصة بك، بعد كل شيء.
@david هل ستفكر في إضافة ذلك إلى المنشور العلوي والحفاظ عليه بمجرد دمج cakeday؟
شكرًا لـ ChatGPT الذي صاغها بشكل صحيح تمامًا في محاولة واحدة من هذا الموجه:
يرجى كشط عناوين URL الخاصة بـ GitHub لكل المكونات الإضافية المذكورة في هذا المنشور https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574#p-1810533-affected-plugins-3
قم بتجميعها في قائمة وأنشئ أمر يونكس يخبرني ما إذا كانت أي من هذه المكونات الإضافية مذكورة بالفعل في ‘git clone’ في ملف containers/app.yml الخاص بـ Discourse.
على السطح، يبدو لي أن هذا شيء معقول للنظر فيه في مرحلة ما - وجود طريقة تعريفية أكثر لتحديد المكونات الإضافية التي يتم تحميلها أو لا يتم تحميلها عند بدء التشغيل، حتى لو كان المصدر لا يزال موجودًا على القرص.
ومع ذلك، لا أعرف ما مدى جدوى أو صعوبة القيام بذلك.
من الممكن بالتأكيد. لكنه يضيف تعقيدًا - شيئًا آخر للدعم/الصيانة. وسيكون مفيدًا فقط في البيئات ذات المستأجر الواحد (أي، ليس في بيئات الاستضافة المشتركة، حيث يريد المستأجرون المختلفون إضافات مختلفة).
إذا كان الأمر كذلك، أعتقد أنه سيكون من المفيد قضاء الوقت في تحسين تجربة المستخدم والأداء للإضافات “المعطلة” (وهو ما بدأنا بالفعل في القيام به منذ هذا الدمج الكبير في النواة).
أوه، لقد كان تحديثًا صعبًا. تحديد المشكلة في سجل إعادة البناء ليس بالأمر السهل في البداية. وجدتها، وتجاهلت مكونًا إضافيًا آخر لإزالته من التكوين الخاص بنا مرتين، وبالتالي نجحت محاولة إعادة البناء الثالثة في تجاوز هذا الجزء. كان من المفيد حقًا التحقق من التكوين وتنبيهنا في المقام الأول إلى أنه يحتاج إلى تعديل. يتحقق discourse-doctor (بسيط جدًا، ولكن يمكن اعتباره بداية) من المكونات الإضافية في التكوين، لذلك يمكن استخدامه كأساس. ربما فات الأوان الآن بعد 3 أسابيع، مهما كان الأمر…
لكن هذا لم يكن كل شيء، فقد واجهنا أيضًا أخطاء في db:migrate. حاولت مرة أخرى مرتين، ثم شغلت discourse-doctor، والذي قام بإعادة البناء أيضًا، وبشكل غريب نجح. لقد تحققت من الكود الخاص به، ولا يفعل شيئًا على الإطلاق، ويستدعي إعادة البناء بنفس الطريقة التي نفعلها. وبالتالي يبدو أن db:migrate نجح في المحاولة الثالثة لسبب ما؟ قرأت عبر الموضوع أن العدد الكبير من المكونات الإضافية المضافة يضيف تبعيات، والتي قد تتعارض / تكون أقدم مما تم استخدامه سابقًا. لحسن الحظ، لم نكن بحاجة إلى إضافة خطوة إزالة مكون إضافي يدويًا، أو تعديل التبعيات، أو تغيير قاعدة البيانات، كما احتاج الآخرون. هل من المتوقع بطريقة ما أن ينجح تشغيل db:migrate عدة مرات في النهاية؟ يمكنني فقط أن آمل ألا يكون هناك شيء مكسور…
لقد تم تثبيتها في وقت سابق، وقد أغفلناها فقط من واجهة المستخدم مع بقية الإضافات المجمعة من قبل. تم تحسين واجهة المستخدم لدينا لإظهار كل ما هو موجود بشكل صحيح. (كان لدينا عدد من الإغفالات بما في ذلك الدردشة التي تم إخفاؤها بواسطة CSS)
لقد لاحظت بالفعل زيادة في سرعة فريق التطوير الداخلي في الوقت القصير جدًا الذي تم فيه تطبيق هذا. إنه يؤدي إلى منتج أكثر استقرارًا، وهو أمر يسعدني جدًا.
لا توجد خطط للتراجع عن هذا. تحتاج إلى التكيف مع العالم الجديد.
في رأيي، إذا تعطل شيء ما بسبب عدم تثبيت إضافة، فهذا بحد ذاته هو خطأ. لا ينبغي أن يعتمد الأساس على الإضافات. يجب أن تسرد الإضافات نفسها بوضوح متطلباتها على صفحاتها الخاصة.
ولكن نعم، هذا سيجعل الإصدار المستضاف ذاتيًا أقل استقرارًا في المستقبل، حيث سيواجه المستضيفون الذاتيون هذه المشكلات. بين هذا و الموضوع المتشعب، لا أحصل حقًا على انطباع بأن استقرار المستضيفين الذاتيين هو أولوية عالية للفريق.
لم نفكر في ذلك مسبقًا، لذلك ربما تكون بعض الموافقات قد فُقدت. لكننا تمكنا من نقل جزء كبير منها من مشاريع الإضافات على Crowdin إلى النواة. سنقوم بعمل أفضل في المرة القادمة حيث أصبح لدينا الآن الأدوات لنقل الموافقات بين المشاريع.
لا، لم نتحقق مسبقًا، لكنني تحققت لاحقًا. لم يكن لدى أي من الإضافات تعليقات لم يتم الرد عليها على Crowdin. لدينا أداة داخلية تخزن جميع التعليقات التي تم نشرها على إضافات Crowdin الخاصة بنا. يمكننا حتى استخدامها لنشر التعليقات المفقودة على Crowdin مرة أخرى، على سبيل المثال، عندما تحذف Crowdin التعليقات لأن السلسلة المصدر تم تحديثها. لم يكن تنفيذ هذا أولوية.
أتفق مع هذا الرأي. في رأيي، الانفصال الحقيقي هو إبقائها مدرجة كإضافات.
بمجرد دمجها، يجب نقلها إلى شيء يحمل علامة تجارية مثل “الميزات الأساسية” حيث تُعتبر الإضافات مكونات اختيارية يمكن تثبيتها. مقابل جزء من البرنامج الرئيسي. لذلك، في رأيي، من الخطأ تسميتها بالإضافات عندما لا يكون القصد إلغاء تثبيتها.
على غرار مكونات الثيم (TC) التي تم دمجها في الأساس مثل “فقاعات شخصية” غير مدرجة في مكونات الثيم. صحيح أنه في هذه الحالة بالذات لا يمكنك تعطيل مكون الثيم السابق. إذا كنت تريد العودة إلى ما كانت عليه قبل ذلك، فستحتاج إلى إنشاء مكون ثيم للتراجع عن التغييرات
ولكن بعد المزيد من التفكير وقراءة المزيد من المشاركات. إذا تم دمج المكونات الإضافية مع النواة. يجب ألا يطلق عليها حقًا اسم مكونات إضافية ولا يتم إدراجها في “المكونات الإضافية”. ولكن ربما شيء مثل ميزات النواة أو ميزات اختيارية. نظرًا لأنه لم يعد من المفترض حقًا إلغاء تثبيتها.
لا يوجد سبب يجعل برامج المنتديات المصممة بشكل صحيح تتطلب إعلانات لتشغيلها.
إذا قررت Discourse دمج ميزات معادية، فإن الشيء الوحيد الذي ستجبر الناس على فعله هو إما تشعيب Discourse أو الهجرة إلى شيء آخر. أولئك منا الذين لا يحبون التكنولوجيا الكبيرة / مواد الإعلانات يشعرون بقوة شديدة تجاه هذا. لن تجبر Discourse على ذلك، بغض النظر عن مدى صعوبة دفعها. (حاولت Ubuntu هذا معنا والآن أعلى مستودع لدي هو شيء يزيل الإعلانات ؛))
لست متأكدًا من أنني أتابع. إذا كنت تقصد بالكود الإعلاني المكونات الإضافية المدمجة في المنتج الأساسي مقابل بقائها كإضافات/تثبيتات اختيارية. إذا عدنا إلى الوراء، ستجد أن مجموعة متنوعة من “الكود الإعلاني” تم دمجها في الأساس.
يمكنني أن أرى من منظور فريق التطوير أن العديد من المكونات الإضافية الخاصة بهم قد بدأت كمكونات إضافية للسماح باختبار أكثر مرونة قبل دمجها في البرنامج الأساسي.
أستطيع أن أقدر، مثل أي برنامج، أن هناك غالبًا ميزات قد لا يستخدمها الأشخاص ويختارون تعطيلها والبحث عن طرق لإلغاء تثبيت الميزات.
بينما أعترف بأن هناك العديد من المكونات الإضافية المدمجة مؤخرًا والتي من المحتمل ألا أستخدمها. ولكن وجود تعطيل بسيط وتصفيتها هو شيء جيد للجميع.
أتفهم أنه جزئيًا، كما ذكر الفريق، فإن الهدف هو تسهيل الأمور باستخدام الإضافات للاستضافة الذاتية.
الآن، في رأيي، يجب أن تكون واجهة المسؤول قابلة للتخصيص بشكل أكبر كما كانت في السابق. حيث يمكن أن يساعد هذا أيضًا الأشخاص الذين ينتقلون من منصة أخرى من خلال القدرة على تحميل مسؤول هناك يشبه تخطيط المنصة التي يأتون منها. يشبه إلى حد كبير كيف يفعل لينكس هذا مع بعض محاكاة أنظمة التشغيل الأخرى. ولكن هذا موضوع آخر.
أستطيع أن أقدر الشعور بأن ديسكورس قد تبدأ في الاتجاه نحو البرامج الضخمة. أظهرت المفاعلات كم يمكن أن يكون ويندوز إن تي أنحف.
