مواد پر جائیں
امیجز اور میڈیا

آپ کا WordPress اپلوڈز فولڈر اتنا بڑا کیوں ہے

آپ کا WordPress اپلوڈز فولڈر اس لیے بڑا ہے کیونکہ WordPress کبھی بھی ہر تصویر کی ایک ہی فائل محفوظ نہیں کرتا۔ ہر اپلوڈ اصل فائل کے ساتھ ری سائز شدہ کاپیوں کا ایک مقررہ سیٹ بنا دیتا ہے

شائع شدہ

آپ کا WordPress اپلوڈز فولڈر اس لیے بڑا ہے کیونکہ WordPress کبھی بھی ہر تصویر کی ایک ہی فائل محفوظ نہیں کرتا۔ ہر اپلوڈ اصل فائل کے ساتھ ری سائز شدہ کاپیوں کا ایک مقررہ سیٹ بنا دیتا ہے — عام کیمرہ سائز کی تصویر کے لیے سات کاپیاں، اس سے پہلے کہ کوئی theme یا plugin مزید کاپیاں شامل کرے۔ کچھ بھی خراب نہیں ہوا؛ آپ صرف وہ ضربِ عمل دیکھ رہے ہیں جو ہر ایک اپلوڈ پر ہوتا ہے۔ اس کا حل یہ ہے کہ ان سائزز کو بننے سے روک دیں جو آپ کبھی سرو نہیں کرتے، پھر ری جنریٹ کریں تاکہ پرانی کاپیاں ڈسک سے حذف ہو جائیں۔

حساب لگائیں

ایک 4000×3000 JPEG اپلوڈ کریں اور /wp-content/uploads/2026/07/ کے اندر دیکھیں۔ آپ کو ایک فائل نہیں ملے گی۔ آپ کو یہ ملیں گی:

  • photo.jpg — اصل، بغیر کسی تبدیلی کے
  • photo-scaled.jpg — 2560px کی ایک کاپی جو WordPress اصل کے بجائے سرو کرتا ہے
  • photo-150x150.jpgthumbnail
  • photo-300x225.jpgmedium
  • photo-768x576.jpgmedium_large
  • photo-1024x768.jpglarge
  • photo-1536x1152.jpg — 2× والا medium_large
  • photo-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، اور نہ ہی کوئی ایسی چیز جسے مزید ری جنریٹ کرنا ٹھیک کر دے گا۔ چھوٹا فرق مطلب حساب بس ویسا ہی ہے جیسا کہ ہے: فی اپلوڈ سات سے زیادہ فائلیں، جو بالکل ویسے کام کر رہی ہیں جیسے انہیں ڈیزائن کیا گیا ہے۔

FAQ

سوالات

WordPress ہر اپلوڈ کی گئی تصویر کی اتنی کاپیاں کیوں بناتا ہے؟

WordPress ہر اپلوڈ پر ری سائز شدہ کاپیوں کا ایک مقررہ سیٹ بناتا ہے۔ ایک 4000x3000 JPEG اصل فائل کے علاوہ صرف core سے سات فائلوں کی صورت میں ڈسک پر آتی ہے: -scaled، thumbnail، medium، medium_large، large، اور دو ریٹینا سائز۔ اس میں ایک theme اور WooCommerce شامل کر دیں تو ایک اپلوڈ چودہ یا پندرہ فائلوں میں بدل جاتا ہے۔

WordPress میں میری تصویر کا -scaled ورژن کیا ہوتا ہے؟

-scaled فائل 2560px کی وہ کاپی ہے جو WordPress آپ کے اصل کے بجائے پیش کرتا ہے، اور یہ big_image_size_threshold filter کے ذریعے تب بنتی ہے جب کوئی اپلوڈ اس سے چوڑی ہو۔ آپ کا بغیر چھیڑا ہوا اصل بھی ڈسک پر رہتا ہے، اس لیے ایک بڑی اپلوڈ دونوں فائلیں رکھتی ہے۔

WordPress کو ایسے image sizes بنانے سے کیسے روکوں جو میں کبھی استعمال نہیں کرتا؟

انہیں functions.php میں ڈی رجسٹر کریں: 1536x1536 اور 2048x2048 کے لیے remove_image_size استعمال کریں، اور medium_large کو intermediate_image_sizes_advanced filter سے unset کریں۔ یہ صرف آئندہ اپلوڈز روکتا ہے، اس لیے بعد میں wp media regenerate --yes چلائیں تاکہ ڈسک پر پہلے سے موجود کاپیاں حذف ہو جائیں۔

کیا جگہ خالی کرنے کے لیے wp-content/uploads سے فائلیں FTP کے ذریعے حذف کر سکتا ہوں؟

نہیں۔ ہر attachment کی سب سائز فہرست اس کے _wp_attachment_metadata میں رہتی ہے، اس لیے ہاتھ سے فائلیں حذف کرنے پر ٹوٹے ہوئے حوالے پیچھے رہ جاتے ہیں۔ ری جنریشن کوئی سائز دوبارہ نہیں بنا سکتی جب آپ وہ اصل ہٹا چکے ہوں جس سے وہ اخذ ہوتی ہے، اور اصل حذف کرنے کا مطلب ہے وہ تصویر ہمیشہ کے لیے ضائع۔

کیا Settings → Media میں image sizes کو 0 کر دینے سے اپلوڈز فولڈر چھوٹا ہو جاتا ہے؟

نہیں۔ thumbnail، medium یا large کو صفر کرنا آئندہ جنریشن روک دیتا ہے مگر ڈسک پر پہلے سے موجود کسی چیز کو نہیں چھوتا۔ Settings → Media اسکرین medium_large، 1536، 2048، یا کسی theme یا plugin کے رجسٹر کردہ سائز تک پہنچ بھی نہیں سکتی، اس لیے زیادہ تر فائلیں بالکل وہیں رہتی ہیں۔