چرا پوشه uploads وردپرس شما اینقدر بزرگ است
پوشه uploads وردپرس شما به این دلیل بزرگ است که وردپرس هرگز به ازای هر تصویر فقط یک فایل ذخیره نمیکند. هر آپلود مجموعهای ثابت از کپیهای تغییر اندازهدادهشده را در کنار فایل اصلی میسازد.
منتشرشده
پوشه uploads وردپرس شما به این دلیل بزرگ است که وردپرس هرگز به ازای هر تصویر فقط یک فایل ذخیره نمیکند. هر آپلود مجموعهای ثابت از کپیهای تغییر اندازهدادهشده را در کنار فایل اصلی میسازد — برای یک عکس با ابعاد معمول دوربین، هفت نسخه، آن هم پیش از آنکه هیچ قالب یا افزونهای نسخههای بیشتری اضافه کند. هیچ چیز خراب نشده است؛ شما فقط دارید همان تکثیری را میبینید که در تکتک آپلودها اتفاق میافتد. راهحل این است که تولید سایزهایی را که هرگز سرو نمیکنید متوقف کنید و سپس تصاویر را دوباره تولید (regenerate) کنید تا کپیهای قدیمی از روی دیسک حذف شوند.
حساب و کتاب را انجام دهید
یک تصویر 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— نسخه 2× ازmedium_largephoto-2048x1536.jpg— نسخه 2× ازlarge
یعنی فایل اصلی بهعلاوه هفت نسخه مشتق، آن هم فقط از هسته وردپرس. یک آپلود 3 مگابایتی میتواند پیش از آنکه حتی یک افزونه اجرا شود، روی دیسک به 5 تا 6 مگابایت تبدیل شود. حالا یک قالب را اضافه کنید که چهار سایز مخصوص خودش را ثبت میکند و ووکامرس (سه سایز دیگر) را هم اضافه کنید، آنگاه یک آپلود به چهارده یا پانزده فایل تبدیل میشود. این را در یک کتابخانه چند هزار تصویری ضرب کنید و آنگاه دیگر بزرگ بودن حجم پوشه معما نخواهد بود.
اگر عدد دقیق را برای ابعاد و سایزهای ثبتشده خودتان میخواهید، ماشینحساب فضای ذخیرهسازی تصاویر این ضرب و تقسیم را برایتان انجام میدهد.
چرا این اتفاق میافتد
وقتی آپلود میکنید، 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 پیکسل است. هر تصویری که پهنتر از این باشد یک کپی scaled دریافت میکند که همان تصویر «full» سروشده میشود، در حالی که فایل اصلی روی دیسک باقی میماند. بنابراین یک آپلود بزرگ هم فایل اصلی غولپیکر و هم نسخه 2560 پیکسلی را نگه میدارد.
میتوانید دقیقاً ببینید که سیستم شما برای یک تصویر مشخص چه چیزی تولید میکند با ابزار بازرسی سایزهای تصویر.
چطور آن را رفع کنیم، به ترتیب
۱. قبل از دست زدن به هر چیزی، اندازهگیری کنید. حدس زدن وقتتان را تلف میکند. از ریشه سایت:
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۲. سایزهایی را که سرو نمیکنید از ثبت خارج کنید. بیشتر قالبها هرگز سایزهای 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;
} );۳. برای حذف کپیهای قدیمی، تصاویر را دوباره تولید کنید. خارج کردن از ثبت فقط تولید آینده را متوقف میکند — فایلهایی که همین حالا روی دیسک هستند تا زمانی که regenerate نکنید باقی میمانند:
wp media regenerate --yesنسخههای اخیر WP-CLI هنگام اجرا، فایلهای مربوط به سایزهایی را که دیگر ثبت نشدهاند حذف میکنند. اگر بهجای آن از افزونه Regenerate Thumbnails استفاده میکنید، گزینه «delete unregistered sizes» آن را تیک بزنید — بدون تیک زدن این گزینه، فایلهای قدیمی باقی میمانند.
۴. به دنبال فایلهای یتیم (orphaned) بگردید. تعویض قالب هرگز سایزهایی را که قالب قبلی ثبت کرده بود پاک نمیکند. حذف نوشتهها هم همیشه نسخههای مشتق آنها را حذف نمیکند. بعد از مرحله ۳، اگر du -sh هنوز خیلی بالاتر از عددی است که ماشینحساب پیشبینی میکند، فایلهای یتیم دارید — فایلهایی روی دیسک که هیچ پیوستی (attachment) به آنها ارجاع نمیدهد.
چه کارهایی نکنید
برای «صرفهجویی در فضا» تصاویر scaled را غیرفعال نکنید. فایل -scaled کوچکتر از فایل اصلی شماست. خاموش کردن big_image_size_threshold چیزی را حذف نمیکند — فقط باعث میشود وردپرس فایل اصلی چند مگابایتی را برای هر بازدیدکننده سرو کند. این یک تصمیم مربوط به پهنای باند و کیفیت است، نه پاکسازی فضای ذخیرهسازی، و معمولاً حجم صفحه را بدتر میکند. ابزار غیرفعال کردن تصاویر scaled توضیح میدهد که چه زمانی این کار واقعاً درست است؛ کوچک کردن پوشه uploads یکی از آن موارد نیست.
فایلها را مستقیماً از پوشه uploads از طریق SFTP حذف نکنید. فهرست زیرسایزهای هر پیوست در _wp_attachment_metadata آن نگهداری میشود. حذف دستی فایلها ارجاعهای شکسته باقی میگذارد و اگر فایل اصلی که یک سایز از آن مشتق شده را حذف کرده باشید، regenerate نمیتواند آن سایز را بازسازی کند. فایل اصلی را حذف کنید و آن تصویر برای همیشه از بین رفته است.
در تنظیمات → رسانه سایز thumbnail/medium/large را روی 0 نگذارید به این امید که پوشه کوچک شود. صفر کردن یک سایز فقط تولید آینده را متوقف میکند اما به هیچ چیزی که همین حالا روی دیسک است دست نمیزند، و این رابط کاربری به medium_large، 1536، 2048 یا هیچ سایز قالب/افزونهای دسترسی ندارد — آنها اصلاً آنجا نیستند.
دیتابیس را مقصر ندانید. یک پوشه uploads سنگین یعنی فایلهای تصویری، و تقریباً هرگز دیتابیس نیست. بهینهسازی جداول این عدد را تکان نمیدهد.
هنوز گیر کردهاید؟
اگر بعد از regenerate کردن پوشه هنوز بزرگتر از حد انتظار است، ابعاد واقعی تصاویر و سایزهای ثبتشده خود را در ماشینحساب فضای ذخیرهسازی وارد کنید و عدد آن را با du -sh wp-content/uploads مقایسه کنید. یک اختلاف بزرگ یعنی فایلهای یتیم از یک قالب قدیمی یا نوشتههای حذفشده — نه هسته وردپرس، و نه چیزی که regenerate کردن بیشتر آن را رفع کند. یک اختلاف کوچک یعنی محاسبات دقیقاً همین است که هست: هفت فایل یا بیشتر به ازای هر آپلود، که دقیقاً همانطور که طراحی شده کار میکند.