آپ کا WordPress اپلوڈز فولڈر اتنا بڑا کیوں ہے
آپ کا WordPress اپلوڈز فولڈر اس لیے بڑا ہے کیونکہ WordPress کبھی بھی ہر تصویر کی ایک ہی فائل محفوظ نہیں کرتا۔ ہر اپلوڈ اصل فائل کے ساتھ ری سائز شدہ کاپیوں کا ایک مقررہ سیٹ بنا دیتا ہے
شائع شدہ
آپ کا WordPress اپلوڈز فولڈر اس لیے بڑا ہے کیونکہ WordPress کبھی بھی ہر تصویر کی ایک ہی فائل محفوظ نہیں کرتا۔ ہر اپلوڈ اصل فائل کے ساتھ ری سائز شدہ کاپیوں کا ایک مقررہ سیٹ بنا دیتا ہے — عام کیمرہ سائز کی تصویر کے لیے سات کاپیاں، اس سے پہلے کہ کوئی theme یا plugin مزید کاپیاں شامل کرے۔ کچھ بھی خراب نہیں ہوا؛ آپ صرف وہ ضربِ عمل دیکھ رہے ہیں جو ہر ایک اپلوڈ پر ہوتا ہے۔ اس کا حل یہ ہے کہ ان سائزز کو بننے سے روک دیں جو آپ کبھی سرو نہیں کرتے، پھر ری جنریٹ کریں تاکہ پرانی کاپیاں ڈسک سے حذف ہو جائیں۔
حساب لگائیں
ایک 4000×3000 JPEG اپلوڈ کریں اور /wp-content/uploads/2026/07/ کے اندر دیکھیں۔ آپ کو ایک فائل نہیں ملے گی۔ آپ کو یہ ملیں گی:
photo.jpg— اصل، بغیر کسی تبدیلی کےphoto-scaled.jpg— 2560px کی ایک کاپی جو WordPress اصل کے بجائے سرو کرتا ہےphoto-150x150.jpg—thumbnailphoto-300x225.jpg—mediumphoto-768x576.jpg—medium_largephoto-1024x768.jpg—largephoto-1536x1152.jpg— 2× والاmedium_largephoto-2048x1536.jpg— 2× والاlarge
یعنی اصل کے علاوہ سات مشتق فائلیں، صرف core سے۔ ایک 3 MB کا اپلوڈ کسی بھی plugin کے چلنے سے پہلے ہی ڈسک پر 5–6 MB بن سکتا ہے۔ اب ایک ایسا theme شامل کریں جو اپنے چار سائز رجسٹر کرتا ہے اور WooCommerce (تین مزید)، اور ایک اپلوڈ چودہ یا پندرہ فائلوں میں بدل جاتا ہے۔ اسے چند ہزار تصویروں کی لائبریری سے ضرب دیں اور فولڈر کا حجم اب کوئی معمہ نہیں رہتا۔
اگر آپ اپنے اپنے ابعاد اور رجسٹرڈ سائزز کے لیے درست عدد چاہتے ہیں، تو image storage calculator آپ کے لیے یہ ضرب کر دیتا ہے۔
یہ کیوں ہوتا ہے
جب آپ اپلوڈ کرتے ہیں، تو wp_generate_attachment_metadata()، wp_create_image_subsizes() کو کال کرتا ہے، جو get_intermediate_image_sizes() سے واپس آنے والے ہر سائز پر لوپ کرتا ہے اور ہر اُس سائز کے لیے فائل لکھتا ہے جس کے لیے اصل تصویر کافی بڑی ہو۔ Core thumbnail، medium، medium_large، large کے علاوہ WP 5.3 میں شامل کیے گئے 1536x1536 اور 2048x2048 ریٹینا سائزز کو رجسٹر کرتا ہے۔ کوئی بھی theme یا plugin جو add_image_size() کال کرتا ہے وہ اسی لوپ میں مزید اضافہ کر دیتا ہے — مستقل طور پر، ہر آئندہ اپلوڈ کے لیے۔
-scaled فائل ایک الگ طریقہ کار سے آتی ہے: big_image_size_threshold filter، جس کی ڈیفالٹ 2560px ہے۔ اس سے چوڑی کوئی بھی چیز ایک اسکیلڈ کاپی حاصل کرتی ہے جو سرو کی جانے والی “full” تصویر بن جاتی ہے، جبکہ اصل ڈسک پر باقی رہتی ہے۔ یعنی ایک بڑا اپلوڈ دونوں رکھتا ہے — دیوہیکل اصل اور 2560px والا ورژن۔
آپ image sizes inspector کے ذریعے بالکل درست دیکھ سکتے ہیں کہ آپ کا سیٹ اپ کسی دی گئی تصویر کے لیے کیا کچھ بناتا ہے۔
اسے ترتیب سے کیسے ٹھیک کریں
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. ان سائزز کو ڈی رجسٹر کریں جو آپ سرو نہیں کرتے۔ زیادہ تر themes کبھی 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 plugin استعمال کر رہے ہیں، تو اس کا “delete unregistered sizes” آپشن ٹِک کریں — یہ باکس چیک کیے بغیر، پرانی فائلیں باقی رہتی ہیں۔
4. یتیم فائلوں کا شکار کریں۔ themes بدلنا کبھی بھی اُن سائزز کو صاف نہیں کرتا جو پرانے theme نے رجسٹر کیے تھے۔ پوسٹس حذف کرنا بھی ہمیشہ ان کی مشتق فائلوں کو نہیں ہٹاتا۔ مرحلہ 3 کے بعد، اگر du -sh اب بھی calculator کے پیش گوئی کردہ عدد سے کہیں زیادہ ہے، تو آپ کے پاس یتیم فائلیں ہیں — ڈسک پر ایسی فائلیں جن کا حوالہ کوئی attachment نہیں دیتا۔
کیا نہ کریں
“جگہ بچانے” کے لیے اسکیلڈ امیجز کو غیر فعال نہ کریں۔ -scaled فائل آپ کی اصل تصویر سے چھوٹی ہوتی ہے۔ big_image_size_threshold کو بند کرنا کچھ بھی حذف نہیں کرتا — یہ صرف WordPress کو مجبور کرتا ہے کہ ہر وزیٹر کو کئی میگابائٹ والی مکمل اصل تصویر سرو کرے۔ یہ ایک بینڈوڈتھ اور کوالٹی کا فیصلہ ہے، اسٹوریج کی صفائی نہیں، اور یہ عام طور پر صفحے کے وزن کو مزید بگاڑ دیتا ہے۔ disable-scaled-images tool بتاتا ہے کہ یہ اصل میں کب درست فیصلہ ہوتا ہے؛ آپ کے اپلوڈز فولڈر کو سکیڑنا ان میں سے ایک نہیں ہے۔
SFTP کے ذریعے سیدھا uploads سے فائلیں حذف نہ کریں۔ ہر attachment کی سب سائز فہرست اس کے _wp_attachment_metadata میں رہتی ہے۔ ہاتھ سے فائلیں حذف کرنا ٹوٹے ہوئے حوالے چھوڑ دیتا ہے، اور اگر آپ نے وہ اصل ہٹا دی جس سے کوئی سائز مشتق تھا تو ری جنریشن اسے دوبارہ نہیں بنا سکتی۔ اصل حذف کریں اور وہ تصویر ہمیشہ کے لیے ختم۔
Settings → Media میں thumbnail/medium/large کو 0 کر کے یہ توقع نہ کریں کہ فولڈر سکڑ جائے گا۔ کسی سائز کو صفر کرنا آئندہ بننے کو روکتا ہے مگر ڈسک پر موجود کسی چیز کو نہیں چھوتا، اور UI medium_large، 1536، 2048، یا کسی theme/plugin سائز تک نہیں پہنچ سکتا — وہ وہاں موجود ہی نہیں ہیں۔
ڈیٹا بیس کو الزام نہ دیں۔ بھاری uploads فولڈر تصویر کی فائلیں ہوتی ہیں، تقریباً کبھی DB نہیں۔ ٹیبلز کو optimize کرنا اس عدد کو نہیں ہلائے گا۔
اب بھی پھنسے ہوئے ہیں؟
اگر ری جنریٹ کرنے کے بعد بھی فولڈر توقع سے بڑا ہے، تو اپنے حقیقی تصویری ابعاد اور رجسٹرڈ سائزز کو storage calculator میں سے گزاریں اور اس کے عدد کا du -sh wp-content/uploads سے موازنہ کریں۔ بڑا فرق مطلب پرانے theme یا حذف شدہ پوسٹس کی یتیم فائلیں — نہ کہ core، اور نہ ہی کوئی ایسی چیز جسے مزید ری جنریٹ کرنا ٹھیک کر دے گا۔ چھوٹا فرق مطلب حساب بس ویسا ہی ہے جیسا کہ ہے: فی اپلوڈ سات سے زیادہ فائلیں، جو بالکل ویسے کام کر رہی ہیں جیسے انہیں ڈیزائن کیا گیا ہے۔