„Maximum execution time exceeded”. Co oznacza ten błąd i jak go rozwiązać?

Komunikat „Maximum execution time exceeded” pojawia się zwykle w najmniej wygodnej chwili: podczas aktualizacji wtyczek, importu produktów do sklepu, tworzenia kopii zapasowej albo zapisywania długiej strony w edytorze. Operacja urywa się w połowie, a na ekranie zostaje angielskie zdanie o przekroczonym czasie. Dla właściciela firmy, który sam opiekuje się swoją stroną na WordPressie, wygląda to groźnie, choć w większości przypadków da się to naprawić w kilkanaście minut.

Ten tekst jest instrukcją dla osób, które nie są programistami, ale mają dostęp do kokpitu WordPressa i do panelu hostingu. Opisuję w nim, co ten błąd naprawdę oznacza, jak ustalić, co trwało zbyt długo, w jaki sposób bezpiecznie wydłużyć limit czasu i kiedy samo wydłużenie nie wystarczy.

Po lekturze czytelnik będzie umiał odczytać komunikat, sprawdzić aktualny limit na swoim serwerze, zmienić go jedną z czterech metod, a także rozpoznać sytuację, w której problem leży w konkretnej wtyczce albo w ustawieniach hostingu, a nie w samym limicie.

Co oznacza komunikat „Maximum execution time exceeded”?

WordPress jest napisany w języku PHP. Każde wyświetlenie strony i każda czynność w kokpicie to uruchomienie skryptu PHP na serwerze. Serwer pilnuje, żeby żaden skrypt nie pracował w nieskończoność, i w tym celu stosuje ustawienie o nazwie max_execution_time. Jest to największa dopuszczalna liczba sekund pracy jednego skryptu.

Według dokumentacji PHP wartość domyślna tego ustawienia to 30 sekund. Gdy skrypt przekroczy limit, PHP przerywa go i zgłasza błąd krytyczny. Pełna treść komunikatu wygląda zazwyczaj tak: Fatal error: Maximum execution time of 30 seconds exceeded in /wp-content/plugins/nazwa-wtyczki/plik.php on line 120. Liczba sekund w komunikacie to limit obowiązujący na danym serwerze, więc zamiast 30 może tam być 60, 120 albo inna wartość.

Limit nie jest usterką. To zabezpieczenie, które chroni serwer przed źle napisanym kodem i przed zablokowaniem zasobów przez jedną operację. Błąd oznacza tylko tyle, że jakaś czynność potrzebowała więcej czasu, niż serwer jej przyznał. Pytanie brzmi: czy to czynność była uzasadniona i limit jest zbyt niski, czy też limit jest rozsądny, a coś w witrynie działa zbyt wolno.

Co wlicza się do limitu, a co nie?

Dokumentacja PHP zaznacza rzecz, o której mało kto wie. Na serwerach innych niż Windows do limitu liczy się wyłącznie czas pracy samego skryptu. Czas oczekiwania na odpowiedź bazy danych, na połączenie z innym serwerem czy na operacje na strumieniach danych nie jest wliczany. Na serwerach z systemem Windows mierzony jest czas rzeczywisty.

W praktyce oznacza to dwie rzeczy. Po pierwsze, strona może ładować się dłużej niż wynosi limit i mimo to nie wywołać tego błędu, bo większość czasu zajęło czekanie na bazę danych. Po drugie, jeżeli komunikat jednak się pojawia, to znaczy, że serwer przez cały limit intensywnie przetwarzał kod PHP. To wskazówka, że przyczyną jest ciężka operacja albo pętla w kodzie, a nie chwilowo wolne łącze.

Czym jest drugi limit: max_input_time?

Obok czasu wykonywania istnieje ustawienie max_input_time. Określa ono, ile sekund skrypt może poświęcić na odebranie przesyłanych danych, na przykład dużego pliku wgrywanego przez formularz. Domyślna wartość to -1, co według dokumentacji oznacza, że w tej roli używany jest limit max_execution_time. Przy wgrywaniu dużych plików importu oba ustawienia warto więc podnosić razem.

Po czym rozpoznać ten błąd, gdy komunikat się nie wyświetla?

Na wielu serwerach wyświetlanie błędów PHP jest wyłączone, i słusznie, bo odwiedzający nie powinni widzieć ścieżek do plików. Wtedy zamiast angielskiego zdania widać jeden z kilku innych objawów, a właściwy komunikat trafia tylko do dziennika błędów.

• Ekran z napisem „W witrynie wystąpił błąd krytyczny”. WordPress przechwytuje błędy krytyczne i wysyła na adres administratora wiadomość z nazwą wtyczki lub motywu, który zawiódł, oraz z odnośnikiem do trybu odzyskiwania.
• Pusta, biała strona bez żadnej treści.
• Aktualizacja, import albo tworzenie kopii zapasowej zatrzymuje się zawsze w podobnym miejscu, a pasek postępu przestaje się przesuwać.
• Komunikat o nieudanej aktualizacji lub o nieudanym zapisie w edytorze, mimo że połączenie z internetem działa.
• Błąd 500 albo 504 zwracany przez serwer zamiast strony.

Żaden z tych objawów nie przesądza jeszcze o przyczynie, bo podobnie wygląda na przykład brak pamięci. Pewność daje dopiero wpis w dzienniku błędów zawierający słowa „Maximum execution time”. Jeżeli na ekranie widać wyłącznie ogólny ekran błędu, pomocny będzie osobny tekst o tym, jak znaleźć wtyczkę, która wywołała błąd krytyczny.

Jakie czynności najczęściej przekraczają limit czasu?

Z mojej praktyki wynika, że ten błąd rzadko pojawia się przy zwykłym przeglądaniu strony. Niemal zawsze towarzyszy jednej z kilku ciężkich operacji, które z natury trwają długo.

• Import dużego pliku: produktów do sklepu, wpisów z innej witryny, gotowej zawartości motywu.
• Tworzenie lub przywracanie kopii zapasowej, szczególnie gdy wtyczka pakuje całą witrynę w jednym przebiegu.
• Aktualizacja wielu wtyczek naraz albo aktualizacja bazy danych po dużej zmianie wersji wtyczki.
• Masowe przetwarzanie obrazów, na przykład ponowne tworzenie miniatur lub optymalizacja całej biblioteki mediów.
• Zapis bardzo rozbudowanej strony w kreatorze stron albo skanowanie całej witryny przez wtyczkę bezpieczeństwa.

Druga grupa przyczyn to nie sama operacja, lecz warunki, w jakich przebiega. Przeciążony serwer na współdzielonym hostingu, przestarzała wersja PHP, rozrośnięta baza danych albo wtyczka z błędem, która wpada w pętlę, sprawiają, że nawet umiarkowana czynność nie mieści się w limicie. W takim przypadku wydłużanie czasu tylko odsuwa problem.

Jak sprawdzić, jaki limit obowiązuje na serwerze?

Zanim cokolwiek zostanie zmienione, trzeba znać punkt wyjścia. Najprościej odczytać go z samego komunikatu błędu, ale jeśli komunikat nie jest widoczny, WordPress pokazuje tę wartość w kokpicie.

1. Po zalogowaniu do kokpitu należy przejść do menu „Narzędzia” i wybrać pozycję „Stan witryny”.
2. Na górze ekranu trzeba przełączyć się z karty „Status” na kartę „Informacje”.
3. Na liście sekcji należy rozwinąć sekcję „Serwer”.
4. W rozwiniętej sekcji widać między innymi wersję PHP, limit czasu PHP, maksymalny czas wprowadzania danych i limit pamięci. Wartość limitu czasu warto zanotować.
5. Po każdej późniejszej zmianie ustawień należy wrócić w to samo miejsce i porównać wartość z zanotowaną.

Gdy kokpit jest niedostępny, tę samą wartość pokazuje panel hostingu w części poświęconej ustawieniom PHP. Nazwa tej części zależy od dostawcy, dlatego w razie wątpliwości najlepiej poszukać jej w pomocy hostingu pod hasłem max_execution_time.

Jak ustalić, co dokładnie trwało zbyt długo?

To najważniejsza część całej naprawy. Bez niej podnoszenie limitu jest działaniem bez rozeznania. Źródłem informacji jest ścieżka do pliku podana w komunikacie błędu. Jeżeli zawiera fragment /wp-content/plugins/, to następna nazwa katalogu jest nazwą wtyczki. Fragment /wp-content/themes/ wskazuje motyw, a /wp-includes/ lub /wp-admin/ samo jądro WordPressa.

Jedno zastrzeżenie: plik z komunikatu to miejsce, w którym skrypt znajdował się w chwili upływu czasu. Nie zawsze jest to źródło problemu. Jeśli wskazany jest plik jądra WordPressa, zwykle oznacza to, że jakaś wtyczka zleciła mu bardzo dużo pracy. Dlatego obok ścieżki trzeba brać pod uwagę to, jaka czynność była właśnie wykonywana.

Jak włączyć dziennik błędów WordPressa?

Jeżeli komunikat nie pokazuje się na ekranie, trzeba go zapisać do pliku. Służy do tego tryb diagnostyczny opisany w dokumentacji WordPressa. Wymaga on edycji pliku wp-config.php, dlatego przed zmianą należy pobrać jego kopię na dysk.

1. Należy połączyć się z serwerem przez menedżer plików w panelu hostingu albo przez program FTP i otworzyć katalog główny witryny.
2. Plik wp-config.php trzeba pobrać na komputer jako kopię, a następnie otworzyć do edycji.
3. Przed wierszem z komentarzem /* That's all, stop editing! */ wkleja się trzy wiersze podane poniżej. Jeśli wiersz z WP_DEBUG już w pliku istnieje, należy zmienić jego wartość, zamiast dopisywać drugi.
4. Po zapisaniu pliku trzeba powtórzyć czynność, która kończyła się błędem.
5. W katalogu wp-content pojawi się plik debug.log. Należy go otworzyć i odszukać wiersz ze słowami „Maximum execution time”.
6. Po zakończeniu diagnozy wartość WP_DEBUG trzeba przywrócić na false, a plik debug.log usunąć z serwera, ponieważ zawiera ścieżki do plików witryny.

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

Trzeci wiersz sprawia, że błędy nie wyświetlają się odwiedzającym, a jedynie trafiają do pliku. Na stronie, która działa i przyjmuje klientów, to ustawienie jest obowiązkowe. Wielu dostawców hostingu prowadzi też własny dziennik błędów PHP dostępny w panelu i wtedy edycja pliku nie jest potrzebna.

Co zrobić, gdy dziennik nie wskazuje jednej wtyczki?

Wtedy pozostaje metoda kolejnego wyłączania. W kokpicie, w menu „Wtyczki”, wyłącza się wszystkie wtyczki poza tą, która jest niezbędna do wykonania danej operacji, i powtarza się czynność. Jeżeli błąd zniknął, wtyczki włącza się pojedynczo, za każdym razem ponawiając próbę, aż błąd wróci. Ostatnio włączona wtyczka jest tą, która wydłuża operację ponad limit.

Gdy kokpit nie działa, to samo da się zrobić przez FTP: w katalogu /wp-content/plugins/ zmienia się nazwę katalogu podejrzanej wtyczki, na przykład przez dopisanie na końcu słowa „-wylaczona”. WordPress przestaje ją wtedy wczytywać. Przywrócenie pierwotnej nazwy pozwala włączyć ją ponownie w kokpicie. Na sklepie internetowym takie próby radzę przeprowadzać poza godzinami największego ruchu.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl. Przejmę sprawę: odczytam dziennik błędów, ustalę, która operacja lub wtyczka przekracza czas, i ustawię limit na serwerze tak, żeby strona znów działała bez przerw.

Jak wydłużyć limit czasu wykonywania skryptu?

Istnieją cztery drogi. Podaję je w kolejności od najbezpieczniejszej. Wystarczy jedna skuteczna, nie należy stosować wszystkich jednocześnie, bo później trudno ustalić, które ustawienie faktycznie obowiązuje. Jako wartość docelową zazwyczaj wystarcza 120 albo 300 sekund. Wartości 0, czyli brak limitu, nie należy ustawiać na działającej stronie nigdy.

Zmiana w panelu hostingu

Większość dostawców udostępnia w panelu klienta ekran z ustawieniami PHP dla domeny. To najlepsza metoda, bo nie wymaga edycji plików i nie grozi błędem składni. W panelu cPanel ekran ten nosi nazwę „MultiPHP INI Editor”. W innych panelach trzeba szukać części o ustawieniach lub konfiguracji PHP.

Na takim ekranie wybiera się domenę, odnajduje pole max_execution_time, wpisuje nową liczbę sekund i zatwierdza zmianę. Jeśli obok widoczne jest pole max_input_time, warto ustawić w nim tę samą wartość. Zmiana zwykle zaczyna obowiązywać po kilku minutach.

Wpis w pliku .htaccess

Tę metodę podaje dokumentacja WordPressa. Działa ona wyłącznie na serwerach Apache, na których PHP pracuje jako moduł serwera. W katalogu głównym witryny otwiera się plik .htaccess, pobiera jego kopię na dysk i na samym początku pliku, przed blokiem oznaczonym # BEGIN WordPress, wstawia jeden wiersz:

php_value max_execution_time 300

Tu potrzebna jest ostrożność. Jeżeli PHP działa na serwerze w innym trybie, wiersz ten nie zostanie zrozumiany i cała witryna zacznie zwracać błąd 500. Nie jest to groźne, o ile kopia pliku leży na dysku: wystarczy usunąć dopisany wiersz i strona wraca natychmiast. Kto nie ma pewności, w jakim trybie pracuje PHP, powinien wybrać inną metodę.

Plik php.ini albo .user.ini

Na serwerach, gdzie PHP pracuje w trybie CGI lub FastCGI, a tak jest dziś na większości hostingów współdzielonych, ustawienia dla jednej witryny zapisuje się w pliku .user.ini umieszczonym w katalogu głównym strony. Jeżeli pliku nie ma, należy go utworzyć jako zwykły plik tekstowy. Wpisuje się do niego:

max_execution_time = 300
max_input_time = 300

Dokumentacja PHP podaje, że pliki tego typu są odczytywane ponownie domyślnie co 300 sekund. Zmiana nie zadziała więc od razu i przed sprawdzeniem efektu trzeba odczekać około pięciu minut. Na serwerach własnych lub wirtualnych ten sam wiersz wpisuje się w głównym pliku php.ini, po czym trzeba ponownie uruchomić usługę PHP.

Wiersz w pliku wp-config.php

PHP ma funkcję set_time_limit(), która ustawia limit z poziomu kodu. W pliku wp-config.php, przed wierszem z komentarzem o zakończeniu edycji, dopisuje się wiersz:

set_time_limit( 300 );

Uważam tę metodę za ostatnią w kolejności. Część dostawców blokuje tę funkcję i wtedy wiersz nie przynosi skutku. Ponadto, zgodnie z dokumentacją, każde wywołanie tej funkcji zeruje licznik i odlicza czas od nowa, a wtyczki mogą ją wywoływać samodzielnie z inną wartością. Wynik bywa więc mniej przewidywalny niż przy ustawieniu po stronie serwera.

Zgłoszenie do pomocy technicznej hostingu

Na wielu kontach współdzielonych klient nie może zmienić limitu samodzielnie albo może go podnieść tylko do określonego pułapu. Wtedy jedyną drogą jest zgłoszenie. Dokumentacja WordPressa wprost zaleca kontakt z dostawcą, gdy samodzielna zmiana nie jest możliwa. Treść zgłoszenia może brzmieć tak:

Dzień dobry, na stronie pod adresem [adres domeny] podczas [nazwa czynności, np. importu produktów] pojawia się błąd „Maximum execution time of [liczba] seconds exceeded”. Proszę o podniesienie wartości max_execution_time oraz max_input_time dla tej domeny do 300 sekund albo o informację, jaka jest najwyższa wartość dostępna w moim pakiecie. Proszę też o potwierdzenie, czy serwer WWW nie przerywa żądań wcześniej własnym limitem czasu.

Ostatnie zdanie zgłoszenia ma znaczenie, o czym niżej. Dobrze też dołączyć pełną treść błędu z dziennika razem ze ścieżką do pliku, bo pozwala to pracownikowi hostingu szybciej ocenić sytuację.

Dlaczego zmiana limitu nie przynosi efektu?

Zdarza się, że po wykonaniu opisanych czynności komunikat nadal podaje starą liczbę sekund albo operacja nadal się urywa. Przyczyn jest kilka i każdą można sprawdzić.

Pierwsza: ustawienie zostało zapisane w miejscu, którego serwer nie czyta. Wiersz php_value w pliku .htaccess nie działa w trybie FastCGI, a plik .user.ini nie działa, gdy PHP jest modułem Apache. Rozstrzyga to ekran „Stan witryny”: jeśli w sekcji „Serwer” nadal widać starą wartość, zmiana nie została przyjęta i trzeba użyć innej metody.

Druga: dostawca ustawił górny pułap, którego konto nie może przekroczyć. Wtedy każda wyższa wartość jest pomijana bez żadnego komunikatu. Informację o pułapie zawiera specyfikacja pakietu hostingowego albo odpowiedź pomocy technicznej.

Trzecia: żądanie przerywa nie PHP, lecz serwer WWW. Dokumentacja PHP przypomina, że serwery mają własne ograniczenia czasu, na przykład dyrektywę Timeout w Apache, które również mogą zakończyć działanie skryptu. Podobną rolę pełni ustawienie request_terminate_timeout w PHP-FPM oraz limity serwera pośredniczącego. W takiej sytuacji zamiast komunikatu PHP pojawia się zwykle błąd bramy. Szerzej opisałem to w tekście o tym, jak przy błędzie 504 znaleźć proces, który trwa za długo. Tych ustawień klient hostingu współdzielonego nie zmienia sam, zmienia je dostawca.

Czwarta: limit został podniesiony, ale operacja i tak się w nim nie mieści. Jeżeli po zmianie z 30 na 300 sekund komunikat podaje już 300, a błąd wraca, dalsze podnoszenie nie ma sensu. Trzeba zmienić sposób wykonania operacji albo usunąć to, co ją spowalnia.

Jak usunąć przyczynę, zamiast tylko wydłużać czas?

Wyższy limit jest rozwiązaniem właściwym dla jednorazowej, ciężkiej czynności. Jeśli błąd powtarza się regularnie, lepiej zmniejszyć pracę, jaką serwer ma do wykonania w jednym żądaniu.

Podział dużej operacji na mniejsze części

Plik importu z kilkoma tysiącami pozycji warto podzielić na kilka mniejszych plików i wgrywać je po kolei. Wtyczki do importu i do kopii zapasowych mają zazwyczaj w ustawieniach wielkość jednej partii albo czas jednego przebiegu. Zmniejszenie tej wartości sprawia, że operacja trwa dłużej w sumie, ale żadne pojedyncze żądanie nie przekracza limitu. Aktualizacje wtyczek lepiej wykonywać pojedynczo niż zaznaczać wszystkie naraz.

Uruchomienie operacji z wiersza poleceń

Dokumentacja PHP podaje, że przy uruchamianiu z wiersza poleceń domyślna wartość limitu wynosi 0, czyli limit nie obowiązuje. Jeżeli hosting daje dostęp przez SSH i ma zainstalowane narzędzie WP-CLI, ciężkie czynności można wykonać tą drogą, na przykład poleceniem wp plugin update --all albo wp core update. To rozwiązanie dla osób, które znają pracę w terminalu. Pozostałym radzę zlecić to komuś doświadczonemu.

Odciążenie witryny i serwera

Jeśli limit przekraczają zwykłe czynności, takie jak zapis wpisu, przyczyną jest ogólna powolność witryny. Należy wtedy sprawdzić wersję PHP na ekranie „Stan witryny” i w panelu hostingu przełączyć ją na aktualnie zalecaną, usunąć nieużywane wtyczki, a wtyczkę wskazaną w dzienniku zaktualizować lub zastąpić inną. Kolejność takiej diagnozy opisałem w tekście o tym, co spowalnia WordPressa.

Bywa też, że witryna po prostu wyrosła z najtańszego pakietu hostingowego. Sklep z dużą liczbą produktów i kilkudziesięcioma wtyczkami potrzebuje więcej mocy obliczeniowej niż strona wizytówka. Wtedy rozmowa z dostawcą o wyższym pakiecie jest uczciwszym rozwiązaniem niż kolejne obejścia.

Po czym poznać, że naprawa zadziałała?

Sprawdzenie składa się z trzech prostych czynności. Najpierw ekran „Stan witryny”, karta „Informacje”, sekcja „Serwer”: limit czasu PHP powinien pokazywać nową wartość. Następnie trzeba powtórzyć dokładnie tę operację, która wcześniej kończyła się błędem, i doprowadzić ją do końca. Na koniec należy zajrzeć do dziennika błędów i upewnić się, że po chwili zmiany nie przybył w nim żaden nowy wiersz ze słowami „Maximum execution time”.

Jeżeli przerwana była aktualizacja, trzeba dodatkowo obejrzeć stronę oczami odwiedzającego. Przerwana aktualizacja potrafi pozostawić witrynę w trybie konserwacji. Dokumentacja WordPressa wyjaśnia, że odpowiada za to plik .maintenance w katalogu głównym, który w takiej sytuacji nie został usunięty. Wystarczy usunąć go przez FTP, a potem ponowić aktualizację.

Po przerwanym imporcie warto sprawdzić, czy część pozycji nie została wgrana dwukrotnie albo tylko częściowo. Po przerwanej kopii zapasowej niepełny plik archiwum należy usunąć i wykonać kopię od nowa, bo uszkodzonego archiwum nie da się potem odtworzyć.

Jakich błędów unikać przy zmianie limitu?

Najpoważniejszy błąd to ustawienie limitu na 0 albo na wiele godzin i pozostawienie go na stałe. Skrypt, który wpadł w pętlę, będzie wtedy zajmował serwer bez końca, a dostawca hostingu może z tego powodu ograniczyć lub zawiesić konto za nadmierne zużycie zasobów. Bezpieczniej podnieść limit umiarkowanie, a po zakończeniu jednorazowej operacji przywrócić wcześniejszą wartość.

Drugi błąd to edycja plików .htaccess i wp-config.php bez kopii. Jeden zbędny znak w każdym z nich wyłącza całą witrynę. Przed każdą zmianą plik należy pobrać na dysk, a przed większymi pracami wykonać pełną kopię witryny. Jak zrobić ją tak, żeby dało się z niej skorzystać, wyjaśniam w tekście o kopii zapasowej WordPressa.

Trzeci błąd to dopisywanie fragmentów kodu przez edytor plików motywu w kokpicie. Pomyłka w tym miejscu odcina dostęp do kokpitu, a zmiana znika przy aktualizacji motywu. Czwarty to instalowanie przypadkowych wtyczek, które obiecują podniesienie limitu jednym kliknięciem: w najlepszym razie robią to samo, co jeden wiersz w pliku, a każda dodatkowa wtyczka to kolejny element do utrzymania.

Piąty błąd to pozostawienie włączonego trybu diagnostycznego. Plik debug.log rośnie z każdym dniem i bywa dostępny z zewnątrz pod przewidywalnym adresem. Po zakończeniu pracy tryb należy wyłączyć, a plik usunąć.

Najczęstsze pytania

Czy ten błąd może uszkodzić stronę?

Sam komunikat niczego nie niszczy, ale przerwana w połowie operacja może zostawić ślady: witrynę w trybie konserwacji, częściowo wgrany import albo niepełne archiwum kopii zapasowej. Dlatego po usunięciu przyczyny trzeba dokończyć lub powtórzyć przerwaną czynność i obejrzeć stronę od strony odwiedzającego.

Jaką wartość limitu ustawić?

Nie ma jednej oficjalnie zalecanej liczby. Dokumentacja WordPressa w swoim przykładzie podaje 60 sekund, a w praktyce dla importów i kopii zapasowych stosuje się zwykle od 120 do 300 sekund. Należy wybrać najniższą wartość, przy której operacja kończy się poprawnie, zamiast ustawiać z góry bardzo wysoką.

Czy limit czasu i limit pamięci to to samo?

Nie. Limit czasu określa, jak długo skrypt może pracować, a limit pamięci, ile pamięci może zająć. Brak pamięci zgłaszany jest innym komunikatem: „Allowed memory size exhausted”. Oba błędy często towarzyszą tym samym ciężkim operacjom, ale naprawia się je innymi ustawieniami, dlatego najpierw trzeba dokładnie przeczytać treść wpisu w dzienniku.

Dlaczego błąd pojawia się tylko w kokpicie, a strona dla odwiedzających działa?

Ciężkie operacje, takie jak aktualizacje, importy i zapisy w kreatorze stron, wykonuje się w kokpicie, a odwiedzający najczęściej otrzymują gotową stronę z pamięci podręcznej, której serwer nie musi budować od nowa. Witryna może więc działać poprawnie z zewnątrz i jednocześnie zawodzić przy pracach administracyjnych.

Czy wydłużenie limitu spowolni stronę?

Nie. Limit jest tylko górną granicą i nie wpływa na szybkość zwykłych żądań, które kończą się w ułamku tego czasu. Ryzyko polega na czym innym: przy bardzo wysokim limicie wadliwy skrypt dłużej zajmuje zasoby serwera, zanim zostanie zatrzymany, co może odbić się na pozostałych odwiedzających.

Komunikat podaje inną liczbę sekund niż ta, którą ustawiono. Co to znaczy?

Liczba w komunikacie to limit faktycznie obowiązujący w chwili błędu. Jeśli różni się od ustawionej, to albo zmiana nie została jeszcze odczytana przez serwer, albo zapisano ją w pliku, którego serwer nie uwzględnia, albo któraś wtyczka sama ustawia własny limit funkcją set_time_limit(). W tym ostatnim przypadku należy poszukać odpowiedniej opcji w ustawieniach tej wtyczki.

Czy da się naprawić ten błąd bez dostępu do FTP?

Często tak. Jeżeli kokpit działa, limit można odczytać na ekranie „Stan witryny”, a zmienić w panelu hostingu, bez dotykania plików. Gdy panel nie daje takiej możliwości, pozostaje zgłoszenie do pomocy technicznej dostawcy. Dostęp do plików jest niezbędny dopiero wtedy, gdy kokpit przestał się otwierać.

Co zrobić, gdy błąd wraca mimo limitu 300 sekund?

Wtedy problemem nie jest limit, lecz sama operacja albo wtyczka. Należy podzielić zadanie na mniejsze części, sprawdzić w dzienniku, który plik powtarza się w komunikatach, zaktualizować lub wymienić wskazaną wtyczkę i zapytać dostawcę hostingu o obciążenie serwera w chwili błędu. Dalsze podnoszenie limitu zazwyczaj tylko wydłuża czas oczekiwania na ten sam błąd.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

Pliki konfiguracyjne, dzienniki błędów i rozmowy z pomocą techniczną hostingu to nie jest zajęcie, na które właściciel firmy powinien poświęcać wieczory. Chętnie zajmę się tym od początku do końca: wykonam kopię witryny, odczytam dziennik, ustalę, która operacja lub wtyczka przekracza czas, ustawię limit we właściwym miejscu na serwerze, w razie potrzeby porozmawiam z dostawcą hostingu i dokończę przerwaną aktualizację albo import. Na koniec przekażę krótką informację, co było przyczyną i co zostało zmienione.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony oraz treść komunikatu, jeśli jest widoczna. Odpowiem, co da się zrobić i od czego zacznę.