Aktualizacja WordPressa bez wysadzania strony w powietrze

TL;DR: Aktualizacja WordPressa to nie rosyjska ruletka, tylko procedura, jak tankowanie samochodu. Najpierw robisz kopię zapasową (całą: pliki i bazę), potem sprawdzasz, czy wtyczki i motyw dogadają się z nową wersją, aktualizujesz po kolei, a nie wszystko naraz, i na końcu klikasz po stronie jak klient. Jeśli zobaczysz komunikat „Na tej stronie wystąpił błąd krytyczny”, nie panikuj: WordPress od wersji 5.2 wysyła administratorowi maila z linkiem do trybu odzyskiwania, a winowajcę zwykle da się wyłączyć w kilka minut. Najdroższa aktualizacja to ta, której nie zrobiłeś, bo luki w starych wtyczkach to dziś główna droga włamań.

Znasz ten moment? Logujesz się do panelu WordPressa, a tam czerwone kółeczko z liczbą 17. Siedemnaście aktualizacji. Wtyczki, motyw, sam WordPress, tłumaczenia. Ręka sama wędruje do przycisku „Zaznacz wszystko” i „Aktualizuj”, a w głowie pojawia się myśl: „a co, jeśli strona się wysypie?”. Więc zamykasz kartę i obiecujesz sobie, że zrobisz to w weekend. Jest listopad. Obietnica pochodzi z marca.

Od 2013 roku robię i naprawiam strony na WordPressie i mogę z ręką na sercu powiedzieć: większość awarii, z którymi dzwonią do mnie klienci, nie bierze się z aktualizacji. Bierze się z jej braku. Ale rozumiem ten strach, bo aktualizacja zrobiona „na pałę” też potrafi narobić bigosu. Dlatego w tym wpisie pokażę, jak aktualizować WordPressa tak, żeby spać spokojnie, i co zrobić, gdy mimo wszystko coś wybuchnie.

Dlaczego w ogóle trzeba aktualizować WordPressa

Bo WordPress to nie obraz w ramce, który raz powieszony wisi do końca świata. To raczej samochód. Jeździ świetnie, dopóki ktoś wymienia olej, klocki i opony na zimowe. Aktualizacje robią trzy rzeczy:

• Łatają dziury w zabezpieczeniach. To najważniejszy powód. Gdy w popularnej wtyczce zostaje wykryta luka, autor wydaje poprawkę, a informacja o luce trafia do publicznych baz. Od tej chwili boty na całym świecie szukają stron, które poprawki nie zainstalowały. Twoja strona z wtyczką sprzed roku to dla nich jak samochód z kluczykami w stacyjce. Więcej o tym, skąd biorą się te luki, piszę we wpisie o podatnościach WordPressa.
• Utrzymują zgodność z serwerem. Hostingi co jakiś czas podnoszą wersję PHP, bo stare przestają dostawać poprawki bezpieczeństwa. Wtyczka napisana pod PHP sprzed kilku lat potrafi na nowej wersji po prostu przestać działać. WordPress podaje na swojej stronie zalecane wymagania serwera^[1] i warto się ich trzymać.
• Dają nowe funkcje i poprawki błędów. To najprzyjemniejsza część, choć szczerze mówiąc, dla większości firmowych stron najmniej istotna.

W filmie „Dzień świstaka” Bill Murray budzi się codziennie w tym samym dniu. Strona bez aktualizacji ma podobnie, tyle że świat wokół niej idzie do przodu, a hakerzy z każdym dniem znają ją lepiej.

Co może pójść nie tak (żeby wiedzieć, czego się bać)

Uczciwie: aktualizacja czasem coś psuje. Najczęściej widzę takie scenariusze:

• Konflikt wtyczek. Wtyczka A po aktualizacji zaczyna gryźć się z wtyczką B. Jedna zmieniła sposób działania, druga jeszcze się nie dostosowała.
• Stary motyw kontra nowy WordPress. Motyw kupiony w 2017 roku, nieaktualizowany od 2019, z autorem, który zniknął jak kamfora. Nowy WordPress już go nie rozumie.
• Zmodyfikowane pliki. Ktoś kiedyś „na szybko” poprawił coś bezpośrednio w kodzie wtyczki albo motywu. Aktualizacja nadpisała zmiany i nagle znika fragment strony, który „zawsze tam był”.
• Przerwana aktualizacja. Zamknięta karta, padnięty internet albo za mało pamięci na serwerze. Strona zostaje zawieszona w trybie konserwacji z komunikatem, że jest chwilowo niedostępna.

Brzmi groźnie, ale każdy z tych problemów ma rozwiązanie, a większości da się uniknąć, jeśli zrobisz kilka rzeczy przed kliknięciem przycisku.

Zanim klikniesz „Aktualizuj”: przegląd przed lotem

Piloci przed startem przechodzą checklistę, nawet jeśli latają od 30 lat. Nie dlatego, że nie umieją, tylko dlatego, że wiedzą, jak drogi bywa jeden pominięty punkt. Moja lista przed aktualizacją wygląda tak:

1. Kopia zapasowa. Cała, czyli pliki i baza danych, a nie tylko „jakiś eksport wpisów”. I przechowywana poza serwerem. To jest punkt, którego nie wolno pominąć, nawet przy najmniejszej aktualizacji. O tym, jak zrobić ją porządnie, napisałem osobny wpis: kopia zapasowa WordPress. Oficjalna dokumentacja WordPressa też zaczyna instrukcję aktualizacji właśnie od kopii^[2].
2. Changelog, czyli lista zmian. Przy dużych aktualizacjach (np. z wersji 3.x na 4.0 wtyczki) zajrzyj, co się zmieniło. Jeśli autor pisze „przepisaliśmy wszystko od nowa”, to sygnał, żeby zrobić to ostrożniej.
3. Zgodność. Sprawdź, czy wtyczka jest testowana z Twoją wersją WordPressa i czy motyw ma aktualnego autora. Wtyczka, która nie dostała poprawki od trzech lat, to kandydatka do wymiany, a nie do aktualizacji.
4. Pora. Nie w piątek o 16:00 i nie w środku kampanii reklamowej. Najlepiej rano w dzień roboczy, kiedy masz czas zareagować, a hosting ma kogoś w pracy.
5. Staging, jeśli masz. Kopia strony na osobnym adresie, na której testujesz aktualizacje, zanim zrobisz je na żywej stronie. Przy sklepach i dużych serwisach to standard, przy małej wizytówce wystarczy dobra kopia.

Aktualizacja krok po kroku, czyli bez brawury

Kopia zrobiona? To teraz właściwa część. Kolejność ma znaczenie:

1. Najpierw wtyczki, pojedynczo albo małymi grupkami. Zamiast „zaznacz wszystko” aktualizuj po 2-3 wtyczki i po każdej partii zajrzyj na stronę. Jeśli coś się wysypie, od razu wiesz, kto zawinił. Przy 17 naraz zostajesz detektywem bez poszlak.
2. Potem motyw. Jeśli korzystasz z motywu potomnego (child theme), Twoje zmiany przetrwają. Jeśli ktoś dłubał bezpośrednio w motywie głównym, aktualizacja je nadpisze, więc najpierw je zabezpiecz.
3. Na końcu rdzeń WordPressa. Drobne wersje poprawkowe (np. z 6.8.1 na 6.8.2) WordPress na większości stron instaluje sam w tle. Duże wersje wymagają Twojego kliknięcia.
4. Tłumaczenia. Bezpieczne, możesz klikać śmiało.

I najważniejsze: nie zamykaj karty w trakcie aktualizacji. To nie jest dobry moment na przewietrzenie przeglądarki. Jeśli WordPress utknie z komunikatem o zaplanowanych pracach konserwacyjnych, zwykle wystarczy usunąć z głównego katalogu strony plik .maintenance przez FTP albo menedżer plików w panelu hostingu^[2].

Testy po aktualizacji: klikaj jak klient

Aktualizacja się skończyła, panel świeci na zielono. To jeszcze nie koniec. Panel administratora może działać, a strona dla klientów może wyglądać jak po przejściu tornada. Sprawdź:

• stronę główną i kilka podstron, także na telefonie,
• formularz kontaktowy, wysyłając prawdziwą wiadomość testową (bo formularz, który wygląda dobrze, a nie wysyła maili, to klasyk, o którym pisałem w tekście o tym, co zrobić, gdy formularz kontaktowy nie wysyła wiadomości),
• w sklepie cały proces zakupu, łącznie z płatnością testową,
• menu, slidery, galerie i wszystko, co się rusza,
• czy nie pojawiły się dziwne komunikaty, puste miejsca albo błędy 404 na podstronach.

Wyczyść przy tym pamięć podręczną (cache) wtyczki i przeglądarki. Inaczej możesz oglądać stronę sprzed aktualizacji i cieszyć się, że wszystko działa, podczas gdy klienci widzą coś zupełnie innego.

„Na tej stronie wystąpił błąd krytyczny”. Co teraz?

No dobrze, wydarzyło się. Wchodzisz na stronę, a zamiast niej biała plansza z jednym zdaniem: „Na tej stronie wystąpił błąd krytyczny”. Pierwsza reakcja to zwykle mieszanka paniki i myśli o zmianie zawodu. Spokojnie. Jak mówił Gandalf: „Nie od nas zależy, w jakich czasach przyszło nam żyć. Możemy tylko zdecydować, co zrobimy z czasem, który został nam dany”. A tego czasu potrzeba zwykle niewiele.

Ten komunikat oznacza, że jakiś fragment kodu PHP, najczęściej wtyczka albo motyw, wyrzucił błąd, którego WordPress nie potrafi obejść. Dobra wiadomość jest taka, że od wersji 5.2 WordPress ma wbudowaną ochronę przed takimi błędami^[3]. Co robisz:

1. Sprawdź skrzynkę administratora. WordPress wysyła na adres administratora strony maila z informacją, która wtyczka lub motyw spowodował błąd, i z linkiem do trybu odzyskiwania (recovery mode). Po kliknięciu logujesz się do panelu, w którym winowajca jest wstrzymany, i możesz go wyłączyć albo przywrócić poprzednią wersję. Zajrzyj też do spamu, ten mail lubi się tam chować.
2. Nie dostałeś maila? Połącz się z serwerem przez FTP albo menedżer plików hostingu, wejdź do katalogu wp-content/plugins i zmień nazwę folderu ostatnio aktualizowanej wtyczki, np. dopisując na końcu „-off”. WordPress przestanie ją ładować. Jeśli strona wróciła, masz winowajcę.
3. Nie wiesz, która to wtyczka? Zmień nazwę całego folderu plugins. Wszystkie wtyczki się wyłączą. Potem przywróć nazwę i włączaj je po kolei w panelu, aż strona znowu się wysypie.
4. Włącz tryb debugowania. W pliku wp-config.php ustaw WP_DEBUG i WP_DEBUG_LOG na true, a błędy trafią do pliku wp-content/debug.log^[4]. W logu zwykle jest czarno na białym napisane, który plik i która linijka narozrabiały. Po diagnozie wyłącz debugowanie, bo log nie powinien wisieć publicznie.
5. Ostateczność: przywróć kopię. Właśnie po to robiłeś ją przed aktualizacją. Kopia przywrócona w 10 minut jest warta więcej niż godzina heroicznej walki z kodem.

Jedna ważna uwaga: jeśli błąd krytyczny pojawił się nagle, bez żadnej aktualizacji z Twojej strony, a w plikach widzisz rzeczy, których nie rozpoznajesz, to może nie być wina aktualizacji, tylko włamania. Wtedy zajrzyj do wpisu o tym, co zrobić, gdy strona WordPress została zhakowana.

Automatyczne aktualizacje: włączać czy nie?

Od wersji 5.5 WordPress pozwala włączyć automatyczne aktualizacje dla każdej wtyczki i motywu z osobna^[5]. To kuszące: włączasz i zapominasz. Moje zdanie jest takie:

• Tak dla drobnych aktualizacji bezpieczeństwa rdzenia (są domyślnie włączone i niech tak zostanie) oraz dla prostych, popularnych wtyczek od solidnych autorów.
• Raczej nie dla wtyczek, od których zależy coś kluczowego: sklepu, płatności, kreatora stron, na którym zbudowany jest cały wygląd, albo formularzy, z których przychodzą zapytania.
• Zawsze z kopią. Automatyczna aktualizacja bez automatycznej kopii zapasowej to jak skok na bungee bez sprawdzenia liny. Pewnie się uda. Pewnie.

Złoty środek dla większości firmowych stron to automaty dla drobiazgów plus regularny, ręczny przegląd reszty, na przykład raz na dwa tygodnie albo raz w miesiącu.

A może po prostu nie ruszać? Mity o aktualizacjach

„Działa, to nie ruszam”. Działa, dopóki działa. Strona bez aktualizacji nie psuje się od razu, psuje się nagle. Zwykle wtedy, gdy hosting zmieni wersję PHP albo bot znajdzie lukę w wtyczce sprzed dwóch lat. A naprawa po włamaniu kosztuje kilka razy więcej niż rok regularnych aktualizacji.

„Mam wtyczkę bezpieczeństwa, więc aktualizacje są zbędne”. Wtyczka bezpieczeństwa to alarm w domu. Przydaje się, ale nie zastąpi zamknięcia drzwi na klucz. Więcej o tym, co realnie chroni stronę, piszę w tekście o tym, jak zabezpieczyć stronę WordPress przed włamaniem.

„Wyłączona wtyczka jest bezpieczna”. Niestety nie. Pliki nieaktywnej wtyczki nadal leżą na serwerze i bywają dostępne z zewnątrz. Wtyczki, których nie używasz, po prostu usuń.

„Mała strona nikogo nie interesuje”. Botów nie interesuje, czy jesteś małą kwiaciarnią, czy dużym sklepem. Skanują wszystko jak leci, a Twoja strona to dla nich darmowy serwer do rozsyłania spamu albo podrzucania linków do kasyn.

Najczęstsze pytania

Jak często aktualizować WordPressa?

Dla typowej strony firmowej wystarczy przegląd raz na dwa tygodnie lub raz w miesiącu. Aktualizacje bezpieczeństwa, szczególnie te oznaczone jako krytyczne, warto instalować od razu, gdy się pojawią.

Czy aktualizacja WordPressa usunie moje treści?

Nie. Wpisy, strony, zdjęcia i ustawienia są w bazie danych i katalogu uploads, których aktualizacja nie rusza. Zagrożone są tylko zmiany wprowadzone bezpośrednio w plikach wtyczek lub motywu, dlatego przed aktualizacją zawsze rób kopię zapasową.

Co oznacza komunikat „Na tej stronie wystąpił błąd krytyczny”?

Oznacza błąd w kodzie PHP, najczęściej we wtyczce lub motywie. WordPress wysyła wtedy administratorowi maila z linkiem do trybu odzyskiwania. Jeśli mail nie dotarł, winowajcę można wyłączyć, zmieniając nazwę jego folderu przez FTP.

Co aktualizować najpierw: wtyczki czy WordPressa?

Najbezpieczniej najpierw wtyczki, potem motyw, a na końcu rdzeń WordPressa, zawsze po wykonaniu kopii zapasowej. Wtyczki aktualizuj pojedynczo lub w małych grupach i po każdej partii sprawdzaj stronę.

Nie masz czasu na aktualizacje? Od tego jestem

Jeśli czerwone kółeczko w panelu wywołuje u Ciebie lekką palpitację serca, mogę zająć się tym za Ciebie. W ramach administracji stronami robię kopie, aktualizacje i testy po nich, a gdy coś już się wysypało, pomagam w ramach naprawy stron. Zadzwoń: +48 606 719 343 albo napisz: lukasz@freelancerka.com. Obiecuję, że nie kliknę „zaznacz wszystko” w piątek o 16:00.

Przypisy i źródła

Wszystkie źródła zweryfikowane; dostęp: 5 listopada 2026.

1. WordPress.org, „Requirements” - wordpress.org
2. WordPress Documentation, „Updating WordPress” - wordpress.org
3. Make WordPress Core, „Fatal Error Recovery Mode in 5.2” - make.wordpress.org
4. Advanced Administration Handbook, „Debugging in WordPress” - developer.wordpress.org
5. WordPress Documentation, „Plugin and themes auto-updates” - wordpress.org