Push witryny staging na żywą witrynę produkcyjną

TL;DR: Kreator Push WP STAGING kopiuje zmiany ze staging – pliki, tabele bazy danych lub jedno i drugie – na żywą witrynę. Najpierw wykonaj Backup żywej witryny (Krok 1), wybierz, co przesłać w Krokach 2–3, a następnie uruchom push. Jeśli push się nie powiedzie, zobacz sekcję rozwiązywania problemów poniżej.

Ten artykuł wyjaśnia, jak wykonać push witryny staging na żywą i przenieść modyfikacje z witryny staging na witrynę produkcyjną z WP STAGING | PRO. Jeśli jeszcze nie skonfigurowałeś witryny staging, zobacz, jak utworzyć witrynę WordPress staging przed śledzeniem tego przewodnika.

Jeśli chcesz przekonwertować witrynę staging na witrynę produkcyjną za pomocą podstawowej wersji WP STAGING, przeczytaj ten artykuł z alternatywną metodą migracji, jeśli Kreator Push nie jest dostępny.

Co musisz przesłać?

Zanim otworzysz Kreator Push, zdecyduj, co chcesz przenieść na żywą witrynę. Określi to, jakich kroków potrzebujesz.

Wideo: Migracja witryny WordPress staging na witrynę produkcyjną

Poniższe wideo pokazuje, jak WP STAGING | PRO przesyła dane z witryny staging na produkcyjną.

WP STAGING | PRO może wykonać push wszystkich plików mediów, motywów, pluginów oraz danych bazy danych z witryny WordPress staging z powrotem na witrynę produkcyjną.

Przed push: lista kontrolna

Potwierdź wszystko poniższe przed uruchomieniem Kreatora Push:

• Witryna produkcyjna jest żywa i dostępna pod swoim URL (np. https://example.com).
• Witryna staging została utworzona za pomocą WP STAGING i zawiera zmiany, które chcesz wdrożyć.
• WP STAGING | PRO jest zainstalowany i aktywny na witrynie produkcyjnej.
• Wersje rdzenia WordPress na staging i produkcji są identyczne.

Zawsze wykonuj Backup witryny produkcyjnej przed rozpoczęciem push. Backup pozwala przywrócić produkcję w kilka minut, jeśli coś pójdzie nie tak podczas push.

Push pełnej witryny staging na żywo

Skorzystaj z tej ścieżki, gdy chcesz wykonać push jednocześnie plików i tabel bazy danych.

Krok 1: Wykonaj Backup witryny produkcyjnej i staging

Wykonaj Backup witryny produkcyjnej przed rozpoczęciem push przy użyciu wbudowanego narzędzia Backupu WP STAGING | PRO.

Przejdź do WP STAGING > Backup & Migration > Create New Backup. Wpisz nazwę i kliknij Start Backup. Po zakończeniu Backupu zapisz lokalną kopię przez Actions > Download.

Krok 2: Wybierz tabele bazy danych

Przejdź do witryny produkcyjnej > WP STAGING > Start / STAGING.

Jeśli masz kilka witryn staging, wybierz tę, którą chcesz przenieść, i kliknij przycisk Push Changes.

Kliknij Database Tables i wybierz wszystkie tabele, które chcesz przesłać ze staging na produkcję. Każda wybrana tabela całkowicie nadpisze swój odpowiednik na witrynie produkcyjnej.

Aby zrozumieć, które tabele bazy danych uwzględnić przed push, referencja struktury bazy danych WordPress wymienia każdą tabelę rdzenia i opisuje, co przechowuje.

Odznacz konkretną tabelę, aby wykluczyć ją z push.

Uwaga: Jeśli przesyłasz tylko aktualizacje plików pluginu lub motywu, nie musisz przesyłać żadnych tabel bazy danych. Jeśli jednak zmieniłeś ustawienia, utworzyłeś wpisy, przypisałeś menu lub zainstalowałeś nowe pluginy na staging, te akcje są zapisane w bazie danych i musisz przesłać odpowiednie tabele.

Krok 3: Wybierz pluginy, motywy i pliki mediów

Kliknij Select Files i wybierz wszystkie foldery pluginów, mediów i motywów, które chcesz skopiować na produkcję.

Możesz też wskazać dodatkowe foldery, wpisując ich pełne ścieżki bezwzględne w polu tekstowym.

Krok 4: Wykluczanie tabel lub plików z push

Dwie opcje kontrolują, co zostanie usunięte z witryny produkcyjnej podczas push:

• Uninstall all plugins on the production site – usuwa z produkcji pluginy, które już nie istnieją na staging.
• Delete the wp-content/uploads folder – czyści katalog uploads produkcji przed skopiowaniem folderu uploads ze staging.

Jeśli obie opcje są wyłączone, nic nie jest usuwane z produkcji. Plugin usunięty na staging zostanie dezaktywowany na produkcji, ale pozostanie zainstalowany i można go ręcznie ponownie aktywować.

Krok 5: Uruchom proces push

Kliknij Push Staging Site to Live site, aby rozpocząć push.

Po zakończeniu push przeładuj witrynę. Wszystkie zmiany ze staging będą na żywo na witrynie produkcyjnej.

Uwaga: WordPress czasami wymaga ponownego zalogowania się po pełnym push. Dzieje się tak, gdy dane sesji z bazy staging zastąpią sesję produkcji – to normalne zachowanie.

Push tylko zmian bazy danych

Jeśli twoje zmiany ograniczają się do treści, ustawień lub konfiguracji pluginów – i nie zmieniałeś żadnych plików motywu czy pluginu – wykonaj push tylko tabel bazy danych.

W Kreatorze Push otwórz Database Tables i wybierz tylko tabele zawierające twoje zmiany. Pozostaw wszystkie foldery plików niezaznaczone w Select Files. Jest to szybsze, zmniejsza ryzyko i pozostawia pliki produkcji nietknięte.

Aby zrozumieć, które tabele bazy danych uwzględnić przed push, referencja struktury bazy wymienia każdą tabelę rdzenia WordPress i to, co przechowuje.

Użytkownicy WooCommerce: Wyklucz tabele zamówień i klientów WooCommerce podczas push witryny staging sklepu. Push tych tabel nadpisałby dane żywych transakcji. Callout WooCommerce w Kroku 2 wymienia konkretne tabele do pominięcia.

Push tylko plików (motywy, pluginy, media)

Jeśli zaktualizowałeś lub przetestowałeś motyw lub plugin na staging i potwierdziłeś, że działa, wykonaj push tylko zmienionych plików – push bazy danych nie jest potrzebny.

W Kreatorze Push pozostaw Database Tables w pełni niezaznaczone. W Select Files wybierz tylko foldery, które się zmieniły: np. wp-content/themes/your-theme dla aktualizacji motywu lub wp-content/plugins/plugin-name dla pojedynczego pluginu.

Po push ręcznie usuń pluginy istniejące tylko na staging po push na żywą, jeśli zainstalowałeś jakiekolwiek narzędzia deweloperskie, które nie powinny działać na produkcji.

Co zrobić, jeśli push się nie powiedzie

W naszej kolejce wsparcia najczęstsze powody, dla których push się zacina lub powoduje błędy, mieszczą się w czterech kategoriach.

Push zacina się przy dużych bazach danych

Jeśli proces push zawiesza się lub przekracza limit czasu podczas kopiowania tabel bazy danych, najczęstszą przyczyną jest zbyt mała wartość ustawienia max_allowed_packet w MySQL. Ten limit kontroluje maksymalny rozmiar pojedynczego zapytania do bazy; gdy wiersz tabeli go przekracza – typowymi winowajcami są zserializowane wartości opcji i wpisy z osadzonymi obrazami base64 – push zatrzymuje się w trakcie operacji.

Rozwiązanie: zwiększ max_allowed_packet w konfiguracji MySQL lub poproś dostawcę Hostingu o zwiększenie. Zobacz też ograniczenia konfiguracji PHP, które mogą przerwać push – dyrektywy takie jak memory_limit i max_input_vars również mogą powodować timeouty przy push dużych bibliotek mediów.

Mieszana treść lub zepsute URL po push

Jeśli żywa witryna pokazuje zepsute obrazy lub ostrzeżenia mixed-content po push, domena staging nadal jest obecna w niektórych wierszach bazy danych. WP STAGING podmienia URL podczas push, ale zserializowane wartości w niestandardowych tabelach pluginów mogą zostać pominięte.

Rozwiązanie: uruchom wyszukiwanie i zamianę w bazie danych, aby zamienić domenę staging na domenę produkcyjną. Błędy REST API pojawiające się po push na żywą są często spowodowane tym samym niedopasowaniem URL; poprawienie zamiany domeny rozwiązuje oba problemy.

Admin nie może się zalogować po push

Jeśli wykonałeś push pełnej bazy danych i nie możesz zalogować się do admina produkcji, tabela użytkowników staging zastąpiła tabelę produkcji, a twoje oryginalne dane logowania admina już nie pasują.

Rozwiązanie: zresetuj hasło admina bezpośrednio w MySQL za pomocą narzędzia zarządzania bazą danych twojego hosta (np. phpMyAdmin). Alternatywnie, najpierw rozwiąż problemy z logowaniem na witrynie staging, a następnie ponownie wykonaj push.

Biały ekran lub błąd krytyczny po push

Biały ekran tuż po push zwykle oznacza, że plugin, który działał na staging, jest niekompatybilny ze środowiskiem serwera produkcji – zazwyczaj różnica wersji PHP lub niezgodność konfiguracji serwera.

Włącz log debugowania WordPress, aby zidentyfikować plugin: dodaj define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); do wp-config.php. Log błędów pojawi się w wp-content/debug.log. Po zidentyfikowaniu i naprawieniu niekompatybilnego pluginu usuń stałe debugowania.

Po push: lista kontrolna weryfikacji

Przejdź te kontrole przed uznaniem push za zakończony:

• [ ] Odwiedź stronę główną produkcji – potwierdź, że nowa treść lub design są widoczne.
• [ ] Zaloguj się do admina produkcji – potwierdź, że dane logowania działają.
• [ ] Sprawdź https://your-domain.com/wp-json/ – odpowiedź JSON potwierdza, że REST API działa.
• [ ] Otwórz narzędzia deweloperskie przeglądarki → Console – brak ostrzeżeń mixed-content.
• [ ] Przetestuj wszelkie formularze, procesy checkout lub krytyczne funkcjonalności.
• [ ] Ręcznie usuń pluginy istniejące tylko na staging po push na żywą, które nie powinny działać na produkcji.
• [ ] Poproś o ponowne indeksowanie w Google Search Console, jeśli zmieniła się istotna treść.

Powiązane artykuły

• Szybki start: jak wykonać push nowego motywu z witryny staging na produkcyjną
• Push witryny staging na żywą witrynę produkcyjną
• Utwórz środowisko Dev > Staging. Utwórz witrynę staging i skopiuj ją na inną witrynę staging przed wydaniem
• Wskazówki do Backupu witryny WordPress produkcyjnej i staging
• Przeniesiona witryna na nowy serwer – nie można wykonać push witryny staging