Aby bezpiecznie zaktualizować WordPressa, w pierwszej kolejności wykonaj pełną kopię zapasową plików i bazy danych, a dopiero potem aktualizuj kolejno wtyczki, motywy i na końcu rdzeń systemu. Taka kolejność ogranicza ryzyko konfliktów, a kopia pozwala w razie awarii przywrócić działającą stronę w kilka minut.
Zrób kopię zapasową przed aktualizacją
Nie polegaj wyłącznie na kopiach wykonywanych przez hosting — miej własną, którą możesz pobrać na dysk.
1. Przejdź do Wtyczki → Dodaj wtyczkę i zainstaluj darmową wtyczkę UpdraftPlus (albo Duplicator).
2. Otwórz Ustawienia → UpdraftPlus Backups i kliknij Wykonaj kopię teraz (ang. Backup Now).
3. Zaznacz obie opcje: kopię bazy danych oraz kopię plików (motywy, wtyczki, katalog uploads).
4. Po zakończeniu pobierz wszystkie archiwa na swój komputer — kopia trzymana wyłącznie na serwerze przepada razem z nim przy poważnej awarii.
Dodatkowo sprawdź w panelu hostingu, czy usługodawca robi automatyczne kopie i jak szybko możesz je przywrócić — to Twoja druga linia obrony.
Aktualizuj w kolejności: wtyczki, motywy, rdzeń
1. Przejdź do Kokpit → Aktualizacje.
2. Najpierw zaktualizuj wtyczki — pojedynczo lub małymi partiami, a po każdej partii odśwież stronę i sprawdź, czy wszystko działa. Tak od razu namierzysz winowajcę ewentualnej awarii.
3. Potem zaktualizuj motywy. Jeśli zmieniałeś pliki motywu bez motywu potomnego (child theme), aktualizacja nadpisze Twoje poprawki. W motywach blokowych (np. naszym darmowym Składzie) zmiany wprowadzone w Edytorze witryny zapisują się w bazie danych, więc aktualizacja ich nie usunie.
4. Na końcu kliknij przycisk aktualizacji przy rdzeniu WordPressa.
Przed dużą aktualizacją rdzenia (zmiana pierwszej lub drugiej liczby w numerze wersji, np. z 6.9 na 7.0) zajrzyj na strony kluczowych wtyczek w katalogu wordpress.org i sprawdź pole „Przetestowana do wersji”. Jeśli autor dawno nie testował wtyczki z nowym WordPressem, odczekaj kilka dni, aż opublikuje zgodną wersję.
Tryb konserwacji i wersja PHP
Podczas aktualizacji WordPress sam włącza tryb konserwacji: tworzy w katalogu głównym plik .maintenance i pokazuje odwiedzającym komunikat „Witryna jest tymczasowo niedostępna z powodu zaplanowanych prac konserwacyjnych”. Jeśli aktualizacja zostanie przerwana i komunikat nie znika, połącz się z serwerem przez FTP lub menedżer plików hostingu i usuń plik .maintenance — strona wróci natychmiast.
Przy dłuższych pracach możesz włączyć własny tryb konserwacji darmową wtyczką LightStart (dawniej WP Maintenance Mode), która pokaże gościom estetyczną planszę zamiast rozgrzebanej strony.
Zanim ruszysz z aktualizacją rdzenia, sprawdź też wersję PHP w Narzędzia → Stan witryny, w zakładce „Informacje”. Aktualny WordPress działa najlepiej na PHP 8.2 lub nowszym (8.3, 8.4); wersje 7.x są przestarzałe i wyraźnie wolniejsze. Wersję PHP zmienisz w panelu hostingu (zwykle jednym kliknięciem), a po zmianie od razu przeklikaj stronę — stara wtyczka może nie działać z nowym PHP.
Biała strona po aktualizacji (WSOD) — co robić
Biały ekran to zwykle błąd krytyczny PHP wywołany przez niekompatybilną wtyczkę lub motyw. WordPress wysyła wtedy e-mail „Twoja witryna ma problemy techniczne” z linkiem do trybu odzyskiwania — zacznij od sprawdzenia skrzynki, także folderu spam.
1. Kliknij link z e-maila, zaloguj się w trybie odzyskiwania i wyłącz wskazaną wtyczkę lub motyw.
2. Jeśli e-mail nie dotarł, a do panelu nie możesz wejść, połącz się przez FTP i zmień nazwę katalogu wp-content/plugins na np. plugins-off — wszystkie wtyczki zostaną wyłączone. Gdy strona wróci, przywróć nazwę katalogu i wyłączaj wtyczki pojedynczo, aż znajdziesz winowajcę.
3. Gdy winny jest motyw, zmień nazwę jego katalogu w wp-content/themes — WordPress przełączy się na motyw domyślny (któryś z serii Twenty), o ile jest zainstalowany.
4. Jeśli nic nie pomaga, przywróć kopię zapasową z pierwszego kroku i powtórz aktualizację, tym razem partiami.
Aby poznać dokładną treść błędu, włącz rejestrowanie błędów. Najpierw zrób kopię pliku wp-config.php (edytujesz kluczowy plik konfiguracyjny, więc kopia jest obowiązkowa), a następnie dodaj w nim przed linią „/* That’s all, stop editing! */”:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );
Komunikaty trafią do pliku wp-content/debug.log, a ścieżka w treści błędu wskaże katalog winnej wtyczki lub motywu. Po naprawie ustaw WP_DEBUG i WP_DEBUG_LOG z powrotem na false.
Cała procedura zajmuje kwadrans, a może oszczędzić Ci wielu godzin odzyskiwania strony. Aktualizuj regularnie — nadrabianie wielu wersji naraz to najczęstsza przyczyna problemów.