أستخدم S3 لتخزين المرفقات، مما يسمح بسعة تصل إلى 160 جيجابايت.
لقد قمت بتغيير حد nginx إلى 0 (غير محدود).
معامل “upload_size” في ملف app.yml مضبوط أيضًا على 0.
لا نقوم برفع الملفات مباشرة إلى S3، بل تنتقل أولاً إلى خادمك، ثم يرسل الخادم الملفات إلى S3. وهذا يعني أنك لا تريد تحديد حد أكبر من مساحة القرص المجانية المتاحة لديك.
حسناً، أود تحديد الحد إلى 10 جيجابايت، ف لدي مساحة تخزين كافية. لكن كيف يمكنني تغيير حد Discourse؟
يمكنك تجاوز الحد الأقصى باستخدام إضافة مخصصة. يمكنك استخدام هذه الإضافة كمثال:
شكرًا لك، يمكنني تأكيد أن الحد قد أُلغي باستخدام هذا الإضافة والإعدادات:
files:
max_attachment_size_kb:
client: true
default: 1024000
max: 6144000
ومع ذلك، لدي مشكلتان:
- عند رفع ملف بحجم 2 جيجابايت، يتم الرفع بنجاح حتى 100% ثم يفشل مع ظهور رسالة خطأ عامة.
- في كل مرة أحاول فيها ذلك، يزداد حجم حاوية Docker الخاصة بـ Discourse بمقدار 2 جيجابايت ولا يتم تنظيفها!! أنا على وشك نفاد المساحة.. كيف يمكنني تنظيف هذا؟
سيكون من الأفضل لك استخدام خدمة سحابية مناسبة حسب اختيارك، وربط الملفات في مواضيع Discourse. فـDiscourse لم يُصمم ليكون أداة لتخزين الملفات الكبيرة.
أنا أستخدم تخزين سحابي S3. لا ينبغي تخزين أي شيء على Discourse نفسه.
هذا ليس ما أعنيه — أعني خدمة سحابية مخصصة للأفراد مثل Google Drive أو OneDrive أو Dropbox وما إلى ذلك.
بغض النظر عن الطريقة التي تستخدمها، فإن Discourse لم يُصمم للتعامل مع الملفات الكبيرة.
بغض النظر عن المكان الذي ينتهي فيه الملف، فإن Discourse لا يُقصد به أن يكون آلية رفع ملفات ضخمة أيضًا.
أفهم أن ذلك لم يكن مقصودًا، لكنه سيكون ميزة رائعة بالنسبة لي، وسيعزز تجربة المستخدم إذا لم يضطروا للذهاب إلى خدمة أخرى لرفع الملفات ثم العودة إلى Discourse. لذا آمل ألا تتأذوا إذا حاولت جعلها تعمل، رغم أن ذلك لم يكن مقصد التطوير الأصلي.
من عجائب المصادر المفتوحة أنك حر في التعديل.
وبالمثل، إذا لم يكن شيء ما مدعومًا، فلا توجد ضمانات بأن التغييرات المستقبلية في Discourse لن تجعل التعديلات التي تجريها اليوم غير قابلة للتشغيل تمامًا في المستقبل.
أنا أفكر في السماح برفع ملفات كبيرة (قد تصل إلى 50 ميجابايت، ومن الممكن أن يكون هناك رفع جماعي عبر واجهة برمجة التطبيقات) على موقعي أيضًا. أنا أحاول فقط فهم القلق هنا. إذا كان S3 مُهيأً للتعامل مع رفع الملفات الكبيرة وتخزينها، وربط منتدى Discourse بهذه الملفات لعرض رابط تنزيل للمستخدمين، فهل يمكن لأي شخص تقديم مزيد من التفاصيل حول المكان الذي تتوقع أن يواجه فيه Discourse مشاكل؟
مكون التحميل الحالي غير مصمم ببساطة للرفع الكبير (فقط نسخ احتياطية في واجهة إدارة النظام)
نحن نقوم حاليًا بتوحيد وإعادة هيكلة كود الرفع الخاص بنا، ونخطط لدعم الرفع المباشر إلى S3. بمجرد الانتهاء من ذلك، يمكن تقنيًا أن تعمل الرفع الكبيرة إلى S3.
شكرًا لك على هذه المعلومات، @sam. لم أكن أعرف سابقًا كيفية تخزين تحميلات الملفات. يبدو إذن أنه، افتراضيًا، تُخزَّن تحميلات الملفات على نفس الخادم الذي يشغّل Discourse، وفي هذه الحالة أفهم كيف قد تكون التحميلات الكبيرة مشكلة. كما أدرك كيف تعملون على دعم التحميلات المباشرة إلى S3 في المستقبل.
ماذا لو قمت الآن بإعداد النظام لإرسال تحميلات الملفات إلى S3، كما هو موصوف هنا؟
هل سيوفر ذلك نفس الميزة الآن التي تخططون لإطلاقها في المستقبل كميزة تلقائية، ويسمح لـ Discourse بدعم تحميلات (وتنزيلات) الملفات الكبيرة؟
نظام التحميلات الحالي لدينا يتبع المسار: المستخدم → خادم Discourse → S3.
أما النظام الجديد الذي سنطلقه خلال بضعة أسابيع، فسيتبع المسار: المستخدم → S3.
هل ستتمكن المواقع من الانتقال بسلاسة إلى نظام الرفع الجديد، بحيث تظل عمليات الرفع تحت النظام القديم تعمل، كما تعمل تلك تحت النظام الجديد أيضًا؟
أفترض ذلك، نظرًا لأن جميع الملفات ستُخزن على S3، لكنني أردت التأكد. شكرًا لك.
بما أن الملفات ستنتهي في نفس المكان، مع تجنب بعض المسارات الطويلة فقط، فإن التغيير سيكون شفافًا لكل من المستخدمين والمسؤولين.
للتوضيح: أتوقع أن المستخدمين لن يلاحظوا أي تغيير على الإطلاق، سوى أن (ربما؟) ملفاتهم ستُحمّل وتُنزّل بسرعة أكبر، وهذا سيمكن من رفع ملفات أكبر إذا رغب المسؤولون في ذلك. هل هذا صحيح تقريبًا؟
من المرجح أن تُحمّل الملفات بسرعة أكبر. أما التحميلات فستبقى كما هي (حيث أن الميزة ستؤثر فقط على التحميلات).
أفترض ذلك، لكن الأمر يعود لفريق ديسكورد لإصدار بيان رسمي بشأنه.