Aktualizacja WordPress – jak ją bezpiecznie przeprowadzić?

Jak zaktualizować WordPress w kokpicie krok po kroku?

Cały proces zajmuje kilka minut, ale kolejność ma znaczenie. Najpierw aktualizuję rdzeń WordPressa, potem wtyczki pojedynczo, na końcu motyw. Ta sekwencja minimalizuje ryzyko konfliktów między komponentami. Poniżej dokładna procedura, którą stosuję na każdej stronie klienta. Same aktualizacje to naturalny etap już po tym, jak zainstalujesz WordPressa.

1. Zaloguj się do panelu administracyjnego WordPress pod adresem twoja-domena.pl/wp-admin.
2. Przejdź do zakładki Kokpit → Aktualizacje. Zobaczysz listę wszystkich dostępnych aktualizacji: rdzenia, wtyczek i motywów.
3. Wykonaj pełną kopię zapasową strony. Używam do tego Duplicatora lub UpdraftPlus. Backup musi obejmować pliki i bazę danych.
4. Kliknij przycisk Zaktualizuj teraz przy najnowszej wersji WordPressa. Nie zamykaj karty przeglądarki do zakończenia procesu.
5. Po aktualizacji rdzenia wróć do zakładki Aktualizacje. Zaznacz pierwszą wtyczkę i kliknij Zaktualizuj. Aktualizuj wtyczki pojedynczo, nie zbiorczo.
6. Po każdej zaktualizowanej wtyczce otwórz stronę w nowej karcie i sprawdź czy wszystko działa. Jeśli coś się wysypie, od razu wiesz która wtyczka jest problemem.
7. Na końcu zaktualizuj motyw WordPress. Jeśli korzystasz z motywu potomnego, aktualizacja nadpisze tylko motyw główny. Twoje modyfikacje w child theme pozostaną nienaruszone.
8. Wyczyść pamięć podręczną (cache) w swojej wtyczce cachującej i sprawdź stronę na froncie.

Aktualizacja rdzenia WordPress do najnowszej wersji

Rdzeń to fundament całego systemu. Każda nowa wersja WordPressa zawiera poprawki bezpieczeństwa, łatki krytycznych błędów i zmiany w API, od których zależą wtyczki i motywy. Rozróżniam dwa typy wydań: główne (np. 6.4 → 6.5) wprowadzają nowe funkcje i zmiany w edytorze Gutenberg, poboczne (np. 6.5.1 → 6.5.2) naprawiają wyłącznie luki i bugi. Poboczne instaluję od razu. Przy głównych najpierw sprawdzam changelog na wordpress.org i czekam 3-5 dni po premierze, aż autorzy wtyczek wypuszczą kompatybilne wersje. Aktualizację rdzenia WordPress zawsze przeprowadzam jako pierwszą, przed wtyczkami i motywem. Odwrotna kolejność generuje konflikty, bo wtyczka zaktualizowana pod nowe API trafi na stary rdzeń.

Aktualizacja wtyczek w WordPressie – pojedynczo czy zbiorczo?

Zbiorcza aktualizacja wtyczek oszczędza 2 minuty, ale potrafi kosztować godziny debugowania WordPress. Gdy aktualizujesz 12 wtyczek naraz i strona przestaje działać, nie wiesz która z nich jest odpowiedzialna. Dlatego na stronach produkcyjnych aktualizuję wtyczki pojedynczo. Po każdej klikam frontend, sprawdzam formularze, koszyk w WooCommerce i kluczowe podstrony. Jeśli widzę problem, cofam tę jedną wtyczkę z kopii zapasowej i zgłaszam błąd autorowi. Zbiorczą aktualizację stosuję wyłącznie na świeżym stagingu, gdzie mogę szybko przywrócić całe środowisko. Na stronie klienta, która generuje zamówienia i leady, taki skrót to ryzyko, na które nie ma uzasadnienia. Zainstalowane wtyczki, które od ponad 6 miesięcy nie otrzymały aktualizacji, traktuję jako potencjalne zagrożenie i szukam dla nich zamienników.

Aktualizacja motywu WordPress bez utraty zmian

Każda aktualizacja motywu nadpisuje wszystkie pliki w katalogu motywu głównego. Jeśli edytowałeś functions.php, style.css lub szablony bezpośrednio w motywie, Twoje zmiany znikną. Rozwiązaniem jest motyw potomny (child theme), który przechowuje modyfikacje w osobnym folderze wp-content/themes/nazwa-child. Aktualizacja motywu WordPress dotyczy wtedy wyłącznie motywu rodzica, a child theme zostaje nietknięty. Przed każdym update’m sprawdzam jeszcze czy w motywie głównym nie dodałem ręcznie kodów śledzących Google Analytics, piksela Facebooka albo pliku weryfikacyjnego Search Console. Te elementy przenoszę wcześniej do wtyczki Code Snippets lub sekcji head przez functions.php w child theme. Dzięki temu automatyczna aktualizacja motywu WordPress nie usunie żadnej integracji.

Testy po aktualizacji WordPress – co sprawdzić zanim uznasz, że działa

Aktualizacja, która przeszła bez błędu w kokpicie, wcale nie oznacza, że strona działa. Białego ekranu nie zobaczysz, ale koszyk potrafi przestać dodawać produkty, formularz kontaktowy – nie wysyłać maili, a płatność może zatrzymać się na bramce lub po prostu się odłączyć od panelu zewnętrznego. Dlatego po każdej aktualizacji WordPress przechodzę stałą listę testów w tej samej kolejności: od najważniejszych ścieżek generujących pieniądze po elementy techniczne. Zajmuje to kilka minut, a wyłapuje 90% problemów, zanim zauważy je klient.

Checklista testów po aktualizacji WordPress:

• Strona główna i podstrony dynamiczne – otwórz front w trybie incognito i sprawdź, czy layout się nie rozjechał (to najczęstszy skutek konfliktu motywu z wtyczką).
• Formularze kontaktowe – wyślij testową wiadomość i potwierdź, że mail faktycznie dotarł, a nie tylko pokazał komunikat „wysłano”.
• Koszyk WooCommerce – dodaj produkt, przejdź do koszyka i do kasy. Sprawdź, czy liczą się ceny, wysyłka i kupony.
• Płatności – wykonaj testową transakcję (tryb sandbox bramki), bo aktualizacja wtyczki płatności potrafi cicho zerwać połączenie z operatorem.
• Maile transakcyjne – potwierdzenie zamówienia, rejestracja konta, reset hasła. To ścieżki, które klient zauważa jako pierwsze.
• Logowanie i panel administracyjny – wyloguj się i zaloguj ponownie, sprawdź, czy kokpit i edytor Gutenberg działają bez błędów.
• Wtyczki cache i optymalizujące – wyczyść pamięć podręczną, przeładuj stronę i upewnij się, że po czyszczeniu cache front nadal wygląda poprawnie.
• Core Web Vitals – przepuść stronę przez PageSpeed Insights. Aktualizacja rdzenia i PHP zwykle poprawia wydajność, ale nowa wersja wtyczki potrafi ją pogorszyć.
• Konsola błędów przeglądarki i logi serwera – otwórz narzędzia deweloperskie (F12) i sprawdź, czy nie sypie błędami JS, oraz zajrzyj w logi błędów PHP na hostingu.
• Indeksacja i błędy 500 – zerknij do Google Search Console, czy po aktualizacji nie pojawiły się błędy serwera, które crawler zdąży zaindeksować w ciągu godzin.

Jeśli którykolwiek test wypada źle, nie aktualizuję niczego dalej – wracam do ostatniej sprawnej kopii zapasowej albo cofam pojedynczą wtyczkę, którą właśnie zmieniłem. Dlatego aktualizuję wtyczki pojedynczo: gdy test koszyka padnie, dokładnie wiem, która wtyczka odpowiada za problem.

Dlaczego regularne aktualizacje WordPress są konieczne?

WordPress napędza ponad 40% wszystkich stron w internecie. Ta popularność sprawia, że jest głównym celem ataków. Z raportów Sucuri wynika, że większość zhackowanych witryn działała na przestarzałych wersjach CMS WordPress z niezałatanymi lukami. Regularne aktualizacje WordPressa zamykają te luki zanim ktokolwiek zdąży je wykorzystać. To nie kwestia higieny. To kwestia przetrwania strony. Każdy tydzień zwłoki z update’m zwiększa powierzchnię ataku, bo exploity na starsze wersje są publicznie dokumentowane i dostępne dla każdego.

Jak często aktualizować WordPress?

WordPress aktualizuję według prostej zasady: poprawki bezpieczeństwa od razu, duże wydania z kilkudniowym opóźnieniem, a wtyczki i motyw w stałym rytmie tygodniowym. Nie ma jednej „częstotliwości aktualizacji WordPress” dla wszystkiego, bo każdy komponent ma inne ryzyko i inne tempo wydań. Rdzeń poboczny to czysta łatka, którą warto wgrać natychmiast. Duża wersja rdzenia i aktualizacja wtyczek WordPress to już zmiany, które potrafią coś zepsuć, więc traktuję je ostrożniej. Poniżej dokładny harmonogram, który stosuję na stronach klientów.

Element	Jak często	Tryb
Rdzeń poboczny (np. 6.5.1 → 6.5.2)	Od razu, tego samego dnia	Automatycznie
Rdzeń główny (np. 6.4 → 6.5)	3–5 dni po premierze	Ręcznie, po sprawdzeniu changelogu
Wtyczki WordPress	Raz w tygodniu, pojedynczo	Ręcznie na produkcji, auto na prostych stronach
Motyw WordPress	Przy okazji wtyczek, po backupie	Ręcznie (z motywem

Aktualizacja a bezpieczeństwo strony – czym ryzykujesz bez update’u?

Na przestrzeni lat naprawiałem dziesiątki stron, które padły ofiarą ataku wyłącznie przez brak aktualizacji. Scenariusze powtarzają się. Stara wtyczka kontaktowa z niezałataną podatnością pozwala wstrzyknąć kod PHP. Przestarzały motyw z otwartą luką XSS przekierowuje odwiedzających na strony phishingowe. Nieaktualizowany rdzeń umożliwia przejęcie konta administratora bez znajomości hasła. Wirusy na stronie internetowej potrafią działać miesiącami w tle, rozsyłając spam z Twojej domeny. Efekt? Google oznacza witrynę jako niebezpieczną, bezpieczeństwo strony spada do zera, a odbudowa reputacji domeny zajmuje tygodnie. Koszt naprawy zhackowanej strony to wielokrotność ceny regularnej administracji WordPress.

Jak przygotować stronę przed aktualizacją?

Przygotowanie do aktualizacji WordPress decyduje o tym czy proces przebiegnie gładko czy skończy się awarią. Zanim kliknę cokolwiek w kokpicie, wykonuję trzy rzeczy w stałej kolejności: backup, weryfikacja kompatybilności wtyczek i sprawdzenie wersji PHP na serwerze. Ten schemat stosuję od lat i dzięki niemu ani razu nie straciłem danych klienta. Pomijanie któregokolwiek z tych kroków to najczęstszy błąd, który widzę u osób zarządzających stroną WordPress samodzielnie. Pełna kopia zapasowa zajmuje 5 minut. Naprawa strony bez backupu potrafi zająć dni.

Kopia zapasowa przed aktualizacją — co musi obejmować

Backup przed aktualizacją musi obejmować dwie rzeczy: komplet plików z serwera i pełny eksport bazy danych. Kopia tylko plików albo tylko bazy jest bezużyteczna przy przywracaniu strony. Kluczowy jest moment wykonania — pełną kopię robię zawsze bezpośrednio przed aktualizacją, bo ta z poprzedniej nocy nie wystarczy, jeśli od rana doszły zamówienia, wpisy albo zmiany ustawień. Przywrócenie z dobrej wtyczki trwa 3-5 minut i nie wymaga dostępu do FTP ani phpMyAdmin. Porównanie wtyczek backupowych wraz z zakresem darmowych planów opisałem osobno w poradniku o kopiach zapasowych stron www.

Sprawdzenie kompatybilności wtyczek i wersji PHP

Przed każdą aktualizacją otwieram repozytorium wordpress.org i sprawdzam ostatnią datę aktualizacji każdej zainstalowanej wtyczki. Jeśli wtyczka nie była aktualizowana od 12 miesięcy, traktuję ją jako ryzyko. Oznacza to że autor prawdopodobnie porzucił projekt i nie testował zgodności z najnowszą wersją WordPressa. Kolejny krok to weryfikacja wersji PHP. Loguję się do panelu hostingu, najczęściej cPanel lub DirectAdmin, i sprawdzam jaka wersja PHP jest przypisana do domeny. Najnowsza wersja systemu WordPress 6.x wymaga minimum PHP 7.4, ale optymalnie działa na PHP 8.2 lub 8.3. Część starszych motywów WordPress i wtyczek nie wspiera PHP 8.x. Dlatego aktualizację PHP WordPress przeprowadzam osobno, po udanym update rdzenia, i testuję stronę natychmiast po przełączeniu. Jeśli coś padnie, cofam wersję PHP w panelu hostingu w 30 sekund. Warto pamiętać, że PHP zmieniasz na poziomie serwera, nie w kokpicie WordPressa — dlatego wielu właścicieli stron szuka tej opcji w panelu administracyjnym i jej tam nie znajduje. Samą procedurę zmiany, wybór odpowiedniej wersji i testy kompatybilności opisałem w poradniku jak zaktualizować PHP w WordPressie.

Ręczna aktualizacja WordPress przez FTP – gdy kokpit nie działa

Zdarza się że po nieudanej aktualizacji panel administracyjny WordPress przestaje odpowiadać. Biały ekran, błąd 500 albo pętla przekierowań. W takiej sytuacji jedyną drogą jest ręczna aktualizacja WordPress przez klienta FTP. Używam do tego FileZilli, ale dowolny klient SFTP zadziała tak samo. Procedura wygląda identycznie niezależnie od hostingu. Cały proces trwa 10-15 minut jeśli masz przygotowaną kopię zapasową i znasz dane dostępowe do serwera.

Instrukcja:

1. Pobierz najnowszą wersję WordPressa z wordpress.org/download. Rozpakuj archiwum ZIP na dysku lokalnym.
2. Połącz się z serwerem przez klienta FTP. Dane logowania znajdziesz w panelu hostingu (cPanel, DirectAdmin) w sekcji konta FTP.
3. Przejdź do katalogu głównego strony na serwerze. Zobaczysz tam foldery wp-admin, wp-content, wp-includes oraz pliki wordpress w katalogu głównym.
4. Usuń z serwera foldery wp-admin i wp-includes. To pliki rdzenia WordPress, które zostaną zastąpione nowymi.
5. Nie usuwaj folderu wp-content. Znajdują się w nim Twoje motywy, wtyczki, media i wszystkie pliki WordPress związane z treścią strony.
6. Nie usuwaj pliku wp-config.php. Zawiera dane dostępowe do bazy danych i konfigurację strony.
7. Z rozpakowanego archiwum na dysku zaznacz wszystkie pliki i foldery z wyjątkiem wp-content. Wgraj je na serwer nadpisując istniejące pliki.
8. Po zakończeniu uploadu otwórz w przeglądarce adres twoja-domena.pl/wp-admin. Jeśli WordPress wymaga aktualizacji bazy danych, zobaczysz komunikat z przyciskiem potwierdzenia. Kliknij go.
9. Zaloguj się do kokpitu i sprawdź aktualną wersję WordPress w zakładce Aktualizacje. Zweryfikuj działanie strony na froncie, przetestuj formularze i kluczowe podstrony.
10. Po udanej ręcznej aktualizacji WordPressa aktywuj ponownie wszystkie wtyczki pojedynczo. Część mogła zostać automatycznie dezaktywowana podczas procesu.

Automatyczne aktualizacje WordPress – kiedy warto je włączyć?

Na prostych stronach wizytówkowych i blogach bez rozbudowanych integracji automatyczne aktualizacje WordPress sprawdzają się dobrze. System sam pobiera i instaluje nowe wersje rdzenia, wtyczek i motywów bez ingerencji właściciela. Problem zaczyna się przy sklepach WooCommerce, stronach z płatnymi motywami i niestandardowymi wtyczkami. Tam jedna niekompatybilna aktualizacja potrafi wyłączyć koszyk, zepsuć bramkę płatności albo rozjechać cały layout. Dlatego automatyczne aktualizacje włączam wyłącznie na stronach, które nie obsługują transakcji i nie korzystają z więcej niż 10 wtyczek. Przy rozbudowanych serwisach zostawiam automatyczne tylko aktualizacje poboczne rdzenia (łatki bezpieczeństwa) i ręcznie kontroluję resztę.

Jak skonfigurować automatyczne aktualizacje wtyczek i motywów?

WordPress oferuje dwa poziomy konfiguracji: bez kodu z poziomu kokpitu i zaawansowany przez pliki PHP. Pierwsza opcja wystarcza dla większości stron. Druga daje precyzyjną kontrolę nad tym, które komponenty aktualizują się same.

Z poziomu kokpitu:

1. Przejdź do Wtyczki → Zainstalowane wtyczki.
2. Przy wybranej wtyczce kliknij Włącz automatyczne aktualizacje. Powtórz dla każdej wtyczki WordPress, którą chcesz aktualizować automatycznie.
3. Dla motywu przejdź do Wygląd → Motywy, kliknij Szczegóły motywu i włącz automatyczne aktualizacje.

Przez wp-config.php i filtry PHP:

1. Otwórz plik wp-config.php w katalogu głównym strony.
2. Dodaj linię define(’WP_AUTO_UPDATE_CORE’, 'minor’); — rdzeń będzie aktualizował się automatycznie tylko przy wydaniach bezpieczeństwa.
3. W pliku functions.php motywu potomnego dodaj filtr add_filter(’auto_update_plugin’, '__return_true’); jeśli chcesz włączyć automatyczną aktualizację wszystkich wtyczek.
4. Aby wyłączyć automatyczne aktualizacje dla konkretnego motywu WordPress, użyj filtra add_filter(’auto_update_theme’, '__return_false’);.

Zalety i wady automatycznych aktualizacji

Decyzja o włączeniu automatycznych aktualizacji WordPress sprowadza się do jednego pytania: czy masz czas i wiedzę żeby reagować na problemy po aktualizacji, czy wolisz żeby system robił to za Ciebie kosztem kontroli. Obie opcje mają konkretne konsekwencje.

• Zalety: aktualizacje bezpieczeństwa instalują się natychmiast po wydaniu, bez czekania aż właściciel strony się zaloguje. Strona zawsze działa na najnowszej wersji WordPressa, co zmniejsza powierzchnię ataku. Oszczędność czasu przy prostych witrynach sięga kilku godzin miesięcznie.
• Wady: brak kontroli nad tym co i kiedy się zmienia. Automatyczna aktualizacja wtyczek WordPress potrafi uruchomić się w szczycie ruchu i na 30 sekund wyłączyć stronę. Konflikt między zaktualizowaną wtyczką a motywem WordPress może pozostać niezauważony przez dni jeśli nikt nie monitoruje witryny. Płatne wtyczki pobrane spoza repozytorium wordpress.org często nie wspierają automatycznych aktualizacji i wymagają ręcznego wgrania nowej wersji. Największe ryzyko to aktualizacja zbiorcza w nocy, która położy stronę, a właściciel dowie się o tym dopiero rano od klientów.

Strona WordPress nie działa po aktualizacji – co robić?

Zacznij od rozpoznania objawu, nie od szukania winnego. Objaw wskazuje warstwę, w której coś pękło, a to przesądza o dalszej ścieżce. Zanim cokolwiek zrobisz, wstrzymaj pozostałe aktualizacje. Każda kolejna zmiana zaciera obraz i utrudnia ustalenie przyczyny.

Objaw	Co zwykle za tym stoi	Pierwszy ruch
Biały ekran, zero komunikatu	błąd krytyczny PHP przy wyłączonym wyświetlaniu błędów	włącz zapis logu i przeczytaj debug.log
„Wystąpił błąd krytyczny” plus e-mail do administratora	WordPress złapał błąd i zna jego źródło	otwórz link do trybu odzyskiwania z wiadomości
Błąd 500	uszkodzony .htaccess, limit pamięci PHP, niezgodna wersja PHP	sprawdź log błędów serwera w panelu hostingu
Front działa, kokpit nie	konflikt wtyczki występujący tylko w wp-admin	zmień nazwę folderu plugins przez FTP
„Trwa zaplanowana konserwacja” nie znika	plik .maintenance został po przerwanej aktualizacji	usuń .maintenance z katalogu głównego
Strona wstaje, ale układ się rozsypał	stary cache albo style motywu niezgodne z nową wersją	wyczyść cache strony i CDN, dopiero potem diagnozuj
Błąd połączenia z bazą danych	problem leży po stronie bazy, nie plików	zweryfikuj dane dostępowe w wp-config.php

Komunikat „w witrynie wystąpił błąd krytyczny” z linkiem w mailu działa od WordPressa 5.2. Po aktualizacji oznacza najczęściej jedno: nowa wersja wtyczki lub motywu wywołała błąd PHP. Zgodnie z notatką deweloperską na make.wordpress.org tryb odzyskiwania wstrzymuje wadliwe rozszerzenie wyłącznie dla Twojej sesji, a pozostali odwiedzający nadal widzą błąd. Wyjście z trybu przywraca poprzedni stan. To wejście awaryjne do kokpitu, przez które wykonujesz właściwą poprawkę, czyli cofnięcie wersji albo wyłączenie wtyczki na stałe.

Jeśli masz biały ekran i żadnej wskazówki, włącz logowanie błędów. W wp-config.php ustaw WP_DEBUG i WP_DEBUG_LOG na true, a WP_DEBUG_DISPLAY na false. Tak opisuje to dokumentacja WordPressa w sekcji Debugging in WordPress. Log trafi do pliku wp-content/debug.log, a odwiedzający nie zobaczą komunikatów PHP. W logu zwykle widać pełną ścieżkę do pliku, czyli nazwę wtyczki lub motywu odpowiedzialnego za błąd.

Sposób aktualizacji przesądza o tym, ile pracy Cię czeka. Przy aktualizacji pojedynczej znasz winowajcę w minutę. Przy zbiorczej masz kilkanaście podejrzanych naraz. Dlatego przy większych serwisach aktualizuję wtyczki partiami i sprawdzam stronę po każdej partii. To wydłuża całość o kilka minut i skraca diagnostykę o godziny.

Kiedy cofnięcie wersji wystarczy, a kiedy nie

Cofaj dokładnie ten element, który się zepsuł, a nie całą stronę. Wtyczkę, motyw i rdzeń przywrócisz do poprzedniej wersji bez ruszania treści, a procedury dla każdego z tych przypadków opisuje osobny poradnik o cofaniu zmian w WordPressie. Po nieudanej aktualizacji liczy się jednak co innego: ustalenie, czy rollback plików w ogóle rozwiąże problem.

Część nieudanych aktualizacji system odwraca sam. Według notatek zespołu WordPressa na make.wordpress.org od wersji 6.3 przy ręcznej aktualizacji wtyczki lub motywu powstaje tymczasowa kopia w wp-content/upgrade-temp-backup. Gdy instalacja się nie powiedzie, poprzednia wersja wraca na miejsce, a wtyczka z błędem krytycznym nie zostaje ponownie włączona. Od wersji 6.6 ta sama ochrona obejmuje aktualizacje automatyczne: WordPress sprawdza stronę zapytaniem loopback i po wykryciu błędu krytycznego przywraca starszą wersję, wysyłając informację na adres administratora. Zanim więc zaczniesz cofać ręcznie, zajrzyj do skrzynki i na listę wtyczek. Może się okazać, że wersja już wróciła, a aktualizacja czeka w kolejce na ponowną próbę.

Ten mechanizm ma granicę, którą warto znać. Zespół WordPressa wprost zaznacza, że tymczasowa kopia nie służy do cofania aktualizacji zakończonej sukcesem. Chroni wyłącznie przed błędem podczas instalacji i przed błędem krytycznym po niej. Jeżeli pliki wgrały się poprawnie, a dopiero potem rozjechał się koszyk, formularz albo układ sekcji, automat nie zareaguje. Taki przypadek cofasz ręcznie.

Jest też sytuacja, w której podmiana plików nie pomoże wcale. Wiele wtyczek przy pierwszym uruchomieniu po aktualizacji przebudowuje własne tabele albo zapisuje opcje w nowym formacie. Starsza wersja kodu tego formatu nie rozumie i albo rzuca błąd, albo działa wadliwie. Objaw jest charakterystyczny: wróciłeś do poprzedniej wersji, a problem został. Wtedy potrzebujesz stanu bazy sprzed aktualizacji, czyli kopii zapasowej strony internetowej wykonanej razem z plikami.

Wybór ścieżki sprowadza się do czterech sytuacji:

• Aktualizowałeś pojedynczo i znasz winowajcę: cofnij wersję tego jednego elementu. Baza zostaje nietknięta, ryzyko minimalne.
• Aktualizowałeś zbiorczo: wyłącz wszystkie wtyczki i włączaj je po jednej, sprawdzając stronę po każdej. Żmudne, ale wskazuje konflikt jednoznacznie.
• Rollback nie pomógł albo wtyczka zmieniła strukturę bazy: przywróć pliki i bazę z tego samego momentu.
• Nie wiesz, co się zmieniło, bo stronę prowadzi kilka osób: najpierw sprawdź dziennik zdarzeń, dopiero potem cokolwiek cofaj.

Po powrocie do działającej wersji nie powtarzaj aktualizacji na żywej stronie. Odtwórz konflikt na kopii testowej, znajdź przyczynę tam i dopiero sprawdzoną konfigurację przenieś na produkcję.

Ile kosztuje aktualizacja WordPress i od czego zależy cena?

Samodzielna aktualizacja w kokpicie jest darmowa. Koszt pojawia się gdy potrzebujesz kogoś, kto zrobi to bezpiecznie z backupem, testem kompatybilności i gotowością do naprawy. Prosta strona wizytówkowa z kilkoma wtyczkami to 100–200 zł jednorazowo. Strona firmowa z kilkunastoma wtyczkami i testem na stagingu to 200–500 zł. Sklep WooCommerce, gdzie trzeba przetestować koszyk, płatności i maile transakcyjne, kosztuje 400–800 zł za pełną aktualizację. Stała opieka stron internetowych na WordPress zamyka się w 150–500 zł miesięcznie i obejmuje regularne aktualizacje, backup WordPress, monitoring i naprawę błędów. Cena zależy od trzech rzeczy: liczby zainstalowanych wtyczek, złożoności strony i tego czy zlecasz jednorazowo czy w modelu stałej opieki. Jedna zepsuta bramka płatnicza w sklepie kosztuje wielokrotnie więcej niż miesięczna administracja.

Najczęściej zadawane pytania o aktualizację WordPress