Jak: łatwo przenosić instalację WordPress z wersji programistycznej do produkcyjnej?

Robię programowanie na jednym pudełku, a drugiego używam do produkcji. W tej chwili po prostu zrzucam bazę danych, a następnie znajduję zamiennik dla zmian adresu URL; następnie skopiuj pliki i zaimportuj nowy SQL.

Czy są na to lepsze sposoby?

@ Insanity5902 : Wdrożenie witryny WordPress z jednego urządzenia do drugiego jest PITA od pierwszego dnia pracy z WordPress. (Prawdę mówiąc, była to PITA z Drupalem przez 2 lata, zanim zacząłem z WordPress, więc problem z pewnością nie dotyczy wyłącznie WordPress.)

Niepokoiło mnie to, że za każdym razem, gdy potrzebowałem przenieść witrynę, musiałem spędzać tak często zdublowany wysiłek i powstrzymywałem się od wdrażania do testowania tak często, jak bym wolał. Więc około 4-6 miesięcy temu zacząłem pracować nad wtyczką do rozwiązania problemu migracji hosta i wspomniałem o swoich pomysłach na forum WP Tavern .

Cóż, szybko do przodu do dzisiaj i mam już prawie działającą i wygodnie nazywam to „ WP Migrate Webhosts ”. Mimo że wtyczka wciąż ma bardzo dużo wersji beta (prawdopodobnie nawet alfa), biorąc pod uwagę twoje pytanie, myślę, że jestem gotowy, aby ludzie zaczęli na nim walić.

Przewidywany przypadek użycia jest taki, że:

1. najpierw programista obsługuje przesyłanie wszystkich zmienionych plików motywów i wtyczek przez FTP,
2. następnie przesyła rozwojową bazę danych MySQL na serwer testowy w całości i na końcu
3. następnie uruchamia wtyczkę, aby migrować wszelkie odwołania z poprzedniej domeny do nowej. (Moja wtyczka nie próbuje rozwiązać łączenia nowych pól lub tabel bazy danych z danymi na żywo; TO jest o wiele większy problem, którego nie jestem pewien, jak rozwiązać).

Możesz pobrać wtyczkę z mojej strony i rozpakować do katalogu wtyczek (jeśli nie wiesz, jak to zrobić, to ta wtyczka nie jest dla Ciebie, ponieważ wymaga kogoś, kto wie, co robią, aby z niej skorzystać). utrzymuj tę wtyczkę online, dopóki nie wypuszczę jej na WordPress.org, po czym powinieneś poszukać jej tam.

Aby go użyć innego podejścia w swoją wp-config.phpktóre normalnie przez zakomentowanie cztery (4) określa DB_NAME, DB_USER, DB_PASSWORDi DB_HOST, a zamiast rejestracji wartości domyślne dla webhosts a następnie rejestracji informacji o każdym samą witryną. Oto, jak wp-config.phpmoże wyglądać ten segment (zauważ, że pierwsza sekcja to niepotrzebny kod skomentowany, a także zauważ, że skonfigurowałem plik hosts na moim komputerze lokalnym z nie-routowalnymi .devdomenami najwyższego poziomu, aby ułatwić codzienny rozwój. Na Macu VirtualHostX sprawia, że ​​jest to bardzo proste):

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
//define('DB_NAME', 'wp30');

/** MySQL database username */
//define('DB_USER', 'wp30_anon');

/** MySQL database password */
//define('DB_PASSWORD', '12345');

/** MySQL hostname */
//define('DB_HOST', '127.0.0.1:3306');

require_once(ABSPATH . 'wp-content/plugins/wp-migrate-webhosts/wp-webhosts.php');
register_webhost_defaults(array(
 'database'  => 'example_db',
 'user'      => 'example_user',
 'password'  => '12345',
 'host'      => 'localhost',
 'sitepath'  => '',        // '' if WordPress is installed in the root
));
register_webhost('dev',array(
 'name'      => 'Example Local Development',
 'host'      => '127.0.0.1:3306',
 'domain'    => 'example.dev',
 'rootdir'   => '/Users/mikeschinkel/Sites/example/trunk',
));
register_webhost('test',array(
 'name'      => 'Example Test Server',
 'rootdir'   => '/home/example/public_html/test',
 'domain'    => 'test.example.com',
));
register_webhost('stage',array(
 'name'      => 'Example Staging Server',
 'rootdir'   => '/home/example/public_html/stage',
 'domain'    => 'stage.example.com',
));
register_webhost('live',array(
 'name'      => 'Example Live Site',
 'rootdir'   => '/home/example/public_html/',
 'password'  => '%asd59kar12*fr',
 'domain'    => 'www.example.com',
));
require_once(ABSPATH . 'wp-content/plugins/wp-migrate-webhosts/set-webhost.php');

Mam nadzieję, że jest to (głównie) oczywiste. Próbowałem uczynić kod tak czystym, jak tylko mogłem, ale niestety wymaga on tych dwóch tajemniczych require_once()linii przed i po bloku kodu rejestracyjnego webhost, ponieważ nie było możliwości, by „ zaczepić ” WordPressa przed wp-config.phpwywołaniem.

Po zaktualizowaniu wp-config.phpmożesz po prostu użyć skrótu URL, wp-migrate-webhostsaby przejść do ekranu administratora w następujący sposób:

http://example.com/wp-migrate-webhosts

Powyższy zabierze Cię na ekranie administratora jak poniższy, który ma sporo części opisu tekstu i pozwala na migrację OD którykolwiek z pozostałych domen hostingowe za pomocą jednego kliknięcia po wybraniu domen migrować z ( UWAGA : Ten przykład pokazuje dzieje W DÓŁ z serwerów testowych / etapowych / na żywo do lokalnego rozwoju, ale możesz mieć pewność, że może migrować do dowolnej domeny, w której się znajduje. Oznacza to również, że wtyczka będzie świetna do przejęcia istniejącej witryny na żywo i szybkiego uruchomienia lokalnego środowiska programistycznego! ):

Jeśli nie jest jasne, „ migracja ” w tym kontekście oznacza aktualizację wszystkich odniesień w bieżącej bazie danych, aby były odpowiednie dla aktualnie zdefiniowanego hosta internetowego (a „ bieżący ” jest wąchany przez inspekcję $_SERVER['SERVER_NAME']).

Co ciekawe, wtyczka implementuje niektóre podstawowe migracje, ale każdy może ją podłączyć i wykonywać własne migracje . Na przykład, jeśli dodasz wtyczkę galerii, która przechowuje pełne ścieżki do obrazów w bazie danych, możesz przechwycić migrate_webhostsakcję, która zostanie przekazana każdemu z hosta „ z ” i webhosta „ do ” jako tablicę metadanych i będziesz mógł do wykonywania wszystkiego, co trzeba zrobić w bazie danych przy użyciu SQL lub dowolnych odpowiednich funkcji API WordPress w celu przeprowadzenia migracji. Tak, każdy z nas mógłby to zrobić bez wtyczki, ale bez wtyczki stwierdziłem, że napisanie całego potrzebnego kodu wymagało więcej wysiłku niż było warte. Dzięki wtyczce łatwiej jest pisać te małe haczyki i sobie z tym poradzić.

Może się również zdarzyć, że migracja zakończy się niepowodzeniem w przypadkach, których nie przetestowałem, a może pomożesz mi ulepszyć wtyczkę? Każdy, kto chce, może wysłać mi wiadomość e-mail za pośrednictwem mojego konta Gmail (mój pseudonim to „mikeschinkel”).

Ponadto, plugin został zaprojektowany, aby zaakceptować metadane witryną użytkownika zdefiniować oprócz tych Uznaje jak database, user, password, host, domainitd. Doskonałym przykładem może być googlemaps_apikey, w którym można przechowywać różne klucze API dla każdej domeny, który potrzebuje plugin Twojego Google Map za do prawidłowego działania (kto z was, który korzystał z wtyczki Google Maps, nie wdrożył aplikacji na serwerze na żywo i zapomniał zmienić kod na poprawny klucz API? Daj spokój, bądź szczery ... :) Dzięki tej wtyczce googlemaps_apikeyelementem w register_webhost () tablica i mały zwyczaj migrate_webhostshak można skutecznie wyeliminować, że w trosce!

Cóż, o to chodzi. Uruchamiam tę wtyczkę tutaj na WordPress Answer's Exchange, ponieważ wywołało ją pytanie @ Insanity5902. Daj mi znać, jeśli jest to pomocne, tutaj w razie potrzeby lub e-mailem, jeśli nie.

PS Jeśli zdecydujesz się użyć tego, pamiętaj, że jest to wersja alfa / beta, a to oznacza, że ​​się zmieni, więc przygotuj się na drobną operację, jeśli chcesz go użyć teraz, a następnie użyj wydanej wersji, gdy zostanie pobita przez wiele rąk.

PPS Jakie są moje cele? Uwielbiam widzieć, jak migruje to do rdzenia WordPress, aby wszyscy mieli do niego dostęp. Ale zanim to zostanie nawet uznane za konieczne, wiele osób musi być zainteresowanych jego użyciem, aby upewnić się, że faktycznie rozwiązuje więcej problemów, niż może potencjalnie stworzyć. Jeśli więc podoba ci się ten pomysł, skorzystaj z niego i pomóż mi nabierać rozpędu w celu ewentualnego włączenia go do rdzenia WordPress.

Jeśli to możliwe, włączam WP_HOMEi WP_SITEURLwłączam wp-config.php. To, w połączeniu ze zrzutem bazy danych i importem, jest najprostszym ze wszystkich znanych mi rozwiązań.

http://codex.wordpress.org/Changing_The_Site_URL#Edit_wp-config.php

Mój ulubiony hack; dodaj ustawienie, aby /etc/hostsdomena produkcyjna wskazywała na pole programistyczne, tylko na komputerze. Aby wdrożyć do produkcji, zsynchronizuj wszystkie pliki i przepchnij bazę danych.

Ryzyko związane z tą strategią jest jasne; możesz pomylić swoje środowisko programistyczne ze środowiskiem produkcyjnym.

Nadal jest to łatwa poprawka.

Chciałem coś podobnego, kiedy przeprowadziłem migrację do WP kilka miesięcy temu, więc napisałem dość prosty skrypt powłoki, który używa rsync i mysqldump nad ssh:

http://snarfed.org/sync_wordpress

Nie jest zaawansowany ani oparty na sieci, ale cieszę się z tego.

WP Engine to nowa usługa oferująca „Przetwarzanie jednym kliknięciem”:

WPEngine ma wyjątkową funkcję o nazwie „inscenizacja”. Oto jak to działa: zanim wprowadzisz przerażającą zmianę na swoim blogu, kliknij przycisk „migawka”. Tworzymy pełną kopię Twojego bloga i ustawiamy go w oddzielnym, bezpiecznym obszarze. Możesz grać z czymkolwiek chcesz; nic nie jest żywe. Dotykając swojej głównej witryny, tylko wtedy, gdy jesteś gotowy, aby ją uruchomić.

Wygląda na bardzo łatwy sposób na szybkie przejście od rozwoju do produkcji, szczególnie w przypadku witryny już działającej.

Wtyczka duplikatora: Oto wtyczka, nad którą pracowałem. Obecnie jest w fazie beta, ale wykonuje pracę dla większości witryn. Obecnie jest on przeznaczony dla mniejszych instalacji WordPress. http://wordpress.org/extend/plugins/duplicator/

Zasoby: Dodatkowe zasoby dla wtyczki można znaleźć tutaj: http://lifeinthegrid.com/duplicator/

Społeczność: Daj nam znać o swoich sukcesach lub problemach, na które możesz natknąć się! Aby łatwiej zarządzać różnymi wątkami, prosimy o publikowanie problemów na forach wtyczek WordPress.org. Nie publikuj żadnych danych logowania z wtyczki na forach internetowych. Dane rejestracyjne można przesyłać do naszej witryny pomocy technicznej.

Możesz rzucić okiem na produkt firmy iThemes o nazwie BackUpBuddy . Używałem go tylko dwa razy, za każdym razem miałem jakiś problem, ale ogólnie wygląda obiecująco.

Osobiście rozwiązuję ten problem w moim projekcie na Github o nazwie Autopress . Nie mam jeszcze idealnego rozwiązania, ale zbliżam się, szczególnie z wtyczką wpstage od ludzi z wpengine.

To wygląda obiecująco. Pracujemy nad niektórymi skryptami do obsługi migracji niektórych danych, na przykład wp-options, zmiany ścieżek w db, kopiowanie na nośniku.

Problemem jest to, że witryna na żywo stale się rozwija, podczas gdy druga jest w fazie rozwoju. Jedna strona, nad którą pracujemy, ma 20 postów dziennie i ponad 3000 komentarzy dziennie. To za dużo danych, aby przenieść je za pomocą phpmyadmin lub wiersza poleceń. Przenoszenie danych zawsze powoduje z jakiegoś powodu problemy z UTF.

Teraz, kiedy wygląda na to, że opcje menu są przechowywane w DB, mam jeszcze więcej do czynienia.

Sprawdzam cały mój kod w SVN i wdrażam kod za pośrednictwem FTP z serwera (Beanstalk). Nie powoduje to jednak zmian w DB ani nie aktywuje nowych wtyczek.

Obecnie planuję utworzyć plik manifestu podczas opracowywania wszystkich zmian w witrynie na żywo.

Na przykład plik miałby linie czytelne dla człowieka

Obejmowałby wtyczki do aktywacji, opcje wp, aby przenieść, obrazy do przeniesienia, strony do przeniesienia. Następnie moja wtyczka wykryłaby plik manifestu i wprowadziła wszystkie zmiany w witrynie pomostowej.

Kiedy to przetestowałem i byłem pewien, że dostałem wszystko, byłem pewien, że zadziała na produkcji.

Ta wtyczka jest wciąż tylko pomysłem, ale mam dla niej napisany kod.

Ponadto, jeśli chcesz wprowadzić zmiany tylko do adresu URL w swojej bazie danych, możesz użyć następującego kodu SQL.

wystarczy zastąpić $old$starą domeną i $new$nową

update wp_postmeta set meta_value = replace(meta_value, '$old$' , '$new$') ;
update wp_posts set post_content = replace(post_content, '$old$' , '$new$') ;
update wp_options set option_value = replace(option_value, '$old$' , '$new$') ;

Dwa projekty Google Summer of Code, które mają podobny cel:

• Automatyczna migracja (GSoC 2010)
• WordPress Move ( propozycja ) (GSoC 2011)

Używam polecenia eksportowania subversion do instalowania plików WordPress (http://core.svn.wordpress.org/tags//), a także wszystkich wtyczek w repozytorium (http://plugins.svn.wordpress.org//tags //), a następnie po prostu skompresuj motyw i niestandardowe wtyczki i zainstaluj je normalnie. Gdy wszystko to uruchomi się bez zawartości, eksportuję testową bazę danych i szukam / zastępuję adres URL ORAZ ścieżkę pliku (przechowywaną na nośnik) i importuję do pustej bazy danych, a następnie przełączam informacje o bazie danych w wp-config .php. Ogólnie zajmuje mi to około 10-20 minut.

Zwykle loguję się do phpMyadmin, przesyłam bazę danych i edytuję zawartość wp_options> siteurl i wp_options> home do oczekiwanej domeny. Jeśli musisz zaktualizować adresy URL w swoich postach i zawartości stron, możesz przeszukać / zamienić adres URL i ścieżkę multimediów / przesyłania w pliku .SQL przed przesłaniem. To szybka praca.

Chociaż nie brakuje tu dobrych rozwiązań, w duchu dzielenia się pomyślałem, że dodam mój skrypt wdrażania bash do stosu: https://github.com/jplew/SyncDB

SyncDB to skrypt wdrażania bash, mający na celu wyeliminowanie nudy z synchronizacji lokalnych i zdalnych wersji witryny Wordpress. Pozwala programistom pracującym w środowisku lokalnym (np. MAMP) na szybkie „wypychanie” lub „ściąganie” zmian na lub z serwera produkcyjnego za pomocą jednego polecenia terminala.

Ten skrypt działa dobrze ze znakiem Jaquith za WP-szkielet, i uprzęży mysqldump, giti rsynczsynchronizować całą witrynę, baza danych, kod, a media w dwóch krokach:

./syncdb
git push hub master

Korzystam z http://wordpress.org/plugins/wp-clone-by-wp-academy/ . Działa ładnie!

Tylko 3 kroki:

1. Zainstaluj wtyczkę na obu stronach.
2. Użyj wtyczki, aby wygenerować kopię zapasową na starej stronie.
3. Weź podany przez siebie zapasowy adres URL i podłącz go do strony wtyczki w nowej witrynie, naciśnij go, a migracja zakończy się w ciągu kilku sekund!

Automatycznie dostosowuje wszystkie adresy URL - w tym szeregowe zamiany ciągów - więc nie ma ryzyka utraty konfiguracji widżetów itp.

Jedyne problemy, jakie miałem, to niektóre witryny z większymi bazami danych (~ 300 MB), co spowodowało przekroczenie limitu czasu wykonywania skryptu PHP podczas importowania kopii zapasowej witryny.

Począwszy od 2017 roku, oto dwa najlepsze sposoby, które znalazłem, aby obsłużyć transfer bazy danych WordPress od rozwoju do produkcji.

WP Migracja DB Pro / WP Sync DB

https://wordpress.org/plugins/wp-migrate-db/

Te wtyczki WordPress umożliwiają wypychanie, pobieranie i synchronizowanie tabel bazy danych między instalacjami WordPress. Jest to o wiele lepsze niż szukanie / zamiana z wielu powodów, ponieważ:

• Eksportuje bazę danych jako zrzut danych MySQL (podobnie jak phpMyAdmin)
• Wyszukuje i zamienia adresy URL i ścieżki plików
• Obsługuje dane serializowane
• Pozwala zapisać go na komputerze jako plik SQL

Jestem fanem zarabiania za pracę, którą wykonuję, więc polecam wesprzeć pana Brada Touesnarda i kupić kopię licencji prawdziwej rzeczy. WP Sync DB jest replikacją i dlatego zawsze pozostaje w tyle za wsparciem. Dzięki tej wtyczce proces jest bardzo prosty:

1. Zainstaluj / aktywuj wtyczkę w lokalnym hoście i środowisku produkcyjnym
2. Skonfiguruj transfer wypychany z lokalnego hosta / serwera programistycznego do swojej produkcji
3. Wypełnij reguły, dla których tabele mają zostać przesłane, i zdefiniuj reguły wyszukiwania i zastępowania, które mają być wykonywane
4. Otóż ​​to!

Wyszukiwanie i zamiana baz danych dla baz danych WordPress przez InterconnectIT

https://interconnectit.com/products/search-and-replace-for-wordpress-databases/

To bezpłatne narzędzie nie jest wtyczką, ale jest instalowane w katalogu głównym instalacji produkcyjnej WordPress. Nie jest to tak dobre jak WP Migrate DB Pro, ponieważ wymaga kilku ręcznych kroków, ale mimo to jest świetną opcją, która konsekwentnie działa. Podczas korzystania z tego podejścia proces wygląda następująco:

1. Wykonaj kopię zapasową lokalnej bazy danych, jest to absolutnie konieczne, ponieważ wkrótce ją ponownie zaimportujemy
2. Dodaj skrypt do folderu w katalogu głównym instalacji
3. Uruchom wyszukiwanie i zamień w bazie danych
4. Wyeksportuj bazę danych i zapisz ją dla środowiska produkcyjnego
5. Ponownie zaimportuj kopię zapasową z kroku 1, aby przywrócić lokalnego hosta
6. Połącz się z produkcyjną bazą danych i zrób jej kopię zapasową (jak zawsze powinieneś zrobić te rzeczy)
7. Zaimportuj eksport, który wykonaliśmy PO uruchomieniu procedury znajdowania / zastępowania z kroku 4

Możesz zastosować szybsze podejście, ale wiąże się to z przestojami w miejscu produkcji, co moim zdaniem jest niedopuszczalne. Dlatego nazywamy to produkcją, prawda?

ponieważ uruchamiam moje witryny w IIS (uruchamiam również asp.net, więc potrzebuję systemu Windows), używam WebPI z Msft, aby zainstalować nową instancję, a następnie kopiuję szablon i używam importu / eksportu do przesłania danych.

To nie jest idealne, ale cała sprawa zajmuje mniej niż godzinę.

Oczywiście byłoby miło mieć rozwiązanie za jednym kliknięciem, ale to było dla mnie najłatwiejsze.

Inne płatne rozwiązanie: platforma motywów Xtreme One wydała wersję 1.2 z Xtreme Backup, która pozwala „eksportować lub importować ustawienia swoich Childthemes, układów lub widżetów ze wszystkimi ich ustawieniami / zawartością jako plik XML”.

Znalazł to współpracownik. Ciekawa koncepcja, choć nie działa na wielu serwerach. Nadal go badam, ale wygląda na to, że może on działać świetnie w przypadku wystąpienia scenicznego

http://code.google.com/p/deploymint/

Być może nie było tak, kiedy zadałeś pytanie, ale korzystam z usługi o nazwie Blogvault od kilku miesięcy i zrobiło to bezbłędnie. Prawdopodobnie wykonałem ponad 50 migracji (przekraczanie domen, subdomen i hostów internetowych), nie jest to żaden problem i nie zajmuje to wcale czasu.

Jest to usługa płatna (na domenę / miesiąc), ale nie tak bardzo.

RAMP to nowa wtyczka do wdrażania zawartości od Crowd Favourite, i wygląda naprawdę gładko. To jednak 250 USD, więc jeszcze tego nie wypróbowałem. Może jednak zwróci się w ilości zaoszczędzonego czasu, więc rozważam to.

Dużą zaletą, jaką ma w porównaniu z innymi wymienionymi metodami, jest to, że może inteligentnie łączyć posty, komentarze itp. Nie chodzi tylko o importowanie mysqldump, lecz bardziej o kontrolę źródła w bazie danych. Na przykład podczas wdrażania postu będzie także wdrażać tagi dla tego postu, jeśli nie istnieją jeszcze w produkcji.

Pozwól, że oddam jedną z moich ulubionych :-)

// proven local<->live codefork (covers local network testing, i.e. from mobile devices):
$GLOBALS['is_local'] =  
    in_array( $_SERVER['REMOTE_ADDR'], array("127.0.0.1","::1")) || // simple localhost (IPv4 IPv6)
              $_SERVER['HTTP_HOST'] == 'local.workblog'          || // call by local name (adjust)
       substr($_SERVER["REMOTE_ADDR"],0,8) == '192.168.';           // (mobile) device in local network

$table_prefix  = NULL; // ensure scope

if ( $GLOBALS['is_local'] )  // LOCAL fork ------------------------
{
        ....
}
else  // STAGE/LIVE fork -------------------
{

... a potem pracujesz na swój sposób. DB_NAME, DB_USER ... prefiks tabeli. Osobiście włączam ALTERNATE_WP_CRON na lokalnym (aby uniknąć irytujących ostrzeżeń ), WP_DEBUG na obu (jeśli nie jesteś programistą) lub tylko na żywo (jeśli jesteś), inny ini_set('display_errors', '0');na żywo może również zrobić coś dobrego, na koniec, jak wspomniano powyżej: WP_HOME i WP_SITEURL na odpowiedni lokalny / aktualny adres URL.

To prawie wszystko, nic nie pozostało ponad klasycznym WordPressem „To wszystko, przestań edytować!” linia...

192.168. część umożliwia wykonanie niektórych testów lokalnych (tj. z padów lub telefonów) w sieci lokalnej)

$ GLOBALS ['is_local'] może się również przydać w tworzeniu motywu, w celu uzyskania dodatkowych wyników debugowania itp.

Od jakiegoś czasu używam wtyczki Backupbuddy. Pozwala wykonać kopię zapasową bazy danych i wszystkich plików, pobrać ją jako plik zip lub wysłać bezpośrednio na inny serwer za pośrednictwem FTP. Pozwala również znaleźć i zastąpić adres URL. Cały proces zajmuje mi zwykle około 5 minut. Ponieważ wszystkie pliki są skompresowane, proces przesyłania / pobierania przebiega znacznie szybciej. I nie, nie pracuję dla nich, ale ta wtyczka naprawdę znacznie ułatwiła cały ten proces.

Innym przydatnym narzędziem do obsługi migracji serwerów dla witryn jest interfejs WordPress, w tym artykule jest dobry przegląd tego, co można zrobić, ale w szczególności sekcja „Wyszukaj i zamień” jest przydatna do znalezienia wszystkich odniesień do starego / dev URL strony :

Zaawansowane zarządzanie WordPress z WP-CLI

To najłatwiejszy sposób: https://themes.artbees.net/docs/website-migration/
Wystarczy dwa kliknięcia. Jeden do eksportu, drugi do importu.

Jest to możliwe przy użyciu wtyczki All in one WP Migration. Powyższy link pokazuje, jak z niego korzystać.

Jeśli próbujesz osiągnąć ciągłą synchronizację, sugeruję użycie rsync wraz z niestandardowym zadaniem cron do przepisania dowolnego adresu URL lub danych specyficznych dla witryny.

Po dłuższym śledzeniu tej odpowiedzi stworzyłem własną małą wtyczkę - Pitta Migration . Powody są następujące:

1. Ze wszystkich pomysłów wypróbowanych tutaj - najprostsze są opcje WP_HOMEiWP_SITEURL
2. Następnie używam ich do ustawienia dwóch pasujących wp_optionsadresów URL - co obejmuje przypadki, gdy wtyczki / motywy je ignorują
3. Daje mi to 100% pewności co do zmian w mojej bazie danych
4. Działa to również na różnych platformach (wszystkie skrypty bash nie działają ładnie w systemie Windows)
5. Łatwo jest zrozumieć, co robi wtyczka
6. Nie ma konfiguracji poza dwiema stałymi - wykonaj mysqldump i mysql zaimportuj do lokalnej bazy danych, a wtyczka zobaczy, że stała i tabela różnią się, i zaktualizuje je, aby pasowały
7. Bez wyszukiwania tekstu i zamiany
8. Nie ma szans na zbicie bazy danych - używam obiektu bazy danych WordPress do dwóch aktualizacji i nic więcej
9. Ładnie współpracuje z takimi elementami, jak WordPress Skeleton, w którym możesz mieć wszystko pod kontrolą źródła i ustawić lokalną konfigurację
10. Umieściłem go w katalogu wtyczek WordPress i na Github, aby był bezpłatny, w pełni otwarty, łatwy do rozwidlenia i łatwy w instalacji
11. Po zainstalowaniu możesz o nim zapomnieć i powinien on po prostu „działać” - wystarczy, że powiesz, że baza danych została zmodyfikowana
12. Powinien działać z każdym procesem tworzenia kopii zapasowych / FTP / przywracania

Moim zdaniem najłatwiej podążam ręcznie. Po prostu skopiuj folder wp-content i plik wp-config.php na nowy host. Wyeksportuj bazę danych ze starego hosta i zaimportuj ją do nowej bazy danych nowego hosta.

W nowej bazie danych hosta przejdź do tabeli opcji wp i tam zmień adres URL witryny i URL blogu na Nowy adres hosta ze starego hosta. jak z http: // localhost / wp do http://example.com

Teraz w pliku wp-config zmień informacje o bazie danych i użytkowniku, dodając nowe informacje o hoście.

Teraz zaloguj się do nowego wp-admin i przejdź do ustawień i zapisz bezpośredni link.

Gotowe. Myślę, że jest to proste bez użycia żadnych wtyczek.

Próbowałem różnych wtyczek i wszystkie z nich mają wiele problemów.

Dlatego wolę ten prosty ręczny transfer, który wydaje mi się łatwiejszy.