Aktualizacja WordPressa potrafi pójść gładko, ale potrafi też wywrócić stronę do góry nogami. Biały ekran, błędy w koszyku, znikające style, blokujący się edytor i telefony od klientów to realne skutki aktualizacji zrobionej na szybko. Da się to ograniczyć do minimum i zrobić aktualizacje w trybie bez przestojów, jeśli uporządkuje się kilka kroków wokół kopii zapasowych, testów i kolejności działań.
Kiedy aktualizacja bywa ryzykowna
Najczęściej problem pojawia się przy dużym skoku wersji rdzenia albo przy wtyczkach, które głęboko ingerują w działanie strony jak sklep, wielojęzyczność czy page builder. Ryzyko rośnie też wtedy, gdy hosting ma ostrzejsze limity pamięci i czasu wykonywania skryptów, a strona działa na wielu rozszerzeniach, które nie były dawno porządkowane.
Niebezpieczne są także aktualizacje wykonywane w godzinach szczytu oraz bez przygotowanego planu powrotu. Jeśli do tego dochodzi brak kopii i testów na kopii roboczej, to nawet drobna zmiana potrafi wstrzymać sprzedaż albo publikację nowych treści.
Kopia zapasowa która naprawdę pomaga
Kopia to nie przycisk dla świętego spokoju, tylko realna tarcza. Powinna obejmować bazę danych i wszystkie pliki strony, w tym katalog z motywami, wtyczkami oraz mediami. Najlepiej trzymać ją poza serwerem produkcyjnym, aby awaria hostingu nie zmiotła razem strony i backupu.
Warto wiedzieć jak szybko przywrócić kopię i ile to potrwa. Samo posiadanie pliku z kopią nie wystarczy. Dobrą praktyką jest przetestowanie odtwarzania na oddzielnej instalacji, choćby na subdomenie, tak aby w razie potrzeby wykonać przywrócenie bez stresu i domysłów.
Przed aktualizacją zrób świeżą kopię i sprawdź jej integralność. Jeżeli masz intensywny ruch lub sklep, rozważ także zrzut bazy tuż przed startem prac, aby ograniczyć potencjalną utratę nowych wpisów, zamówień czy komentarzy.
Staging w prosty sposób
Kopia robocza to bezpieczne miejsce do przetestowania zmian. Najłatwiej skorzystać z wbudowanego stagingu w hostingu. Jeśli go nie ma, można przygotować kopię na subdomenie, zabezpieczyć ją hasłem i wyłączyć wysyłkę maili, by nie dublować powiadomień. Na takiej kopii wykonasz aktualizacje, sprawdzisz kluczowe funkcje i dopiero potem powtórzysz działania na produkcji.
Kolejność aktualizacji i przygotowanie
Przed startem zrób przegląd wtyczek i motywów. Sprawdź wymagania wersji oraz listy zmian zwane changelogami czy deklarują zgodność z Twoją wersją WordPressa i PHP. Jeśli widzisz dawno nieaktualizowane rozszerzenia, zaplanuj ich wymianę na wspierane, ale nie mieszaj tego z samą aktualizacją rdzenia. Jedna zmiana na raz to mniej zmiennych do opanowania.
Bezpieczna kolejność zwykle wygląda tak najpierw wtyczki, potem motyw, a na końcu rdzeń, szczególnie przy dużych wydaniach. Dzięki temu rozszerzenia już są gotowe na nowe funkcje w rdzeniu. Po każdej paczce zmian zrób krótkie testy, aby szybko złapać ewentualne problemy u źródła.
Przed przejściem na większą wersję upewnij się, że serwer ma zalecane parametry pamięć, wersję PHP i limity czasu. Wyłącz na chwilę ciężkie zadania w tle, na przykład generatory miniatur czy importy, aby nie walczyły o zasoby podczas aktualizacji.
Zobacz więcej darmowej wiedzy na ProjektWordPress.pl.
Testy po aktualizacji bez technicznego żargonu
Sprawdź logowanie, edycję wpisu w edytorze blokowym, dodawanie obrazków i publikację. Przejdź kilka kluczowych podstron, także na telefonie. Jeśli masz formularze, wyślij testowe zgłoszenie i zobacz czy przychodzi mail oraz czy zapis pojawia się w panelu formularza.
W sklepie przejdź cały proces zamówienia dodanie do koszyka, wybór dostawy i płatność testowa. Rzuć okiem na wyszukiwarkę i filtrowanie produktów. Zwróć uwagę na szybkość ładowania i czy nic nie rozjechało się w układzie.
Plan B i szybki powrót do działania
Najprostszy powrót to przywrócenie kopii. Czasem wystarczy cofnąć same pliki, a bazę zostawić bez zmian, na przykład gdy problem dotyczy stylów czy skryptów. Gdy błąd dotyczy danych, przywrócenie bazy może być konieczne, ale wtedy licz się z utratą najnowszych wpisów lub zamówień jeśli nie zrobiłeś świeżego zrzutu.
Jeśli po aktualizacji padła tylko jedna wtyczka, można ją tymczasowo wyłączyć przez zmianę nazwy katalogu w menedżerze plików. To szybki sposób, by strona wstała, a problematyczne rozszerzenie poczekało na aktualizację lub zamianę. Taka interwencja bywa pomocna także przy błędach edytora i konfliktach skryptów.
Miej pod ręką krótką ściągę z wersjami które działały wcześniej. Spisz też podstawowe kroki odtwarzania kopii i dane dostępowe do hostingu. W sytuacji presji czasu taka lista skraca reakcję i zmniejsza nerwy.
Aktualizacje w oknach mniejszego ruchu
Nawet jeśli celem jest brak przestojów, warto zaplanować prace na godziny, gdy ruch jest najniższy. Wtedy nawet krótkie potknięcie mniej boli. Uprzedź zespół redakcyjny aby na chwilę wstrzymał edycję treści, co ogranicza ryzyko konfliktów w bazie podczas prac.
Cache i CDN jak uniknąć fałszywych alarmów
Po aktualizacji wiele stron pokazuje jeszcze stare wersje plików z pamięci podręcznej. Efekt bywa mylący dla Ciebie i dla użytkowników. Wyczyść cache aplikacyjny i ten po stronie serwera, a w razie potrzeby odśwież zasoby w CDN. Jeśli masz tryb deweloperski w usłudze CDN, włącz go na czas testów, aby mieć pewność, że oglądasz świeże pliki.
Nie rób pełnych czyszczeń wszystkiego bez opamiętania. Lepiej zacząć od odświeżenia kluczowych stron i zasobów, a potem w razie potrzeby poszerzać zakres. Po finalizacji prac warto rozgrzać pamięć podręczną odwiedzając najważniejsze adresy lub używając funkcji preładowania wtyczki cache.
Jeśli po aktualizacji coś wygląda źle tylko u części użytkowników, przyczyną często jest stary cache przeglądarki. Dodanie wersjonowania plików statycznych przez wtyczkę wydajności pomaga wymusić pobranie nowych stylów i skryptów bez ingerencji po stronie użytkownika.
Automatyzacja i powiadomienia z rozsądkiem
Automatyczne aktualizacje drobnych wydań bezpieczeństwa mają sens, pod warunkiem że masz włączone powiadomienia mailowe i prosty plan kontroli po fakcie. W przypadku wtyczek lepiej zostawić automatyzację tylko tym, które są kluczowe dla bezpieczeństwa i mają stabilną historię wydań, a resztę aktualizować ręcznie według rytmu na przykład raz w tygodniu po wcześniejszym teście na kopii.
Przyda się też monitoring dostępności i błędów, choćby prosty. Szybka informacja o niedostępności strony lub wzroście błędów PHP sprawia, że reagujesz od razu, a nie po godzinach. Połączenie tego z uporządkowanym procesem kopia staging test aktualizacja daje spokojną pracę bez nerwów i bez przestojów.