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

اپ لوڈ کے بعد WordPress کی تصاویر دھندلی کیوں نظر آتی ہیں (اور اس کا حل)

دس میں سے نو بار آپ کی تصاویر دراصل دھندلی ہوتی ہی نہیں — WordPress نے انہیں اپ لوڈ کے وقت چھوٹا کر دیا اور اب وہی محدود کاپی پیش کر رہا ہے۔ WordPress 5.3 کے بعد سے کوئی بھی

شائع شدہ

دس میں سے نو بار آپ کی تصاویر دراصل دھندلی ہوتی ہی نہیں — WordPress نے انہیں اپ لوڈ کے وقت چھوٹا کر دیا اور اب وہی محدود کاپی پیش کر رہا ہے۔ WordPress 5.3 کے بعد سے، جو بھی تصویر 2560px سے زیادہ چوڑی یا لمبی ہو اسے خاموشی سے ایک -scaled ورژن سے بدل دیا جاتا ہے جس کا سب سے لمبا کنارہ زیادہ سے زیادہ 2560px تک محدود ہوتا ہے، اور یہی چھوٹی فائل آپ کی theme کسی hero، فل-وِڈتھ بلاک، یا retina ڈسپلے کو بھرنے کے لیے کھینچ کر بڑا کرتی ہے۔ اس کا حل یہ ہے کہ پہلے ثابت کریں کہ ہوا کیا ہے، پھر یا تو حد بڑھا دیں یا ایسی تصاویر اپ لوڈ کرنا بند کر دیں جنہیں اپنے باکس سے بڑا ہونے کی ضرورت ہو۔

یہ کیوں ہوتا ہے

جب آپ کوئی تصویر اپ لوڈ کرتے ہیں تو WordPress wp_create_image_subsizes() چلاتا ہے (جو wp-admin/includes/image.php میں ہے)۔ اگر سب سے لمبا کنارہ big_image_size_threshold سے زیادہ ہو — جو بطورِ ڈیفالٹ 2560px ہے — تو یہ _wp_image_meta_replace_original() کو کال کرتا ہے، your-photo-scaled.jpg بناتا ہے، اور attachment میٹا ڈیٹا کو دوبارہ لکھ دیتا ہے تاکہ اب full سائز اس scaled کاپی کی طرف اشارہ کرے۔ آپ کا اصل original ڈسک پر your-photo.jpg کے طور پر محفوظ رہتا ہے اور wp_get_original_image_path() اس کی طرف اشارہ کرتا ہے، لیکن فرنٹ اینڈ پر کوئی چیز اسے پیش نہیں کرتی۔ ہر انٹرمیڈیٹ سائز اور ہر srcset امیدوار 2560px والی scaled فائل سے بنتا ہے، نہ کہ اُس چیز سے جو آپ نے اپ لوڈ کی تھی۔

تو دھندلاہٹ یہاں سے آتی ہے۔ آپ فل-بلیڈ ہیڈر کے لیے ایک شاندار 4000px تصویر اپ لوڈ کرتے ہیں۔ WordPress اسے 2560px پر محدود کر دیتا ہے۔ ایک عام ڈسپلے پر 1600px چوڑے کنٹینر میں یہ ٹھیک ہے۔ لیکن 2x retina سکرین پر براؤزر کو اُس کنٹینر کو تیزی سے بھرنے کے لیے تقریباً 3200 حقیقی پکسلز درکار ہوتے ہیں، اُس کے پاس صرف 2560 ہیں، اور وہ فرق کو اپ اسکیل کرتا ہے۔ نرم کنارے، مبہم تصویر-میں-متن، بالکل وہی “اپ لوڈ کے بعد دھندلا” والی علامت۔

اسی مسئلے کا دوسرا نصف حصہ یہ ہے کہ srcset ایسا سائز چن لیتا ہے جو بہت چھوٹا ہو۔ اگر آپ کی theme ایسی content width بتائے جو دراصل رینڈر ہونے والے باکس سے میل نہ کھائے، تو WordPress براؤزر کو ایک -1024x683 یا -1536x1024 انٹرمیڈیٹ تھما دیتا ہے اور وہ کھینچ کر بڑا ہو جاتا ہے۔ وجہ وہی — ڈسپلے باکس دستیاب پکسلز سے بڑا — بس محرک مختلف ہے۔

دیکھیں کہ WordPress نے دراصل کیا پیش کیا

اندازہ مت لگائیں۔ دھندلی تصویر پر رائٹ-کلک کریں، اسے نئے ٹیب میں کھولیں، اور URL میں فائل کا نام دیکھیں۔ اگر یہ -scaled.jpg پر ختم ہوتا ہے یا -1024x683.jpg جیسے ڈائمینشن سفکس پر، تو آپ نے تصدیق کر لی: براؤزر آپ کے اپ لوڈ کے بجائے ایک چھوٹی کی گئی ڈیریویٹو رینڈر کر رہا ہے۔ آپ عنصر کا معائنہ بھی کر سکتے ہیں اور currentSrc پڑھ سکتے ہیں تاکہ یہ دیکھیں کہ براؤزر نے دراصل کون سا امیدوار چنا۔

کچھ بھی دوبارہ اپ لوڈ کرنے سے پہلے پوری تصویر دیکھنے کے لیے، تصویر کو WordPress image sizes tool میں ڈالیں — یہ ہر وہ ڈیریویٹو دکھاتا ہے جو WordPress اُسی فائل سے بنائے گا، بشمول اس کے کہ آیا کوئی -scaled کاپی بنتی ہے اور کن ڈائمینشنز پر، تاکہ آپ کو پہلے ہی معلوم ہو جائے کہ آپ کا سورس اُس جگہ کے لیے کافی بڑا ہے یا نہیں جہاں آپ اسے رکھ رہے ہیں۔

سرور پر آپ ہر محدود کی گئی فائل کی فہرست بنا سکتے ہیں:

find wp-content/uploads -name '*-scaled.*'

اسے کیسے ٹھیک کریں، ترتیب وار

1. اگر آپ کی تصاویر کو واقعی 2560px سے بڑا ہونے کی ضرورت ہے (بڑے heroes، retina، پرنٹ-کوالٹی گیلریاں)، تو حد بڑھا دیں:

// functions.php or a small mu-plugin
add_filter( 'big_image_size_threshold', function () {
    return 3840; // longest edge, in pixels
} );

یا حد کو مکمل طور پر بند کر دیں:

add_filter( 'big_image_size_threshold', '__return_false' );

2. متاثرہ تصاویر دوبارہ اپ لوڈ کریں۔ یہ وہ قدم ہے جسے لوگ چھوڑ دیتے ہیں۔ حد بدلنے سے صرف نئے اپ لوڈز پر اثر پڑتا ہے۔ آپ کی لائبریری میں پہلے سے موجود تصاویر اپنا پرانا میٹا ڈیٹا برقرار رکھتی ہیں، اور thumbnails دوبارہ بنانا انٹرمیڈیٹ سائزوں کو محدود کی گئی -scaled فائل سے دوبارہ تعمیر کرتا ہے — یہ وہ ریزولوشن واپس نہیں لاتا جو ضائع کر دی گئی تھی۔ قابلِ اعتماد راستہ یہ ہے: فلٹر بدلیں، attachment حذف کریں، دوبارہ اپ لوڈ کریں۔

3. اگر آپ کا سورس پہلے ہی ≤2560px ہے اور پھر بھی دھندلا ہے، تو مسئلہ حد کا نہیں — ڈسپلے باکس تصویر سے بڑا ہے۔ کوئی بڑا سورس اپ لوڈ کریں، یا کنٹینر چھوٹا کریں۔ retina تیزی کے لیے آپ کے سورس کو اُس باکس کی CSS پکسل چوڑائی سے تقریباً دوگنا ہونا چاہیے جسے وہ بھرتا ہے۔

4. صرف اوپر والے کاموں کے بعد thumbnails دوبارہ بنائیں تاکہ انٹرمیڈیٹ سائز ہم آہنگ ہوں — لیکن سمجھ لیں کہ یہ صفائی ہے، علاج نہیں۔

کیا نہیں کرنا چاہیے

JPEG کوالٹی کو 100 تک مت بڑھائیں۔ WordPress wp_editor_set_quality کے ذریعے بطورِ ڈیفالٹ 82 کوالٹی پر کمپریس کرتا ہے، اور آن لائن آدھی مشورے آپ کو اسے اوور رائیڈ کرنے کو کہتے ہیں:

add_filter( 'wp_editor_set_quality', function () { return 90; } );

کمپریشن آرٹیفیکٹس کم کرنے کے لیے یہ ٹھیک ہے، لیکن ایک کھینچی ہوئی، اپ اسکیل کی گئی تصویر ایک ریزولوشن کا مسئلہ ہے، کمپریشن کا نہیں۔ 82 سے 100 پر جانا آپ کی فائلوں کو پھلا دیتا ہے اور جو نرمی آپ دیکھ رہے ہیں اُس کے لیے تقریباً کچھ نہیں کرتا۔

-scaled کو ردِعمل میں غیر فعال مت کریں۔ حد بند کرنا (اس کے لیے ایک ٹول موجود ہے) صحیح فیصلہ ہے اگر آپ 2560px سے اوپر کی تصاویر پیش کرتے ہیں — لیکن اگر آپ کا اصل مسئلہ ایک بہت چھوٹے انٹرمیڈیٹ کا کھینچا جانا ہے، تو اسے غیر فعال کرنے سے کچھ نہیں بدلتا اور آپ بلاوجہ بینڈوِڈتھ کی بچت کھو دیتے ہیں۔ پہلے تشخیص کریں۔

کیش کو مورد الزام مت ٹھہرائیں یا پہلے thumbnails دوبارہ مت بنائیں۔ دوبارہ بنانا اُسی محدود سورس سے پڑھتا ہے، لہٰذا یہ تفصیل بحال نہیں کر سکتا۔ کسی CDN یا پیج کیش کو صاف کرنا اُس فائل کو نہیں چھوئے گا جو ڈسک پر شروع سے ہی چھوٹی تھی۔

theme کی CSS یا object-fit کی طرف مت جائیں۔ کوئی بھی اسٹائلنگ پکسلز کا اضافہ نہیں کرتی۔ اگر پیش کی گئی فائل -scaled یا کسی ڈائمینشن سفکس پر ختم ہوتی ہے، تو مسئلہ فائل کا ہے، لے آؤٹ کا نہیں۔

پھر بھی پھنسے ہوئے ہیں؟

اگر آپ نے تصدیق کر لی ہے کہ پیش کی گئی فائل آپ کی مکمل-ریزولوشن اپ لوڈ ہے — نہ کوئی -scaled، نہ کوئی ڈائمینشن سفکس — اور پھر بھی وہ نرم ہے، تو دیکھیں کہ آیا کوئی plugin (کوئی آپٹیمائزر، ایک CDN امیج-ریسائزر، یا کوئی lazy-load لائبریری) آپ کے src کو ایک کمپریس شدہ پراکسی سے بدل رہا ہے۔ تصویر کو image sizes tool سے گزاریں تاکہ تصدیق ہو کہ WordPress کو دراصل کیا بنانا چاہیے، پھر اس کا موازنہ اُس چیز سے کریں جو براؤزر دراصل لوڈ کرتا ہے۔ جب یہ دونوں اختلاف کریں، تو WordPress اور براؤزر کے درمیان کوئی چیز اصل مجرم ہے۔