أعتقد أن ما يقترحونه هو أنه إذا تم إدراج مكون إضافي تم تجميعه بالفعل مع النواة في app.yaml، فسيتم تجاهله ببساطة. مع إشعار يفيد بأن تضمينه في app.yaml كان زائدًا عن الحاجة ويمكن للمالك إزالته.
أجد أيضًا أنه من المزعج بعض الشيء أنه طالما لدي أي مكونات إضافية مدرجة في app.yaml الخاص بي، فإنني دائمًا ما أخاطر بفشل التحديث. لذلك في كل مرة أقوم فيها بالتحديث أحتاج إلى التحقق مرة أخرى لمعرفة ما إذا كان أحد المكونات الإضافية الخاصة بي قد تمت إضافته إلى النواة.
لماذا لا يكون هناك ببساطة برنامج نصي يقوم بذلك لمسؤول النظام؟
أنا شخصياً أقوم بتنظيم الإضافات حسب الفريق أو المؤلف لجعل حياتي أسهل قليلاً، لذا أعرف أي الإضافات رسمية وما إلى ذلك. ولكن إذا كانت الفكرة هي جعل Discourse أكثر سهولة في الاستخدام، فيجب القيام بذلك من جانب الفريق.
ليس مختلفًا كثيرًا عندما تنصح الأشخاص عندما يواجه المستخدم ترقية معطلة بسبب فشل ترقية Postreq (إذن؟).
مع الإضافات، هذا هو بالضبط المكان الذي كانت فيه فكرة Procourse Installer فكرة رائعة لتبسيط تثبيت الإضافات وإلغاء تثبيتها دون الحاجة إلى استخدام سطر الأوامر.
بالتأكيد، أتفهم أنه قد يحتاج إلى مزيد من الصقل في حالة حدوث خطأ ما. ولكن يمكن أن يكون ذلك سهلاً بما يكفي مع ملف سجل أو خيار احتياطي بسيط إذا لزم الأمر من سطر الأوامر. أقدر أن هذا قد يجعله أكثر جاذبية للاستضافة الذاتية مقابل خطة مدفوعة. ومع ذلك، هناك ما يكفي من الإيجابيات للخطة المدفوعة للذهاب في هذا الاتجاه.
يمكن أيضًا تصميم هذا النوع من مدير الإضافات أو نسخه للسماح للخطط المستضافة بتثبيت الإضافات ضمن مستوى الاستضافة الخاص بها، حيث قد لا تكون بعض الإضافات مطلوبة في خطة معينة.
بالتأكيد فاتني منشور منذ فترة طويلة بخصوص تجميع الدردشة وحاولت تثبيته. لا أعتقد أن العلامة تم تحديثها في المكون الإضافي. بالطبع، تسبب ذلك في تعطل الموقع لأنه لم يعجبه محاولة تثبيت المكون الإضافي عندما كان من الممكن نظريًا ربما تجاهل الإدخال مع إعادة بناء مكتملة تنصح بإزالته لأنه غير ضروري.
حسنًا، تم استلام الملاحظات! 
أعتقد أنه يمكننا إغلاق هذا الموضوع الآن - سأضبط مؤقتًا لإعطاء الزملاء فرصة للرد إذا أرادوا ذلك.
هل سيتم تضمين whos-online في الإصدار الأساسي؟
مع المبادرة الأخيرة لتضمين المزيد من الإضافات الرسمية في الإصدار الأساسي، كنت أتساءل عما إذا كانت إضافة “من متصل” (Who’s Online) قيد النظر لتضمينها.
لقد لاحظت أنها متاحة في خطط الاستضافة الرسمية (تُحتسب ضمن حصة الإضافات)، لذا أنا فضولي لمعرفة ما إذا كان ذلك يشير إلى تحرك نحو تبني أوسع.
أتفهم تمامًا إذا كانت قيود الأداء أو التوافق الفلسفي تعني أنه يجب أن يظل افتراضيًا ما لم يُحدد خلاف ذلك في app.yml.
شكرًا!
لا نخطط حاليًا لنقل المزيد من المكونات الإضافية إلى النواة الأساسية. كان Cakeday هو الأخير، وكان يجب القيام به بشكل منفصل عن الدفعة الرئيسية بسبب بعض التعقيدات في الطريقة التي تم تمكينه بها افتراضيًا سابقًا.
أتفهم تمامًا الإحباط بشأن العملية هنا - بالتأكيد ليست سلسة كما أرغب. لإعطاء بعض السياق: المشكلة الأساسية هي أن ملفات app.yml ليست ملفات تكوين لـ Discourse. إنها تكوين pups، وخطوط تثبيت المكونات الإضافية هي مجرد أوامر shell.
جلب المنطق الخاص بـ Discourse إلى pups، وجعله يتجاهل أوامر shell معينة، ليس خيارًا حقًا. هذه الأداة لا تستخدم لـ Discourse فقط. بالإضافة إلى ذلك، أشك في أن عددًا من الأشخاص سيكونون غير راضين عن تغيير أوامر shell التي تعمل أثناء التمهيد دون علمهم.
لذلك، توصلنا إلى الحل الأنظف الذي يمكننا العثور عليه بالأدوات المتاحة: فرض إعادة بناء سطر الأوامر، ثم عرض رسالة تطلب من الأشخاص إزالة السطر المتأثر من تكوينهم.
منشور مثير للاهتمام يا ديفيد!
لاحظت شيئًا في OP لموضوع إضافة Who’s Online:
فكر مليًا قبل تثبيت هذه الإضافة
أعتقد أن “تثبيت” قد يكون من الأفضل صياغتها كـ “تمكين” هناك - إذا كان ذلك صحيحًا من الناحية الفنية.
الصياغة الحالية قد تعطي انطباعًا بأن وجود إضافات مجمعة إضافية هو مصدر قلق فلسفي أو متعلق بالأداء - بينما يتعلق الأمر حقًا بما إذا كانت مُمكّنة. نظرًا لأن الإضافة الأساسية الجديدة التي لم تكن ممكّنة من قبل تكون معطلة افتراضيًا بعد إعادة البناء، فإن الخطر لا يكمن في تثبيتها مع النواة، بل في تشغيلها.
هذا ليس صحيحًا بالضرورة، انظر Disabled plugins still causing performance impact
الآن تم حل هذه المشكلة المحددة (في الغالب) على الإضافات المجمعة، ولكن قد لا يزال هذا يحدث في إضافات أخرى هنا وهناك.
يضيف المكون الإضافي discourse-categories-suppressed واجهة مستخدم بسيطة اختيارية لإخفاء فئات محددة من موجز “الأحدث”. يتكامل من خلال قائمة منسدلة واحدة في:
المسؤول ← الإعدادات ← الفئات
“الفئات المخفية من الصفحة الرئيسية”
يبدو هذا وكأنه إعداد أساسي طبيعي جدًا - خاصة وأن:
• إنه رسمي ويتم صيانته بنشاط
• يظل معطلاً افتراضيًا ما لم يختار مسؤول تمكينه
• تعتمد العديد من المجتمعات (بما في ذلك مجتمعي) على “الأحدث” كعرض أساسي للهبوط وتريد تحكمًا أدق في ما يظهر هناك
هل سينظر الفريق في تجميع هذا المكون الإضافي (لا يزال معطلاً افتراضيًا)، حتى يتمكن المسؤولون من استخدام هذا التبديل دون الحاجة إلى تثبيت أي شيء إضافي؟
شكرًا للنظر - يبدو أنه تفضيل واجهة مستخدم صغير ستستفيد منه العديد من المواقع من توفره بشكل جاهز.
تم إغلاق هذا الموضوع تلقائيًا بعد يومين. لم يعد يُسمح بالردود الجديدة.
لست متأكدًا مما إذا كان هذا مقصودًا، ولكني أردت الإبلاغ عنه:
نحن نستخدم الإصدار المستقر القديم v3.5.4 وكنا نستخدم إضافة cakeday.. ومع ذلك، توقفت عمليات إعادة البناء (لنفس إصدار Discourse) عن العمل لأن cakeday قد تم دمجها في النواة. لذلك، قمت بتعطيل الإضافة في ملف yml و… حسنًا، لقد اختفت. الآن تعمل عمليات البناء مرة أخرى، ولكن لم يعد لدينا أيام كعك حيث لا يُظهر واجهة المستخدم الإدارية أي علامة على تثبيت الوظيفة.
أفترض أن السبب هو أننا نستخدم إصدارًا مستقرًا قديمًا، ولكنه كان لا يزال نتيجة غير متوقعة لإعادة بناء نفس إصدار Discourse.
لم يتم تضمين إضافة cakeday في الإصدار 3.5.4، وهذا هو السبب في أنك لم تعد تراها.
هل أنت متأكد من أن هذا هو سبب فشلها؟ إذا رأيت شيئًا مثل:
تلميح: الإضافة ‘$plugin’ مدمجة الآن مع Discourse ويجب عدم تضمينها في تكوين الحاوية الخاص بك
فأنا أخشى أنه سيتم عرض ذلك على أي عملية إعادة بناء فاشلة عند تضمين إضافة cakeday في ملف التكوين. كانت هذه هي الطريقة الأكثر فعالية التي يمكننا من خلالها تحذير الأشخاص بشأن المشكلة، ولكنها قد تكون مربكة للأشخاص الذين يستخدمون إصدارات نواة أقدم.
لذا، إذا كنت بحاجة إلى إضافة cakeday، أعتقد أنه يجب أن تكون قادرًا على إضافتها مرة أخرى إلى ملف app.yml وإعادة البناء. أظن أن الفشل كان بسبب شيء آخر، والذي قمت بحله الآن.
بالمناسبة: أوصي بشدة بالترقية إلى إصدار مدعوم. الإصدار 3.5 لم يعد يتلقى تحديثات أمنية، وقد يكون عرضة للهجوم.
Cloning into 'docker_manager'...
I, [2026-03-09T15:05:49.126710 #1] INFO -- : > cd /var/www/discourse/plugins && git clone https://github.com/discourse/discourse-cakeday.git
fatal: destination path 'discourse-cakeday' already exists and is not an empty directory.
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse/plugins && git clone https://github.com/discourse/discourse-cakeday.git failed with return #<Process::Status: pid 146 exit 128>
Location of failure: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.4.0/lib/pups/exec_command.rb:138:in `spawn'
exec failed with the params {"cd"=>"$home/plugins", "cmd"=>["git clone https://github.com/discourse/docker_manager.git", "git clone https://github.com/discourse/discourse-cakeday.git", "git clone https://github.com/discourse/discourse-whos-online.git", "git clone -b no-regional-flags https://github.com/mentalstring/discourse-nationalflags.git", "git clone https://github.com/discourse/discourse-yearly-review.git", "git clone https://0fa273b19b56a1a58c41484d49a01d99f1b5b8d2@github.com/mentalstring/custom-username-validator", "git clone https://github.com/discourse/discourse-saved-searches"]}
bootstrap failed with exit code 128
---
HINT: The plugin 'discourse-cakeday' is now bundled with Discourse and should not be included in your container configuration.
Remove the line 'git clone https://github.com/discourse/discourse-cakeday' from your containers/web_only.yml file, then try again.
For more information, see https://meta.discourse.org/t/373574
---
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
إعادة إضافة المكون الإضافي إلى app.yml يتسبب في حدوث الخطأ المذكور أعلاه. إزالته على الفور تجعل عملية البناء تعمل مرة أخرى. يبدو أن هذا المكون الإضافي هو المشكلة الوحيدة.
أنا على علم بأننا نستخدم إصدارًا قديمًا وأن الترقية مدرجة في خارطة الطريق. أردت فقط أن أشير إلى أنه على الرغم من أننا لم نغير الإصدار الذي نعمل به، إلا أن 3.5.4 كان يتم بناؤه بنجاح (مع المكون الإضافي) ولكنه توقف عن البناء مع المكون الإضافي ولا يبدو أن لدينا أي طريقة لاستعادة وظيفة المكون الإضافي (سواء من خلال المكون الإضافي أو في النواة).
مثير للاهتمام! أتساءل عما إذا كان ذلك بسبب أن صورة دوكر (docker image) الخاصة بنا تتضمن الآن discourse-cakeday، وعندما يتم “تخفيض إصدار” النواة (core) إلى 3.5، فإنها تترك دليلاً فارغًا خلفها.
إذا أضفت rm -rf discourse-cakeday قبل السطر git clone https://.../discourse-cakeday، فسيؤدي ذلك إلى تنظيفه. لذا سيبدو شيئًا كهذا:
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- rm -rf discourse-cakeday
- git clone https://github.com/discourse/discourse-cakeday
نعم، لقد نجح ذلك. إنه يعمل مرة أخرى - شكرًا لك!
أعتذر عن تحويل هذا الموضوع إلى مسار جانبي طفيف، ولكني لا أعتقد أن هناك موضوعًا أكثر ملاءمة وهذا يتعلق إلى حد ما بالمشكلة السابقة.
منذ رسالتي السابقة، أعتقد أنه تم إجراء المزيد من التغييرات على discourse/docker_manager مما يتسبب في تعطل المزيد من الأشياء في عمليات بناء الإصدارات الأقدم. بعد إعادة بناء اليوم، توقف قسم الإدارة بأكمله في Discourse عن العمل مع أخطاء مثل هذه:
loader.js:247 Uncaught (in promise) Error: Could not find module `discourse/admin/models/admin-plugin` imported from `discourse/plugins/docker_manager/discourse/models/repo`
تمكنت من إصلاح البناء باستخدام هذا في ملف yml:
- git clone https://github.com/discourse/docker_manager.git && cd docker_manager && git reset --hard 314bbd78c200860c76bb62ced65b40e7cde5aa02 && cd ..
لست متأكدًا من الالتزام الذي كان يسبب المشكلة، ولكن هذا كان كافيًا لإعادته للعمل مرة أخرى.
أعلم، أعلم، يجب أن أقوم بالترقية (أقصد ذلك حقًا). ولكن من المحتمل أن يكون هناك أشخاص آخرون مثلنا عالقون في الإصدارات الأقدم لفترة أطول مما هو مخطط له لسبب أو لآخر، وتوقف الإصدارات الأقدم عن العمل دون تغيير الإصدار أمر غير متوقع بعض الشيء.
على أي حال، لقد وجدت حلاً بديلاً حتى نقوم بالترقية، لذا أشارك هذا في حال كان مفيدًا للآخرين في نفس الموقف.
ما هو إصدار نواة Discourse الذي تستخدمه؟ هل ما زال 3.5؟
نعم، 3.5.4. سنقوم بالترقية قريبًا، نأمل ذلك.