لماذا يكون حجم مجلد uploads في ووردبريس كبيراً إلى هذا الحد
يكبر حجم مجلد uploads في ووردبريس لأن ووردبريس لا يخزّن أبداً ملفاً واحداً لكل صورة. كل عملية رفع تولّد مجموعة ثابتة من النسخ المُعاد تحجيمها إلى جانب
نُشر
يكبر حجم مجلد uploads في ووردبريس لأن ووردبريس لا يخزّن أبداً ملفاً واحداً لكل صورة. كل عملية رفع تولّد مجموعة ثابتة من النسخ المُعاد تحجيمها إلى جانب الأصل — سبع نسخ لصورة بحجم كاميرا اعتيادي، قبل أن يضيف أي قالب أو إضافة المزيد. لا شيء تالف؛ أنت ببساطة ترى المضاعفة التي تحدث مع كل عملية رفع. الحل هو التوقف عن توليد المقاسات التي لا تعرضها أصلاً، ثم إعادة التوليد كي تُحذف النسخ القديمة من القرص.
احسبها بنفسك
ارفع صورة JPEG واحدة بمقاس 4000×3000 وانظر داخل /wp-content/uploads/2026/07/. لن تجد ملفاً واحداً. ستجد هذه الملفات:
photo.jpg— الأصل، دون أي تعديلphoto-scaled.jpg— نسخة بعرض 2560 بكسل يعرضها ووردبريس بدلاً من الأصلphoto-150x150.jpg—thumbnailphoto-300x225.jpg—mediumphoto-768x576.jpg—medium_largephoto-1024x768.jpg—largephoto-1536x1152.jpg— نسخةmedium_largeبمقياس 2×photo-2048x1536.jpg— نسخةlargeبمقياس 2×
هذا هو الأصل زائد سبع نسخ مشتقة، من النواة وحدها. صورة بحجم 3 ميغابايت قد تنتهي على القرص بحجم 5–6 ميغابايت قبل أن تعمل أي إضافة واحدة. أضف الآن قالباً يسجّل أربعة مقاسات خاصة به وWooCommerce (ثلاثة مقاسات إضافية)، وتتحول عملية رفع واحدة إلى أربعة عشر أو خمسة عشر ملفاً. اضرب ذلك في مكتبة تضم بضعة آلاف من الصور، ويتوقف حجم المجلد عن كونه لغزاً.
إذا أردت الرقم الدقيق لأبعادك ومقاساتك المسجّلة أنت، فإن حاسبة تخزين الصور تقوم بعملية الضرب نيابةً عنك.
لماذا يحدث ذلك
عند الرفع، تستدعي wp_generate_attachment_metadata() الدالة wp_create_image_subsizes()، التي تمرّ على كل مقاس تُرجعه get_intermediate_image_sizes() وتكتب ملفاً لكل مقاس يكون الأصل كبيراً بما يكفي لإنتاجه. تسجّل النواة thumbnail وmedium وmedium_large وlarge، إضافةً إلى مقاسي الشبكية 1536x1536 و2048x2048 اللذين أُضيفا في ووردبريس 5.3. أي قالب أو إضافة يستدعي add_image_size() يضيف إلى الحلقة نفسها — بشكل دائم، ولكل عملية رفع مستقبلية.
الملف -scaled يأتي من آلية منفصلة: مرشّح big_image_size_threshold، وقيمته الافتراضية 2560 بكسل. أي صورة أعرض من ذلك تحصل على نسخة مُصغّرة تصبح هي الصورة “الكاملة” المعروضة، بينما يبقى الأصل على القرص. لذا فإن صورة كبيرة تحتفظ بـكلا الأصل الضخم ونسخة 2560 بكسل.
يمكنك أن ترى بالضبط ما يولّده إعدادك لصورة معيّنة عبر أداة فحص مقاسات الصور.
كيفية حل المشكلة، بالترتيب
1. قِس قبل أن تلمس أي شيء. التخمين يضيّع الوقت. من جذر الموقع:
du -sh wp-content/uploads
find wp-content/uploads -type f \( -name '*.jpg' -o -name '*.webp' -o -name '*.png' \) | wc -l
du -ah wp-content/uploads | sort -rh | head -20
2. ألغِ تسجيل المقاسات التي لا تعرضها. معظم القوالب لا تُخرج أبداً مقاسي 1536 و2048، وكثير منها لا يستخدم medium_large إطلاقاً. تخلّص منها:
// functions.php — stop generating sizes this site never outputs
add_action( 'init', function () {
remove_image_size( '1536x1536' );
remove_image_size( '2048x2048' );
} );
// Drop medium_large too, if your theme doesn't use the 768px size
add_filter( 'intermediate_image_sizes_advanced', function ( $sizes ) {
unset( $sizes['medium_large'] );
return $sizes;
} );
3. أعد التوليد لحذف النسخ القديمة. إلغاء التسجيل يوقف التوليد المستقبلي فقط — الملفات الموجودة على القرص تبقى إلى أن تعيد التوليد:
wp media regenerate --yes
إصدارات WP-CLI الحديثة تحذف ملفات المقاسات التي لم تعد مسجّلة أثناء عملها. أما إذا كنت تستخدم إضافة Regenerate Thumbnails بدلاً من ذلك، فعلّم على خيار “delete unregistered sizes” — بدون تفعيل هذا المربع، تبقى الملفات القديمة.
4. طارِد الملفات اليتيمة. تبديل القوالب لا ينظّف أبداً المقاسات التي سجّلها القالب القديم. وحذف المقالات لا يزيل دائماً نسخها المشتقة كذلك. بعد الخطوة 3، إذا كان du -sh لا يزال أعلى بكثير مما تتوقعه الحاسبة، فلديك ملفات يتيمة — ملفات على القرص لا يشير إليها أي مرفق.
ما لا ينبغي فعله
لا تعطّل الصور المُصغّرة (scaled) بحجة “توفير المساحة”. الملف -scaled أصغر من الأصل. إيقاف big_image_size_threshold لا يحذف شيئاً — بل يجعل ووردبريس يعرض الأصل الكامل بحجمه الذي يبلغ عدة ميغابايتات لكل زائر. هذا قرار يتعلق بعرض النطاق والجودة، لا بتنظيف التخزين، وعادةً ما يجعل وزن الصفحة أسوأ. تشرح أداة تعطيل الصور المُصغّرة متى يكون ذلك فعلاً القرار الصحيح؛ وتقليص حجم مجلد uploads ليس أحد تلك الحالات.
لا تحذف الملفات مباشرةً من uploads عبر SFTP. قائمة المقاسات الفرعية لكل مرفق موجودة في _wp_attachment_metadata الخاص به. حذف الملفات يدوياً يترك مراجع مكسورة، وإعادة التوليد لا يمكنها إعادة بناء مقاس إذا كنت قد حذفت الأصل المشتق منه. احذف الأصل، وتلك الصورة ضاعت إلى الأبد.
لا تضبط thumbnail/medium/large على 0 في إعدادات → الوسائط متوقعاً أن يتقلّص المجلد. تصفير مقاس يوقف التوليد المستقبلي لكنه لا يمسّ أي شيء موجود على القرص، والواجهة لا تستطيع الوصول إلى medium_large أو 1536 أو 2048 أو أي مقاس تابع لقالب أو إضافة — تلك ليست موجودة هناك أصلاً.
لا تلُم قاعدة البيانات. مجلد uploads الثقيل هو ملفات صور، ولا يكون قاعدة البيانات إطلاقاً تقريباً. تحسين الجداول لن يحرّك الرقم.
لا تزال عالقاً؟
إذا بقي المجلد أكبر من المتوقع بعد إعادة التوليد، مرّر أبعاد صورك الحقيقية ومقاساتك المسجّلة عبر حاسبة التخزين وقارن رقمها بـdu -sh wp-content/uploads. الفجوة الكبيرة تعني ملفات يتيمة من قالب قديم أو مقالات محذوفة — لا من النواة، ولا شيء يحلّه مزيد من إعادة التوليد. أما الفجوة الصغيرة فتعني أن الحساب هو ببساطة ما هو عليه: سبعة ملفات أو أكثر لكل عملية رفع، تعمل تماماً كما صُمّمت.