خطأ HTTP عند رفع الصور في ووردبريس: شجرة قرار تصل إلى السبب فعلاً

“خطأ HTTP” ليس سبباً. إنه اعتراف من أداة رفع الوسائط بأنها أرسلت ملفك إلى الخادم وعاد إليها رد لم تستطع قراءته كنجاح — وهناك ستة أعطال مختلفة على الأقل، لا رابط بينها، تنتج هذه العبارة ذاتها. والتخمين بينها هو سبب إضاعة الناس عصراً كاملاً في رفع upload_max_filesize على موقع مشكلته الحقيقية قاعدة في جدار الحماية.

أسرع طريق للخروج هو ملاحظة واحدة تقسم الأسباب الستة إلى مجموعتين، ثم فحص واحد لكل فرع.

أولاً: اقرأ الرد الفعلي

افتح أدوات المطوّر في متصفحك، انتقل إلى تبويب Network، وارفع الملف مرة أخرى. راقب الطلب المتجه إلى async-upload.php. وما يعود منه هو تشخيصك.

ما تراه	ما يعنيه	انتقل إلى
403 أو 406 مع محتوى HTML	جدار الحماية أو mod_security رفض الطلب	الفرع أ
500، أو رد فارغ، أو محتوى مبتور	انهار PHP أو نفدت ذاكرته في منتصف العملية	الفرع ب
413	تجاوز محتوى الطلب حداً على مستوى الخادم	الفرع ج
200، لكن المحتوى ليس JSON نظيفاً	إضافة أو قالب طبع مخرجات قبل الرد	الفرع د
الطلب لا يكتمل أبداً / تنتهي مهلته	حد زمن التنفيذ، غالباً مع الملفات الكبيرة	الفرع ب

هذه النظرة الواحدة تُسقط عنك معظم النصائح المنتشرة على الإنترنت. وإذا تعذّر عليك الوصول إلى أدوات المتصفح، فعّل التسجيل في wp-config.php أولاً:

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

أعد محاولة الرفع، ثم اقرأ wp-content/debug.log. سطر الخطأ الفادح يسمّي الفرع صراحةً. وإذا كان السطر مكثفاً، الصقه في مفكك سجل الأخطاء — فهو يربط توقيعات الأخطاء الفادحة الشائعة بما تعطل فعلاً.

الفرع أ — قاعدة في جدار الحماية أو mod_security

رمز 403 مع صفحة HTML في المحتوى يعني أن الطلب لم يصل إلى ووردبريس أصلاً. فشيء أمامه — mod_security أو Cloudflare أو Wordfence أو Sucuri أو مجموعة قواعد مضيفك نفسه — قرر أن طلب POST يبدو خبيثاً.

الفحص: عطّل أي إضافة حماية مؤقتاً وأعد الرفع. فإن لم يتغير شيء، فالقاعدة موجودة على مستوى الخادم، وتحتاج إلى مضيفك ليراجع سجل تدقيق mod_security عند توقيت الرفع الفاشل. وبإمكانهم استثناء رقم القاعدة تحديداً.

وكن صريحاً مع نفسك بشأن النصائح التي ستجدها هنا. المقاطع التي تطلب منك وضع هذا في .htaccess:

SecFilterEngine Off
SecFilterScanPOST Off

موجهة إلى mod_security 1.x، وهو شبه منقرض. وعلى خادم حديث، إما ألا تفعل هذه التوجيهات شيئاً، أو تُنتج خطأ 500 يجعل الموقع أسوأ. فالإصدارات الحديثة من mod_security تستخدم SecRuleEngine، ومعظم الاستضافات المُدارة تمنع تجاوزه على مستوى المجلدات أصلاً. اسأل المضيف، ولا تلصق شيئاً.

الفرع ب — حدود ذاكرة PHP أو زمن التنفيذ

هذا أكثر الفروع شيوعاً، وأوضحها علامةً: إنه متقطع. الملف نفسه يُرفع من المحاولة الثالثة، أو صورة بحجم 2 ميجابايت تفشل بينما يمر ملف PDF بحجم 6 ميجابايت بسلاسة. الحدود الصارمة في الإعدادات تفشل بالطريقة نفسها في كل مرة، أما أعطال الذاكرة فلا، لأن المتاح منها يعتمد على ما يفعله الخادم في تلك اللحظة.

ولماذا الصور تحديداً: لأن ووردبريس لا يخزن الملف فحسب، بل يفكّ ضغطه إلى بكسلات خام ليولّد كل المقاسات الوسيطة — medium_large، وأي مقاس مسجّل عبر add_image_size، وwoocommerce_thumbnail إن كنت تدير متجراً، إضافة إلى نسخة -scaled إن تجاوزت الصورة قيمة big_image_size_threshold. فصورة JPEG بدقة 12 ميجابكسل حجمها بضعة ميجابايت على القرص، وقرابة 48 ميجابايت في الذاكرة، قبل احتساب حيّز التصغير. وحد 128 ميجابايت يتبخر سريعاً.

ارفعه في wp-config.php، فوق سطر “stop editing”:

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

والتكلفة الحقيقية: لا يمكن لـ WP_MEMORY_LIMIT أن يتجاوز ما يسمح به PHP نفسه. فإذا كان مضيفك يحدّ memory_limit عند 128 ميجابايت، فهذا الثابت مجرد زينة. تحقق من القيمة الحقيقية في أدوات ← صحة الموقع ← معلومات ← الخادم، لا مما كتبته أنت. وإذا كان حد PHP نفسه هو السقف، فلن يحركه إلا المضيف.

الفرع ج — حدود حجم الملف وحجم الطلب

راجع الأرقام الفعلية في أدوات ← صحة الموقع ← معلومات ← معالجة الوسائط. هناك إعدادان مهمان، والناس لا يغيّرون إلا واحداً منهما دائماً:

• upload_max_filesize — الحد الأقصى للملف الواحد.
• post_max_size — الحد الأقصى لمحتوى الطلب بأكمله.

فإذا تجاوز طلب POST كاملاً قيمة post_max_size، يتخلص PHP من الطلب قبل أن ينفّذ ووردبريس أي كود. ولا يبقى شيء ليُعاد، فتحصل أداة الرفع على رد غير قابل للتفسير وتقول “خطأ HTTP”. ويجب أن تكون post_max_size أكبر بمريح دائماً من upload_max_filesize.

وهناك تنبيه يستحق المعرفة: حين يتجاوز الملف قيمة upload_max_filesize وحدها، تلتقط أداة الرفع ذلك في المتصفح عادةً وتقول إن الملف يتجاوز الحد الأقصى للرفع — وهي رسالة أوضح. لذلك فرسالة “خطأ HTTP” المجردة تشير إلى post_max_size أو إلى الفرع ب أكثر مما تشير إلى الإعداد الذي يرفعه الجميع أولاً.

ومكان تغييرهما يعتمد على بيئتك. على Apache مع mod_php، يعمل .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، ولا يرفعه إلا المضيف.

الفرع د — مكتبة تحرير الصور (Imagick مقابل GD)

يفضّل ووردبريس استخدام ImageMagick حين تكون إضافة PHP الخاصة بها متوفرة، ويعود إلى GD عند غيابها. وعلى الاستضافات المشتركة، تكون ImageMagick هي المشكلة كثيراً: فملف إعدادات السياسة الخاص بها يقيّد الذاكرة والقرص والمساحة لكل عملية، وحين يتجاوز التصغير أحد هذه الحدود تموت العملية دون رسالة مفيدة. وستلاحظ ذلك عادةً مع الصور الكبيرة بينما تعمل الصغيرة — وهو ما يشبه الفرع ب دون أن يكون منه.

افرض استخدام GD لاختبار الفرضية:

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

ضع ذلك في functions.php أو في إضافة mu صغيرة، وأعد محاولة الرفع، ثم احذفه إن لم يتغير شيء.

والمقايضة الصريحة: GD ليست أفضل بإطلاق. فهي تحتفظ بالصورة النقطية غير المضغوطة كاملة في ذاكرة PHP، ولذلك قد تصطدم مع الملفات الضخمة جداً بـ memory_limit حيث كانت ImageMagick — التي تعمل جزئياً خارج مخصصات PHP — لتنجح. فالتحويل قد يستبدل عطلاً بعطل آخر. عامِله كأداة تشخيص أولاً، وكحل ثانياً.

الفرع هـ — صلاحيات مجلد الرفع

نادر على الاستضافة المُدارة، وشائع بعد عملية نقل مباشرةً أو بعد ترحيل يدوي للخادم. فإذا لم يكن مجلد wp-content/uploads قابلاً للكتابة من قِبل مستخدم خادم الويب، أو ورث مجلد سنة/شهر أُنشئ حديثاً مالكاً خاطئاً، تفشل عملية الكتابة.

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

ينبغي أن تكون صلاحيات المجلدات 755 عادةً وأن يملكها المستخدم الذي يعمل PHP باسمه. ولا تضبطها على 777 لمجرد أن منتدى ما نصحك بذلك — فهي تعالج العرض بجعل المجلد قابلاً للكتابة من كل حساب على الخادم، وهو انكشاف حقيقي على الاستضافة المشتركة.

الفرع و — اسم الملف

أرخص فحص في القائمة، فأجرِه مبكراً رغم أنه الأقل احتمالاً. أعد تسمية الملف إلى حروف إنجليزية صغيرة وأرقام وشرطات — بلا تشكيل ولا فواصل عليا ولا علامات عطف ولا # ولا حروف غير لاتينية — ثم أعد الرفع. فالمحارف الخاصة تُفعّل أحياناً قاعدة أمنية أو تنكسر على نظام ملفات بترميز غير متطابق. عشر ثوانٍ لاستبعاد الاحتمال.

ما لا ينبغي فعله

لا تبدأ بتعطيل كل الإضافات. فهو إجراء معطِّل ولا يختبر سوى الفرع أ والفرع د. رد الشبكة يخبرك بأكثر من ذلك في خمس ثوانٍ.

لا تضف سطر معالج عشوائياً إلى .htaccess. فالمقاطع المتداولة التي تضيف توجيه SetHandler أو AddHandler تفترض إعداد PHP لمضيف بعينه. وعلى بيئة مختلفة تُسقط الموقع بالكامل بخطأ 500.

لا تقبل “نجحت في المحاولة الثانية” كحل. فالنجاح المتقطع هو توقيع الفرع ب، وسيعود العطل لحظة انشغال الخادم أو رفع أحدهم ملفاً أكبر.

ما زلت عالقاً؟

إذا كان الرد 200 نظيفاً مع JSON صالح ومع ذلك يفشل الرفع، فالعطل يقع بعد وصول الملف — عادةً إضافة مرتبطة بسلسلة معالجة المرفقات تُطلق خطأً فادحاً، أو إضافة تحسين ترسل طلبها الخاص إلى خدمة خارجية تنتهي مهلته. فعّل WP_DEBUG_LOG، أعد المحاولة، ثم مرّر الخطأ الفادح الناتج عبر مفكك سجل الأخطاء لترى أي ملف وأي خطاف هو المسؤول فعلاً.