Як виправити помилку 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 — це механізм захисту ресурсів, а не довільне обмеження. Вона запобігає тому, щоб скрипт, що вийшов з-під контролю, монополізував час CPU у спільному пулі процесів, що особливо критично в багатоорендній інфраструктурі.

Ліміт стає реальною перешкодою в таких сценаріях:

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

Критичний нюанс, який більшість посібників не згадує: max_execution_time вимірює час CPU, витрачений PHP-процесом, а не реальний час. На сильно завантаженому сервері скрипт може виконуватися 90 реальних секунд, витративши лише 28 секунд CPU, і ніколи не досягти ліміту. Натомість CPU-інтенсивний цикл досягає ліміту швидше, ніж очікується. Ця відмінність важлива при діагностиці переривчастих тайм-аутів.

Як перевірити поточне значення 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 та виділеними ресурсами, які не конкурують з іншими орендарями

Для обчислювально інтенсивних навантажень, таких як рекомендації товарів на основі ШІ або великомасштабні конвеєри обробки зображень, 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 на рівні сервера.