الروابط الأساسية قد حُذفت منذ فترة طويلة - ألا ينبغي أن يعني ذلك توقف ظهور ملفات .gif هذه؟ عند النقر على “عرض الصورة” من قائمة السياق، يتم نقلي إلى عنوان community.signalusers، هل هذا السلوك متوقع؟
أقوم باختبار، وسأقوم بتعديل هذا النص خلال حوالي 300 ثانية ثم أحذف الرابط بعد ذلك بوقت قصير.
deleted.png
تعديل #2
الرابط محذوف لكن الصورة لا تزال موجودة في سجل التعديلات، ربما لا تحتوي على سجل Upload لأنها لم تُحذف بواسطة التنظيف التلقائي.
يبدو أن تنظيف التحميلات إعداد عام سيستهدف جميع الصور التي تحتوي على سجل upload، أليس كذلك؟ وليس فقط تلك الموجودة بسبب download_remote_images_to_local. إذا كان الأمر كذلك، فيجب أن أتمكن من العثور على أمثلة على الموقع لصور تم تحميلها بشكل عادي ولم يتم إزالتها نتيجة التنظيف التلقائي.
هل تمانع لو سألت عن المدة المحددة في إعداد clean orphan uploads grace period hours هنا حتى أقدمها كحل؟ أم أن له قيمة افتراضية؟
إذا قرروا تفعيل هذا الإعداد، فهل سيتعين عليهم القيام بأي شيء لتطبيقه على المنشورات السابقة؟
تعديل
فقط من أجل الوضوح التام، الفكرة هنا هي أن هذه ليست مشكلة، بل إن إعدادًا يحتاج إلى تفعيل. لا أريد فقط أن أعود وأقول: “يجب عليك تفعيل هذا!” فيجيبون: “هو مفعّل بالفعل!” وسأبدو في موقف محرج.
لقد أمسكتُ بنفسي أيضًا أبحث بعنف عن مكان لاستعراض التحميلات (أنا معتاد عليه من MediaWiki) لأنني أعرف تمامًا أن الملفات تُحمَّل مرتين أو ثلاثًا أو حتى أربع مرات، وأحيانًا أتساءل أين الملف الذي قمتُ بتحميله منذ فترة، ربما فقد أو حُذف، لأتمكن من ربطه بدلاً من إعادة تحميله مرة أخرى… أعتقد أن هناك ما يُقال بشأن متصفح الملفات…
كان عليّ أيضًا حذف ملف تم تحميله بطريقة ما. لا يوجد لدينا مهمة التنظيف مفعلة لأن بعض الملفات تأتي من استيراد من برنامج منتديات مختلف ولم تتم الإشارة إليها بعد في المشاركات المستوردة بشكل صحيح. لذلك، احتجت إلى إيجاد طريقة يدوية. ما يلي يعمل ولكنه ليس أنيقًا …
تأكد من أن التحميل المعني لم يعد موجودًا في الإصدار الحالي لأي مشاركة. بهذه الطريقة، ستعتبره Discourse يتيمًا ولن تسبب مشاكل عند حذفه.
استخدم إضافة مستكشف البيانات (Data Explorer plugin) أو طريقة أخرى للاستعلام عن قاعدة بيانات Discourse لسرد التحميلات اليتيمة، والعثور على التحميل المعني، وتدوين upload_id واسم الملف الخاص به. الاستعلام ذو الصلة:
SELECT
uploads.id, uploads.user_id, uploads.created_at,
uploads.url, uploads.filesize
FROM uploads
LEFT OUTER JOIN post_uploads ON uploads.id = post_uploads.upload_id
WHERE post_uploads.post_id IS NULL
ORDER BY created_at DESC
LIMIT 100
في قاعدة البيانات أو باستخدام وحدة تحكم Rails لـ Discourse، احذف السجل المعني من جدول uploads بواسطة معرف التحميل الخاص به. هنا أستخدم وحدة تحكم Rails:
Upload.where(id: 16384).first.delete
احذف الملف المرتبط بما في ذلك جميع الإصدارات المحسّنة (إن وجدت، ينطبق على الصور) من نظام الملفات عبر SSH. لاحظ العلامة النجمية المضافة قبل امتداد الملف لالتقاط الإصدارات المحسّنة أيضًا، والتي لها لاحقة هنا. بالطبع،
cd /path/to/discourse/shared/public/
find . -name 43adade7a4cc64426adb8232a56cb2c3b49fb7c9*.pdf -type f -delete
هاه! يبدو أن الصورة المشار إليها في هذا المنشور لم يتم التقاطها بواسطة هذه الإعدادات:
لماذا لم يتم حذفها؟
هل يمكنني أيضًا أن أتساءل لماذا يقوم Discourse “بتحميل” ملف مرتبط مثل رابط Dropbox هنا؟ النقطة من ربط ملف معين ستكون غالبًا في الاحتفاظ بالتحكم في المحتوى.
مع تغيير إعادة تسمية post_uploads إلى upload_references، لم يعد استعلام SQL المذكور في الخطوة 2 صالحًا. الكود المحدث هو:
SELECT
uploads.id, uploads.user_id, uploads.created_at,
uploads.url, uploads.filesize
FROM uploads
LEFT OUTER JOIN upload_references ON uploads.id = upload_references.upload_id
WHERE upload_references.target_id IS NULL
ORDER BY created_at DESC
LIMIT 100