Błąd krytyczny WordPress potrafi całkowicie zablokować stronę, kokpit administratora albo wybrane podstrony. Najczęściej pojawia się po aktualizacji wtyczki, zmianie motywu, edycji kodu, migracji serwisu lub problemie z konfiguracją hostingu. Choć komunikat wygląda poważnie, w wielu przypadkach naprawa jest możliwa bez utraty danych.
Najważniejsze jest spokojne działanie według kolejności. Najpierw zabezpiecz pliki i bazę danych, następnie ustal, co zmieniło się przed awarią, a dopiero później wyłączaj wtyczki, sprawdzaj motyw, debugowanie, plik .htaccess i logi serwera. Dzięki temu naprawiasz przyczynę, a nie tylko chwilowo ukrywasz objaw.
Streszczenie artykułu:
- Błąd krytyczny WordPress najczęściej powoduje wtyczka, motyw, limit pamięci PHP, plik .htaccess albo problem z bazą danych.
- Jeśli nie działa panel WordPress, wtyczki można wyłączyć przez FTP, SFTP lub menedżer plików w hostingu.
- Tryb debugowania pomaga wskazać konkretny plik, funkcję lub rozszerzenie, które zatrzymuje działanie strony.
- Przed każdą naprawą warto wykonać kopię zapasową plików i bazy, nawet gdy witryna już pokazuje błąd.
- Po uruchomieniu strony trzeba usunąć prawdziwą przyczynę awarii, aby problem nie wrócił przy następnej aktualizacji.
Czym jest błąd krytyczny WordPress?
Błąd krytyczny WordPress oznacza, że system nie może poprawnie załadować jednego z elementów potrzebnych do działania strony. Może to być wtyczka, motyw, fragment własnego kodu, plik konfiguracyjny, funkcja PHP albo połączenie z bazą danych. WordPress zatrzymuje wtedy działanie witryny, aby nie dopuścić do dalszych problemów.
Najczęstszy komunikat na stronie
Najczęściej użytkownik widzi informację o tym, że w witrynie wystąpił błąd krytyczny. Czasem pojawia się też biały ekran, błąd 500, pętla przekierowań albo komunikat o braku połączenia z bazą danych. Objaw może dotyczyć całej strony, tylko kokpitu administratora albo wybranych podstron.
Od wersji WordPress 5.2 system może wysłać wiadomość e-mail do administratora. Taki e-mail bywa bardzo pomocny, ponieważ często wskazuje nazwę wtyczki lub motywu, który spowodował problem. Może też zawierać link do trybu odzyskiwania, który pozwala wejść do panelu mimo awarii.
Dlaczego nie warto działać chaotycznie?
Największym błędem jest przypadkowe usuwanie plików, instalowanie kolejnych wtyczek naprawczych albo nadpisywanie strony bez kopii zapasowej. Takie działania mogą pogorszyć sytuację, szczególnie gdy witryna zawiera sklep, formularze, konta użytkowników lub aktualne zamówienia.
Bezpieczna naprawa polega na eliminowaniu możliwych przyczyn krok po kroku. Najpierw warto ustalić, co wydarzyło się przed awarią. Aktualizacja jednej wtyczki, zmiana wersji PHP albo edycja pliku functions.php często wystarczy, aby wskazać właściwy kierunek diagnostyki.
Co najczęściej powoduje błąd krytyczny WordPress?
Najczęstszą przyczyną błędu krytycznego jest konflikt wtyczek lub niezgodność wtyczki z aktualną wersją WordPress, PHP albo motywu. Każde rozszerzenie dodaje własny kod i może wpływać na bazę danych, panel administracyjny, płatności, formularze, SEO, cache lub bezpieczeństwo strony.
Konflikt wtyczek po aktualizacji
Problem często pojawia się po aktualizacji jednej lub kilku wtyczek naraz. Nowa wersja może korzystać z funkcji niedostępnej w starszej wersji PHP, zmieniać strukturę kodu albo kolidować z innym rozszerzeniem. Szczególnie ryzykowne są duże aktualizacje, które wprowadzają wiele zmian jednocześnie.
Jeżeli błąd pojawił się zaraz po aktualizacji, zacznij od ostatnio zmienionych wtyczek. W praktyce warto wyłączyć je pojedynczo i po każdej zmianie sprawdzać stronę. Gdy witryna zacznie działać, znasz element, który wymaga cofnięcia, wymiany albo aktualizacji do poprawionej wersji.
Problem z motywem lub własnym kodem
Drugim częstym źródłem awarii jest motyw. Błąd może wynikać z niezgodności szablonu z nową wersją WordPress, błędu w pliku functions.php albo dodatkowego kodu wklejonego bez testów. Nawet jedna brakująca klamra, literówka w funkcji lub niepoprawne wywołanie PHP może zatrzymać całą stronę.
Jeśli przed awarią były wprowadzane zmiany w motywie, warto je cofnąć. Gdy nie masz dostępu do kokpitu, możesz zmienić nazwę folderu aktywnego motywu przez FTP. WordPress spróbuje wtedy użyć motywu domyślnego, o ile taki znajduje się na serwerze.
Limity serwera i baza danych
Błąd krytyczny może też wynikać z wyczerpania pamięci PHP, problemu z bazą danych, błędnego hasła do bazy albo uszkodzonego pliku .htaccess. Takie przyczyny są mniej oczywiste, ponieważ komunikat na stronie bywa podobny do awarii wtyczki. Dlatego ważne są logi i debugowanie.
W przypadku starszych hostingów problemem bywa nieaktualna wersja PHP. Nowe wtyczki coraz częściej wymagają nowszego środowiska, a stary serwer może nie obsługiwać funkcji wykorzystywanych przez aktualny kod. W takiej sytuacji sama dezaktywacja wtyczki może nie wystarczyć na dłużej.
Jak naprawić błąd krytyczny bez dostępu do panelu?
Brak dostępu do panelu WordPress nie oznacza, że strona jest niemożliwa do naprawienia. Wiele działań można wykonać bezpośrednio na serwerze, korzystając z FTP, SFTP albo menedżera plików w panelu hostingu. To najważniejsza metoda, gdy kokpit nie ładuje się po aktualizacji lub pokazuje tylko komunikat o błędzie.
Wyłączenie wszystkich wtyczek przez FTP
Wejdź do katalogu z plikami WordPress i otwórz folder wp-content. Następnie znajdź katalog plugins i zmień jego nazwę na przykład na plugins-old. WordPress nie będzie mógł załadować rozszerzeń, więc automatycznie je dezaktywuje. Dane wtyczek nie zostaną usunięte, ponieważ zmieniasz tylko nazwę folderu.
Po tej zmianie odśwież stronę. Jeśli witryna zacznie działać, przyczyną była jedna z wtyczek. Przywróć nazwę folderu plugins, zaloguj się do kokpitu i włączaj rozszerzenia pojedynczo. Po każdej aktywacji sprawdzaj stronę w nowej karcie lub trybie prywatnym przeglądarki.
Praktyczna kolejność działań:
- Zrób kopię plików i bazy danych.
- Połącz się z serwerem przez FTP, SFTP lub menedżer plików.
- Przejdź do katalogu wp-content.
- Zmień nazwę folderu plugins.
- Sprawdź, czy strona i kokpit zaczęły działać.
- Przywróć nazwę folderu i aktywuj wtyczki pojedynczo.
Wyłączenie jednej problematycznej wtyczki
Jeżeli wiesz, która wtyczka wywołała błąd, nie musisz dezaktywować wszystkich rozszerzeń. Wystarczy wejść do wp-content/plugins i zmienić nazwę folderu konkretnej wtyczki. To dobre rozwiązanie, gdy awaria pojawiła się po aktualizacji jednego dodatku, na przykład formularza, wtyczki SEO, cache albo sklepu.
Po odzyskaniu dostępu do kokpitu sprawdź, czy dostępna jest poprawka. Jeżeli problem dotyczy świeżej wersji, można tymczasowo wrócić do poprzedniego wydania wtyczki. Trzeba jednak traktować to jako rozwiązanie przejściowe, ponieważ starsze wersje mogą mieć luki bezpieczeństwa.
Tymczasowa zmiana motywu
Gdy wyłączenie wtyczek nie pomaga, sprawdź motyw. Przejdź do wp-content/themes i zmień nazwę folderu aktywnego szablonu. Jeżeli na serwerze znajduje się motyw domyślny WordPress, system może przełączyć się na niego automatycznie. Dzięki temu panel administratora często wraca do działania.
Po zalogowaniu sprawdź ostatnie zmiany w motywie. Szczególną uwagę zwróć na plik functions.php, pliki szablonów i własne fragmenty kodu. Jeśli motyw był dawno nieaktualizowany, rozważ jego aktualizację, kontakt z autorem albo migrację na nowszy, aktywnie rozwijany szablon.
Jak włączyć debugowanie i sprawdzić źródło błędu?
Debugowanie pozwala przejść od zgadywania do konkretów. Zamiast ogólnego komunikatu o błędzie możesz zobaczyć, który plik, funkcja lub folder powoduje problem. To bardzo przydatne, gdy wyłączenie wtyczek i zmiana motywu nie dają jednoznacznej odpowiedzi.
Włączenie debugowania w wp-config.php
Plik wp-config.php znajduje się w głównym katalogu instalacji WordPress. Otwórz go przez FTP, SFTP albo menedżer plików i znajdź linię z WP_DEBUG. Jeżeli jej nie ma, dodaj odpowiednie wpisy przed fragmentem informującym o zakończeniu edycji pliku.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Takie ustawienie zapisuje błędy do pliku debug.log w katalogu wp-content. To bezpieczniejsze niż wyświetlanie szczegółowych błędów wszystkim odwiedzającym. Po zapisaniu zmian odśwież stronę, a następnie sprawdź zawartość pliku debug.log.
Jak czytać log błędów?
W logu szukaj nazw wtyczek, motywów, ścieżek plików i komunikatów fatal error. Jeśli w ścieżce pojawia się wp-content/plugins/nazwa-wtyczki, problem prawdopodobnie dotyczy konkretnego rozszerzenia. Jeżeli widzisz wp-content/themes/nazwa-motywu, źródłem może być aktywny motyw.
Nie każdy wpis w logu oznacza awarię krytyczną. Ostrzeżenia i drobne komunikaty mogą pojawiać się od dawna. Najważniejsze są błędy oznaczone jako fatal error, parse error albo uncaught error. Zwróć też uwagę na godzinę, ponieważ powinna odpowiadać momentowi wystąpienia awarii.
Kiedy wyłączyć debugowanie?
Po zakończeniu naprawy wyłącz debugowanie. Wystarczy zmienić wartość WP_DEBUG na false albo usunąć dodane wcześniej linie. Tryb debugowania nie powinien działać stale na stronie produkcyjnej, ponieważ logi mogą zajmować miejsce, a szczegóły techniczne nie powinny być niepotrzebnie dostępne.
Jeżeli debugowanie nie pokazuje źródła problemu, sprawdź logi serwera w panelu hostingu. Często znajdują się w sekcji z błędami PHP, dziennikami serwera lub statystykami. Hosting może mieć dostęp do informacji, których nie widać z poziomu samego WordPressa.
Co zrobić przy białym ekranie, błędzie 500 i błędzie bazy danych?
Nie każdy krytyczny problem WordPress wygląda tak samo. Czasem widzisz biały ekran, czasem błąd 500, a czasem informację o braku połączenia z bazą danych. Każdy z tych objawów wymaga podobnej ostrożności, ale trochę innej kolejności działań.
Biały ekran śmierci
Biały ekran śmierci oznacza, że strona przestała generować widoczną treść. Przyczyną może być błąd PHP, konflikt wtyczek, problem z motywem albo zbyt niski limit pamięci. Zacznij od włączenia debugowania, ponieważ bez komunikatu technicznego trudno określić źródło problemu.
Jeżeli debugowanie wskazuje na przekroczenie pamięci, można rozważyć zwiększenie limitu PHP. W pliku wp-config.php czasem stosuje się wpis zwiększający limit pamięci, ale skuteczność zależy od ustawień hostingu. Jeśli serwer blokuje wyższy limit, konieczny będzie kontakt z administratorem hostingu.
define( 'WP_MEMORY_LIMIT', '256M' );
Wewnętrzny błąd serwera 500
Błąd 500 często wiąże się z plikiem .htaccess, konfliktem kodu, limitem pamięci lub problemem po stronie serwera. Najprostszy test polega na zmianie nazwy pliku .htaccess na przykład na .htaccess-old. Plik znajdziesz w głównym katalogu WordPress.
Jeżeli po zmianie nazwy strona zacznie działać, zaloguj się do panelu i przejdź do ustawień bezpośrednich odnośników. Następnie zapisz ustawienia bez wprowadzania zmian. WordPress utworzy nowy plik .htaccess z podstawowymi regułami. Warto później porównać stary plik z nowym, ponieważ dodatkowe reguły mogły pochodzić z wtyczek bezpieczeństwa, cache lub przekierowań.
Błąd połączenia z bazą danych
Komunikat o błędzie połączenia z bazą danych oznacza, że WordPress nie może odczytać danych potrzebnych do działania strony. Przyczyną może być błędna nazwa bazy, użytkownik, hasło, host bazy albo awaria serwera bazodanowego. Wszystkie podstawowe dane znajdziesz w pliku wp-config.php.
Najważniejsze wpisy to DB_NAME, DB_USER, DB_PASSWORD i DB_HOST. Sprawdź je z danymi w panelu hostingu. Jeżeli hasło użytkownika bazy zostało zmienione, trzeba zaktualizować je także w wp-config.php. Gdy dane są poprawne, a błąd nadal występuje, problem może leżeć po stronie hostingu lub uszkodzonych tabel.
| Objaw | Możliwa przyczyna | Pierwszy krok |
|---|---|---|
| Biały ekran | Błąd PHP, motyw, wtyczka, pamięć | Włącz debugowanie |
| Błąd 500 | .htaccess, serwer, limit PHP | Zmień nazwę .htaccess |
| Brak połączenia z bazą | Błędne dane lub awaria bazy | Sprawdź wp-config.php |
| Błąd tylko na podstronach | Bezpośrednie odnośniki | Zapisz ustawienia linków |
| Pętla przekierowań | SSL, adres URL, wtyczka SEO | Sprawdź adres witryny |
Jak naprawić pętlę przekierowań i błędy podstron?
Pętle przekierowań często są mylone z błędem krytycznym, ponieważ użytkownik również nie może wejść na stronę lub panel administratora. Przeglądarka pokazuje wtedy komunikat o zbyt wielu przekierowaniach. Problem może dotyczyć całej domeny albo tylko wybranej podstrony.
Błędny adres WordPress i adres witryny
Jedną z częstych przyczyn jest niepoprawny adres WordPress lub adres witryny. Problem może pojawić się po migracji, zmianie domeny, przejściu na HTTPS albo błędnym ustawieniu certyfikatu SSL. Jeżeli strona wymusza HTTPS, ale certyfikat nie działa poprawnie, przeglądarka może utknąć w pętli.
Jeśli masz dostęp do panelu, sprawdź adresy w ustawieniach ogólnych WordPress. Powinny być zgodne z prawdziwym adresem strony i protokołem. Gdy panel nie działa, adresy można poprawić w bazie danych albo tymczasowo przez plik functions.php, ale taka zmiana wymaga ostrożności i późniejszego usunięcia dodanych linii.
Wtyczki SEO, cache i przekierowań
Pętle przekierowań często powodują wtyczki do SEO, cache, SSL lub przekierowań. Dwa rozszerzenia mogą próbować zarządzać tym samym adresem w różny sposób. Jedna wtyczka przekierowuje z adresu A do B, a druga z B do A. W efekcie przeglądarka nie może dotrzeć do właściwej wersji strony.
W takiej sytuacji wyłącz wtyczki odpowiedzialne za przekierowania i cache. Jeżeli strona zacznie działać, włączaj je pojedynczo i sprawdzaj ustawienia. Szczególną uwagę zwróć na wymuszanie HTTPS, przekierowania z www na bez www, stare reguły po migracji i ręcznie dodane przekierowania 301.
Problem z bezpośrednimi odnośnikami
Jeżeli działa strona główna, ale podstrony pokazują błąd 404, problem często dotyczy bezpośrednich odnośników lub pliku .htaccess. W panelu WordPress wystarczy przejść do ustawień bezpośrednich odnośników i zapisać je ponownie. To odświeża reguły adresów.
Gdy nie da się zapisać ustawień, sprawdź uprawnienia pliku .htaccess. Typowe uprawnienia dla tego pliku to 0644, choć konfiguracja zależy od hostingu. Jeśli WordPress nie może zapisać zmian, trzeba poprawić uprawnienia albo ręcznie odtworzyć podstawowe reguły.
Jak bezpiecznie przywrócić stronę po nieudanej aktualizacji?
Przywracanie strony po aktualizacji wymaga zachowania równowagi między szybkością a bezpieczeństwem. Najprościej byłoby odtworzyć backup, ale nie zawsze jest to najlepsze pierwsze działanie. W sklepie internetowym lub serwisie z formularzami można w ten sposób utracić nowe zamówienia, wiadomości albo rejestracje.
Kiedy użyć kopii zapasowej?
Kopia zapasowa jest najlepszym rozwiązaniem, gdy nie da się szybko ustalić przyczyny awarii, a strona musi wrócić do działania. Warto jednak najpierw zabezpieczyć aktualny stan, nawet uszkodzony. Dzięki temu można później odzyskać nowe dane, które pojawiły się po wykonaniu wcześniejszego backupu.
Jeżeli awaria dotyczy tylko plików wtyczki lub motywu, często lepiej wyłączyć problematyczny element niż odtwarzać całą stronę. Przywrócenie całej bazy powinno być decyzją świadomą, szczególnie gdy strona przyjmuje płatności, zapytania ofertowe lub rezerwacje.
Cofnięcie wtyczki do poprzedniej wersji
Jeśli błąd pojawił się po aktualizacji konkretnej wtyczki, można rozważyć tymczasowe cofnięcie jej do poprzedniej stabilnej wersji. To często przywraca działanie strony, zanim autor wtyczki opublikuje poprawkę. Nie należy jednak zostawiać starej wersji bez kontroli, zwłaszcza gdy aktualizacja zawierała poprawki bezpieczeństwa.
Po cofnięciu wersji sprawdź dokumentację wtyczki, forum wsparcia i wymagania techniczne. Problem może wynikać z wersji PHP, konfliktu z inną wtyczką albo niezgodności z motywem. Wtedy samo cofnięcie dodatku jest tylko chwilową ulgą, a nie pełnym rozwiązaniem.
Testowanie przed ponowną aktualizacją
Po naprawie nie wykonuj ponownie tej samej aktualizacji na ślepo. Najpierw sprawdź ją na kopii testowej strony. Środowisko staging pozwala wykryć konflikt bez ryzyka dla działającej witryny. To szczególnie ważne przy sklepach WooCommerce, stronach z płatnościami i serwisach firmowych.
Dobra kolejność po awarii:
- Przywróć dostęp do strony przez wyłączenie wadliwego elementu.
- Zabezpiecz aktualny stan plików i bazy.
- Ustal nazwę wtyczki, motywu lub reguły, która powodowała problem.
- Sprawdź wymagania wersji PHP i WordPress.
- Przetestuj poprawkę na kopii strony.
- Dopiero potem wdroż zmianę na stronie produkcyjnej.
Jak zapobiegać błędom krytycznym WordPress?
Zapobieganie błędom krytycznym polega na tym, aby aktualizacje i zmiany nie były wykonywane bez zabezpieczenia. WordPress jest elastyczny, ale duża liczba wtyczek, stary motyw i brak kopii zapasowej znacząco zwiększają ryzyko awarii. Dobre procedury pozwalają uniknąć większości nerwowych sytuacji.
Regularne kopie zapasowe
Kopia zapasowa powinna obejmować pliki oraz bazę danych. Same pliki nie wystarczą, ponieważ wpisy, produkty, ustawienia, zamówienia i konta użytkowników znajdują się w bazie. Sama baza też nie wystarczy, ponieważ motywy, zdjęcia i wtyczki są przechowywane w plikach.
Ważne jest nie tylko tworzenie backupów, ale również testowanie ich odtwarzania. Kopia, której nie da się przywrócić, daje fałszywe poczucie bezpieczeństwa. Najlepiej przechowywać backup poza głównym serwerem, aby awaria hostingu nie pozbawiła Cię jedynej kopii strony.
Mniej wtyczek i lepsza kontrola
Każda dodatkowa wtyczka to kolejny fragment kodu, który może wejść w konflikt z resztą strony. Nie chodzi o to, aby unikać rozszerzeń za wszelką cenę, lecz aby używać tylko tych naprawdę potrzebnych. Wtyczki nieaktywne, porzucone albo zdublowane funkcjonalnie warto usuwać.
Zasady bezpiecznego utrzymania strony:
- Aktualizuj WordPress, wtyczki i motywy regularnie.
- Nie instaluj kilku wtyczek realizujących tę samą funkcję.
- Usuwaj dodatki, których nie używasz.
- Sprawdzaj zgodność wtyczek z wersją PHP.
- Testuj większe aktualizacje na kopii strony.
Środowisko testowe i kontrola aktualizacji
Strona testowa pozwala sprawdzić aktualizacje przed wdrożeniem ich na produkcji. Wiele hostingów oferuje funkcję staging, czyli kopię witryny uruchamianą jednym kliknięciem. Dzięki temu możesz przetestować nową wersję wtyczki, motywu lub WordPress bez ryzyka dla odwiedzających.
Automatyczne aktualizacje mogą być wygodne, ale w przypadku ważnych stron warto stosować je ostrożnie. Łatki bezpieczeństwa zwykle należy wdrażać szybko, natomiast duże aktualizacje funkcjonalne lepiej poprzedzić backupem i testem. Taka procedura zajmuje mniej czasu niż naprawa strony po nagłej awarii.
Podsumowanie
Błąd krytyczny WordPress najczęściej da się naprawić bez utraty danych, jeśli działasz spokojnie i metodycznie. Najpierw wykonaj kopię zapasową, sprawdź mail administratora, wyłącz wtyczki przez FTP lub menedżer plików, przetestuj motyw, włącz debugowanie i przeanalizuj logi. Jeśli problem dotyczy bazy danych, pliku .htaccess, przekierowań albo limitów serwera, naprawiaj konkretną przyczynę zamiast odtwarzać stronę w ciemno. Po przywróceniu działania witryny wdroż backupy, staging i kontrolę aktualizacji, ponieważ dobra profilaktyka jest znacznie tańsza niż szybka interwencja przy niedziałającej stronie.
FAQ – Najczęściej zadawane pytania
Co oznacza błąd krytyczny WordPress?
Błąd krytyczny oznacza, że WordPress nie może poprawnie załadować strony z powodu problemu w kodzie, wtyczce, motywie, bazie danych albo konfiguracji serwera. System przerywa działanie, aby nie pogłębiać awarii i nie wyświetlać szczegółowych informacji technicznych użytkownikom.
Czy błąd krytyczny usuwa dane ze strony?
Najczęściej nie. Wpisy, strony, produkty, zdjęcia i ustawienia zwykle nadal znajdują się w bazie danych i plikach na serwerze. Ryzyko utraty danych pojawia się wtedy, gdy naprawa jest wykonywana bez kopii zapasowej, przez przypadkowe usuwanie plików albo nieprzemyślane odtwarzanie starego backupu.
Jak wyłączyć wtyczki, gdy nie działa kokpit WordPress?
Połącz się z serwerem przez FTP, SFTP albo menedżer plików. Następnie przejdź do wp-content i zmień nazwę folderu plugins. WordPress automatycznie dezaktywuje wszystkie wtyczki. Po odzyskaniu dostępu przywróć nazwę folderu i włączaj rozszerzenia pojedynczo, aby znaleźć problematyczne.
Czy trzeba włączać debugowanie WordPress?
Debugowanie warto włączyć, gdy nie wiesz, co powoduje awarię. Pozwala ono zapisać szczegóły błędów do pliku debug.log. Dzięki temu łatwiej wskazać konkretną wtyczkę, motyw albo plik. Po zakończeniu naprawy debugowanie trzeba wyłączyć, aby nie tworzyć zbędnych logów.
Co zrobić, jeśli błąd pojawił się po aktualizacji wtyczki?
Najpierw wyłącz tę wtyczkę przez panel albo przez FTP. Potem sprawdź, czy autor opublikował poprawkę. Jeśli nie, możesz tymczasowo wrócić do poprzedniej stabilnej wersji, ale nie traktuj tego jako rozwiązania na stałe. Sprawdź też zgodność wtyczki z wersją WordPress, PHP i aktywnym motywem.
Kiedy zgłosić problem do hostingu?
Z hostingiem warto skontaktować się wtedy, gdy wyłączenie wtyczek i motywu nie pomaga, logi wskazują na problemy PHP, bazę danych albo limity serwera. Przed zgłoszeniem przygotuj godzinę awarii, treść komunikatu, wykonane kroki oraz informację o ostatnich aktualizacjach.