Cum să muți folderul wp-content WordPress existent împreună cu baza de date pe un server nou și un nou nume de domeniu?
Rulez WordPress 3.5.1 pe o stivă LEMP (pe Linode)...
Am un folder wp-content pentru un site WP împreună cu o copie de rezervă completă a bazei de date. URL-ul site-ului era ceva de genul:
test.example.com
Doresc să fac site-ul operațional pe propriul meu server la:
test.mydomain.com
Și odată ce site-ul este finalizat și modificările DNS intră în vigoare, vreau ca URL-ul site-ului să fie:
myclientsdomain.com
Care este metoda preferată (și, sper, cea mai simplă) de a gestiona mutările de server și schimbările de domeniu de acest gen? Caut un răspuns pas cu pas, unul care să țină cont de toate situațiile descrise mai sus atât pentru fișiere, cât și pentru baza de date.

Există un ghid pas cu pas excelent pentru mutarea WordPress în Codex. Este ceea ce urmez când schimb domeniile.
Mutarea fișierelor este destul de simplă. Referințele hard-codate din baza de date sunt cele dificile. Totuși, căutarea și înlocuirea serializată se va ocupa de toate modificările din baza de date. Am folosit în trecut plugin-ul Velvet Blues, dar scriptul Search and Replace este foarte bun.

Eu folosesc minunatul plugin Duplicator pentru a finaliza această procedură exactă în mod regulat.
http://wordpress.org/extend/plugins/duplicator/
Plugin-ul este complet suportat și există întrebări frecvente excelente disponibile aici:
http://lifeinthegrid.com/labs/duplicator/
Plugin-ul va crea o copie de rezervă .zip atât pentru baza de date, cât și pentru fișiere, precum și un fișier de instalare .php pe care îl veți plasa în noul director rădăcină. Pur și simplu introduceți noile informații ale bazei de date și el face restul.
Este probabil plugin-ul meu preferat pentru WordPress până acum.
Dacă aveți nevoie de ajutor pe parcurs, nu ezitați să mă anunțați.

Folosesc acest plugin ÎNTOTDEAUNA pentru site-urile clienților, pot crea o copie exactă a WordPress-ului lor și o pot instala pe serverul meu de dezvoltare, fac modificările și apoi pot copia exact înapoi pe serverul lor dacă este nevoie

Vei avea câteva lucruri de luat în considerare (mai târziu în răspuns), sugerez următorii pași:
Fă o copie de rezervă a fișierelor și bazei de date
Acest lucru este destul de explicativ. Vei face multe manipulări de date, așa că asigură-te că originalul tău este în siguranță.
Transferă fișierele tale
Cea mai rapidă metodă este să ai un furnizor de servicii de găzduire unde poți importa directoare de pe un alt server. Acest lucru se poate face furnizând detaliile FTP, precum și definind directorul țintă.
Deoarece serverele au de obicei o conexiune la internet mult mai rapidă decât cea pe care o au utilizatorii, aceasta este metoda preferată pentru transferul datelor. Poți folosi și linia de comandă pentru a executa aceste comenzi manual.
Opțiunea mai lentă este să generezi un fișier ZIP, să-l descarci, să-l încarci pe noul tău server și să-l decomprimi. Dacă nu ai posibilitatea de a face asta, mergi pe calea cea lentă - descarcă tot și încarcă tot. Și mergi să bei o cafea în timp ce fișierele se transferă :)
Transferă baza ta de date
Din nou, mulți furnizori de servicii de găzduire au opțiunea de a importa o bază de date existentă într-una nouă, chiar și de pe un alt server (desigur, vechiul tău server trebuie să accepte conexiuni externe de date).
Dacă poți face asta, minunat, dar poți și exporta/importa baza ta de date.
Setează noul (Sub-)Domeniu pe noul tău director
Pe noul tău server, asigură-te că fișierele tale sunt configurate la fel ca pe cel vechi și direcționează subdomenul tău către același director ca pe serverul vechi (de obicei rădăcina WordPress)
Editează wp-config.php
Salvează noul wp-config.php
. Trebuie doar să editezi detaliile de conectare la baza de date.
Încarcă noua URL
WordPress ar trebui să fie configurat până acum, dar încă folosește vechea SiteURL și AdminURL, așa că nu vei putea să te autentifici.
Schimbă acele valori în tabelul options
din noua ta bază de date. Cele două valori pe care le cauți sunt siteurl
și home
. Pune noul domeniu acolo.
Verifică autentificarea și site-ul tău
Acum totul ar trebui să funcționeze până acum, poți să te autentifici, să editezi și să scrii, precum și să folosești site-ul. Singura problemă poate fi că postările tale încă au vechea URL pentru imagini și atașamente în ele.
Dacă postările tale conțin vechea URL, sau dacă nu ești sigur, verifică baza ta de date în tabelul posts
.
Poți face asta căutând direct în baza ta de date sau folosind un script precum Serial Search and Replace. Dacă găsești vechea URL, va trebui să o înlocuiești manual sau automat. Eu prefer să o fac automat și să verific erorile ulterior.
Verifică celelalte tabele
Verifică și dacă celelalte tabele conțin vechea URL. Aceasta poate fi un pic mai dificil de înlocuit, dar trebuie făcut pentru a muta complet site-ul.
Regenerează permalinkurile tale
Doar pentru a fi sigur, salvează din nou setările de permalinkuri pentru a le recrea.
Verifică site-ul tău
Te rog, nu uita să verifici CU ADEVĂRAT site-ul tău după ce l-ai transferat. Verifică toate funcțiile, în special cele AJAX, formularele de contact, hărțile, etc., deoarece acestea au șanse mai mari să eșueze decât PHP/HTML simplu.
Timp pentru bere :)
Lucruri la care trebuie să fii atent!!
Ca întotdeauna, nimic care a fost creat manual, transferat manual și editat automat nu este sigur. Iată câteva capcane comune în care este ușor să pici, dar care pot fi evitate ușor.
- Pluginuri prost codate (Salvează URL-ul site-ului tău în loc de calea relativă și folosește funcțiile WordPress pentru a obține URL-ul complet. Pot apărea și multe probleme cu AjaxURL.)
- Probleme de codare (Fii absolut sigur că folosești aceeași codare pe ambele servere și baze de date!!! De obicei, dacă mergi cu UTF-8 recomandat, ar trebui să fie bine)
- Date serializate (Aceasta este cea mai mare problemă pe care o poți întâlni. Dacă folosești un plugin precum Tablepress, unde un întreg tabel este stocat într-un array serializat, acesta se va strica imediat ce înlocuiești ceva automat. Dacă ai date de genul acesta, caută o funcție de export/import în acel plugin specific și folosește-o ca un pas suplimentar. Dacă nu au această funcție, va trebui să o faci manual)
- Setări de server (Se poate întâmpla ușor ca site-ul tău să nu ruleze pe noul server din cauza setărilor implicite. Asigură-te că ai suficiente resurse disponibile!)
- URL-uri hardcodate în tema ta (deși acest lucru nu ar trebui să se întâmple, se întâmplă prea des și strică imaginile și linkurile imediat ce vechiul site nu mai este disponibil)
- Probleme de caching (Nu folosi aceleași fișiere de caching ca pe serverul vechi. Cea mai bună metodă ar fi să dezactivezi caching-ul înainte de a exporta site-ul, precum și să golești toate cache-urile)
- Presupunerea că totul funcționează când schimbi setările a doua oară pe server (verifică întotdeauna totul din nou)
- Opțiuni în pluginurile și tema ta (vechile adrese de email etc.)
Asta ar trebui să fie tot. Pare mult de făcut, dar de fapt majoritatea se întâmplă automat. Trebuie doar să te gândești la tot ce POATE merge prost și să verifici dacă s-a întâmplat :)
Distracție plăcută!

Nu este nevoie să folosești plugin-uri, scripturi sau cunoștințe de SQL. Un simplu editor de text este suficient pentru migrare. Trebuie să încarci toate fișierele WordPress pe noul server și să modifici doar 3 valori în wp-config.php (din directorul principal WordPress): define('DB_NAME', 'numele_nou_baza_date'); define('DB_USER', 'nume_utilizator_baza_date'); define('DB_PASSWORD', 'parola_baza_date');
Apoi, dacă folosești un client MySQL precum phpMyAdmin pe serverul curent, trebuie să exporti baza de date într-un fișier, să deschizi your_db_dump.sql în editorul de text, să găsești și să înlocuiești toate aparițiile test.example.com cu test.mydomain.com, după care trebuie să imporți acel fișier .sql în noua bază de date (pe care ai definit-o în wp-config.php). Asta e tot.

O simplă căutare și înlocuire va eșua în aproximativ 99% din cazurile de mutare a domeniului, deoarece o parte din date, în special widget-urile, sunt serializate și trebuie să ajustați atât dimensiunile șirurilor, cât și conținutul.

Nu pot fi de acord cu tine. Am mutat multe instalări WordPress cu această metodă și a funcționat întotdeauna. În baza de date, aproape toate înlocuirile se fac cu guid-ul postărilor. Doar câteva înlocuiri se fac în wp_options (cum ar fi siteurl, home). Pot fi de acord că unele date sunt serializate, dar acest lucru nu este aplicabil pentru URL-ul domeniului nostru. Widget-urile proiectate corect folosesc bloginfo('url'); nu URL direct, așa că nu trebuie să ne îngrijorăm de datele serializate.

da, dacă planifici în avans sau ai doar noroc, s-ar putea să funcționeze, de aceea am spus 99% ;), dar întrebarea este una generală. Și asta din propria mea experiență.

Deci avem experiențe diferite ;) Aș spune că această metodă VA funcționa în 99% din cazuri. Poate greșesc, pentru că lucrez cu wp doar de câțiva ani, dar nu am întâmpinat nicio rezistență în timpul mutării wp, nici măcar cu plugin-uri și widget-uri activate.

cred că depinde de ce folosești pe site. Experiența mea proastă a fost cu site-uri simple... Ideea este că, așa cum a subliniat @helgatheviking, există o unealtă gratuită care face căutarea și înlocuirea și ține cont de serializare, așa că nu este nevoie să riști chiar dacă ești 99% sigur că vei câștiga.

da, va funcționa în 99% din cazuri, dar de ce să îndrumi greșit chiar și 1%? Răspunsul tău ar trebui să includă mențiunea că poate invalida unele date. Într-o lume ideală toate plugin-urile sunt codate perfect, dar într-adevăr am întâlnit și eu acest lucru, nu trăim într-o lume perfectă.

Sunt de acord, că nu trăim într-o lume perfectă și întotdeauna există o oarecare șansă de eșec. Amândoi aveți dreptate. El a cerut cea mai directă cale pentru migrare și cred că aceasta este ea. Și va funcționa în majoritatea cazurilor. Cu un risc de 1% de eșec, pot să risc, dacă ar trebui să fie cea mai ușoară cale. Aceasta este propunerea mea pentru rezolvarea acestei probleme. Dacă te pot întreba, ai putea să-mi trimiți câteva linkuri pentru plugin-uri sau widget-uri care ar putea crea probleme cu acest mod de migrare? Nu am văzut până acum.

Ceea ce fac eu este:
Creez o nouă bază de date pe gazda de destinație. Import fișierul SQL. Rulez următoarele interogări SQL pe noua bază de date:
UPDATE wp_options SET option_value = replace(option_value, 'test.example.com', 'test.mydomain.com') WHERE option_name = 'home' OR option_name = 'siteurl'; UPDATE wp_postmeta SET meta_value = replace(meta_value, 'test.example.com', 'test.mydomain.com') WHERE meta_key = '_menu_item_url'; UPDATE wp_posts SET guid = replace(guid, 'test.example.com','test.mydomain.com'); UPDATE wp_posts SET post_content = replace(post_content, 'test.example.com', 'test.mydomain.com');
Încarc fișierele WordPress pe serverul de destinație.
- Încarc folderul wp-content, suprascriind fișierele implicite WordPress.
- Configurez wp-config.php în mod normal, folosind numele bazei de date, utilizatorul și parola din baza de date creată.
- Merg în Panoul de control și schimb manual orice instanțe ale test.example.com în widget-uri (acestea nu pot fi schimbate prin interogare SQL deoarece sunt serializate în baza de date).
- Când va veni momentul să trec la myclientsdomain.com, efectuez din nou interogările SQL și remedierile widget-urilor menționate mai sus.
În funcție de tema și plugin-urile folosite, poate fi nevoie să faci modificări suplimentare în baza de date sau în Panoul de control. Acestea vor trebui descoperite și schimbate pe măsură ce le găsești.
Avertisment cinstit că nu este perfect și poate fi o adevărată bătaie de cap să muți WordPress între domenii. Un alt lucru pe care l-am văzut făcut este adăugarea următoarelor în fișierul wp-config:
define('WP_HOME','http://'. $_SERVER['SERVER_NAME']);
define('WP_SITEURL','http://'. $_SERVER['SERVER_NAME']);
Aceasta va ajuta site-ul să funcționeze pe orice domeniu se află în prezent, dar va trebui totuși să te ocupi de URL-uri hardcodate în conținut, opțiuni și meniuri. Nu am testat acest lucru personal și nu știu dacă trebuie să elimini opțiunile corespunzătoare din baza de date pentru ca acestea să funcționeze.
Actualizare: Trebuia să ghicesc că va exista un plugin pentru gestionarea părții de bază de date http://wordpress.org/extend/plugins/wp-migrate-db/

Recomand serios să NU faceți comenzile SQL de actualizare sugerate mai sus. Tabelul de opțiuni poate conține în special multe date serializate - simpla înlocuire/căutare în date serializate va corupe acele date

Sugerez eliminarea completă a acelei părți din răspunsul dvs. și, de fapt, avertizarea împotriva tehnicilor manuale de căutare/înlocuire precum aceea sau utilizarea comenzii 'sed'.

Nu fac o simplă înlocuire/căutare. Limitez comenzile la modificarea câmpurilor care NU conțin date serializate și, de fapt, menționez să nu folosiți astfel de comenzi pentru a modifica informațiile stocate în widget-uri, deoarece acele date SUNT serializate.
În ceea ce privește tabelul de opțiuni, folosesc specific instrucțiunea WHERE "WHERE option_name = 'home' OR option_name = 'siteurl';" pentru a evita modificarea datelor serializate.

Am observat acum, am ratat clauza WHERE prima dată când am citit-o. Îmi pare rău pentru asta. Totuși, nu ar trebui să fie nevoie să modifici valorile home și siteurl în tabela options, asta face WP_HOME/WP_SITEURL. Folosirea acestor definiții suprascrie valorile din tabela options, iar adăugarea definiției suplimentare WP_RELOCATE determină ca primele două să suprascrie setările din tabela options.

De asemenea, sunt destul de sigur că nu ar trebui să modifici guid-urile din tabela post. Acestea nu sunt menite să fie folosite ca URL-uri, ci mai degrabă ca ID-uri unice. Edit: Am verificat - pentru atașamente există un caz în care trebuie să modifici guid-ul, dar nu se aplică unei schimbări simple de domeniu.

Veți observa că utilizarea definirii WP_HOME și WP_SITEURL a fost separată de restul răspunsului meu și am menționat și "Nu am testat asta personal și nu știu dacă trebuie să elimini opțiunile corespunzătoare din baza ta de date pentru ca acestea să funcționeze." Am recunoscut că nu știam mai multe despre acest subiect, dar că era diferit de utilizarea bazei de date.
GUID-urile nu sunt doar ID-uri unice și schimbarea lor nu este întotdeauna necesară, dar nu este dăunătoare.

Este în regulă, doar oferam informații mai relevante despre acele două opțiuni, nu încercam să transform discuția într-o ceartă. În ceea ce privește GUID-urile, acestea pot fi de fapt dăunătoare. Ele sunt unice la nivel global. Global în acest caz înseamnă întreaga lume, de aceea includ informații despre domeniu. Deci, orice sistem extern care interacționează cu sistemul tău (de exemplu, un agregator RSS), va pierde urmărirea întregului tău conținut.

Relevant - http://codex.wordpress.org/Changing_The_Site_URL#Important_GUID_Note

OP a spus că transferă de pe site-ul său de dezvoltare. Acest site nu ar trebui să fie încă agregat, iar dacă este, pierderea acestor linkuri este preferabilă, deoarece nu dorești ca linkurile și conținutul către spațiul tău de dezvoltare să ajungă în surse externe.

"Pentru ca câmpul GUID să fie 'global' unic, este o convenție acceptată să se utilizeze URL-ul sau o reprezentare a acestuia. Astfel, dacă deții example.com, atunci doar tu folosești example.com și, prin urmare, este unic pentru tine și site-ul tău." <- Acest lucru poate fi încălcat dacă GUID-ul conține domeniul de dezvoltare (dacă spațiul de dezvoltare este agreat de surse externe, de exemplu). Brusc, există două postări care au același GUID. Mai bine ar fi să conțină domeniul live, astfel încât această regulă să poată fi respectată, după părerea mea.

Un răspuns anterior conținea această metodă, dar iată pașii detaliați cu câteva informații suplimentare:
- Nu instala WordPress
- Transferă prin FTP întregul director original WordPress într-un director nou (vezi mai jos dacă lipsește ceva)
- Importă baza de date SQL folosind phpMyAdmin din panoul de control al serverului tău.
- Transferă fișierul searchreplacedb.php în directorul în care se află WordPress.
- Rulează searchreplacedb.php din browser (șterge-l după aceea!!!)
Ia-ți puțin timp liber și facturează clientului tău 75$!
(searchreplacedb.php este disponibil GRATUIT pe: interconnectit.com/products/search-and-replace-for-wordpress-databases ... ei au și instrucțiuni).
Dacă ai doar folderul de conținut WordPress, ai o altă problemă. Trebuie să obții restul instalației WordPress de EXACT ACEEAȘI VERSIUNE. Caută în baza de date dacă nu știi ce versiune de WordPress este. Este ușor să descarci versiuni vechi online. Pune totul la locul potrivit ca înainte, folosind FTP pentru a configura noile foldere, dacă vrei să apară exact ca înainte. Nu vizita site-ul după ce ai încărcat baza de date și fișierele WordPress dacă lipsește ceva, altfel se va reveni la tema implicită sau se vor dezactiva pluginurile. Am pierdut setările pluginurilor și a trebuit să refac totul, așa că gândește-te bine și mergi încet.
Dacă ai deja un subfolder sau un addon, sau noul site va avea nevoie de unul, planifică în avans. Nu înlocui pur și simplu URL-ul fără a ține cont de noul folder necesar sau de absența acestuia. S-ar putea să fie nevoie să rulezi searchreplacedb pentru 'folder/url' înainte de a reveni la 'url', etc. Altfel ai putea strica un 'addon' transformându-l într-o 'instalare în director rădăcină cu afișare în subdirector' sau altă prostie de genul ăsta!
Dacă noua structură se potrivește cu cea veche și ai întregul director WordPress, poți face asta mai ușor și mai repede decât durează să citești acest post! Pune programul în același director în care ai încărcat WordPress pentru cele mai bune rezultate, așa cum spun instrucțiunile, deoarece are o configurare automată.
Dacă nu ai acces FTP sau la panoul de control sau la baza de date SQL, chiar ai nevoie de un server mai bun și s-ar putea să n-ai noroc.
Încearcă căutarea și înlocuirea recomandată în alte postări și, dacă ai noroc, ai o versiune mai veche de WordPress și se încadrează în parametrii necesari, va funcționa; o metodă foarte neplăcută de a te juca de noroc cu site-ul tău.
De asemenea, nu edita niciodată date în Notepad decât dacă știi că nu există șiruri mai lungi decât poate accepta. Iată o eroare frumoasă pe care s-ar putea să o cauți săptămâni întregi! Dacă trebuie să te uiți la ele, doar te uiți, nu le salva. Ar trebui să uiți că Notepad există și să folosești Notepad++, dar editarea manuală a datelor serializate într-un editor de text este la fel de rea ca încercarea de a face căutare și înlocuire în phpMyAdmin; nu face asta.
Poți căuta "sql serialized data". Răspunsul scurt este că căutarea și înlocuirea vor strica datele serializate într-un SQL. Bazele de date WordPress conțin date serializate... din ce în ce mai mult în prezent.
Am făcut asta de prea multe ori și am avut succes marginal și m-am lovit de pereți de multe ori înainte să cercetez corect problema. Acum este floare la ureche.

Am mutat mai multe site-uri de pe un server/domeniu pe altul în acest fel, și tot ce ai nevoie de obicei este o copie de rezervă și folderul wp-content, pe care pare că le ai. Iată metoda pe care o urmez:
- Instalează WordPress pe noul site. Poți folosi orice metodă dorești pentru asta, unele gazde oferă instalări cu un singur click, altfel poți proceda conform metodei preferate.
- Suprascrie folderul wp-content cu copia pe care o ai. Acest pas asigură că toate plugin-urile, fișierele încărcate etc. sunt la fel ca pe vechiul server.
- Suprascrie baza de date cu copia pe care o ai. Eu folosesc de obicei phpMyAdmin cu funcția de Import. Un lucru la care trebuie să fii atent este că, dacă copia ta de rezervă nu include instrucțiuni DROP, va trebui să ștergi mai întâi toate tabelele din baza de date.
- Dacă schimbi numele de domeniu, va trebui să navighezi în tabelul wp_options din phpMyAdmin și să actualizezi opțiunea "site_url". Există o altă opțiune numită "home" pe care o poți actualiza, dar nu este obligatoriu, deoarece aceasta poate fi schimbată din panoul de administrare WordPress odată ce site-ul tău este funcțional.
Gata!
Asta ar trebui să fie tot ce ai nevoie pentru a-ți face site-ul funcțional. Odată ce este operabil, ar fi bine să verifici orice setări specifice plugin-urilor/temelor care ar putea face referire la vechiul site și să regenerezi legăturile permanente.
