حل مشكلة "Allowed Memory Size Exhausted" في ووردبريس

إذا كان موقعك يعرض Fatal error: Allowed memory size of 268435456 bytes exhausted، أضف هذا السطر إلى ملف wp-config.php فوق تعليق /* That's all, stop editing! */: define( 'WP_MEMORY_LIMIT', '256M' );. هذا يعيد معظم المواقع للعمل في أقل من دقيقة. لكن اقرأ بقية هذه الصفحة قبل أن تغادر، لأن رفع الحد هو تشخيص وليس علاجاً. إذا عاد الانهيار عند رقم أعلى، فالمشكلة الحقيقية هي كود يستهلك الذاكرة بلا حدود، ورفع السقف يمنحه مجالاً أكبر ليتمادى فقط.

ماذا يعني الخطأ فعلياً

يتتبع PHP كمية الذاكرة التي خصصها كل طلب. وعندما يحاول طلب واحد تخصيص ذاكرة تتجاوز memory_limit المضبوط في php.ini (أو المُتجاوَز من قِبل ووردبريس)، يوقف PHP الطلب فوراً بخطأ فادح ويطبع عدد البايتات التي توقف عندها. 268435456 bytes تساوي 256M. و 134217728 تساوي 128M. و 536870912 تساوي 512M. الرقم الذي يلي “tried to allocate” يخبرك بحجم القشة الأخيرة، لا بحجم المشكلة نفسها.

يضيف ووردبريس حدوده الخاصة فوق حدود PHP. الثابت WP_MEMORY_LIMIT (الافتراضي 40M، أو حد PHP إن كان أعلى) يتحكم في الواجهة الأمامية. والثابت WP_MAX_MEMORY_LIMIT (الافتراضي 256M) يتحكم في عمليات لوحة التحكم مثل مكتبة الوسائط وتحديثات الإضافات، وهي تحتاج فعلاً إلى ذاكرة أكبر. يستدعي ووردبريس ini_set('memory_limit', ...) عند التحميل بناءً على هذه الثوابت — لكن فقط إذا سمح مضيفك بـ ini_set، وفقط حتى الحد الأقصى الصارم الذي يضبطه مضيفك. هذا الجزء الأخير هو سبب ظهور تعديل wp-config.php أحياناً وكأنه بلا أثر.

أصلحها بالترتيب

1. ارفع حد ووردبريس في wp-config.php. هذا أول ما تجربه لأنه قابل للتراجع ولا يمسّ أي شيء آخر.

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

إذا لم تكن متأكداً من مكان وضع هذه الأسطر أو أردت ضبط بقية الثوابت الشائعة بشكل صحيح في الوقت نفسه، فإن مولّد wp-config يكتب لك كتلة نظيفة يمكنك لصقها. الموضع مهم — أي شيء أسفل سطر “stop editing” يتم تجاهله.

2. إذا لم يُحدث ذلك أي فرق، فمضيفك يضع حداً على PHP. ارفع memory_limit على مستوى PHP. في ملف php.ini:

memory_limit = 256M

على كثير من الاستضافات المشتركة لا يمكنك تعديل php.ini مباشرة. جرّب ملف .user.ini في جذر موقعك بدلاً من ذلك، أو اضبطه عبر .htaccess في إعداد Apache/mod_php:

php_value memory_limit 256M

لاحظ أن php_value في .htaccess يسبب خطأ 500 على nginx أو في إعدادات PHP-FPM، لأنه توجيه خاص بـ Apache/mod_php. إذا حصلت على خطأ 500 بعد إضافته، فهذا هو السبب — احذفه واستخدم .user.ini.

3. تأكد من القيمة الفعلية المطبّقة. لا تثق بما عدّلته، بل ثق بما يبلّغ عنه PHP. ضع ملفاً من سطر واحد في جذر موقعك:

<?php echo ini_get('memory_limit');

حمّله في المتصفح، اقرأ القيمة، ثم احذف الملف. إذا ظل يعرض 128M بعد أن ضبطت 256M، فمضيفك يتجاوز إعدادك وعليك التواصل معه أو استخدام إعداد لوحة التحكم لديه.

الجزء الذي تتجاهله معظم الأدلة

رفع الحد هو تشخيص. وإليك كيفية قراءة النتيجة.

إذا ضبطت 256M وبقي الموقع يعمل تحت الحركة الطبيعية، فقد كان لديك سقف مشروع لكنه منخفض جداً — وهذا شائع في المواقع ذات مكتبات الوسائط الكبيرة، أو WooCommerce، أو منشئات الصفحات. انتهيت.

إذا ضبطت 256M فانهار مجدداً، ثم 512M فانهار مجدداً، توقف عن رفعه. الطلب الطبيعي في ووردبريس لا يحتاج إلى 512M. عندما يتصاعد استهلاك الذاكرة بلا سقف، فهناك شيء يدور في حلقة أو يتراكم: إضافة تحمّل جدول قاعدة بيانات كاملاً في مصفوفة، أو add_action يستدعي نفسه بشكل متكرر، أو روتين استيراد يحتفظ بكل صف في الذاكرة دفعة واحدة، أو إضافتان تتصارعان داخل نفس الـ hook. رفع الحد لا يصلح حلقة بلا حدود — بل يؤخر الانهيار بضع ثوانٍ فقط ويجعل إعادة إنتاجه أصعب.

للعثور على السبب، عطّل جميع الإضافات وبدّل إلى قالب افتراضي مثل Twenty Twenty-Four. إذا توقف الخطأ، أعد تفعيل الإضافات واحدة تلو الأخرى حتى يعود. فعّل سجل التصحيح لتلتقط أين ينهار:

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

السطر الفادح في wp-content/debug.log يذكر اسم الملف ورقم السطر الذي خصّص الكتلة الأخيرة. وهذا عادةً هو موضع الحلقة، أو على بُعد استدعاء دالة واحد منها.

ما يجب ألا تفعله

لا تضبط WP_MEMORY_LIMIT على -1 أو 1024M وتنساه. الذاكرة غير المحدودة لا تصلح التسريب؛ بل تترك طلباً جامحاً يلتهم الخادم بأكمله، ما قد يوقع كل موقع آخر على نفس الجهاز ويجلب لك اتصالاً من مضيفك. السقف ميزة أمان. احتفظ بواحد.

لا تلصق ini_set('memory_limit', '512M') في functions.php كحل أساسي. يعمل متأخراً جداً لبعض حالات الفشل — إذا حدث الانهيار أثناء تحميل نواة ووردبريس قبل تنفيذ functions.php الخاص بقالبك، فلن يعمل السطر إطلاقاً. يُحمَّل wp-config.php مبكراً وهو المكان الصحيح.

لا تفترض أنها مشكلة استضافة وترقّي خطتك. أحياناً تكون الاستضافة فعلاً أقل من اللازم. لكن غالباً يتبعك نفس الانهيار بالضبط إلى الخطة الأكبر لأن السبب انتقل معك ضمن إضافاتك. استبعد الحلقة أولاً؛ فهذا مجاني.

لا ترفع memory_limit لإصلاح خطأ max_execution_time. إنهما حدّان مختلفان برسائل مختلفة. نفاد الذاكرة يقول “Allowed memory size … exhausted.” والمهلة تقول “Maximum execution time … exceeded.” رفع الحد الخاطئ يضيّع عليك عصر يوم كامل.

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

إذا تأكدت أن الحد الفعلي المطبّق هو 256M أو أعلى بصدق، واختبرت بجميع الإضافات معطّلة وقالب افتراضي، وما زال يستنفد الذاكرة، فلديك تسريب حقيقي يستحق التتبع في سجل التصحيح بدلاً من سقف يستحق الرفع. التقط السطر الفادح، ولاحظ إلى دليل أي إضافة يشير، وهذا هو تقرير الخطأ الخاص بك. اضبط ثوابت wp-config.php الأساسية بشكل صحيح أولاً باستخدام مولّد wp-config حتى تعرف أن الحدود مضبوطة حيث تظنها — ثم اذهب لقراءة السجل.