أعتقد أن ما يقترحونه هو أنه إذا تم إدراج مكون إضافي تم تجميعه بالفعل مع النواة في 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 واجهة مستخدم بسيطة اختيارية لإخفاء فئات محددة من موجز “الأحدث”. يتكامل من خلال قائمة منسدلة واحدة في:
المسؤول ← الإعدادات ← الفئات
“الفئات المخفية من الصفحة الرئيسية”
يبدو هذا وكأنه إعداد أساسي طبيعي جدًا - خاصة وأن:
• إنه رسمي ويتم صيانته بنشاط
• يظل معطلاً افتراضيًا ما لم يختار مسؤول تمكينه
• تعتمد العديد من المجتمعات (بما في ذلك مجتمعي) على “الأحدث” كعرض أساسي للهبوط وتريد تحكمًا أدق في ما يظهر هناك
هل سينظر الفريق في تجميع هذا المكون الإضافي (لا يزال معطلاً افتراضيًا)، حتى يتمكن المسؤولون من استخدام هذا التبديل دون الحاجة إلى تثبيت أي شيء إضافي؟
شكرًا للنظر - يبدو أنه تفضيل واجهة مستخدم صغير ستستفيد منه العديد من المواقع من توفره بشكل جاهز.
تم إغلاق هذا الموضوع تلقائيًا بعد يومين. لم يعد يُسمح بالردود الجديدة.