كانت لدي بعض الأفكار العشوائية التي خطرت ببالي، وكان أحدها ملحق لتثبيت الملحقات. هذا يتطلب إعادة بناء المنتدى. هل هناك طريقة لإعادة البناء باستخدام Ruby؟ أنا حقًا لا أريد أن أجرب:
p `cd ../../`
p `. /launcher rebuild app`
3 إعجابات
في التثبيت القياسي، يعمل Discourse (وبالتالي المكونات الإضافية) داخل حاوية Docker. لا تمتلك هذه الحاوية وصولاً كاملاً إلى نظام ملفات المضيف، لذا لا يمكنها الوصول إلى الدليل /var/discourse الخاص بالمضيف لتعديل app.yml أو تشغيل launcher.
وحتى لو كان بإمكانها… هناك تبعية دائرية بعض الشيء هنا. سيؤدي تشغيل ./launcher rebuild إلى إنهاء حاوية Docker… مما سيؤدي إلى إنهاء launcher rebuild الذي بدأته من المكون الإضافي 
هناك حلول محتملة هنا. على سبيل المثال، إضافة وحدات تخزين إضافية لـ Docker، بحيث يمكن الوصول إلى التكوين/المشغل من داخل الحاوية. لكن الأمر ليس سهلاً.
على حد علمي، قام شخص ما ذات مرة بإنشاء مكون إضافي “لمدير المكونات الإضافية”… والذي تطلب بعض التعديلات على app.yml لإضافة أشياء مثل وحدة التخزين. لكنني لا أستطيع العثور على أي مواضيع حوله الآن، لذا أفترض أنه لم يعد مدعومًا. ربما يمكن لشخص آخر مشاركة رابط إذا تمكن من العثور عليه؟ (أو ربما كان كل ذلك مجرد حلم 
)
من جانب CDCK، نميل بالتأكيد نحو استخدام السمات عندما نريد أن يتمكن العملاء من التثبيت/التحديث/إلغاء التثبيت حسب الرغبة. السماح للأشخاص بتثبيت المكونات الإضافية بشكل عشوائي ليس خيارًا، لأن ذلك سيؤثر على العملاء الآخرين الذين يعملون على نفس الخادم.
5 إعجابات
نعم، ها هو:
5 إعجابات
هممم… فهمت.
أوه، عفوًا، لم أفكر في ذلك!
إعجاب واحد (1)
سيقوم Dashboard.literatecomputing.com بتثبيت وإزالة المكونات الإضافية عن طريق تعديل app.yml (أو web_only.yml) وإجراء إعادة البناء (في الواقع، التمهيد، التدمير، إعادة البناء). في تثبيت حاويتين، يكون وقت التعطل ضئيلاً.
كما أنه يقوم بأشياء مثل ترقية docker و postgres، و docker prune، وما إلى ذلك. نظرًا لأنه يدير تثبيتًا قياسيًا بالكامل، فأنت لست مرتبطًا به، ولا يمكنه كسر أي شيء إلا إذا كان يقوم بشيء ما بالفعل (مثل تثبيت مكون إضافي سيئ).
إنه مكون إضافي لـ discourse (خاص) يدفع مجموعة أدوات ansible. يمكنك الانضمام إلى مجموعة التجربة المجانية واستخدامه مجانًا (مع دعم محدود).
4 إعجابات
يبدو أن هذا المكون الإضافي يقوم فقط باستنساخ المستودع في مجلد /plugins. مثير للاهتمام.
كان ProCourse Installer رائعًا! من المؤسف أنه تسبب في مشاكل لبعض الإضافات.
3 إعجابات
يمكنك القيام بشيء مثل هذا داخل الحاوية لإضافة مكون إضافي إلى حاوية موجودة:
cd /var/www/discourse/plugins
git clone my-plugin-url
rake db:migrate assets:precompile
sv restart unicorn
ولكن هناك مشاكل في الاحتفاظ بالمكونات الإضافية في الحاوية وفي app.yml عند إعادة البناء لاحقًا.
لقد تعرضت للحرق عدة مرات عند القيام بـ ./launcher destroy app;./launcher start app لتطبيق متغيرات بيئة جديدة من app.yml فقط لأكتشف أن الحاوية “الجديدة” متأخرة عن إصدار قاعدة البيانات. الأمر أسوأ إذا قام شخص ما بترقية بعض المكونات الإضافية فقط في الحاوية التي عملت مع إصدار Discourse الذي كان في الحاوية القديمة، ولكن ليس مع الإصدار الذي تحصل عليه عند إعادة البناء. . .
3 إعجابات
إذًا لهذا السبب قامت إضافة ProCouese فقط باستنساخ المستودعات، ولا يمكن إزالتها إلا عبر صفحة الإضافة هذه لحذف مجلد الإضافة المستنسخة باستخدام rm -rf.
إعجاب واحد (1)
لقد نجحت بالفعل بشكل لائق كإثبات للمفهوم. يمكن تحسينها قليلاً حيث قيل إنها قد تجعل استكشاف الأخطاء وإصلاحها أكثر صعوبة. لذا ربما نحتاج إلى بعض معلومات سطر الأوامر حول كيفية الوصول إلى مثبت procouree. ربما ملف سجل أفضل.
الميزة الإضافية هي أنه يمكنك تعطيل جميع الإضافات ببساطة عن طريق إزالة / التعليق على مثبت pro course. على الرغم من أنها معطلة الآن.
لدى جو بعض الأفكار التقدمية جدًا. إذا كنت أتذكر بشكل صحيح، فقد قام بإنشاء إضافة التصويت على المنشور الأول؟