الانتقال إلى المحتوى
الإعداد

زيادة الحد الأقصى لحجم الملفات المرفوعة في ووردبريس

ثلاثة إعدادات تتحكم في حد الرفع لديك في ووردبريس، ويجب أن تتوافق جميعها. الحد الفعلي هو الأصغر بين upload_max_filesize و post_max_size،

نُشر

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

لماذا يوجد هذا الحد وأين يوجد

ووردبريس لا يضبط حد الرفع. إنه يعرضه فقط. عندما ترى رسالة “The uploaded file exceeds the upload_max_filesize directive in php.ini”، فهذه الرسالة تأتي مباشرةً من PHP.

ثلاث قيم منفصلة تتحكم في الرفع، والسقف الحقيقي هو أيها أقل:

  • upload_max_filesize (PHP) — أكبر ملف مفرد سيقبله PHP.
  • post_max_size (PHP) — أكبر حجم إجمالي لجسم طلب POST. ملفك يُرسَل داخل طلب POST مع بقية حقول النموذج، لذا يجب أن تكون هذه القيمة أكبر من upload_max_filesize.
  • حد جسم الطلب في خادم الويبclient_max_body_size في Nginx، أو LimitRequestBody في Apache. هذه القيمة توجد خارج PHP تمامًا، ولهذا تفشل الحلول المقتصرة على PHP بصمت خلف Nginx.

هناك قيمة رابعة، max_execution_time، لا تحدّ من الحجم لكنها ستُنهي عملية رفع ملف كبير بطيئة في منتصف النقل على اتصال ضعيف. إنها عرَض منفصل، وليست جزءًا من سقف الحجم.

الفخ: تضبط upload_max_filesize = 256M، تعيد التحميل، وما زلت غير قادر على رفع ملف بحجم 100 ميغابايت — لأن post_max_size ما زال 8M. يرفض PHP الطلب بناءً على الحجم الإجمالي للجسم قبل أن يفحص الملف أصلًا. الحد لم يتجاهلك. بل التقطه حدٌّ مختلف أولًا.

كيفية إصلاحه، بالترتيب

اعمل من الأكثر احتمالًا للنجاح وصولًا إلى الحل الأخير.

1. عدّل php.ini (المكان الصحيح). ابحث عن الملف الذي يحمّله موقعك فعليًا — شغّل صفحة تحتوي <?php phpinfo(); واقرأ “Loaded Configuration File”، أو اسأل مزوّد الاستضافة. اضبط قيمتَي PHP معًا، وابقِ post_max_size أكبر من upload_max_filesize:

upload_max_filesize = 256M
post_max_size = 260M
max_execution_time = 300

أعد تشغيل PHP-FPM (sudo systemctl restart php8.2-fpm) أو Apache. التغييرات لا تفعل شيئًا حتى تُعاد عملية PHP.

2. لا تملك صلاحية php.ini؟ استخدم .htaccess (Apache + mod_php فقط). أضف إلى ملف .htaccess في جذر ووردبريس لديك:

php_value upload_max_filesize 256M
php_value post_max_size 260M
php_value max_execution_time 300

هذا ينجح فقط عندما يعمل PHP كوحدة Apache. أما تحت PHP-FPM أو CGI أو FastCGI فإن php_value يُطلق خطأ 500 — وهذا الفشل يعني أنك على المسار الخطأ، لا أن الرقم خاطئ. انتقل إلى .user.ini:

upload_max_filesize = 256M
post_max_size = 260M

3. ارفع حد خادم الويب — الخطوة التي ينساها الجميع. في Nginx، لا يرى PHP الطلب الكبير أصلًا؛ فيُرجع Nginx 413 Request Entity Too Large أولًا. في كتلة الخادم لديك:

client_max_body_size 256M;

أعد التحميل عبر sudo nginx -t && sudo systemctl reload nginx. إذا كنت على Nginx وكانت تعديلات PHP لديك “لم تفعل شيئًا”، فهذا هو السبب في معظم الحالات.

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

ما يجب تجنّبه

لا تعدّل wp-config.php وتتوقع أن يرفع الحد. السطر الشائع نسخه لا يفعل ما تدّعيه المقالات:

@ini_set( 'upload_max_filesize' , '256M' );

قيمة upload_max_filesize من نوع PHP_INI_PERDIR. لا يمكن تغييرها من PHP أثناء التشغيل عبر ini_set(). إنها تقبل قيمًا جديدة فقط من php.ini أو .htaccess أو .user.ini — أبدًا من كود التطبيق. يعمل هذا السطر دون خطأ ولا يفعل شيئًا، مما يجعله من أكثر النصائح الخاطئة المتكرَّرة بثقة في عالم ووردبريس.

لا تلصق @ini_set('post_max_size', ...) أيضًا — القيد نفسه، والنتيجة نفسها بلا أي أثر وبصمت.

لا تضبط WP_MEMORY_LIMIT وتظن أنه حد الرفع. هذا يتحكم في سقف الذاكرة الذي يخصصه PHP لتشغيل الكود. لا علاقة له بحجم الملف الذي يقبله الخادم.

لا تتوقف عند ملف واحد. الفشل الأكثر شيوعًا هو تغيير upload_max_filesize وحده ثم إعلان أن الحل معطوب. غيّر القيم الثلاث جميعًا، وابقِ post_max_size أعلى من upload_max_filesize.

لا تضبط حدودًا مرتفعة بشكل مبالغ فيه “من باب الاحتياط”. حدّ بمقدار 2 غيغابايت يستدعي مشاكل استنزاف الموارد ولا يفيد — إن كنت تحتاج فعلًا إلى ملفات بحجم عدة غيغابايت، فارفعها خارج المتصفح (عبر SFTP، أو إضافة رفع مجزّأ) بدلًا من إجبارها عبر طلب POST واحد في PHP.

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

إذا رفعت القيم الثلاث جميعًا وما زلت تصطدم بجدار، فالطلب يُقيَّد في مكان ما أعلى من خادمك: شبكة توصيل محتوى (CDN) أو وكيل (لوحة تحكم Cloudflare تقيّد حجم جسم الرفع بنفسها)، أو حدّ منصّة استضافة مُدارة يتجاهل ملف php.ini لديك، أو ملف .user.ini لم يُحدَّث بعد — فهو يلتزم بقيمة user_ini.cache_ttl في PHP، لذا قد يتأخر بضع دقائق بعد الحفظ. تأكد مما يعرضه الخادم فعلًا، لا مما كتبته في ملف، وأصلح الطبقة التي ما زالت منخفضة. عندما يطابق الرقم المعروض هدفك أخيرًا، ستنجح عملية الرفع.