WordPress: jak bezpiecznie zaktualizować bazę danych po aktualizacji

Komunikat oznacza, że kod WordPressa wykrył potrzebę uruchomienia procedury dostosowującej bazę do aktualnej wersji silnika. Po aktualizacji plików panel może przekierować administratora do `/wp-admin/upgrade.php`, gdzie można uruchomić ten proces. Sam komunikat nie oznacza, że wpisy, strony lub zamówienia zostały skasowane.

Aktualizacja silnika podmienia pliki WordPressa, aktualizacja wtyczki zmienia jej kod, a aktualizacja bazy wykonuje operacje wymagane przez nową wersję oprogramowania. To osobne etapy, choć mogą wystąpić po sobie. Zanim rozpoczniemy etap bazodanowy, stosujemy procedurę przygotowania i zatrzymania opisaną w następnej sekcji.

Jeżeli komunikat wskazuje błąd połączenia, przejdź do diagnozy połączenia i problemów z bazą danych WordPress. Pozostałe częste problemy, w tym błędy krytyczne i biały ekran, opisujemy w poradniku jak naprawić najczęstsze błędy WordPress.

Przed zmianą bazy potwierdź, że możesz odtworzyć stronę w spójnym stanie sprzed operacji. Wstrzymaj aktualizację, jeśli nie masz kopii bazy i plików, nie potrafisz potwierdzić jej wykonania albo nie wiesz, jak ją przywrócić. W przypadku sklepu uwzględnij również zamówienia zapisane już po utworzeniu kopii.

Zastosuj jedną procedurę przygotowania: wykonaj kopię bazy i plików, sprawdź w panelu hostingu lub systemie backupu jej status, zapisz wersje WordPressa i PHP, zanotuj aktywne wtyczki oraz motyw, a na końcu sprawdź logi PHP i wolne miejsce. W WordPressie informacje o serwerze i zalecenia znajdziesz w Narzędzia > Stan witryny. Nie rozpoczynaj operacji, gdy log zawiera powtarzające się błędy krytyczne albo hosting zgłasza brak miejsca.

Najpierw odtwórz procedurę na stagingu, jeśli aktualizujesz sklep lub stronę z formularzami, które zapisują dane. Nie łącz aktualizacji bazy z migracją hostingu, zmianą PHP i przebudową checkoutu. Jeśli którykolwiek warunek zatrzymania wystąpi, diagnozuj przyczynę przed powrotem do aktualizacji.

Panel WordPressa jest prostą metodą, gdy po aktualizacji plików wyświetla komunikat o wymaganej zmianie bazy i strona nie zgłasza błędów połączenia. Zaloguj się jako administrator i otwórz komunikat albo ścieżkę `/wp-admin/upgrade.php` dla swojej instalacji. Zanim klikniesz przycisk, upewnij się, że procedura przygotowania z poprzedniej sekcji zakończyła się powodzeniem.

Uruchom aktualizację raz i poczekaj na wynik. W czasie wykonywania procesu nie odświeżaj strony, nie zamykaj karty i nie klikaj ponownie przycisku w drugim oknie. Po komunikacie sukcesu wróć do panelu i sprawdź, czy prośba o aktualizację zniknęła.

Jeśli karta długo się ładuje, nie ponawiaj procesu na podstawie samego czasu oczekiwania. Sprawdź, czy panel odpowiada, zapisz widoczny komunikat i ustal stan operacji przez logi hostingu lub administratora. Dopiero po potwierdzeniu, że proces się zakończył albo został bezpiecznie przerwany, podejmij decyzję o dalszym kroku.

WP-CLI przydaje się administratorowi z dostępem SSH, gdy trzeba działać bez panelu albo precyzyjnie wskazać instalację. Polecenie aktualizujące `wp core update-db` uruchamia procedurę WordPressa; można też użyć `--dry-run`, aby porównać wersje bazy bez wykonywania zmiany.

Uwaga: `wp core check-update-db` nie należy jeszcze do stabilnego wydania WP-CLI. Dokumentacja WP-CLI wskazuje, że polecenie wymaga wersji nightly, którą można uzyskać przez `wp cli update --nightly`, albo instalacji osobnego pakietu. Nie traktuj tej kontroli jako komendy dostępnej w każdej standardowej instalacji.

Przed uruchomieniem ustal katalog WordPressa i środowisko, w którym działa polecenie. Przykładowy zestaw dla instalacji z dostępem SSH:

wp --path=/sciezka/do/wordpress core version
wp --path=/sciezka/do/wordpress core update-db --dry-run
wp --path=/sciezka/do/wordpress core update-db

Zamień ścieżkę przykładową na katalog swojej instalacji. Najpierw sprawdź wynik `core version` i `--dry-run`, a właściwą komendę uruchom dopiero po wykonaniu procedury kopii, kontroli logów i zatrzymania. Parametry i dostępność poleceń zależą od wersji WP-CLI oraz konfiguracji hostingu.

W instalacji multisite zachowaj szczególną ostrożność: opcja `--network` aktualizuje bazy wszystkich witryn w sieci. Nie używaj jej w instalacji pojedynczej ani bez potwierdzenia zakresu. Parametr `--url` pozwala wskazać konkretną witrynę w sieci; sprawdź adres przed wykonaniem polecenia. Po operacji odczytaj pełny wynik i sprawdź funkcje strony. Sukces WP-CLI potwierdza wykonanie procedury, ale sam nie potwierdza działania formularzy czy checkoutu.

Po aktualizacji sprawdź funkcje, które zapisują lub przetwarzają dane. Domyślnym miejscem testów jest staging, przygotowany na kopii możliwie zbliżonej do produkcji. Na produkcji wykonuj wyłącznie uzgodniony test kontrolny, z zaakceptowaną metodą płatności i wcześniej ustaloną obsługą zamówienia testowego, aby nie pomylić go z prawdziwym zamówieniem.

Sprawdź też widok mobilny i stronę w innej przeglądarce. Cache czyść dopiero po zakończeniu zmiany, a następnie powtórz test formularza i koszyka na stagingu. Więcej o kolejności aktualizacji i środowisku testowym przeczytasz w instrukcji jak aktualizować WordPress krok po kroku oraz w przewodniku aktualizacji WordPress, backupu i stagingu.

Gdy aktualizacja nie kończy się albo strona przestaje działać, ustal najpierw, czy problem dotyczy połączenia z bazą, kodu PHP czy konkretnej funkcji witryny. Zapisz dokładny komunikat, godzinę i adres, na którym wystąpił błąd. Potem zastosuj procedurę przygotowania i diagnostyki: nie ponawiaj operacji, zabezpiecz stan kopii, sprawdź logi hostingu i dostępność bazy.

Wyłączanie wtyczek wykonuj na kopii lub stagingu, pojedynczo, aby ustalić, która powoduje błąd. Nie edytuj ręcznie numeru wersji bazy w tabeli opcji: ukrycie komunikatu nie wykonuje operacji oczekiwanych przez kod. Przywracając kopię sklepu, uwzględnij zamówienia i inne dane zapisane od momentu wykonania backupu.

Perspektywa KC Mobile: sam komunikat o zakończeniu aktualizacji nie mówi, czy sklep poprawnie zapisuje dane. Dlatego sprawdzamy formularze, koszyk i zamówienie na środowisku testowym, a potem porównujemy wynik z logami. Na produkcji nie tworzymy nieuzgodnionego zamówienia próbnego.

Jeśli po aktualizacji WordPress zwraca błąd 500, biały ekran albo sklep przestał przyjmować zamówienia, naprawa WordPressa po aktualizacji obejmuje diagnozę i przywrócenie działania. Przy regularnym utrzymaniu strony, kopiach i aktualizacjach pomocna jest opieka WordPress.

Stała kolejność prac ułatwia wykrycie przyczyny błędu i skraca przestój. Przed każdą aktualizacją wykonaj kopię plików i bazy, zapisz wersje WordPressa, PHP i wtyczek, a następnie przeprowadź zmianę na stagingu. Dopiero po pozytywnych testach przenieś ją na produkcję w uzgodnionym oknie.

Na stagingu sprawdź panel, formularz, koszyk, checkout, integrację płatności i zapis zamówienia. W przypadku produkcji zaplanuj test kontrolny z właścicielem sklepu: ustal metodę płatności, sposób oznaczenia zamówienia testowego i osobę odpowiedzialną za jego obsługę. Nie zostawiaj testu do samodzielnej interpretacji przez obsługę sklepu.

Zapisz datę, zakres zmian i wynik testów. Jeśli aktualizacja bazy jest częścią większego wdrożenia, rozdziel ją od migracji serwera lub przebudowy checkoutu, by w razie problemu łatwiej wskazać źródło.

• Błąd 404: co oznacza i jak go naprawić na stronie?