Odkładanie aktualizacji zwiększa ryzyko, ale kliknięcie „Aktualizuj wszystko” na ważnej stronie bez kopii również nie jest dobrym planem. Bezpieczny proces powinien być powtarzalny i kończyć się testem najważniejszych funkcji.
W tym poradniku
Co sprawdzić przed aktualizacją?
Zacznij od pełnej kopii plików i bazy danych. Backup powinien znajdować się również poza aktualizowanym serwerem, a sposób jego odtworzenia musi być znany. Sama informacja „hosting robi kopie” nie mówi jeszcze, jak długo są przechowywane i ile trwa ich przywrócenie.
Przejrzyj listę zmian, wymagania wersji PHP i znane problemy. W przypadku sklepu lub rozbudowanej strony najpierw odtwórz kopię na środowisku testowym. Zapisz też stan kluczowych funkcji, aby po aktualizacji porównać je w tych samych warunkach.
Aktualizuj etapami
Nie wprowadzaj jednocześnie aktualizacji systemu, nowej wersji PHP i dużej przebudowy strony. Mniejsza liczba zmian ułatwia wskazanie przyczyny ewentualnego błędu. Po każdym logicznym etapie wyczyść odpowiednie pamięci podręczne i wykonaj krótki test.
- wybierz termin o mniejszym ruchu i poinformuj osoby obsługujące stronę,
- potwierdź wykonanie kopii bezpośrednio przed pracami,
- aktualizuj tylko rozszerzenia z zaufanego, aktywnie wspieranego źródła,
- nie modyfikuj plików rdzenia WordPressa ani oryginalnego motywu nadrzędnego,
- notuj wykonane zmiany i ich kolejność.
Testy po aktualizacji
Samo pojawienie się strony głównej nie oznacza sukcesu. Sprawdź logowanie, formularz kontaktowy, wysyłkę e-maili, menu, wyszukiwarkę i podstrony korzystające z nietypowych modułów. W sklepie przejdź pełną ścieżkę zakupu w uzgodniony sposób, łącznie z płatnością i wiadomościami transakcyjnymi.
Przejrzyj logi błędów, konsolę przeglądarki oraz widok mobilny. Warto wrócić do strony po kilku godzinach, ponieważ część zadań wykonuje się dopiero przez cron.
Co zrobić, gdy aktualizacja zepsuje stronę?
Jeżeli panel działa, zacznij od ustalenia, który etap wywołał problem. Gdy pojawia się biały ekran lub błąd krytyczny, pomocny jest log PHP i czasowe wyłączenie konkretnej wtyczki przez zmianę nazwy jej katalogu. Tryb debugowania nie powinien wyświetlać szczegółów błędów publicznie na produkcji.
Jeśli szybka naprawa nie jest możliwa, użyj wcześniej przygotowanego planu powrotu i przywróć spójną parę: pliki oraz bazę z tego samego momentu. Dopiero potem diagnozuj konflikt na kopii testowej.
Potrzebujesz pomocy?