حسنًا، إذا كان لديّ إضافة (Plugin) متطورة بالفعل في وضع التطوير، فكيف يمكنني نقلها إلى بيئة الإنتاج دون الاعتماد على خدمات خارجية؟ هل توجد طريقة للقيام بذلك؟
نعم، موضّح في هذا المستند
هل أنت جاد؟ يعتمد هذا البرنامج التعليمي بأكمله على GitHub، وسؤالي يتعلق بعدم الاعتماد على أطراف ثالثة.
استضافته على GitHub أو GitLab، ثم استنسخه بالطريقة المعتادة.
يعتمد نظام Discourse نفسه على عدد كبير من الخدمات الخارجية مثل Github و Docker Hub و Rubygems وسجل NPM و LetsEncrypt. لا يبدو لي أن جعل نشر الإضافة مستقلاً عن Github فقط أمر منطقي.
أنت محق، لقد فاتني هذا الجزء. 
هذا منطقي لأنني طورت العديد من الإضافات الصغيرة التي تقوم بأعمال بسيطة، وبالتالي لن تحتاج إلى تحديثات. إدارة GitHub لرفع هذه الإضافات الصغيرة مبالغة، فهي تتطلب جهدًا كبيرًا.
نشر إضافة على GitHub لا يستغرق أقل من دقيقة واحدة من العمل. أنشئ مستودعًا وانسخ/ألصق سكريبت الأوامر (shell script) الذي يظهر عند الإنشاء، والذي يقوم بإجراء عمليات git init و git add و git push. هذا هو السبب في أنك أول من يطرح هذا السؤال. كما أن وضع إضافاتك تحت نظام التحكم في الإصدارات فكرة جيدة، بغض النظر عن حجم الإضافة.
يمكنك نسخ سكريبت التثبيت وتعديله لنسخ مجلدات الإضافة الخاصة بك مباشرة إلى صورة Docker. هذا يفترض أن لديك كود الإضافة محليًا بالفعل. ومع ذلك، أظن أن الحفاظ على سكريبت التثبيت المعدل ليتوافق مع التحديثات التي يتلقاها سيكون أكثر صعوبة بعشر مرات.
لستُ أول من يسأل (فقد سأل آخرون من قبل)، لكن النقاش يصبح أكثر تعقيدًا، وفي النهاية، أنتم لا تجيبون فعليًا على أي شيء.
لا يوجد مبرر لهذا النهج الذي لا يسمح بالمرونة. جربوا على الأقل ووردبريس أو خدمة أخرى مرة واحدة، وسترون أن تثبيت الإضافات ليس كابوسًا كما هو عليه في ديسكورش.
استخدام غيت هب أمر جيد، لكن هل يُنظر إلى الرغبة في العمل محليًا على أنه أمر غير مرغوب فيه؟
للتوضيح فقط: أنا لا أعمل لدى Discourse.org. أنا مجرد مستخدم هنا، مثلكم تماماً.
في Communiteq، قمنا بتطوير لوحة تحكم خاصة بنا تتيح تثبيت وإلغاء تثبيت الإضافات بسهولة. معلومة جانبية: لا تحل هذه اللوحة محل Github، بل تُبنى عليه.
لو كنت قد طوّر (وليس مثبّت) إضافة لووردبريس يوماً ما، لما قلت ذلك أبداً، لأن تطوير الإضافات هو حقاً كابوس.
استخدام نظام التحكم بالمصادر بشكل صحيح سيوفر عليك الكثير من المتاعب والمشكلات في المستقبل. فهو يحافظ على أمان إضافةك (plugin) للمستقبل ويساعد في تتبع سجل تحديثاتها.
يوفر طريقة معيارية لفصل الاهتمامات، مما يقلل من التعقيد.
يتيح لك إدارة النسخ المستقلة بسهولة، ويجعل عمليات نقل الخوادم وإعادة بنائها أكثر بساطة.
كما أنه يمثل النهج الاحترافي.
أنا فضولي لمعرفة كيف قمت ببناء واختبار “إضافة متطورة” دون استخدام جيت هب أو أي خدمة مستودع مماثلة؟ كيف طوّرت “العديد من الإضافات الصغيرة” لديسكورس؟
السلوك العدائي تجاه الأشخاص الذين يحاولون مساعدتك لن يؤدي إلى أي نتيجة. إذا كنت قد طوّرت إضافات من قبل كما تدعي، فستعلم أنه ليس أمرًا كابوسيًا تثبيتها على ديسكورس؛ استخدام مستودع وتحرير ملف app.yml يجب أن يكون أمرًا سهلًا لشخص يستضيف الخدمة بنفسه ومتمرس في تطوير الإضافات.
لا أعرف ما إذا كان الاستضافة على Codeberg ستعمل مع إضافات Discourse. إذا كانت تعمل، فهذا على الأرجح ما يبحث عنه الكاتب الأصلي.
أتفق مع طرح السؤال حول استخدام GitHub. فقد قاموا بحذف حوالي 300,000 مستودع (بسبب انتهاكات حقوق الطبع والنشر DMCA) دون إشعار مسبق، ومنهجية دراسة جامعة كارنيجي ميلون (CMU) — التي تتحقق مما إذا كانت المستودعات التي رُصدت سابقاً قد حُذفت لاحقاً — تشير إلى أن عدد المستودعات المحذوفة عبر الإنفاذ الداخلي أكبر بمقدار رتبة قدرية.
وجدت دراسة جامعة كارنيجي ميلون وحدها حوالي 14,000 مستودع محذوف في عملية مسح واحدة مزيفة النجوم، مقارنةً بحوالي 20,000–47,000 مستودع سنوياً بسبب DMCA. لا توجد مقاييس إجمالية لأن هذه المستودعات تظهر فقط أخطاء 404.
أعني، لا يوجد خطر حقيقي على إضافات Discourse، لكن الآن أصبحت Farble قضية أمن قومي، ولم نكن نعرف ماذا يمكن أن يحدث في المستقبل القريب إذا كان على كل منشور بشري أن يخضع لمصادقة الهوية (KYC) عبر Persona أو شيء مشابه.
إذن، تقترح أن ينتقل فريق Discourse بعيداً عن GitHub؟
هناك بدائل عدة، وهذا أمر جيد. استخدمها إن لزم الأمر، لكن إذا لم تكن مستعداً لبذل قليل من الجهد، فلا داعي لتشغيل Discourse، برأيي.
هل هذا ما تسمّيه صراعًا؟ آسف، لكن لم يحدث أي قتال، وأنت على الأرجح مبالغ في حساسيتك. وأعتذر إن بدا كلامي صراعًا.
على أي حال، للإجابة على سؤالك، لقد فعلت ذلك بوضوح باستخدام حساب GitHub مؤقت، لكن هذه الحسابات صغيرة جدًا لدرجة أنني لا أحتاج إلى اختبارها كثيرًا أو كتابة الكثير من الكود.
لقد قمت بالفعل بتثبيتها باستخدام الحساب المؤقت واختبرت أنها تعمل، لكن على المدى الطويل، لا أريد الاضطرار إلى مراقبة المستودع في كل مرة أريد فيها إجراء تغيير. أنا لا أمزح عندما أقول إنها صغيرة جدًا. على سبيل المثال، واحدة منها تضيف زرًا فقط إلى صفحة خارجية في الصفحة الرئيسية، وهذا كل شيء.
الأمر يشبه أن تقول إنك تريد سيارة، لكنك لا تجد الوقت الكافي لإجراء فحص السلامة السنوي للمركبة.
إنه مجرد جزء من تكلفة ممارسة الأعمال عند الاستضافة علناً على الويب المفتوح.
أنا متأكد من أنه إذا أردت، يمكنك إيجاد طريقة لتعديل سكريبتات التثبيت وإنشاء روابط رمزية لها من مكان ما على خادمك، لكن يبدو أنك لا ترغب في بذل أي جهد، وسيكون عليك أنت كتابة هذا الحل ودعمه.
إذا تمكنت من اختزال ذلك في مكون سمة (Theme Component)، يمكنك اللجوء إلى أسلوب “هيث روبنسون” (وهو أسلوب يعتمد على الحلول المعقدة غير التقليدية) واستخدام discourse_theme لنقل الملفات من جهازك المحلي إلى الخادم، لكن لا تبكِ إذا تعطل جهازك المحلي، أو ضاع، أو سُرق، ولم تتمكن من استعادة الكود الخاص بك (دون أن تضطر بعد ذلك إلى معرفة كيفية استنساخ نسخة حية من الخادم).
أصبح الأمر أبسط حتى لو لم ترغب في تثبيت gem الخاص بـ discourse_theme، حيث يمكن تحميل السمات كملف مضغوط، ويمكنك بناء الكثير منها مباشرةً من واجهة المستخدم الإدارية.
وللتأكيد مجددًا، ما لم تكن تعمل مع Ruby، فلست بحاجة إلى أي إضافة على الإطلاق، لذا فمن المرجح أن السمة هي ما تبحث عنه… ولا حاجة لـ git.
نقطة ممتازة! لكن ميزة discourse_theme تكمن في طريقة التحديث الفورية في المكان نفسه، مما يتيح لك مراجعة التغييرات بسرعة دون الحاجة إلى ضغط التحديث وإعادة رفعه.
الأمر أشبه بالرغبة في قيادة سيارة ولكن دون زيارة محطة الوقود قط. “سأقوم بملء خزان الوقود بيدي عارية”. 
إذا كنت تستخدم GitHub لتطوير الإضافات، فإن استخدامه كمصدر للتثبيت يصبح أمراً سهلاً للغاية. دفع التغييرات إلى المستودع (repo) يتطلب جهداً أقل من نقل ملفات الإضافات المحدثة يدوياً إلى الخادم.
يبدو أنك تحاول تجاوز عملية التثبيت لنشر الإضافات على تثبيت Discourse المستضاف.