(بالمناسبة @Heliosurge أعتقد أن هذا قد طُرح من قبل):
من الواضح أن الموضوع انحرف تمامًا عن مساره الآن، كما يحدث دائمًا في أي نقاش يتحدى التيار. لا أعتزم حتى مناقشة مسألة استخدام مكون سمة، لكنني أشكر الجميع على أي حال.
كيف انحرفت عن المسار؟ لقد طرحت سؤالاً وأعرب الناس عن آرائهم. يبدو الأمر تمامًا في صلب الموضوع بالنسبة لي؟
هل تملك الآن جميع المعلومات التي تحتاجها لتنفيذ أي إعداد تريده؟
أتفق إلى حد ما مع صاحب الموضوع بأن «الآراء» بدأت تتحول إلى «سخرية من صاحب الموضوع لما يريد».
لا أعتقد أن هذا يحتاج إلى مزيد من النقاش. لذا، ما لم يقدم أحد حلولاً أخرى لهذا الموضوع، يمكننا إنهاء النقاش هنا، في رأيي.
أنا أوافق على أن بعض المشاركات تحتوي على عدوانية غير ضرورية.
لقد ذكرت وحدة تحكم (TC) فقط فيما يتعلق بإضافة زر إلى الصفحة الرئيسية. وقد تم إثبات ذلك بالفعل من خلال عدة مكونات. إذا لم تكن هناك مشكلة أمنية، فإن وحدة التحكم (TC) هي السبيل الأمثل.
ومع ذلك، أنا شخصياً مهتم بمعرفة المشاكل التي تواجهها مع السمات (Themes) ومكونات السمات. تُستخدم الإضافات (Plugins) بشكل أساسي للأمان ولأشياء لا يمكن إنجازها داخل وحدة التحكم (TC)، مثل تغيير كيفية عمل الوظائف الأساسية. إذا كنت أكثر راحة، يمكننا مناقشة هذا الأمر في رسالة خاصة ودودة.
فائدة أخرى لوحدة التحكم (TC) هي أنه يمكنك تعديل الكود الخاص بك عند الحاجة ضمن واجهة موقع الويب.
المشكلة التي أراها في مسار الإضافات هي أن حتى الإضافات الرسمية المدمجة في النواة (core) لا تزال تستخدم Git لتحديث الإضافات وبرنامج Discourse نفسه.
يمكنك استخدام دعم الأحجام في ملف app.yml لتثبيت مجلد من المضيف إلى مجلد الإضافات في الحاوية.
يمكنك استخدام أي طريقة تريدها لنسخ شفرة المصدر الخاصة بك من المكان الذي تحفظها فيه إلى دليل discourse/plugins. إذا لم تكن تفضل استخدام الأمر git clone، يمكنك استخدام rsync أو cp -a. فقط انسخ المكوّن الإضافي الخاص بك إلى آلةك الافتراضية (VM) بأي طريقة تريدها، ثم أدرج أمراً يقوم بنسخه بالطريقة التي يعمل بها git clone.
هذا بالتأكيد هو الجواب الصحيح هنا. فهو يحترم المعايير الأصلية للسؤال. لم يكن هذا الموضوع رائعاً من منظور إظهار مجتمع إيجابي وداعم.
@Falco @pfaffman شكراً لكم، لقد أوضحت إجاباتكم شكوكي.
أترك هنا إعداد ملف app.yml الخاص بي في حال كان مفيداً لأي شخص يحاول تحميل الإضافات المحلية إلى Discourse من جهاز المضيف.
## حاوية Docker عديمة الحالة؛ يتم تخزين جميع البيانات في /shared
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared
- volume:
host: /var/discourse/shared/standalone/log/var-log
guest: /var/log
- volume:
host: /var/discourse/plugins
guest: /var/plugins
## تذهب الإضافات إلى هنا
## راجع https://meta.discourse.org/t/19157 للحصول على التفاصيل
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
- cp -a /var/plugins/. $home/plugins/
في إعدادي، أحافظ على جميع الإضافات المخصصة في /var/discourse/plugins على المضيف.
تصبح الدليل المثبتة متاحة داخل الحاوية كـ /var/plugins، وخلال خطاف after_code، الأمر:
cp -a /var/plugins/. $home/plugins/
ينسخ جميع الإضافات المثبتة إلى دليل الإضافات الأصلي في Discourse ($home/plugins، وعادةً ما يكون /var/www/discourse/plugins).
هذا يجعل من الممكن إدارة الإضافات مباشرة من المضيف دون استخدام تثبيت الإضافات المعتمد على git أو الاعتماد على خدمات الاستضافة التابعة لأطراف ثالثة.
رائع. يسعدني أن ذلك نجح معك!
يمكنك أيضاً إنشاء رابط رمزي (symlink) للإضافات بدلاً من نسخها. وإذا فعلت ذلك، يمكن تطبيق التغييرات عليها (على الأقل في بعض الحالات التي لا تحتاج فيها إلى ترحيل أو تجميع الأصول) عن طريق إعادة تشغيل الحاوية.
مرحباً، فقط أتساءل كيف تتعاملون مع عمليات الهجرة والتغييرات في قاعدة البيانات؟
هذه مستقلة عن طريقة تثبيت الإضافة. إذا كانت الإضافة موجودة، فسيتم التعامل مع عمليات الترحيل.
أعيد بناء الحاوية (Container) إلا في ظروف غريبة. ولكن يمكنك تشغيل
rake db:migrate
كما يمكنك أيضاً تجميع الأصول (Assets) مسبقاً. لا أنصح بذلك إلا إذا كان لديك حاجة محددة ومألوفة مع إطار عمل Rails.