Как исправить ошибку max_execution_time в WordPress

Ошибка max_execution_time в WordPress возникает, когда PHP-скрипт превышает максимальное время выполнения, настроенное на уровне сервера. PHP завершает скрипт и возвращает фатальную ошибку, которую WordPress отображает в виде белого экрана, уведомления о превышении времени ожидания или явного сообщения "Maximum execution time exceeded".

По умолчанию большинство сред общего хостинга устанавливают ограничение в 30 секунд. Такие операции, как импорт CSV-файла с товарами WooCommerce, создание полной резервной копии сайта или установка большого пакета плагинов, могут легко превысить этот предел. Увеличение лимита — через php.ini, .htaccess, wp-config.php или на уровне плагина WordPress — устраняет ошибку без ущерба для стабильности сервера при правильном выполнении.

Понимание причин существования лимита и случаев, когда он становится проблемой

Директива max_execution_time в PHP — это механизм защиты ресурсов, а не произвольное ограничение. Она предотвращает монополизацию процессорного времени неуправляемым скриптом в общем пуле процессов, что особенно критично в многопользовательской инфраструктуре.

Лимит становится реальным препятствием в следующих сценариях:

• Крупный импорт или экспорт базы данных через phpMyAdmin или WP-CLI при обработке тысяч строк
• Установка плагинов или тем, при которой распаковываются архивы размером более 50 МБ
• Массовые операции WooCommerce — обновление цен, синхронизация остатков, экспорт заказов
• Полная миграция сайта с использованием таких инструментов, как Duplicator или All-in-One WP Migration
• Запланированные задания cron, агрегирующие данные из внешних API
• Плагины оптимизации изображений, обрабатывающие сотни неоптимизированных загрузок в одном пакете

Важный нюанс, который упускают большинство руководств: max_execution_time измеряет процессорное время, потреблённое PHP-процессом, а не реальное время. На сильно загруженном сервере скрипт может выполняться 90 секунд реального времени, потребляя лишь 28 секунд процессорного времени, и никогда не достигнет лимита. И наоборот, процессорно-интенсивный цикл достигает лимита быстрее, чем ожидается. Это различие важно при диагностике периодических таймаутов.

Как проверить текущее значение max_execution_time

Прежде чем что-либо менять, убедитесь в активном лимите. Создайте временный файл в корне WordPress — никогда не оставляйте его в открытом доступе после тестирования:

<?php
phpinfo();

Загрузите его как phpinfo-test.php, перейдите по адресу https://yourdomain.com/phpinfo-test.php и найдите max_execution_time в выводе. Немедленно удалите файл после проверки.

Альтернативно используйте WP-CLI через SSH:

wp eval 'echo ini_get("max_execution_time");'

Это вернёт значение, активное для запросов WordPress, которое может отличаться от глобального php.ini сервера, если уже действует переопределение на уровне директории.

Метод 1: Редактирование файла php.ini (наиболее надёжный)

Изменение php.ini является наиболее авторитетным методом, поскольку устанавливает директиву на уровне интерпретатора PHP, не переопределяя ничего ниже в иерархии конфигурации и не будучи переопределённым ничем ниже — если только более поздний вызов ini_set() не заменит его во время выполнения.

Шаг 1: Найдите правильный файл php.ini

Именно здесь большинство администраторов допускают ошибку. PHP может загружать несколько файлов .ini в зависимости от используемого SAPI (Server API):

• CLI SAPI (/etc/php/8.x/cli/php.ini) — используется WP-CLI и заданиями cron
• FPM SAPI (/etc/php/8.x/fpm/php.ini) — используется стеками Nginx + PHP-FPM
• Apache mod_php (/etc/php/8.x/apache2/php.ini) — используется Apache с модулем PHP

Редактирование CLI-файла php.ini устранит таймауты WP-CLI, но не повлияет на запросы, инициированные браузером. Всегда сначала определяйте правильный SAPI:

php -i | grep "Loaded Configuration File"

Для веб-запросов проверьте вывод phpinfo() в строке Loaded Configuration File.

Шаг 2: Отредактируйте или создайте php.ini в корне сайта

На общем хостинге, где у вас нет root-доступа, вы можете разместить пользовательский файл php.ini в корневом каталоге вашего сайта (public_html). Откройте его через cPanel File Manager, FTP или SSH:

nano ~/public_html/php.ini

Добавьте или обновите директиву:

max_execution_time = 300

300 секунд (5 минут) достаточно для большинства операций. Для очень крупных миграций временно рассмотрите 600 секунд, а после завершения задачи верните прежнее значение.

Шаг 3: Убедитесь, что изменение вступило в силу

После сохранения повторно выполните проверку phpinfo() или команду WP-CLI из предыдущего шага. Если значение не изменилось, ваш хостинг-провайдер может применять жёсткий лимит через max_execution_time в серверном файле php.ini, который имеет приоритет над вашим пользовательским файлом. В этом случае перейдите к Методу 4.

Шаг 4: Перезапустите PHP-FPM (VPS и выделенные серверы)

На VPS или выделенном сервере, где вы управляете окружением, для применения изменений к веб-запросам требуется перезапуск PHP-FPM:

sudo systemctl restart php8.2-fpm

Замените php8.2-fpm на вашу установленную версию PHP. Apache с mod_php требует перезагрузки Apache вместо этого:

sudo systemctl reload apache2

Метод 2: Редактирование файла .htaccess (только Apache)

Метод .htaccess работает исключительно на серверах Apache, где AllowOverride разрешает директивы конфигурации PHP. Он не работает на Nginx, LiteSpeed с определёнными конфигурациями или в любом стеке, где PHP работает как FastCGI/FPM с AllowOverride None.

Шаг 1: Откройте файл .htaccess

Файл .htaccess по умолчанию скрыт. В cPanel File Manager нажмите Settings в правом верхнем углу и включите Show Hidden Files (dotfiles). Файл находится в public_html.

Через SSH:

nano ~/public_html/.htaccess

Шаг 2: Добавьте директиву PHP

Вставьте следующую строку. Расположение имеет значение — разместите её вне любого блока <IfModule>, чтобы она применялась глобально:

php_value max_execution_time 300

Если ваш сервер использует PHP-FPM (определяется по PHP/x.x.x (fpm-fcgi) в phpinfo()), эта директива вызовет 500 Internal Server Error, поскольку php_value недопустима в этом контексте. Используйте php_admin_value только если хостинг-провайдер явно это разрешает, или перейдите к Методу 1.

Шаг 3: Проверьте наличие ошибок 500

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

Метод 3: Редактирование wp-config.php с использованием set_time_limit()

Функция set_time_limit() сбрасывает таймер выполнения с момента её вызова. Это вызов PHP во время выполнения, а не директива конфигурации, что означает её работу независимо от того, разрешает ли сервер переопределения php.ini или .htaccess — при условии, что список disable_functions PHP не включает её.

Шаг 1: Найдите wp-config.php

Файл находится в корне установки WordPress, на один уровень выше public_html в некоторых конфигурациях сервера, или непосредственно внутри него в других.

find ~/public_html -maxdepth 2 -name "wp-config.php"

Шаг 2: Добавьте директиву

Откройте wp-config.php и добавьте следующую строку перед комментарием /* That's all, stop editing! Happy publishing. */:

set_time_limit(300);

Вызов set_time_limit(0) полностью отключает лимит для данного запроса. Используйте это только как временную диагностическую меру — никогда в продакшене — поскольку это убирает защиту от бесконечных циклов.

Важная оговорка: set_time_limit() влияет только на выполнение текущего скрипта. Это не изменяет общесерверную конфигурацию PHP. Если плагин внутренне порождает подпроцесс или выполняет блокирующий HTTP-запрос, этот подпроцесс не охватывается данным вызовом.

Метод 4: Использование плагина WordPress

Для пользователей, предпочитающих не редактировать серверные файлы напрямую, несколько плагинов предоставляют доступ к значениям конфигурации PHP через административный интерфейс WordPress. Этот подход подходит для нетехнических владельцев сайтов на управляемом хостинге.

Рекомендуемые варианты:

• WP Maximum Execution Time Exceeded — специально нацелен на эту ошибку и пытается применить несколько методов переопределения
• PHP Settings — предоставляет панельный просмотр активных PHP-директив и позволяет безопасно переопределять их там, где это разрешает хостинг-провайдер

Для установки: перейдите в Плагины > Добавить новый в панели управления WordPress, найдите плагин по названию, установите и активируйте. Следуйте странице настроек плагина для установки желаемого времени выполнения.

Ограничение: Плагины могут только вызывать set_time_limit() или ini_set() во время выполнения. Если хостинг-провайдер заблокировал max_execution_time через ограничения open_basedir или жёстко заданную конфигурацию сервера, плагин молча не сможет увеличить лимит. Всегда проверяйте изменение с помощью phpinfo() после активации.

Метод 5: Обратитесь к хостинг-провайдеру

Если ни один из вышеперечисленных методов не даёт подтверждённого изменения в выводе phpinfo(), лимит применяется на уровне сервера вашим хостинг-провайдером. Это распространено на начальных тарифах общего хостинга, где провайдер устанавливает жёсткий потолок для защиты общих ресурсов.

При обращении в службу поддержки предоставьте:

• Точное сообщение об ошибке и действие в WordPress, которое её вызывает
• Текущее значение max_execution_time из phpinfo()
• Необходимое вам значение (например, 300 секунд) и причину (например, крупный импорт WooCommerce)

Надёжные хостинг-провайдеры либо скорректируют лимит для вашего аккаунта, либо укажут на опцию в панели управления (например, PHP-селектор в cPanel), где вы сможете настроить его самостоятельно.

Сравнение всех пяти методов

Диагностика постоянных таймаутов после увеличения лимита

Если вы подтвердили, что новый лимит активен в phpinfo(), но ошибка сохраняется, узкое место, вероятно, не связано с max_execution_time. Рассмотрите следующие альтернативные причины:

Директивы таймаута FastCGI или Nginx — Nginx имеет собственную директиву fastcgi_read_timeout, отдельную от PHP:

fastcgi_read_timeout 300;

Это должно быть задано в серверном блоке Nginx и требует перезагрузки Nginx.

Директива TimeOut Apache — собственный таймаут соединения Apache может завершить запрос до достижения лимита PHP:

TimeOut 300

request_terminate_timeout PHP-FPM — в конфигурации пула PHP-FPM (/etc/php/8.x/fpm/pool.d/www.conf) эта директива независимо завершает рабочие процессы:

request_terminate_timeout = 300

wait_timeout и interactive_timeout MySQL — длительно выполняющиеся запросы к базе данных могут привести к разрыву соединения MySQL в середине выполнения, что PHP отображает как сбой скрипта, а не ошибку базы данных. Проверьте с помощью:

SHOW VARIABLES LIKE '%timeout%';

Таймауты на уровне WooCommerce или плагинов — некоторые плагины реализуют собственную внутреннюю логику таймаута с использованием set_time_limit() PHP с меньшим значением, что сбрасывает счётчик и может переопределить вашу конфигурацию.

Соображения о производительности и лучшие практики

Увеличение max_execution_time — это точечное исправление, а не постоянное архитектурное решение. Если конкретная операция регулярно превышает 30–60 секунд, базовый процесс следует оптимизировать или реструктурировать:

• Пакетная обработка: разбивайте крупные импорты на меньшие части с использованием AJAX-чанкинга (как это делает WP All Import нативно), а не обрабатывайте всё в одном HTTP-запросе
• Фоновая обработка: используйте WP-Cron или правильную очередь задач (Action Scheduler, используемый WooCommerce) для переноса длительных операций за пределы жизненного цикла веб-запроса
• WP-CLI для массовых операций: выполнение через CLI не подвержено таймаутам веб-сервера и является правильным инструментом для импорта баз данных, операций поиска и замены и массовой обработки медиафайлов
• Оптимизация медленных запросов: используйте плагин Query Monitor для выявления запросов к базе данных, потребляющих непропорционально большое время выполнения
• Переход на более высокий тариф хостинга: если ваша рабочая нагрузка постоянно требует расширенного времени выполнения, VPS с cPanel даёт вам полный контроль над конфигурацией PHP и выделенными ресурсами, не конкурирующими с другими арендаторами

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

Практический контрольный список

Используйте этот контрольный список до и после применения любого исправления:

• Подтвердите текущее значение max_execution_time через phpinfo() или WP-CLI перед внесением изменений
• Определите ваш серверный стек (Apache + mod_php, Apache + FPM, Nginx + FPM) перед выбором метода
• Применяйте только один метод за раз — одновременное внесение изменений в php.ini, .htaccess и wp-config.php делает отладку невозможной
• После применения изменения повторно проверьте активное значение в phpinfo() — не предполагайте, что изменение сработало
• Проверьте, воспроизведя исходное неудачное действие, а не просто загрузив главную страницу
• Если ошибка устранена, подумайте, можно ли оптимизировать базовую операцию для выполнения в пределах исходного лимита
• Установите напоминание в календаре для отмены любых временных увеличений лимита (например, set_time_limit(0)) после завершения разовой задачи
• На общем хостинге задокументируйте максимально допустимое значение для вашего тарифа, подтверждённое хостинг-провайдером
• Если таймауты сохраняются после подтверждения увеличения лимита PHP, проверьте fastcgi_read_timeout Nginx, TimeOut Apache и request_terminate_timeout PHP-FPM независимо друг от друга

FAQ

Какое значение max_execution_time наиболее безопасно устанавливать в WordPress?

300 секунд (5 минут) охватывает подавляющее большинство ресурсоёмких операций WordPress, включая установку крупных плагинов, импорт WooCommerce и обновление тем. Значения выше 600 секунд следует рассматривать как временные и отменять после завершения конкретной задачи.

Почему изменение max_execution_time не отображается в phpinfo() после редактирования php.ini?

Скорее всего, вы редактируете неправильный файл php.ini. PHP загружает разные файлы конфигурации для CLI, Apache mod_php и PHP-FPM. Выполните php -i | grep "Loaded Configuration File" для CLI и проверьте строку Loaded Configuration File на странице phpinfo(), доступной через браузер, чтобы определить правильный файл для веб-запросов.

Влияет ли увеличение max_execution_time на всех пользователей моего сервера?

На общем сервере редактирование пользовательского файла php.ini в корне вашего сайта влияет только на ваш аккаунт. Редактирование глобального серверного файла php.ini (требующее root-доступа) влияет на все PHP-процессы на этом сервере. На выделенном сервере вы управляете глобальной конфигурацией и несёте полную ответственность за её влияние.

Будет ли метод .htaccess работать на сервере Nginx?

Нет. Файл .htaccess является механизмом, специфичным для Apache. Nginx не обрабатывает файлы .htaccess. В стеках Nginx + PHP-FPM необходимо редактировать конфигурацию пула PHP-FPM или серверный файл php.ini, оба из которых требуют SSH-доступа.

Может ли плагин WordPress постоянно увеличить max_execution_time?

Нет. Плагины выполняются в среде выполнения PHP и могут только вызывать set_time_limit() или ini_set(), которые влияют только на текущий запрос. Они не могут записывать в php.ini или сохранять изменения конфигурации между запросами. Для постоянного увеличения необходимо изменить php.ini, .htaccess или файл конфигурации пула PHP-FPM на уровне сервера.