Aktualizacja WordPressa bez strachu
Firmy nie aktualizują strony nie z lenistwa, tylko ze strachu: ostatnim razem po aktualizacji zniknął formularz. Ten strach jest uzasadniony. Rozwiązaniem nie jest nieaktualizowanie, tylko rutyna, w której każdy krok da się cofnąć.
Dlaczego aktualizacje psują strony
WordPress to rdzeń plus kilkanaście lub kilkadziesiąt wtyczek od różnych autorów plus motyw, często ze zmianami zrobionymi przez agencję bezpośrednio w jego plikach. Każda aktualizacja zmienia jeden element, a reszta musi do niego pasować. Najczęstsze awarie: wtyczka niezgodna z nową wersją PHP, dwie wtyczki, które po aktualizacji robią to samo, i motyw, którego aktualizacja nadpisuje zmiany agencji. Wszystkie trzy są do przewidzenia, jeśli aktualizuje się po kolei i sprawdza po każdym kroku.
Rutyna krok po kroku
- Kopia zapasowa plików i bazy danych. Nie „hosting robi kopie”, tylko kopia, którą widzicie, pobrana albo zapisana poza serwerem. I sprawdzona: choć raz warto odtworzyć z niej stronę na kopii roboczej, żeby wiedzieć, że działa. Kopia, której nikt nie testował, to nadzieja, nie kopia.
- Kopia robocza strony. Większość hostingów ma funkcję „staging”: klon strony pod osobnym adresem. Jeśli nie ma, da się ją zrobić ręcznie na podkatalogu albo lokalnie. Wszystko poniżej robi się najpierw tam.
- Lista tego, co macie. Wersja PHP, wersja WordPressa, lista wtyczek z datą ostatniej aktualizacji przez autora, motyw i to, czy ma motyw potomny. Wtyczka, której autor nie aktualizował od dwóch lat, to kandydat do wymiany, nie do aktualizacji.
- Kolejność: PHP, rdzeń, wtyczki, motyw. Najpierw sprawdźcie, czy wtyczki deklarują zgodność z nową wersją PHP, i zmieńcie ją w panelu hostingu (da się cofnąć jednym kliknięciem). Potem rdzeń WordPressa. Potem wtyczki, pojedynczo, zaczynając od tych, od których zależy biznes: sklep, formularze, płatności. Motyw na końcu, i tylko jeśli zmiany agencji są w motywie potomnym albo wcale ich nie ma.
- Sprawdzenie po każdym kroku, nie po wszystkich naraz. Inaczej nie wiecie, który krok zepsuł stronę.
- Produkcja. Gdy kopia robocza działa: ta sama kolejność na prawdziwej stronie, poza godzinami ruchu, z kopią zapasową zrobioną bezpośrednio przed.
Co sprawdzić po aktualizacji
- Strona główna i trzy najważniejsze podstrony: wygląd, menu, obrazki.
- Formularz kontaktowy: wysłać testowe zgłoszenie i sprawdzić, czy doszło mailem i do CRM, jeśli jest podłączony.
- Sklep: dodać produkt do koszyka, przejść do płatności, w miarę możliwości zrobić zamówienie testowe.
- Logowanie do panelu i do konta klienta w sklepie.
- Wersja mobilna, przynajmniej na jednym telefonie.
- Szybkość: ten sam pomiar przed i po. Aktualizacja, po której strona ładuje się dwa razy dłużej, nie jest skończona.
- Logi błędów PHP na hostingu: ostrzeżenia, których wczoraj nie było.
Kiedy się zatrzymać
Są sytuacje, w których lepiej przerwać i poprosić o pomoc, niż „spróbować jeszcze raz”:
- Nie macie kopii zapasowej albo nie wiecie, czy działa.
- Po aktualizacji pojawia się błąd krytyczny, a nie wiecie, która wtyczka go powoduje.
- Motyw ma zmiany zrobione bezpośrednio w plikach, bez motywu potomnego. Aktualizacja je skasuje.
- Skok PHP o dwie wersje naraz albo wtyczka, która w opisie aktualizacji ma słowa „breaking change” lub „migracja”.
- Sklep w trakcie promocji albo dzień przed ważnym terminem. Aktualizacje poczekają tydzień, awaria nie.
Jak często
| Co | Jak często |
|---|---|
| Poprawki bezpieczeństwa rdzenia i wtyczek | W ciągu kilku dni od wydania |
| Zwykłe aktualizacje wtyczek | Raz w miesiącu, w jednym bloku |
| Duże wersje WordPressa i PHP | Po miesiącu od wydania, gdy wtyczki nadrobią zgodność |
| Test odtworzenia kopii | Raz na kwartał |
Ta rutyna zajmuje godzinę lub dwie miesięcznie i jest dokładnie tym, co robię w ramach opieki miesięcznej, razem z monitoringiem i pulą drobnych zmian.