Cum să eficientizați migrațiile pe mai multe site-uri WordPress cu MU-Migration

Migrarea unui site WordPress de sine stătător într-un mediu de rețea de site (sau „multisite”) este un efort obositor și dificil, este și opusul adevărat. Importatorul WordPress funcționează destul de bine pentru site-uri mai mici, mai simple, dar lasă loc de îmbunătățire. Exportă conținut, dar nu și date de configurare a site-ului, cum ar fi configurațiile Widget și Customizer, pluginuri și setările site-ului. De asemenea, importatorul se luptă să gestioneze o cantitate mare de conținut. În acest articol, veți învăța cum să simplificați acest tip de migrare folosind MU-Migration, un plugin WP-CLI.

Înțelegerea Multisite-ului

Un multisite WordPress vă permite să rulați mai multe site-uri web în cadrul aceleiași instalări WordPress. Este adesea denumită „Rețea Multisite”. WordPress.com este probabil cel mai mare exemplu de rețea multisite, care rulează mii de site-uri în aceeași instanță WordPress.

Un multisite WordPress poate fi potrivit pentru mai multe cazuri de utilizare, unele dintre ele includ:

• Clientul dvs. poate avea mai multe proprietăți și ar putea avea sens să-și consolideze toate site-urile într-o instalare WordPress unică, partajând un singur domeniu, dar fără a se limita la acesta.

• Odată ce l-ați configurat, este un proces simplu și simplu de a crea site-uri noi și de a utiliza teme și plugin-uri deja disponibile în rețea

O înțelegere profundă a modului în care funcționează multisite depășește scopul acestui articol, dar puteți consulta următoarele linkuri:

• „Creați o rețea”, Codex, WordPress.org

• „WordPress Multisite: Funcții și metode practice”, Kevin Leary, Smashing Magazine

Înțelegerea provocărilor

Diferențele dintre structura unui singur site și a unui multisite WordPress sunt destul de rezonabile. Cu multisite, fiecare subsite primește propriul set de tabele de baze de date, cu excepția tabelului utilizatorului ( wp_user ) care este partajat pe toate site-urile. Modul în care funcționează acest lucru în WordPress este că fiecare set de tabele subsite-ului are ID-ul site-ului adăugat la numele fiecărui tabel ( wp_X_posts , wp_X_postmeta , wp_X_options ).

Această structură a bazei de date în sine introduce deja unele complexități. De exemplu, cum ați migra un subsite de la mai multe site-uri la o singură instalare? Evident, nu puteți doar să exportați și să importați baza de date într-o singură instalare - numele tabelelor sunt diferite! Ar trebui fie să redenumiți tabelele din fișierul .sql exportat, fie să utilizați o interogare ALTER TABLE SQL pentru a redenumi tabelele după importarea lor. Același lucru este valabil și pentru sensul opus: dacă importați un singur site în mai multe site-uri, prefixele de tabel vor trebui, de asemenea, actualizate. Sună a prea multă muncă, nu?

Tabelul utilizatorului în mai multe site-uri este global, ceea ce înseamnă că nu puteți doar să importați tabelul utilizatorului de pe site-ul dvs. unic, deoarece ar înlocui complet tabelul utilizatorului global cu mai multe site-uri. Dacă procedați invers, extrageți un subsite din WordPress și importați într-un singur site, veți transporta toți utilizatorii rețelei, chiar și pe cei care nu aparțin subsite-ului migrat. În plus, dacă migrați un subsite de la un multisite la altul, exportul tabelului utilizatorului este complet în afara tabelului.

Cea mai bună soluție este să exportați utilizatorii separat, dar introduce o altă problemă: atunci când utilizatorii sunt importați, vor primi ID-uri diferite. Pentru a rezolva această problemă, este necesar să urmăriți ID-urile noului utilizator, să creați un tabel de mapare și să utilizați tabelul de mapare pentru a actualiza toate referințele la ID-urile utilizatorilor în WordPress! Din nou, prea multă muncă, nu?

Acestea sunt doar două exemple ale provocărilor cu care cineva se poate confrunta atunci când se confruntă cu migrații ca acesta. Există o grămadă de alte lucruri minore care trebuie avute în vedere, cum ar fi mutarea dosarului de încărcări în locația potrivită, migrarea înregistrărilor din baza de date care fac referire la ID-ul site-ului etc.

Faceți cunoștință cu MU-Migration

MU-Migration este un plugin WP-CLI pe care l-am creat în timp ce lucram la mai multe migrări de clienți și, ulterior, oferit de 10up. A fost conceput pentru a eficientiza procesul de mutare a site-urilor de la un singur site WordPress la o instanță multisite (sau invers). În esență, exportă totul într-un pachet ZIP care poate fi apoi folosit pentru a importa site-ul în instalarea WordPress dorită.

Funcționează prin exportarea conținutului site-ului și, opțional, a temei, plugin-urilor și încarcă foldere într-un pachet zip care poate fi importat cu ușurință într-o altă instalare WordPress. Când utilizați MU-Migration, nu trebuie să vă faceți griji cu privire la detaliile tehnice de bază ale migrării. Pur și simplu se va ocupa de toate acestea pentru dvs., astfel încât să vă puteți concentra pe ceea ce este important: furnizarea unei migrări de succes clienților dvs.

Instalarea WP-CLI și MU-Migration

Pentru a utiliza MU-Migration, mai întâi trebuie să instalați WP-CLI, instrumentul oficial de linie de comandă WordPress. Instalarea WP-CLI este la fel de simplă ca și rularea comenzilor de mai jos pe serverul dvs.:

 $ curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar $ chmod +x wp-cli.phar $ sudo mv wp-cli.phar /usr/local/bin/wp

După ce rulați acești pași, veți putea executa WP-CLI tastând doar wp din orice instalare WordPress, atâta timp cât vă aflați în directorul rădăcină WordPress.

De exemplu, în folderul de instalare WordPress, încercați să rulați următoarea comandă:

 $ wp theme status

Este o comandă simplă și va lista toate temele disponibile, evidențiind care dintre ele este activă în prezent.

În cele din urmă, pentru a instala MU-Migration, puteți utiliza comanda package install . Utilizați următoarea comandă pentru a descărca și instala MU-Migration ca plugin WP-CLI.

 $ wp package install 10up/mu-migration

Efectuarea unei migrari simple

Utilizarea MU-Migration este destul de simplă. Pentru primul nostru scenariu, vom muta un singur site WordPress într-o instalare WordPress multisite.

Exportarea site-ului unic

Vom începe prin a exporta site-ul unic. Pentru a face acest lucru, trebuie să folosim comanda export all :

 $ wp mu-migration export all single-site.zip --themes --plugins --uploads

Comanda de mai sus va exporta întregul site într-un pachet ZIP, steagurile --themes , --plugins și --uploads -urile sunt opționale și vor include tema curentă, toate pluginurile și, respectiv, folderul de încărcări în export. În funcție de dimensiunea site-ului dvs., poate dura ceva timp pentru a finaliza procesul, dar pentru majoritatea site-urilor, procesul de export nu ar trebui să dureze mai mult de câteva minute.

Odată ce se termină, va crea un fișier numit single-site.zip care conține toate datele, temele și pluginurile site-ului, precum și directorul de încărcări. Următorul pas este să îl mutați pe serverul în care locuiește multisite-ul WordPress. Puteți utiliza clientul SFTP preferat sau o soluție mai robustă, cum ar fi rsync .

Importarea unui singur site în mai multe site-uri

Cu fișierul exportat în serverul tău multisite, tot ce trebuie să faci este să folosești comanda de import din directorul multisite WordPress; Inutil să spunem că atât WP-CLI, cât și MU-Migration trebuie instalate și pe serverul de destinație.

 $ wp mu-migration import all /path/to/single-site.zip --new_url=example.com/single-site

Comanda de mai sus va prelua fișierul single-site.zip , îl va extrage și va importa totul în multisite. Acesta va crea un nou subsite în rețeaua dvs. Parametrul --new_url este opțional; va instrui MU-Migration să efectueze o căutare și să înlocuiască pentru a înlocui toate aparițiile URL-ului site-ului site-ului exportat cu cel specificat. Acest parametru este la îndemână atunci când migrarea include o modificare a adresei URL sau dacă importați local sau chiar într-un mediu intermediar.

Procesul de import durează, de obicei, mai mult și depinde de dimensiunea site-ului pe care îl importați, dar nu vă temeți, MU-Migration vă va ține la curent pe măsură ce se derulează migrarea. Când procesul se termină, MU-Migration vă va informa adresa URL finală a site-ului dvs. importat. Este recomandat să ștergeți toate straturile cache care rulează pe serverul dvs., în special Memcache sau Redis.

Reluarea unei migrații

Când faceți migrări, este destul de obișnuit să faceți mai întâi o operațiune uscată cu scopul de a testa lucrurile înainte de a rula migrarea finală, ceea ce înseamnă, de obicei, să luați un alt export și să reimportați în instalația multisite de destinație. Cu toate acestea, rețineți că în primul nostru exemplu de migrare, MU-Migration a creat un nou subsite în cadrul rețelei pentru a importa un singur site deasupra acestuia. Rularea exactă a aceleiași comenzi din nou ar duce la crearea unui alt subsite, care nu este exact ceea ce ne-am aștepta.

Din fericire, este posibil să specificați un blog_id , care îi spune MU-Migration să înlocuiască subsite-ul cu blog_id specificat. De exemplu, să presupunem că comanda anterioară de import a creat un subsite cu 2 ca ID și doriți să rulați din nou migrarea. Ai putea face următoarele:

 $ wp mu-migration import all /path/to/single-site.zip --new_url=example.com/single-site --blog_id=2

Dacă nu cunoașteți blog_id , îl puteți obține prin Setări de administrator de rețea sau rulând $ wp site list .

Extragerea unui subsite dintr-o instalare multisite

MU-Migration acceptă, de asemenea, extragerea subsite-urilor din instalări multisite și importarea acestora fie într-un alt site multiplu, fie într-un singur site.

Pentru aceste două scenarii, am rula comanda de export dintr-o instalare multisite și nu de pe un singur site; aceasta înseamnă că avem nevoie de o modalitate de a specifica ce subsite vrem să exportăm. Pentru a face asta, trebuie doar să transmitem parametrul --blog_id la comanda de export:

 $ wp mu-migration export all subsite-3.zip --themes --plugins --uploads --blog_id=3

În acest exemplu, exportăm un subsite cu ID-ul egal cu 3; aceasta va crea un fișier ZIP care este gata pentru a fi importat într-un alt site multiplu sau într-un singur site. Comanda pentru importul într-un singur site și multisite este exact aceeași, MU-Migration va detecta dacă rulează pe mai multe site-uri sau nu și se va adapta la asta automat. Pe o notă secundară, atunci când importați într-o altă instanță multisite, puteți specifica și parametrul --blog_id pentru a înlocui un subsite existent.

 $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ] $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ] $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ]

Sfaturi pentru desfășurarea unor migrații mari

În timp ce exemplele anterioare funcționează foarte bine pentru migrarea de dimensiuni mici spre medii, migrarea site-urilor mari către sau de la mai multe site-uri poate dura un timp rezonabil. În această secțiune, voi împărtăși câteva lecții învățate în timp ce fac mai multe migrări similare unei întreprinderi.

Creați un plan de migrare

Migrările de date sunt adesea necesare, dar este o parte neglijată a multor proiecte. Migrațiile pot fi greoaie și complexe, dar atunci când sunt planificate corespunzător, pot fi nedureroase. Crearea unui plan de migrare ar trebui să fie primul pas al oricărui proiect de migrare.

Un plan de migrare tipic include lucruri precum:

• Impactul migrării asupra oricăror procese editoriale de producție (de exemplu, înghețarea conținutului, cerințele diferențiate de migrare).

• Cât timp este de așteptat să ruleze migrarea?

• Cum vor fi restaurate backup-urile? Cum va fi gestionată o migrare eșuată?

• Cum va afecta procesul de export performanța site-ului? Multe site-uri nu își pot permite un export de baze de date în orele de vârf.

Ca regulă generală, migrările ar trebui să fie cât mai fluide posibil și, în mod ideal, în ziua lansării, toate sarcinile grele ar fi fost deja finalizate și ar trebui efectuate doar pașii care sunt strict necesari. Aceasta înseamnă că ar trebui să migrați tot ce puteți înainte de data reală de lansare, deoarece vă va oferi spațiu pentru remedierea erorilor și QA. Dacă este un site nou construit și migrați date, puteți beneficia adesea de o fereastră de înghețare a conținutului și puteți muta conținutul din timp. De asemenea, puteți utiliza strategii pentru a vă muta progresiv conținutul, dacă este posibil. Consultați secțiunea următoare pentru un exemplu al acestei tehnici.

Deși neglijat de multe ori, un plan adecvat de migrare poate evita o mare varietate de probleme legate de migrare. Nu lăsați circumstanțe neașteptate să vă facă eșuarea migrației, planificați din timp! Pentru o discuție mai aprofundată despre planificarea unei migrări, vă încurajez să consultați secțiunea de migrare a celor mai bune practici 10up.

Utilizați Rsync pentru a copia progresiv încărcările

Dosarul de încărcări al site-urilor mari poate fi extrem de mare, iar comprimarea acestuia într-un fișier ZIP pentru extragere ulterioară nu este întotdeauna cea mai bună și mai rapidă soluție. Există mai multe alte modalități de a copia folderul de încărcări pe serverul de destinație. Un instrument utilizat în mod obișnuit pentru migrarea similară unei întreprinderi este rsync , care poate transfera fișiere între servere mai rapid decât folosind o soluție SFTP standard și, ca plus, poate întrerupe și restabili transferurile. Păstrează evidența a ceea ce a fost deja transferat, ceea ce înseamnă că ne putem sincroniza progresiv fișierele. De exemplu, puteți începe să sincronizați fișierele cu câteva zile înainte de migrarea efectivă pentru a vă câștiga ceva timp. Apoi, în ziua migrării, tot ce trebuie să faceți este să sincronizați fișierele pentru a vă asigura că tot ce a fost adăugat de la ultima sincronizare este transferat pe serverul de destinație.

Singurul avertisment al acestei abordări este că va trebui să mutați manual subdirectoarele de încărcări în locul potrivit, deoarece multisite-ul are o structură ușor diferită pentru folderul de încărcări: fiecare site primește propriul subdirector unde numele său este ID-ul site-ului. .

Ca exemplu final, să vedem cum am putea migra un singur site mare într-o instanță cu mai multe site-uri. Vom începe prin a exporta site-ul unic într-un pachet ZIP și vom rula un test de rulare uscată pe serverul de destinație. În acel moment, site-ul nu ar fi accesibil nimănui, deoarece domeniul indică în continuare către vechiul server, ceea ce înseamnă că puteți îndrepta în siguranță fișierul gazdei către noul server pentru a testa migrarea. De asemenea, puteți activa un plugin precum Restricționați accesul la site pe site-ul de destinație pentru a vă asigura că nu este în niciun fel accesibil public.

Pentru testul nostru de funcționare uscată, am exporta site-ul cu câteva zile sau săptămâni înainte de data planificată de migrare pentru a testa și a obține o idee despre cât timp va dura procesul. Rețineți că folderul de încărcări nu este inclus.

Mai întâi faceți o alergare uscată

Întotdeauna faceți mai întâi o rulare uscată. În mod ideal, o rulare uscată ar trebui să aibă loc pe serverul real sau într-un mediu de pregătire cu o stivă de server similară.

Luați în considerare utilizarea --mysql-single-transaction

Comanda de import acceptă, de asemenea, un --mysql-single-transaction care va include exportul SQL într-o singură tranzacție pentru a comite toate modificările de la import simultan, prevenind scrierea să copleșească serverul bazei de date, în special în mediile MySQL în cluster.

 $ cd /path/to/wordpress $ wp mu-migration export all site.zip --themes --plugins

Cu rsync , putem transfera cu ușurință fișierul exportat generat:

 $ rsync -aP site.zip [email protected]:/var/www/multisite/

Apoi rulăm comanda de import pe serverul de destinație:

 $ ssh [email protected] $ cd /var/www/multisite $ wp mu-migration import all site.zip

Acum trebuie să știm care este blog_id -ul subsite-ului nou creat; putem obține aceste informații rulând:

Din rezultatul comenzii de mai sus știm că site-ul nostru a fost importat cu ID-ul 2. Vom avea nevoie de acesta pentru a muta corect folderul de încărcări folosind rsync . De pe un singur server de site, am rula următoarele:

 $ rsync -azP wp-content/uploads/ [email protected]:/var/www/multisite/wp-content/uploads/sites/2/

Comanda de mai sus va copia întregul folder de încărcări în locul potrivit pe o instalare multisite, care se află sub folderul site-uri și într-un folder în care numele său este doar ID-ul site-ului (în acest caz, 2). În acest moment, acum putem edita fișierul gazdei pentru a indica domeniul unic site-ului către serverul multisite; apoi putem face unele teste pentru a ne asigura că migrarea a funcționat conform așteptărilor.

Pentru migrarea finală, totul ar fi la fel, cu excepția faptului că am transmite --blog_id=2 la comanda de import:

 $ wp mu-migration import all site.zip --blog_id=2

Și ca beneficiu, sincronizarea încărcărilor se va face mult mai rapid, deoarece rsync va transfera doar fișierele care au fost modificate sau adăugate de la ultima sincronizare.

Concluzie

Migrarea către sau de la multisite este dificilă, iar instrumentul introdus în acest articol simplifică întregul proces de migrare prin reducerea efortului la câteva comenzi CLI. MU-Migration a fost utilizat în mod activ în producție de mai bine de un an și este un proiect complet open-source. Pluginul este dezvoltat pe Github și solicitările de extragere sunt binevenite!