Как исправить fatal error из-за нехватки памяти в WordPress

Если WordPress внезапно перестал открывать админку, а в логах появился Allowed memory size exhausted, проблема обычно не в «слабом хостинге вообще», а в конкретном плагине, теме или слишком низком лимите PHP. Важно не просто увеличить память, а понять, почему она заканчивается и где именно это происходит: в фронтенде, в редакторе, при импорте, в cron или в REST API.

Как выглядит проблема на практике

Типичный сценарий: сайт открывается частично, но при сохранении записи, запуске импорта или открытии каталога плагинов админка выдает белый экран или fatal error. В error log часто встречаются строки вида Allowed memory size of 134217728 bytes exhausted или PHP Fatal error: Out of memory. Это не всегда означает, что памяти «не хватает вообще» — иногда один запрос раздувает потребление из-за тяжелого плагина, большого количества изображений, сложного конструктора или бесконечного цикла в коде темы.

Диагностика: что проверить до изменения лимита

Сначала нужно понять, где именно заканчивается память. Если просто поднять лимит, ошибка может исчезнуть на время, но причина останется и вернется при следующем обновлении или росте нагрузки.

1. Посмотрите error log сервера и debug.log

Если включен режим отладки, в wp-content/debug.log часто видно, какой файл и какая функция съели память. Это самый полезный источник, потому что он показывает не только факт падения, но и точку входа.

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

После включения откройте проблемную страницу еще раз и проверьте wp-content/debug.log. Если лог пустой, смотрите системный error log в панели хостинга.

2. Сравните, где падает сайт

Полезно разделить проблему на сценарии:

• только админка — часто виноват плагин, редактор, список записей или обновление;
• только фронтенд — может быть тяжелая тема, виджет, фильтры, большие запросы к базе;
• только импорт/экспорт — обычно не хватает лимита на один длинный процесс;
• только REST API или cron — возможен зацикленный запрос или массовая обработка данных.

3. Проверьте текущие лимиты PHP и WordPress

Нужно отличать лимит PHP на уровне сервера от лимита, который видит WordPress. В админке это можно посмотреть в Инструменты → Здоровье сайта → Информация, а на сервере — через phpinfo() или панель хостинга. Если PHP ограничен, а в wp-config.php вы уже прописали большее значение, WordPress все равно не сможет выйти за пределы серверного лимита.

Пошаговое решение: как поднять память без лишних рисков

Если диагностика не показала явный баг в коде, начинайте с аккуратного увеличения лимита. Делать это лучше в нескольких местах, но без фанатизма: слишком высокий лимит не лечит утечку памяти и может скрыть проблему до следующего пика нагрузки.

Шаг 1. Увеличьте лимит в wp-config.php

Добавьте строку выше комментария /* That's all, stop editing! */. Для большинства сайтов этого достаточно, если хостинг не режет значение ниже.

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

WP_MEMORY_LIMIT влияет на обычные запросы сайта, а WP_MAX_MEMORY_LIMIT — на административные операции, например массовые действия, импорт или работу редактора. Если хостинг не позволяет такие значения, WordPress просто останется на доступном уровне.

Шаг 2. Проверьте лимит в настройках PHP

На некоторых хостингах нужно отдельно поднять memory_limit в php.ini, .user.ini или через панель управления. Пример для .user.ini:

memory_limit = 256M

Если используется PHP-FPM, изменения могут применяться не сразу. После правки иногда нужно подождать несколько минут или перезапустить PHP-процесс через панель хостинга.

Шаг 3. Уберите источник перерасхода памяти

Если ошибка возвращается даже после увеличения лимита, ищите конкретный узел:

• отключите плагины по одному и повторите проблемное действие;
• временно переключитесь на стандартную тему, если падает фронтенд;
• проверьте последние изменения в functions.php и кастомных плагинах;
• посмотрите, не запускается ли тяжелый запрос в цикле или при каждом хите страницы;
• проверьте, не обрабатывает ли плагин слишком много данных за один проход.

Сравнение подходов: плагин, код или хостинг

Как проверить, что решение сработало

Проверка должна быть не формальной, а по сценарию, где сайт раньше падал. Откройте именно ту страницу или действие, которое вызывало ошибку: сохранение записи, загрузку медиатеки, массовое обновление, импорт, открытие каталога плагинов. Если проблема была в админке, проверьте еще и фронтенд, потому что иногда ошибка проявляется только в одном контексте.

• ошибка Allowed memory size exhausted больше не появляется в логах;
• страница загружается без белого экрана и без обрыва запроса;
• в Site Health не осталось предупреждения о критически низкой памяти;
• повторное выполнение проблемного действия проходит стабильно.

Если после увеличения лимита сайт стал работать, но в логах все равно видно резкий рост потребления, это повод не откладывать разбор кода. Иначе проблема вернется при обновлении плагина, росте базы или более тяжелом контенте.

Частые ошибки и как их исправить

Поменяли только wp-config.php, но ничего не изменилось

Значит, серверный memory_limit ниже. WordPress не может превысить лимит PHP. Проверьте настройки хостинга или .user.ini.

Поставили слишком высокий лимит и забыли про причину

Это временно маскирует проблему. Если один запрос стабильно съедает много памяти, он может начать тормозить сайт даже без fatal error. Нужно найти плагин, тему или кастомный код, который вызывает перерасход.

Ошибка появляется только в редакторе блоков

Часто виноваты тяжелые блоки, сторонние скрипты, большое количество вложенных медиафайлов или конфликт плагинов, которые вмешиваются в редактор. В таком случае полезно проверить консоль браузера и отключить недавние расширения редактора.

После обновления плагина сайт начал падать

Сначала откатите обновление, если есть резервная копия, и проверьте changelog. Иногда новая версия меняет способ загрузки данных и увеличивает потребление памяти на больших сайтах. Если откат невозможен, временно отключите плагин и ищите альтернативу.

Безопасность и производительность: что не стоит делать

Не поднимайте память бесконечно «на всякий случай». Большой лимит не спасает от плохих запросов, а на слабом сервере может привести к тому, что несколько тяжелых процессов одновременно съедят ресурсы и уронят сайт целиком. Если сайт регулярно упирается в память, лучше оптимизировать код, сократить число активных плагинов и убрать лишние фоновые задачи.

Если проблема связана с массовой обработкой контента, лучше разбить задачу на части. Например, импортировать данные пакетами, а не одним большим запуском. Для сложных сайтов полезно отдельно проверить автозагрузку опций в базе и отключить неиспользуемые плагины, которые все равно держат свои данные в памяти на каждом запросе.

Если нужен быстрый и аккуратный аудит дублей, лишних скриптов и технических настроек, иногда помогает специализированный набор инструментов вроде Clearfy Pro, но он не заменяет диагностику конкретного fatal error. Сначала нужно понять источник перерасхода, а уже потом чистить сайт.

Короткий чек-лист перед правкой на продакшене

• сделать резервную копию файлов и базы;
• посмотреть error log и зафиксировать точную ошибку;
• проверить лимит PHP и лимит WordPress;
• внести изменения сначала на staging, если он есть;
• после правки повторить именно тот сценарий, где падал сайт;
• сохранить лог до и после, чтобы сравнить результат.

Если проблема не уходит после поднятия лимита и отключения подозрительных плагинов, почти всегда есть конкретный участок кода, который нужно переписать или заменить. В таких случаях лучше искать причину сразу, чем бесконечно увеличивать память и надеяться, что сайт «сам успокоится».