WordPress میں تصویر اپلوڈ پر "HTTP error": ایک ایسا فیصلہ کن راستہ جو اصل وجہ پکڑ لے

“HTTP error” کوئی وجہ نہیں ہے۔ یہ میڈیا اپلوڈر کا اعتراف ہے کہ اس نے آپ کی فائل سرور کو بھیجی اور جواب میں ایسی چیز ملی جسے وہ کامیابی کے طور پر نہیں پڑھ سکا — اور کم از کم چھ الگ الگ ناکامیاں بالکل یہی تین لفظ پیدا کرتی ہیں۔ ان کے درمیان اندازہ لگانا ہی وہ وجہ ہے کہ لوگ ایسی سائٹ پر پوری دوپہر upload_max_filesize بڑھانے میں لگا دیتے ہیں جس کا اصل مسئلہ فائروال کا ایک رول ہوتا ہے۔

سب سے تیز راستہ ایک ہی مشاہدہ ہے جو ان چھ وجوہات کو دو گروہوں میں بانٹ دیتا ہے، اور پھر ہر شاخ کے لیے ایک جانچ۔

سب سے پہلے: اصل جواب پڑھیں

اپنے براؤزر کے ڈویلپر ٹولز کھولیں، Network ٹیب پر جائیں، اور فائل دوبارہ اپلوڈ کریں۔ async-upload.php والی درخواست پر نظر رکھیں۔ جو کچھ واپس آتا ہے وہی آپ کی تشخیص ہے۔

آپ کو کیا نظر آتا ہے	اس کا مطلب	کہاں جائیں
403 یا 406، HTML باڈی کے ساتھ	فائروال یا mod_security نے درخواست مسترد کی	شاخ A
500، یا خالی جواب، یا ادھوری باڈی	PHP کریش ہو گیا یا بیچ میں میموری ختم ہو گئی	شاخ B
413	ریکویسٹ باڈی سرور کی کسی حد سے بڑھ گئی	شاخ C
200، مگر باڈی صاف JSON نہیں	کسی پلگ ان یا تھیم نے جواب سے پہلے کچھ چھاپ دیا	شاخ D
درخواست مکمل ہی نہیں ہوتی / ٹائم آؤٹ	ایگزیکیوشن ٹائم کی حد، عام طور پر بڑی فائلوں کے ساتھ	شاخ B

یہ ایک نظر آپ کے لیے انٹرنیٹ پر موجود زیادہ تر مشوروں کو خارج کر دیتی ہے۔ اگر آپ براؤزر ٹولز تک نہیں پہنچ سکتے تو پہلے wp-config.php میں لاگنگ آن کریں:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

اپلوڈ دوبارہ کر کے دکھائیں، پھر wp-content/debug.log پڑھیں۔ فیٹل ایرر کی لائن شاخ کا نام کھول کر بتا دیتی ہے۔ اگر لائن گنجلک ہو تو اسے ایرر لاگ ڈی کوڈر میں پیسٹ کریں — یہ عام فیٹل دستخطوں کو اس بات سے جوڑ دیتا ہے کہ اصل میں ٹوٹا کیا ہے۔

شاخ A — فائروال یا mod_security کا رول

باڈی میں HTML صفحے کے ساتھ 403 کا مطلب ہے کہ درخواست WordPress تک پہنچی ہی نہیں۔ اس سے آگے بیٹھی کوئی چیز — mod_security، Cloudflare، Wordfence، Sucuri، یا خود آپ کے ہوسٹ کے رولز — نے فیصلہ کیا کہ یہ POST مشکوک لگتا ہے۔

جانچ یہ ہے: کوئی بھی سیکیورٹی پلگ ان عارضی طور پر غیر فعال کریں اور دوبارہ اپلوڈ کریں۔ اگر اس سے کچھ نہ بدلے تو رول سرور کی سطح پر ہے، اور آپ کو اپنے ہوسٹ سے کہنا ہو گا کہ وہ ناکام اپلوڈ کے وقت کے مطابق mod_security کا آڈٹ لاگ دیکھیں۔ وہ اُس مخصوص رول ID کو وائٹ لسٹ کر سکتے ہیں۔

یہاں ملنے والے مشوروں کے بارے میں خود سے ایمانداری برتیں۔ وہ ٹکڑے جو آپ کو .htaccess میں یہ ڈالنے کو کہتے ہیں:

SecFilterEngine Off
SecFilterScanPOST Off

mod_security 1.x کے لیے ہیں، جو تقریباً ختم ہو چکا ہے۔ جدید سرور پر یہ ہدایات یا تو کچھ نہیں کرتیں یا 500 پھینک کر سائٹ مزید خراب کر دیتی ہیں۔ جدید mod_security میں SecRuleEngine استعمال ہوتا ہے، اور زیادہ تر مینیجڈ ہوسٹس ویسے بھی اس کی فی ڈائریکٹری تبدیلی روک دیتے ہیں۔ ہوسٹ سے پوچھیں؛ پیسٹ نہ کریں۔

شاخ B — PHP کی میموری یا ایگزیکیوشن حدیں

یہ سب سے عام شاخ ہے اور اس کی پہچان بھی سب سے واضح ہے: یہ کبھی ہوتی ہے، کبھی نہیں۔ وہی فائل تیسری کوشش میں چڑھ جاتی ہے، یا 2MB کی تصویر ناکام ہوتی ہے جبکہ 6MB کی PDF آرام سے چلی جاتی ہے۔ سخت کنفیگریشن حدیں ہر بار ایک ہی طرح ناکام ہوتی ہیں۔ میموری کی ناکامیاں نہیں، کیونکہ دستیاب مقدار کا انحصار اس پر ہے کہ سرور اور کیا کر رہا ہے۔

خاص طور پر تصویریں کیوں: WordPress صرف فائل محفوظ نہیں کرتا، وہ اسے کھول کر خام پکسلز میں بدلتا ہے تاکہ ہر درمیانی سائز بنا سکے — medium_large، add_image_size سے رجسٹر کیا گیا ہر سائز، اسٹور چلا رہے ہوں تو woocommerce_thumbnail، اور اگر تصویر big_image_size_threshold سے بڑی ہو تو ایک -scaled نقل بھی۔ 12 میگا پکسل کی JPEG ڈسک پر چند MB کی ہوتی ہے مگر میموری میں تقریباً 48MB لیتی ہے، اور یہ ری سائز بفر سے پہلے کی بات ہے۔ 128MB کی حد بہت جلد ختم ہو جاتی ہے۔

اسے wp-config.php میں “stop editing” والی لائن سے اوپر بڑھائیں:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

اصل قیمت یہ ہے: WP_MEMORY_LIMIT اُس حد سے آگے نہیں جا سکتا جو خود PHP اجازت دے۔ اگر آپ کا ہوسٹ memory_limit کو 128M پر باندھے ہوئے ہے تو یہ کونسٹنٹ محض سجاوٹ ہے۔ اصل قدر Tools → Site Health → Info → Server میں دیکھیں، اُس میں نہیں جو آپ نے لکھا۔ اگر چھت خود PHP کی حد ہے تو اسے صرف ہوسٹ ہی ہٹا سکتا ہے۔

شاخ C — فائل سائز اور پوسٹ کی حدیں

اصل اعداد Tools → Site Health → Info → Media Handling کے نیچے دیکھیں۔ دو سیٹنگز اہم ہیں اور لوگ ہمیشہ صرف ایک بدلتے ہیں:

• upload_max_filesize — ایک فائل کی حد۔
• post_max_size — پوری ریکویسٹ باڈی کی حد۔

اگر پورا POST post_max_size سے بڑھ جائے تو PHP، WordPress کا کوئی کوڈ چلنے سے پہلے ہی درخواست پھینک دیتا ہے۔ واپس بھیجنے کو کچھ ہوتا ہی نہیں، اس لیے اپلوڈر کو ناقابلِ فہم جواب ملتا ہے اور وہ “HTTP error” کہہ دیتا ہے۔ post_max_size ہمیشہ upload_max_filesize سے خاصا بڑا ہونا چاہیے۔

ایک بات جاننے کے قابل ہے: جب فائل صرف upload_max_filesize سے بڑی ہو تو اپلوڈر عام طور پر اسے براؤزر ہی میں پکڑ لیتا ہے اور بتاتا ہے کہ فائل زیادہ سے زیادہ اپلوڈ سائز سے بڑی ہے — یہ زیادہ واضح پیغام ہے۔ اس لیے خالی “HTTP error” اُس سیٹنگ کے مقابلے میں، جسے سب سے پہلے بڑھایا جاتا ہے، زیادہ تر post_max_size یا شاخ B کی طرف اشارہ کرتی ہے۔

انہیں کہاں بدلنا ہے، اس کا انحصار آپ کے اسٹیک پر ہے۔ mod_php کے ساتھ Apache پر .htaccess کام کرتا ہے:

php_value upload_max_filesize 64M
php_value post_max_size 128M

PHP-FPM، LiteSpeed یا NGINX پر — یعنی زیادہ تر جدید ہوسٹنگ پر — یہ لائنیں کچھ نہیں کرتیں، اور 500 بھی پھینک سکتی ہیں۔ ان کی جگہ ہوسٹ کا PHP سیٹنگز پینل یا .user.ini فائل استعمال کریں۔ NGINX اپنی الگ client_max_body_size بھی لاگو کرتا ہے، جسے صرف ہوسٹ ہی بڑھا سکتا ہے۔

شاخ D — امیج ایڈیٹر لائبریری (Imagick بمقابلہ GD)

جب PHP ایکسٹینشن موجود ہو تو WordPress ImageMagick کو ترجیح دیتا ہے، ورنہ GD پر آ جاتا ہے۔ شیئرڈ ہوسٹس پر ImageMagick اکثر خود مسئلہ ہوتا ہے: اس کی پالیسی کنفیگریشن فائل ہر عمل کے لیے میموری، ڈسک اور رقبے کو محدود کرتی ہے، اور جب ری سائز ان میں سے کسی حد سے ٹکراتا ہے تو پروسیس بغیر کوئی کارآمد پیغام دیے مر جاتا ہے۔ یہ عام طور پر بڑی تصویروں پر ہوتا ہے جبکہ چھوٹی چل جاتی ہیں — جو دیکھنے میں شاخ B لگتی ہے مگر ہے نہیں۔

نظریے کی جانچ کے لیے GD پر مجبور کریں:

add_filter( 'wp_image_editors', function ( $editors ) {
    return array( 'WP_Image_Editor_GD' );
} );

اسے functions.php میں یا ایک چھوٹے mu-plugin میں رکھیں، اپلوڈ دوبارہ آزمائیں، اور اگر کچھ نہ بدلے تو ہٹا دیں۔

کھلی بات یہ ہے کہ GD ہر لحاظ سے بہتر نہیں۔ وہ پوری غیر دبی ہوئی بٹ میپ PHP کی میموری میں رکھتا ہے، اس لیے بہت بڑی فائلوں پر وہ memory_limit سے ٹکرا سکتا ہے جہاں ImageMagick — جو کچھ کام PHP کی الاٹمنٹ سے باہر کرتا ہے — کامیاب ہو جاتا۔ یہ تبدیلی ایک ناکامی کو دوسری سے بدل سکتی ہے۔ اسے پہلے تشخیص سمجھیں، حل بعد میں۔

شاخ E — اپلوڈز ڈائریکٹری کی اجازتیں

مینیجڈ ہوسٹنگ پر کم، مگر مائیگریشن یا دستی سرور منتقلی کے فوراً بعد عام۔ اگر wp-content/uploads ویب سرور یوزر کے لیے قابلِ تحریر نہ ہو، یا نئے بننے والے سال/مہینے کے سب فولڈر کو غلط مالک مل جائے، تو لکھائی ناکام ہو جاتی ہے۔

ls -ld wp-content/uploads
ls -ld wp-content/uploads/2026/07

ڈائریکٹریاں عام طور پر 755 ہونی چاہئیں اور ان کا مالک وہی یوزر ہو جس کے تحت PHP چلتا ہے۔ 777 صرف اس لیے نہ رکھیں کہ کسی فورم نے کہہ دیا — یہ علامت اس طرح ٹھیک کرتا ہے کہ فولڈر سرور کے ہر اکاؤنٹ کے لیے قابلِ تحریر ہو جاتا ہے، جو شیئرڈ ہوسٹنگ پر حقیقی خطرہ ہے۔

شاخ F — فائل کا نام

فہرست کی سب سے سستی جانچ، اس لیے کم امکان کے باوجود اسے جلد کر لیں۔ فائل کا نام بدل کر سادہ چھوٹے انگریزی حروف، ہندسے اور ڈیش رکھیں — کوئی اعراب، apostrophe، ampersand، # یا غیر لاطینی حروف نہیں — اور دوبارہ اپلوڈ کریں۔ خاص حروف کبھی کبھار کسی سیکیورٹی رول کو چھیڑ دیتے ہیں یا مختلف اینکوڈنگ والے فائل سسٹم پر ٹوٹ جاتے ہیں۔ خارج کرنے میں دس سیکنڈ لگتے ہیں۔

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

ہر پلگ ان بند کرنے سے آغاز نہ کریں۔ یہ خلل ڈالتا ہے اور صرف شاخ A اور شاخ D کی جانچ کرتا ہے۔ نیٹ ورک کا جواب آپ کو پانچ سیکنڈ میں اس سے زیادہ بتا دیتا ہے۔

.htaccess میں کوئی بے ترتیب ہینڈلر لائن نہ ڈالیں۔ جو ٹکڑے SetHandler یا AddHandler ہدایت شامل کرنے کو کہتے ہیں، وہ کسی مخصوص ہوسٹ کے PHP سیٹ اپ کو فرض کرتے ہیں۔ غلط اسٹیک پر یہ پوری سائٹ کو 500 کے ساتھ گرا دیتے ہیں۔

“دوبارہ کوشش پر چل گیا” کو حل نہ سمجھیں۔ کبھی کبھار کامیابی شاخ B کی پہچان ہے، اور جیسے ہی سرور مصروف ہوا یا کسی نے بڑی فائل چڑھائی، مسئلہ واپس آ جائے گا۔

اب بھی مسئلہ حل نہ ہو؟

اگر جواب صاف 200 اور درست JSON ہے اور پھر بھی اپلوڈ ناکام ہو رہا ہے تو خرابی فائل پہنچنے کے بعد ہے — عام طور پر کوئی پلگ ان جو اٹیچمنٹ پروسیسنگ کی زنجیر میں ہک ہو کر فیٹل پھینک رہا ہے، یا کوئی آپٹیمائزر پلگ ان جو کسی بیرونی سروس کو اپنی درخواست بھیجتا ہے اور وہ ٹائم آؤٹ ہو جاتی ہے۔ WP_DEBUG_LOG آن کریں، مسئلہ دوبارہ پیدا کریں، اور نتیجے میں آنے والا فیٹل ایرر لاگ ڈی کوڈر میں چلائیں تاکہ پتہ چلے کہ اصل ذمہ دار کون سی فائل اور کون سا ہک ہے۔