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?
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?
Odpowiedzi:
@ 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:
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.php
które normalnie przez zakomentowanie cztery (4) określa DB_NAME
, DB_USER
, DB_PASSWORD
i 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.php
moż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 .dev
domenami 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.php
wywołaniem.
Po zaktualizowaniu wp-config.php
możesz po prostu użyć skrótu URL, wp-migrate-webhosts
aby przejść do ekranu administratora w następujący sposób:
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_webhosts
akcję, 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
, domain
itd. 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_apikey
elementem w register_webhost () tablica i mały zwyczaj migrate_webhosts
hak 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_HOME
i WP_SITEURL
włą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/hosts
domena 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:
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
, git
i rsync
zsynchronizować 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:
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.
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ż:
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:
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:
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
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.
WP_LOCAL_DEV
stałą, aby uzyskać coś podobnego
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 :
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:
WP_HOME
iWP_SITEURL
wp_options
adresów URL - co obejmuje przypadki, gdy wtyczki / motywy je ignorują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.