WordPress działał, kliknąłeś aktualizację i nagle pojawiła się biała strona, błąd 500 albo komunikat o błędzie krytycznym. To stresująca sytuacja, ale jednocześnie znasz bardzo ważną informację: awaria ma wyraźny punkt początkowy.
Szybka odpowiedź
Nie aktualizuj teraz kolejnych elementów. Zapisz, co dokładnie zostało zmienione, sprawdź logi, wyłącz lub cofnij komponent, po którym wystąpił błąd. Jeśli serwis jest biznesowo krytyczny, najpierw przywróć działającą wersję, a analizę kontynuuj na stagingu.
Aktualizacja wtyczki
Jeżeli aktualizowana była jedna wtyczka, zacznij od niej. Gdy wp-admin nie działa, można ją wyłączyć przez SFTP zmieniając nazwę katalogu. Jeśli strona wróci, masz silne potwierdzenie źródła problemu.
Aktualizacja motywu
Motyw potomny zwykle chroni własne modyfikacje przed nadpisaniem. Jeżeli zmiany były robione bezpośrednio w motywie nadrzędnym, aktualizacja mogła je usunąć. Błędy PHP po aktualizacji motywu diagnozuje się przez logi, a nie przez zgadywanie.
Aktualizacja WordPressa
Przy aktualizacji rdzenia część starszych dodatków może zacząć korzystać z nieobsługiwanych funkcji. Zanim cofniesz cały WordPress, sprawdź, czy log wskazuje konkretny plugin.
Zmiana PHP
Czasami „aktualizacja WordPressa” zbiega się ze zmianą wersji PHP wykonaną przez hosting. Sprawdź panel serwera i datę zmiany. Niezgodny stary kod może przestać działać natychmiast.
Baza danych i migracje
Niektóre aktualizacje rozszerzeń modyfikują schemat lub dane. Wtedy proste podmienienie plików na starsze nie zawsze jest pełnym rollbackiem. Dlatego kopia bazy sprzed aktualizacji jest tak ważna.
Jak użyć logów?
Szukaj Fatal error, TypeError, Uncaught, błędów składni oraz nazw plików. Ścieżka wp-content/plugins/nazwa... albo themes/nazwa... szybko zawęża obszar.
Kiedy przywrócić backup?
Jeżeli strona generuje sprzedaż lub leady i nie ma szybkiego rozwiązania, przywrócenie działającego stanu może być lepsze biznesowo niż długa diagnostyka na produkcji. Na WooCommerce trzeba szczególnie uważać z bazą: nie chcesz cofnąć zamówień złożonych po wykonaniu kopii.
Jak uniknąć tego następnym razem?
Staging, automatyczna kopia przed zmianą, kontrolowana kolejność aktualizacji i test po wdrożeniu. Do tego monitoring, który natychmiast informuje o błędzie HTTP lub braku odpowiedzi.
Bezpieczna kolejność diagnostyki
Przy problemie WordPress nie działa po aktualizacji najłatwiej stracić czas przez zmienianie kilku rzeczy naraz. Zanim cokolwiek naprawisz, zapisz objaw, godzinę wystąpienia i ostatnie zmiany. Następnie sprawdź logi oraz stan usług, których dotyczy błąd.
Dobra kolejność wygląda tak:
- potwierdź objaw na konkretnym URL-u lub zamówieniu,
- sprawdź logi i komunikaty systemowe,
- ustal ostatnią zmianę,
- wykonaj kopię przed ingerencją,
- zmień jeden element,
- ponownie wykonaj ten sam test,
- po naprawie sprawdź pozostałe funkcje strony.
Czego nie robić?
Nie czyść bazy, nie resetuj haseł i nie aktualizuj wszystkiego „na wszelki wypadek”, jeżeli nie ma ku temu przesłanek. Takie działania niszczą ślady i zwiększają liczbę niewiadomych. Jeżeli serwis generuje sprzedaż, szybki rollback często jest lepszy niż długa naprawa prowadzona bezpośrednio na produkcji.
Powiązane poradniki HeatLogic
Potrzebujesz pomocy?
Jeżeli aktualizacja unieruchomiła stronę, HeatLogic może przywrócić działanie, znaleźć konflikt i przygotować poprawkę bez kolejnych eksperymentów na produkcji.
Najczęściej zadawane pytania
Czy można cofnąć aktualizację wtyczki?
Tak, ale najlepiej użyć znanej, poprzedniej wersji z zaufanego źródła i pamiętać, że niektóre aktualizacje zmieniają też bazę.
Dlaczego panel działa, a frontend nie?
Błąd może być wywoływany tylko przez elementy ładowane na froncie, np. motyw lub określony hook wtyczki.
Czy aktualizacja PHP może zepsuć WordPress?
Tak, jeżeli motyw lub rozszerzenie używa kodu niezgodnego z nową wersją PHP.
Czy warto przywracać całą bazę?
Tylko gdy jest to potrzebne. Na dynamicznej stronie pełne odtworzenie bazy może usunąć nowe dane powstałe po backupie.