Pull i push między działającymi witrynami

Pull i push kopiuje całą witrynę na inny serwer przez HTTP, bez pobierania i wgrywania archiwum, bez SSH i FTP. Baza danych i wp-content przechodzą w małych porcjach, przerwany pull rusza od miejsca przerwania, a kolejne uruchomienie pobiera tylko zmiany. Od Migratora 1.5.0 to część edycji darmowej.

Pull i push to polecenia WP-CLI uruchamiane na witrynie docelowej: w przeglądarce nie ma do nich przycisku.

Zanim zaczniesz

Migrator jest zainstalowany i aktywny na obu witrynach: tej, którą kopiujesz (źródło), i tej, do której kopiujesz (cel).
Na serwerze docelowym jest WP-CLI.
Obie witryny mają ten sam prefiks tabel bazy. Gdy się różnią, pull obejmujący bazę zatrzymuje się, zanim cokolwiek zmieni, i podaje, jaki $table_prefix ustawić w wp-config.php celu.
W sieci multisite uruchamiaj polecenia jako superadministrator: dodaj --user=<login superadministratora>.

Połączenie obu witryn

Na źródle wejdź w Migrator > Pull and Push, zaznacz Let another site pull this one i zapisz. Domyślnie jest wyłączone.
Na witrynie docelowej, z folderu WordPressa, uruchom:
```
wp migrator pull https://stara-witryna.example
```
Pierwsze uruchomienie wypisuje klucz i się zatrzymuje (kod wyjścia 4).
Na ekranie Pull and Push źródła otwórz Set the token or enrol a key, wklej klucz i zapisz.
Uruchom to samo polecenie na witrynie docelowej jeszcze raz. Pull rusza.

Etykiety ekranu są na razie po angielsku. Witryna docelowa zachowuje swój klucz prywatny i używa go przy każdym kolejnym pullu i pushu do tego samego źródła.

Serwer źródłowy bez rozszerzenia PHP OpenSSL nie sprawdzi klucza. Tam ustaw token połączenia na tym samym ekranie i dodawaj --secret=<token> do każdego polecenia.

Dopóki nie zarejestrujesz klucza ani nie ustawisz tokenu, źródło nie odpowiada na żadne żądanie. Potem każdy, kto ma ten klucz lub token, może pobrać wszystkie pliki i całą bazę źródła, łącznie z hashami haseł użytkowników. Traktuj go jak hasło administratora, używaj https i wyłącz Pull and Push, gdy przenosiny się skończą.

Pull na witrynie docelowej

wp migrator pull https://stara-witryna.example

Jeśli nie podasz --skip-database, polecenie prosi o potwierdzenie, bo pull zastępuje bazę danych celu.

Opcja	Co robi
`<url>`	Adres witryny źródłowej. Wymagany.
`--secret=<token>`	Token połączenia ustawiony na źródle. Tylko dla serwera źródłowego bez rozszerzenia OpenSSL; wszędzie indziej pomiń go i użyj wypisanego klucza.
`--private-key-path=<plik>`	Użyj klucza prywatnego zarejestrowanego na źródle zamiast zapisanego.
`--insecure`	Dopuść źródło pod zwykłym `http://`. Każdy na trasie sieciowej może odczytać kopię, więc używaj tego tylko w sieci, którą kontrolujesz.
`--include-host-plugins`	Skopiuj też wtyczki platformowe starego hostingu. Domyślnie zostają na miejscu i są dezaktywowane, bo na innym hostingu rzadko działają.
`--skip-files`	Pobierz tylko bazę danych.
`--skip-database`	Pobierz tylko `wp-content`.
`--yes`	Nie pytaj o potwierdzenie.

Co robi pull, po kolei:

Sprawdza źródło i, gdy pobiera bazę, porównuje prefiksy tabel.
Przy pierwszym pullu sprawdza wolne miejsce. Pliki leżą dwa razy (prywatna kopia i wp-content), więc potrzebuje mniej więcej dwukrotności rozmiaru źródła i zatrzymuje się, zanim cokolwiek zmieni, gdy miejsca brakuje.
Pobiera wp-content i bazę do prywatnego folderu w wp-content/migrator-backups. W tym kroku na witrynie nic się nie zmienia.
Zrzuca obecną bazę celu, potem importuje bazę źródła i przepisuje adresy źródła na adresy celu. Gdy import się nie powiedzie, zrzut wraca na miejsce.
Kopiuje wp-content na miejsce i czyści cache obiektów.

Wznawianie i tylko zmiany

Uruchom to samo polecenie jeszcze raz:

po przerwaniu pull rusza od miejsca, w którym stanął;
po zakończonym pullu pobiera tylko to, co od tego czasu zmieniło się na źródle.

Co zostaje lokalne

Rdzeń WordPressa i wp-config.php na celu nie są ruszane.
Folder wtyczki Migrator (oraz Migrator Pro, jeśli jest zainstalowany) i folder migrator-backups nigdy nie są nadpisywane. Migrator zostaje aktywny po imporcie, więc kolejny pull nadal działa.
Drop-iny związane z serwerem zostają na starym hostingu: advanced-cache.php, object-cache.php, db.php, db-error.php, sunrise.php i fatal-error-handler.php.
Wtyczki platformowe starego hostingu zostają na miejscu i są dezaktywowane, chyba że podasz --include-host-plugins.
Pliki, które są tylko na celu, zostają nietknięte.

Odesłanie zmienionych plików

wp migrator push https://stara-witryna.example

Polecenie odsyła zmiany w wp-content celu na źródło, z którego zrobiono pull. Przechodzą tylko pliki, które różnią się od stanu z ostatniego pullu. Przyjmuje --secret, --private-key-path, --insecure i --yes i prosi o potwierdzenie, bo nadpisuje pliki na źródle.

Źródło musi:

nadać kluczowi witryny docelowej dostęp do push na ekranie Pull and Push, w Set the token or enrol a key;
mieć wyłączone display_errors;
mieć zapisywalny folder obok katalogu głównego witryny, na tym samym dysku, gdzie wysyłane pliki czekają na podmianę.

Gdy push nanosi zmiany, źródło pokazuje stronę konserwacji. Jeśli push zatrzyma się w połowie, uruchom go ponownie, żeby dokończyć.

To polecenie nie wysyła bazy danych. Wysłanie bazy działa tylko na hostingu, na którym API transferu działa pod osobną ścieżką, a tego wtyczka nie skonfiguruje. Dla takiego hostingu zobacz wp migrator remote db-push --help.

Inne polecenia zdalne

wp migrator remote <polecenie> [<url>] [--<opcja>=<wartość>]

Uruchamia dowolne niskopoziomowe polecenie transferu wobec zdalnej witryny, na przykład keygen, files-stats albo db-push. Argumenty i opcje przechodzą bez zmian. Gdy podasz zdalny adres, Migrator dokłada te same --state-dir i --fs-root, których używa pull, chyba że podasz własne. wp migrator remote help wypisuje wszystkie polecenia.

wp migrator remote keygen https://stara-witryna.example
wp migrator remote files-stats https://stara-witryna.example