Backup przed aktualizacją motywu WordPress powinien obejmować zarówno wszystkie pliki strony, jak i pełny zrzut bazy danych SQL. Kopię wykonaj bezpośrednio przed zmianą, niezależnie od automatycznych kopii hostingu. Aktualizacja nadpisuje pliki motywu, a konflikt z wtyczką lub wersją PHP może spowodować błędy wyglądu, funkcji, a nawet całej witryny.
Co musi zawierać pełny backup WordPressa?
Sama kopia plików nie wystarczy. Pliki odpowiadają za kod, motywy, wtyczki i multimedia, natomiast baza danych przechowuje treść strony, użytkowników, ustawienia oraz część konfiguracji motywu. Do odtworzenia działającej witryny potrzebujesz obu elementów z możliwie tego samego momentu.
Pełny backup powinien obejmować:
- Folder wp-content – motywy, wtyczki, multimedia i inne pliki przesłane do biblioteki mediów.
- Plik wp-config.php – konfigurację instalacji i dane potrzebne do połączenia z bazą.
- Plik .htaccess – jeżeli znajduje się w katalogu głównym strony.
- Pełny zrzut bazy danych SQL – wpisy, strony, ustawienia, konta użytkowników i dane dodatków, na przykład WooCommerce.
Backup wykonany poprzedniej nocy może nie zawierać porannych zamówień, formularzy, wpisów lub zmian ustawień. Dlatego przed aktualizacją motywu wykonaj nową kopię, pobierz ją poza serwer i sprawdź, czy proces zakończył się bez błędów.
Jak wykonać backup przed aktualizacją motywu?
Najprostsza metoda polega na użyciu wtyczki do kopii zapasowych. UpdraftPlus jest jednym z przykładów, ale nie jedynym rozwiązaniem. Możesz też skorzystać z panelu hostingu albo wykonać kopię ręcznie przez FTP lub SFTP i narzędzie do eksportu bazy danych.
Procedura z użyciem wtyczki, na przykład UpdraftPlus, wygląda następująco:
- Zaloguj się do panelu administracyjnego WordPressa i otwórz ustawienia używanej wtyczki backupowej.
- Uruchom ręczne tworzenie kopii wszystkich dostępnych elementów, czyli plików oraz bazy danych.
- Poczekaj na zakończenie procesu i sprawdź, czy wtyczka nie zgłosiła błędu.
- Pobierz utworzone archiwa plików i eksport bazy danych na komputer lub do niezależnej lokalizacji.
- Zapisz datę wykonania kopii i dopiero wtedy rozpocznij aktualizację motywu.
Automatyczny backup hostingu jest przydatny, ale nie zawsze zastępuje kopię wykonywaną tuż przed zmianą. Harmonogram może uruchamiać się raz dziennie lub rzadziej, a sposób przywracania zależy od konkretnego panelu. Przed ważną aktualizacją sprawdź, czy hosting pozwala odtworzyć osobno pliki i bazę oraz czy masz dostęp do kopii.
| Metoda | Zalety | Wady | Dla kogo |
|---|---|---|---|
| Wtyczka | Szybka obsługa i możliwość wykonania kopii z panelu WordPressa | Zależność od działania WordPressa, wtyczki i wolnego miejsca na serwerze | Dla większości blogów i prostych stron |
| Hosting | Backup wykonywany poza panelem strony, często z opcją szybkiego przywracania | Różne harmonogramy, zakresy kopii i zasady przechowywania zależne od dostawcy | Dla osób korzystających z narzędzi hostingu |
| Ręcznie przez FTP i SQL | Pełna kontrola nad plikami i eksportem bazy | Wymaga dostępu do serwera i większej wiedzy technicznej | Dla administratorów i rozbudowanych instalacji |
Przy dużej stronie lub sklepie warto najpierw wykonać aktualizację na kopii testowej, czyli w środowisku stagingowym. Staging pozwala sprawdzić motyw, wtyczki i kluczowe funkcje bez narażania działającej witryny.
Motyw potomny a utrata zmian w kodzie
Backup pozwala wrócić do wcześniejszego stanu, ale nie rozwiązuje problemu nadpisywania ręcznych zmian. Aktualizacja motywu głównego zastępuje jego pliki nową wersją. Jeżeli edytowałeś bezpośrednio style.css, functions.php lub pliki szablonów, te modyfikacje mogą zniknąć.
Motyw potomny przechowuje własne style, funkcje i szablony oddzielnie od motywu nadrzędnego. Aktualizujesz wtedy motyw główny, a zmiany zapisane w child theme pozostają na miejscu. Przed aktualizacją sprawdź też, czy kody analityczne, integracje i własne poprawki nie zostały dodane bezpośrednio do plików motywu nadrzędnego.
Backup chroni dane przed awarią, ale nie zastępuje motywu potomnego. Jeśli własny kod znajduje się w motywie głównym, aktualizacja może go nadpisać nawet wtedy, gdy kopia zapasowa została wykonana prawidłowo.
Co sprawdzić po aktualizacji motywu?
Komunikat o zakończeniu aktualizacji oznacza tylko, że WordPress zainstalował nowe pliki. Nie potwierdza, że wszystkie funkcje strony działają prawidłowo. Po zmianie przejdź najważniejsze ścieżki użytkownika, najlepiej na komputerze i urządzeniu mobilnym.
Przed uznaniem aktualizacji za zakończoną sprawdź:
- stronę główną, podstrony i układ elementów na ekranie mobilnym,
- formularze kontaktowe oraz faktyczne dostarczenie wiadomości,
- menu, wyszukiwarkę, logowanie i edycję treści w panelu,
- koszyk, checkout, płatności i wiadomości transakcyjne w WooCommerce.
Wyczyść cache WordPressa, wtyczki cache i CDN, jeśli z niego korzystasz. Następnie sprawdź błędy PHP na hostingu oraz podstawowe wskaźniki wydajności w PageSpeed Insights. Zmiany CSS, JavaScriptu lub sposobu ładowania obrazów mogą wpłynąć na Core Web Vitals.
Jeżeli po aktualizacji pojawi się błąd 500, biały ekran albo niedziałająca funkcja, wstrzymaj kolejne zmiany. Najpierw wyczyść cache i sprawdź logi. Gdy szybka diagnoza nie jest możliwa, przywróć pliki i bazę z kopii wykonanej przed aktualizacją. W sklepie trzeba uwzględnić, że przywrócenie starszej bazy może nadpisać nowe zamówienia lub dane klientów.
Backup przed aktualizacją motywu – lista kontrolna
Przed kliknięciem przycisku aktualizacji upewnij się, że:
- masz kopię plików i bazy danych SQL wykonaną bezpośrednio przed zmianą,
- pobrałeś backup poza serwer i znasz sposób jego przywrócenia,
- własne modyfikacje są zapisane w motywie potomnym,
- masz czas na sprawdzenie strony po aktualizacji i ewentualne przywrócenie kopii.
Taki backup daje realną możliwość powrotu do działającej wersji, a nie tylko poczucie, że kopia istnieje. Przy prostej stronie wystarczy zwykle wtyczka lub panel hostingu. Przy sklepie, rozbudowanych integracjach albo niestandardowym kodzie bezpieczniej połączyć backup z testem na stagingu.
