Bezpieczna aktualizacja WordPressa: właściwa kolejność (wtyczki, motyw, rdzeń), kopia zapasowa, automaty, plan ratunkowy po awarii i dobór wersji PHP w 2026.
Bezpieczna aktualizacja WordPressa sprowadza się do czterech zasad: najpierw kopia zapasowa, potem wtyczki pojedynczo, motyw, na końcu rdzeń - i po każdej z tych rzeczy szybki test strony. Cały proces dla typowej strony firmowej zajmuje 15-20 minut i eliminuje niemal całe ryzyko, którego boją się właściciele stron („zaktualizuję i wszystko padnie").
W tym poradniku znajdziesz sprawdzoną kolejność aktualizacji, ustawienia automatów, plan ratunkowy na wypadek awarii, zasady pracy z wersją PHP oraz odpowiedzi na najczęstsze pytania - także o to, czym różni się aktualizacja dużego sklepu od zwykłej wizytówki.
Zdecydowana większość włamań na strony WordPress wykorzystuje znane, dawno załatane luki w starych wersjach wtyczek i motywów. Napastnicy skanują internet automatycznie - nie musisz być „ważnym celem", wystarczy, że masz dziurawą wtyczkę. Bot znajdzie ją w kilka godzin od publikacji informacji o luce.
Aktualizacje to też wydajność i zgodność: nowe wydania WordPressa są testowane z nowymi wersjami PHP, a przestarzały rdzeń wcześniej czy później zablokuje aktualizację ważnej wtyczki. Regularne aktualizowanie to punkt numer jeden każdego poradnika bezpieczeństwa, w tym naszego hardeningu w 12 krokach.
Przed każdą aktualizacją - plików i bazy danych. Jeśli hosting robi codzienne kopie automatycznie (jak nasz), wystarczy wiedzieć, że ostatnia jest świeża. Jeśli nie - zrób ręcznie; jak, opisujemy w tekście o kopiach zapasowych. Kopia zamienia najgorszy scenariusz („strona padła po aktualizacji") w 15 minut przywracania.
Ważny szczegół: kopia „sprzed pięciu minut" jest lepsza niż wczorajsza, bo w sklepie internetowym przez noc mogły pojawić się zamówienia. Przy stronach transakcyjnych rób migawkę bezpośrednio przed rozpoczęciem prac.
Autorzy wtyczek dostają wersje beta WordPressa z wyprzedzeniem i publikują zgodne wydania zwykle przed premierą rdzenia. Aktualizując najpierw wtyczki, wchodzisz na nowy rdzeń z ekosystemem, który już go zna. Odwrotna kolejność (najpierw rdzeń) to proszenie się o konflikt ze starą wtyczką.
| Co | Automatycznie? | Dlaczego |
|---|---|---|
| Drobne wydania rdzenia (bezpieczeństwa) | tak, zawsze | to łatki na aktywnie wykorzystywane luki; WordPress włącza je domyślnie |
| Proste, dobrze utrzymane wtyczki | tak | ryzyko minimalne, a zaległości rosną najszybciej właśnie tu |
| Wtyczki krytyczne (WooCommerce, buildery, płatności, SEO) | ręcznie | duże wydania zmieniają zachowanie i szablony; chcesz to zrobić po kopii i z testem |
| Motyw | ręcznie | nadpisuje pliki; bez child theme skasuje modyfikacje |
| Duże wydania rdzenia (np. przejście na kolejną gałąź) | ręcznie | po kopii, poza godzinami szczytu, po aktualizacji wtyczek |
Przy sklepach, stronach z rezerwacjami i wszystkim, co zarabia, duże aktualizacje testuj najpierw na kopii roboczej - czyli klonie strony pod technicznym adresem. Kolejność: sklonuj stronę (na naszym hostingu wystarczy skopiować katalog i bazę albo poprosić nas o klon), wykonaj aktualizacje na klonie, przeklikaj, dopiero potem powtórz na produkcji. Różnicę między „testowałem na stagingu" a „zaktualizowałem w piątek o 15:00 na żywo" poznasz przy pierwszej awarii.
Bez paniki - to typowe i odwracalne:
Aktualizacja WordPressa to też aktualizacja wersji PHP w panelu hostingu. Oficjalne wymagania WordPress.org wskazują obecnie PHP w wersji co najmniej 8.3 i bazę MariaDB 10.6+ lub MySQL 8.0+; w praktyce bezpiecznym standardem produkcyjnym jest PHP 8.4, a najnowsze 8.5 dojrzało już na tyle, że główne wtyczki działają na nim bez problemów. Nowsze PHP to też realnie szybsza strona - przejście z gałęzi 7.x na 8.x daje zauważalny skok wydajności bez żadnych zmian w witrynie.
Zmieniaj o jedną wersję w górę, sprawdzaj stronę, w razie zgrzytów wróć jednym kliknięciem. Na naszym hostingu wersję PHP (aż po 8.5) przełączysz osobno dla każdej domeny w panelu - jak to zrobić, pokazujemy w poradniku o ustawieniach PHP na hostingu.
Dla strony firmowej: przegląd aktualizacji raz w tygodniu (15 minut), duże wydania - w wolniejszy dzień, nigdy w piątek po południu. Dla sklepu dodatkowo: migawka przed każdą sesją aktualizacji i test płatności po niej. Jeśli nie chcesz o tym pamiętać, robimy to w ramach stałej opieki McAsystent - aktualizacje, kopie i monitoring, bez Twojego udziału.
Łatki bezpieczeństwa instalują się same i tak ma zostać. Resztę przeglądaj raz w tygodniu - przy typowej stronie firmowej to kwadrans. Zaleganie miesiącami sprawia, że aktualizacje kumulują się w dużą, ryzykowną operację.
Nie - wpisy, strony, media i ustawienia siedzą w bazie danych, której aktualizacja rdzenia i wtyczek nie kasuje. Realne ryzyko dotyczy modyfikacji w plikach motywu bez child theme oraz rzadkich konfliktów wtyczek - i właśnie na to jest kopia zapasowa.
Najpierw wtyczki, potem motyw, na końcu rdzeń. Autorzy wtyczek publikują wydania zgodne z nowym WordPressem przed jego premierą, więc ta kolejność minimalizuje konflikty.
Sprawdź najpierw najprostsze: wyczyść cache, usuń plik .maintenance, zajrzyj do logu błędów PHP. Winną wtyczkę wyłączysz, zmieniając nazwę jej folderu w wp-content/plugins przez FTP. Gdy nie znajdujesz przyczyny - przywróć kopię i aktualizuj pojedynczo.
Minimum zalecane przez WordPress.org to 8.3; rozsądny standard produkcyjny to 8.4, a 8.5 możesz włączyć, jeśli Twoje wtyczki je wspierają (większość popularnych - tak). Wersje 7.x są po końcu wsparcia i nie otrzymują łatek bezpieczeństwa.
Traktuj ją jako ryzyko: sprawdź, czy działa z bieżącym WordPressem i PHP, poszukaj utrzymywanego zamiennika i zaplanuj wymianę. Porzucone wtyczki to najczęstsza droga włamań - luka nigdy nie zostanie załatana.
Wszystkie poradniki z kategorii: WordPress