Jak naprawić błąd max_execution_time w WordPress

Błąd max_execution_time w WordPress występuje, gdy skrypt PHP przekracza maksymalny czas wykonania skonfigurowany na poziomie serwera. PHP kończy działanie skryptu i zwraca błąd krytyczny, który WordPress wyświetla jako biały ekran, komunikat o przekroczeniu limitu czasu lub wyraźny komunikat „Maximum execution time exceeded”.

Domyślnie większość środowisk hostingu współdzielonego wymusza limit 30 sekund. Operacje takie jak importowanie pliku CSV produktów WooCommerce, wykonywanie pełnej kopii zapasowej witryny lub instalowanie dużego pakietu wtyczek mogą łatwo przekroczyć ten limit. Zwiększenie limitu — poprzez php.ini, .htaccess, wp-config.php lub warstwę wtyczek WordPress — rozwiązuje błąd bez narażania stabilności serwera, jeśli zostanie wykonane prawidłowo.

Zrozumienie, dlaczego limit istnieje i kiedy staje się problemem

Dyrektywa max_execution_time PHP jest mechanizmem ochrony zasobów, a nie arbitralnym ograniczeniem. Zapobiega monopolizowaniu czasu CPU przez niekontrolowany skrypt w puli procesów współdzielonych, co jest szczególnie istotne w infrastrukturze wielodostępnej.

Limit staje się prawdziwą przeszkodą w następujących scenariuszach:

• Duże importy lub eksporty baz danych przez phpMyAdmin lub WP-CLI przetwarzające tysiące wierszy
• Instalacje wtyczek lub motywów rozpakowujące archiwa przekraczające 50 MB
• Operacje masowe WooCommerce — aktualizacje cen, synchronizacje stanów magazynowych, eksporty zamówień
• Pełne migracje witryn przy użyciu narzędzi takich jak Duplicator lub All-in-One WP Migration
• Zaplanowane zadania cron agregujące dane z zewnętrznych API
• Wtyczki do optymalizacji obrazów przetwarzające setki niezoptymalizowanych przesłanych plików w jednej partii

Istotna kwestia, którą większość poradników pomija: max_execution_time mierzy czas CPU zużyty przez proces PHP, a nie czas rzeczywisty. Na mocno obciążonym serwerze skrypt może działać przez 90 sekund w czasie rzeczywistym, zużywając jedynie 28 sekund czasu CPU i nigdy nie przekroczyć limitu. Z drugiej strony, pętla intensywnie wykorzystująca CPU osiąga limit szybciej niż oczekiwano. To rozróżnienie ma znaczenie przy diagnozowaniu sporadycznych przekroczeń limitu czasu.

Jak sprawdzić aktualną wartość max_execution_time

Przed wprowadzeniem jakichkolwiek zmian potwierdź aktywny limit. Utwórz tymczasowy plik w katalogu głównym WordPress — nigdy nie pozostawiaj go publicznie dostępnego po testach:

<?php
phpinfo();

Prześlij go jako phpinfo-test.php, odwiedź https://yourdomain.com/phpinfo-test.php i wyszukaj max_execution_time w wynikach. Usuń plik natychmiast po sprawdzeniu.

Alternatywnie użyj WP-CLI przez SSH:

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

Zwraca to wartość aktualnie aktywną dla żądań WordPress, która może różnić się od globalnego php.ini serwera, jeśli nadpisanie dla konkretnego katalogu jest już zastosowane.

Metoda 1: Edycja pliku php.ini (najbardziej niezawodna)

Modyfikacja php.ini jest najbardziej autorytatywną metodą, ponieważ ustawia dyrektywę na poziomie interpretera PHP, nie nadpisując niczego i nie będąc nadpisywaną przez nic poniżej w hierarchii konfiguracji — chyba że późniejsze wywołanie ini_set() zastąpi ją w czasie wykonywania.

Krok 1: Zlokalizuj właściwy plik php.ini

Tu większość administratorów popełnia błąd. PHP może ładować wiele plików .ini w zależności od używanego SAPI (Server API):

• CLI SAPI (/etc/php/8.x/cli/php.ini) — używany przez WP-CLI i zadania cron
• FPM SAPI (/etc/php/8.x/fpm/php.ini) — używany przez stosy Nginx + PHP-FPM
• Apache mod_php (/etc/php/8.x/apache2/php.ini) — używany przez Apache z modułem PHP

Edycja CLI php.ini rozwiąże przekroczenia limitu czasu WP-CLI, ale nie wpłynie na żądania wyzwalane przez przeglądarkę. Zawsze najpierw zidentyfikuj właściwy SAPI:

php -i | grep "Loaded Configuration File"

W przypadku żądań webowych sprawdź wynik phpinfo() w sekcji Loaded Configuration File.

Krok 2: Edytuj lub utwórz php.ini w katalogu głównym witryny

Na hostingu współdzielonym, gdzie nie masz dostępu root, możesz umieścić php.ini na poziomie użytkownika w katalogu głównym swojej witryny (public_html). Uzyskaj do niego dostęp przez Menedżer plików cPanel, FTP lub SSH:

nano ~/public_html/php.ini

Dodaj lub zaktualizuj dyrektywę:

max_execution_time = 300

300 sekund (5 minut) wystarczy dla większości operacji. W przypadku bardzo dużych migracji rozważ tymczasowe ustawienie 600 sekund, a następnie przywróć poprzednią wartość po zakończeniu zadania.

Krok 3: Sprawdź, czy zmiana została zastosowana

Po zapisaniu ponownie uruchom sprawdzenie phpinfo() lub wcześniejsze polecenie WP-CLI. Jeśli wartość nie uległa zmianie, Twój host może wymuszać twardy limit przez max_execution_time w php.ini na poziomie serwera, który nadpisuje Twój plik na poziomie użytkownika. W takim przypadku przejdź do Metody 4.

Krok 4: Uruchom ponownie PHP-FPM (VPS i serwery dedykowane)

Na VPS lub serwerze dedykowanym, gdzie kontrolujesz środowisko, wymagane jest ponowne uruchomienie PHP-FPM, aby zmiana została zastosowana do żądań webowych:

sudo systemctl restart php8.2-fpm

Zastąp php8.2-fpm zainstalowaną wersją PHP. Apache z mod_php wymaga zamiast tego przeładowania Apache:

sudo systemctl reload apache2

Metoda 2: Edycja pliku .htaccess (tylko Apache)

Metoda .htaccess działa wyłącznie na serwerach Apache, gdzie AllowOverride zezwala na dyrektywy konfiguracji PHP. Nie działa na Nginx, LiteSpeed z określonymi konfiguracjami ani na żadnym stosie, gdzie PHP działa jako FastCGI/FPM z AllowOverride None.

Krok 1: Ujawnij i uzyskaj dostęp do pliku .htaccess

Plik .htaccess jest domyślnie ukryty. W Menedżerze plików cPanel kliknij Ustawienia w prawym górnym rogu i włącz Pokaż ukryte pliki (dotfiles). Plik znajduje się w public_html.

Przez SSH:

nano ~/public_html/.htaccess

Krok 2: Dodaj dyrektywę PHP

Wstaw następującą linię. Pozycja ma znaczenie — umieść ją poza blokiem <IfModule>, aby zapewnić globalne zastosowanie:

php_value max_execution_time 300

Jeśli Twój serwer używa PHP-FPM (rozpoznawalnego po PHP/x.x.x (fpm-fcgi) w phpinfo()), ta dyrektywa spowoduje błąd 500 Internal Server Error, ponieważ php_value nie jest prawidłowe w tym kontekście. Używaj php_admin_value tylko jeśli host wyraźnie na to zezwala lub przejdź do Metody 1.

Krok 3: Sprawdź błędy 500

Po zapisaniu natychmiast załaduj stronę główną. Błąd 500 oznacza, że dyrektywa jest niezgodna z konfiguracją serwera. Usuń linię i użyj alternatywnej metody.

Metoda 3: Edycja wp-config.php przy użyciu set_time_limit()

Funkcja set_time_limit() resetuje licznik czasu wykonania od momentu jej wywołania. Jest to wywołanie środowiska uruchomieniowego PHP, a nie dyrektywa konfiguracyjna, co oznacza, że działa niezależnie od tego, czy serwer zezwala na nadpisania php.ini lub .htaccess — o ile lista disable_functions PHP jej nie zawiera.

Krok 1: Zlokalizuj wp-config.php

Plik znajduje się w katalogu głównym instalacji WordPress, o jeden poziom powyżej public_html w niektórych konfiguracjach serwera lub bezpośrednio w nim w innych.

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

Krok 2: Dodaj dyrektywę

Otwórz wp-config.php i dodaj następującą linię przed komentarzem /* That's all, stop editing! Happy publishing. */:

set_time_limit(300);

Wywołanie set_time_limit(0) całkowicie wyłącza limit dla danego żądania. Używaj tego wyłącznie jako tymczasowego środka diagnostycznego — nigdy w środowisku produkcyjnym — ponieważ usuwa zabezpieczenie przed nieskończonymi pętlami.

Ważne zastrzeżenie: set_time_limit() wpływa tylko na bieżące wykonanie skryptu. Nie zmienia ogólnosystemowej konfiguracji PHP. Jeśli wtyczka wewnętrznie uruchamia podproces lub wykonuje blokujące żądanie HTTP, ten podproces nie jest objęty tym wywołaniem.

Metoda 4: Użycie wtyczki WordPress

Dla użytkowników, którzy wolą nie edytować bezpośrednio plików serwera, kilka wtyczek udostępnia wartości konfiguracji PHP przez interfejs administracyjny WordPress. To podejście jest odpowiednie dla nietech­nicznych właścicieli witryn na hostingu zarządzanym.

Zalecane opcje:

• WP Maximum Execution Time Exceeded — celuje konkretnie w ten błąd i próbuje wielu metod nadpisania
• PHP Settings — zapewnia widok panelu aktywnych dyrektyw PHP i umożliwia bezpieczne nadpisania tam, gdzie host na to zezwala

Aby zainstalować: przejdź do Wtyczki > Dodaj nową w panelu WordPress, wyszukaj nazwę wtyczki, zainstaluj i aktywuj. Postępuj zgodnie ze stroną ustawień wtyczki, aby ustawić żądany czas wykonania.

Ograniczenie: Wtyczki mogą wywoływać tylko set_time_limit() lub ini_set() w czasie wykonywania. Jeśli host zablokował max_execution_time przez ograniczenia open_basedir lub zakodowaną konfigurację serwera, wtyczka po cichu nie zwiększy limitu. Zawsze weryfikuj zmianę używając phpinfo() po aktywacji.

Metoda 5: Skontaktuj się z dostawcą hostingu

Jeśli żadna z powyższych metod nie przynosi zweryfikowanej zmiany w wynikach phpinfo(), limit jest wymuszany na poziomie serwera przez Twojego hosta. Jest to powszechne w przypadku podstawowych planów hostingu współdzielonego, gdzie dostawca ustawia twardy limit w celu ochrony zasobów współdzielonych.

Kontaktując się z pomocą techniczną, podaj:

• Dokładny komunikat błędu i akcję WordPress, która go wyzwala
• Aktualną wartość max_execution_time z phpinfo()
• Wartość, której potrzebujesz (np. 300 sekund) i powód (np. duży import WooCommerce)

Renomowani hostodawcy albo dostosują limit dla Twojego konta, albo wskażą opcję w panelu sterowania (np. selektor PHP w cPanel), gdzie możesz samodzielnie go skonfigurować.

Porównanie wszystkich pięciu metod

Diagnozowanie utrzymujących się przekroczeń limitu czasu po zwiększeniu limitu

Jeśli potwierdziłeś, że nowy limit jest aktywny w phpinfo(), ale błąd nadal występuje, wąskim gardłem prawdopodobnie nie jest max_execution_time. Rozważ następujące alternatywne przyczyny:

Dyrektywy timeout FastCGI lub Nginx — Nginx ma własną dyrektywę fastcgi_read_timeout, niezależną od PHP:

fastcgi_read_timeout 300;

Musi być ustawiona w bloku serwera Nginx i wymaga przeładowania Nginx.

Dyrektywa TimeOut Apache — własny limit czasu połączenia Apache może zakończyć żądanie przed osiągnięciem limitu PHP:

TimeOut 300

request_terminate_timeout PHP-FPM — w konfiguracji puli PHP-FPM (/etc/php/8.x/fpm/pool.d/www.conf) ta dyrektywa niezależnie kończy procesy robocze:

request_terminate_timeout = 300

wait_timeout i interactive_timeout MySQL — długo działające zapytania do bazy danych mogą spowodować przerwanie połączenia MySQL w trakcie wykonywania, co PHP wyświetla jako błąd skryptu, a nie błąd bazy danych. Sprawdź za pomocą:

SHOW VARIABLES LIKE '%timeout%';

Limity czasu WooCommerce lub na poziomie wtyczek — niektóre wtyczki implementują własną wewnętrzną logikę limitu czasu używając set_time_limit() PHP z niższą wartością, co resetuje licznik i może nadpisać Twoją konfigurację.

Kwestie wydajności i najlepsze praktyki

Zwiększenie max_execution_time jest ukierunkowaną poprawką, a nie trwałym rozwiązaniem architektonicznym. Jeśli konkretna operacja rutynowo przekracza 30–60 sekund, bazowy proces powinien zostać zoptymalizowany lub przebudowany:

• Przetwarzanie wsadowe: Podziel duże importy na mniejsze fragmenty używając fragmentowania opartego na AJAX (jak robi to natywnie WP All Import), zamiast przetwarzać wszystko w jednym żądaniu HTTP
• Przetwarzanie w tle: Używaj WP-Cron lub właściwej kolejki zadań (Action Scheduler, używany przez WooCommerce), aby przenieść długotrwałą pracę poza cykl życia żądania webowego
• WP-CLI do operacji masowych: Wykonywanie przez CLI nie podlega limitom czasu serwera webowego i jest właściwym narzędziem do importów baz danych, operacji wyszukiwania i zamiany oraz masowego przetwarzania mediów
• Optymalizacja wolnych zapytań: Używaj wtyczki Query Monitor do identyfikacji zapytań do bazy danych zużywających nieproporcjonalnie dużo czasu wykonania
• Ulepszenie planu hostingowego: Jeśli Twoje obciążenie konsekwentnie wymaga wydłużonego czasu wykonania, VPS z cPanel daje Ci pełną kontrolę nad konfiguracją PHP i dedykowanymi zasobami, które nie konkurują z innymi użytkownikami

W przypadku obciążeń wymagających dużej mocy obliczeniowej, takich jak rekomendacje produktów oparte na AI lub potoki przetwarzania obrazów na dużą skalę, hosting GPU całkowicie przenosi intensywne obliczenia poza warstwę PHP.

Praktyczna lista kontrolna decyzji

Użyj tej listy kontrolnej przed i po zastosowaniu jakiejkolwiek poprawki:

• Potwierdź aktualną wartość max_execution_time przez phpinfo() lub WP-CLI przed wprowadzeniem zmian
• Zidentyfikuj stos serwera (Apache + mod_php, Apache + FPM, Nginx + FPM) przed wyborem metody
• Stosuj tylko jedną metodę na raz — jednoczesne wprowadzanie zmian w php.ini, .htaccess i wp-config.php uniemożliwia debugowanie
• Po zastosowaniu zmiany ponownie zweryfikuj aktywną wartość w phpinfo() — nie zakładaj, że zmiana zadziałała
• Przetestuj, odtwarzając oryginalną nieudaną akcję, a nie tylko ładując stronę główną
• Jeśli błąd zostanie rozwiązany, rozważ, czy bazową operację można zoptymalizować, aby działała w ramach pierwotnego limitu
• Ustaw przypomnienie w kalendarzu, aby przywrócić wszelkie tymczasowe zwiększenia limitu (np. set_time_limit(0)) po zakończeniu jednorazowego zadania
• Na hostingu współdzielonym udokumentuj, co host potwierdził jako maksymalną dopuszczalną wartość dla Twojego planu
• Jeśli przekroczenia limitu czasu utrzymują się po potwierdzeniu zwiększenia limitu PHP, sprawdź niezależnie fastcgi_read_timeout Nginx, TimeOut Apache i request_terminate_timeout PHP-FPM

FAQ

Jaka jest najbezpieczniejsza wartość max_execution_time w WordPress?

300 sekund (5 minut) obejmuje zdecydowaną większość zasobochłonnych operacji WordPress, w tym duże instalacje wtyczek, importy WooCommerce i aktualizacje motywów. Wartości powyżej 600 sekund powinny być traktowane jako tymczasowe i przywrócone po zakończeniu konkretnego zadania.

Dlaczego moja zmiana max_execution_time nie pojawia się w phpinfo() po edycji php.ini?

Najprawdopodobniej edytujesz niewłaściwy plik php.ini. PHP ładuje różne pliki konfiguracyjne dla CLI, Apache mod_php i PHP-FPM. Uruchom php -i | grep "Loaded Configuration File" dla CLI i sprawdź wiersz Loaded Configuration File na dostępnej przez przeglądarkę stronie phpinfo(), aby zidentyfikować właściwy plik dla żądań webowych.

Czy zwiększenie max_execution_time wpływa na wszystkich użytkowników mojego serwera?

Na serwerze współdzielonym edycja php.ini na poziomie użytkownika w katalogu głównym witryny wpływa tylko na Twoje konto. Edycja globalnego php.ini serwera (która wymaga dostępu root) wpływa na wszystkie procesy PHP na tym serwerze. Na serwerze dedykowanym kontrolujesz globalną konfigurację i ponosisz pełną odpowiedzialność za jej wpływ.

Czy metoda .htaccess będzie działać na serwerze Nginx?

Nie. Plik .htaccess jest mechanizmem specyficznym dla Apache. Nginx nie przetwarza plików .htaccess. Na stosach Nginx + PHP-FPM musisz edytować konfigurację puli PHP-FPM lub php.ini na poziomie serwera, co wymaga dostępu SSH.

Czy wtyczka WordPress może trwale zwiększyć max_execution_time?

Nie. Wtyczki wykonują się w środowisku uruchomieniowym PHP i mogą wywoływać tylko set_time_limit() lub ini_set(), które wpływają wyłącznie na bieżące żądanie. Nie mogą zapisywać do php.ini ani utrwalać zmian konfiguracji między żądaniami. Aby trwale zwiększyć limit, musisz zmodyfikować php.ini, .htaccess lub plik konfiguracji puli PHP-FPM na poziomie serwera.