Błąd „Maximum Execution Time Exceeded” oznacza, że skrypt PHP działał dłużej niż pozwalała konfiguracja serwera. Najszybszym rozwiązaniem jest zwiększenie wartości max_execution_time, zwykle do 300 sekund, ale traktuj to jako działanie tymczasowe. Jeśli problem powoduje ciężka wtyczka, motyw albo przeciążona baza danych, sam wyższy limit tylko odsunie awarię.
Dlaczego pojawia się błąd Maximum Execution Time Exceeded?
PHP ma limit czasu wykonywania pojedynczego skryptu. Gdy operacja nie zakończy się przed jego upływem, środowisko PHP przerywa działanie procesu. To mechanizm ochronny, który ma zapobiegać sytuacji, w której jeden skrypt długo zajmuje procesor, pamięć lub inne zasoby serwera.
Wartość domyślna często wynosi około 30 sekund, ale zależy od wersji PHP i konfiguracji hostingu. Sam komunikat nie oznacza trwałego uszkodzenia WordPressa. Pojawia się najczęściej podczas importu danych, aktualizacji, tworzenia kopii zapasowej, masowej obróbki obrazów albo pracy wtyczki wykonującej ciężkie zapytania do bazy.
Najczęstsze źródła problemu to:
- rozbudowana lub wadliwa wtyczka wykonująca długą operację,
- motyw generujący kosztowne zapytania albo obliczenia,
- duża baza danych z nadmiarem metadanych, wersji wpisów lub transientów,
- import, migracja, kopia zapasowa albo masowa optymalizacja plików,
- niewystarczające zasoby hostingu współdzielonego.
Jak zwiększyć max execution time w WordPress?
Przed zmianą konfiguracji wykonaj kopię zapasową pliku, który będziesz edytować, oraz całej witryny. Pobierz oryginalny plik przez FTP lub menedżer plików hostingu. Jeśli po zapisaniu zmian strona przestanie działać, przywróć wcześniejszą wersję albo usuń dodaną linię. Nie ustawiaj od razu wartości rzędu 3600 sekund, ponieważ może to długo utrzymywać przeciążony proces.
Poniższa tabela pokazuje, czym różnią się podstawowe metody:
| Metoda | Łatwość | Zalety | Wady |
|---|---|---|---|
.htaccess |
Średnia | Zmiana może objąć skrypty domeny | Nie działa na każdym serwerze, szczególnie przy innej konfiguracji PHP |
wp-config.php |
Łatwa | Plik znajduje się w katalogu WordPressa | Nie każdy hosting pozwala zmienić limit z poziomu kodu |
php.ini lub .user.ini |
Średnia | Ustawienie jest związane z konfiguracją PHP | Dostęp i dozwolona wartość zależą od hostingu |
Wybierz metodę zgodną z konfiguracją serwera:
- Sprawdź plik
.user.ini. Otwórz główny katalog instalacji WordPressa przez FTP. Jeśli plik istnieje, dodaj lub zmień wpismax_execution_time = 300. Jeśli go nie ma, możesz go utworzyć, o ile hosting pozwala na lokalne ustawienia PHP. - Edytuj
wp-config.php. Wykonaj kopię pliku, a następnie dodaj przed komentarzem/* That's all, stop editing! */linięset_time_limit(300);. Zapisz plik i sprawdź, czy operacja, która wywoływała błąd, kończy się poprawnie. - Użyj pliku
.htaccess. Jeżeli serwer obsługuje tę dyrektywę, dodaj wpisphp_value max_execution_time 300. Błąd konfiguracji może spowodować błąd serwera, dlatego przy problemach natychmiast przywróć kopię oryginalnego pliku. - Skonfiguruj
php.ini. Jeśli masz dostęp do tego pliku, ustawmax_execution_time = 300. Na hostingu współdzielonym plik może być niedostępny, a administrator może narzucać maksymalną wartość.
Limit 300 sekund daje skryptowi pięć minut na zakończenie. Nie jest jednak uniwersalną wartością dla każdego serwera. Niektórzy operatorzy ograniczają ten parametr odgórnie, a zmiana w pliku może zostać zignorowana.
Jak znaleźć wtyczkę lub motyw powodujący problem?
Jeśli błąd pojawia się po konkretnej czynności, na przykład imporcie, aktualizacji albo uruchomieniu generatora kopii, zacznij od komponentu używanego podczas tej operacji. Gdy nie masz dostępu do kokpitu, wtyczki można wyłączyć przez zmianę nazwy katalogu wp-content/plugins za pomocą FTP. Po odzyskaniu dostępu przywróć nazwę katalogu i przeprowadź testy.
Przejdź przez tę kolejność diagnostyczną:
- Wyłącz wszystkie wtyczki i sprawdź, czy błąd nadal występuje.
- Włączaj rozszerzenia pojedynczo, wykonując po każdym tę samą operację.
- Przełącz motyw na aktualny motyw domyślny, aby wykluczyć problem w jego kodzie.
- Sprawdź tryb Recovery Mode i wiadomość wysłaną przez WordPress po błędzie krytycznym.
- Przejrzyj logi PHP oraz serwera, a ciężkie zapytania przeanalizuj w Query Monitor.
Po znalezieniu winowajcy zaktualizuj go, skonfiguruj ponownie, zastąp inną wtyczką albo skontaktuj się z jej autorem. Jeśli błąd powraca mimo wyłączenia rozszerzeń, poproś hosting o sprawdzenie logów, obciążenia CPU, pamięci i operacji wejścia-wyjścia.
Jak zapobiegać przekroczeniu limitu?
Podniesienie limitu pozwala dokończyć pojedynczą operację, ale nie przyspiesza kodu. Długofalowo zmniejsz obciążenie witryny:
- Usuwaj nieużywane, porzucone i dublujące się wtyczki.
- Czyść bazę danych z wersji wpisów, autozapisów, spamu i wygasłych transientów.
- Kompresuj obrazy przed wysłaniem i ograniczaj generowanie zbędnych rozmiarów miniatur.
- Włącz pamięć podręczną strony, obiektów lub zapytań, jeśli hosting i konfiguracja WordPressa to umożliwiają.
- Testuj duże aktualizacje, importy i migracje na kopii witryny przed wykonaniem ich na produkcji.
- Aktualizuj WordPress, motyw oraz wtyczki, ale przed aktualizacją wykonuj kopię zapasową.
Kiedy problemem jest hosting?
Na hostingu współdzielonym zasoby są dzielone między wiele stron. Dostawca może też narzucać maksymalny czas wykonywania, którego nie zmienisz przez wp-config.php, .htaccess ani .user.ini. W takiej sytuacji skontaktuj się z pomocą techniczną i zapytaj o dozwoloną wartość oraz przyczynę przerwania skryptu.
Jeśli timeouty występują regularnie mimo wyłączenia problematycznych wtyczek i optymalizacji bazy, rozważ wydajniejszy plan, VPS albo zarządzany hosting WordPress. Większy przydział CPU, pamięci i szybszy dysk mogą skrócić czas operacji, ale sama zmiana serwera nie naprawi wadliwego kodu. Najpierw ustal, czy problem występuje przy jednej funkcji, czy podczas zwykłego działania całej witryny.
Zwiększenie max_execution_time do 300 sekund zwykle szybko usuwa komunikat, lecz trwała poprawa wymaga znalezienia operacji, która przekracza limit. Zacznij od kopii zapasowej, sprawdź wtyczki i logi, a dopiero potem podejmuj decyzję o zmianie konfiguracji lub hostingu.
