Come ottimizzare le migrazioni multisito di WordPress con la migrazione MU

La migrazione di un sito WordPress autonomo in un ambiente di rete di siti (o "multisito") è uno sforzo noioso e complicato, è anche vero il contrario. L'importatore di WordPress funziona abbastanza bene per i siti più piccoli e più semplici, ma lascia margini di miglioramento. Esporta il contenuto, ma non i dati di configurazione del sito, come le configurazioni di Widget e Customizer, i plug-in e le impostazioni del sito. L'importatore fatica anche a gestire una grande quantità di contenuti. In questo articolo imparerai come semplificare questo tipo di migrazione utilizzando MU-Migration, un plug-in WP-CLI.

Capire il multisito

Un multisito WordPress ti consente di eseguire più siti Web all'interno della stessa installazione di WordPress. Viene spesso definita "rete multisito". WordPress.com è probabilmente il più grande esempio di rete multisito, che esegue migliaia di siti all'interno della stessa istanza di WordPress.

Un multisito WordPress può adattarsi perfettamente a diversi casi d'uso, alcuni dei quali includono:

• Il tuo cliente potrebbe avere più proprietà e potrebbe avere senso consolidare tutti i suoi siti in un'unica installazione di WordPress, condividendo un singolo dominio, ma non solo.

• Una volta impostato, è un processo semplice e diretto per creare nuovi siti e sfruttare temi e plug-in già disponibili nella rete

Una profonda comprensione di come funziona il multisito va oltre lo scopo di questo articolo, ma puoi controllare i seguenti link:

• "Crea una rete", Codex, WordPress.org

• "WordPress Multisite: funzioni e metodi pratici", Kevin Leary, Smashing Magazine

Comprendere le sfide

Le differenze tra la struttura di un singolo sito e un multisito WordPress sono abbastanza ragionevoli. Con il multisito, ogni sito secondario ottiene il proprio set di tabelle del database, ad eccezione della tabella dell'utente ( wp_user ) condivisa tra tutti i siti. Il modo in cui funziona in WordPress è che ogni set di tabelle del sottosito ha l'ID del sito aggiunto al nome di ogni tabella ( wp_X_posts , wp_X_postmeta , wp_X_options ).

Questa stessa struttura del database introduce già alcune complessità. Ad esempio, come migrare un sito secondario da un sito multiplo a una singola installazione? Ovviamente, non puoi semplicemente esportare e importare il database nella singola installazione: i nomi delle tabelle sono diversi! Dovresti rinominare le tabelle nel file .sql esportato o utilizzare una query ALTER TABLE SQL per rinominare le tabelle dopo averle importate. Lo stesso vale per il modo opposto: se stai importando un singolo sito in un multisito, anche i prefissi delle tabelle dovranno essere aggiornati. Sembra troppo lavoro, giusto?

La tabella dell'utente in multisito è globale, il che significa che non puoi semplicemente importare la tabella dell'utente dal tuo singolo sito poiché sovrascriverebbe completamente la tabella dell'utente globale multisito. Se si esegue l'operazione inversa, estraendo un sottosito da WordPress e importando in un unico sito, si trasporteranno tutti gli utenti della rete, anche quelli che non appartengono al sottosito di cui si sta effettuando la migrazione. Inoltre, se si esegue la migrazione di un sito secondario da un multisito a un altro, l'esportazione della tabella dell'utente è completamente fuori tabella.

La soluzione migliore è esportare gli utenti separatamente, ma introduce un altro problema: quando gli utenti vengono importati, ottengono ID diversi. Per risolvere questo problema, è necessario tenere traccia degli ID del nuovo utente, creare una tabella di mappatura e utilizzare la tabella di mappatura per aggiornare tutti i riferimenti agli ID utente in WordPress! Ancora una volta, troppo lavoro, giusto?

Questi sono solo due esempi delle sfide che si possono affrontare quando si affrontano migrazioni come questa. Ci sono anche un sacco di altre cose minori che devono essere risolte, come spostare la cartella dei caricamenti nella posizione corretta, migrare i record nel database che fanno riferimento all'ID del sito, ecc.

Incontra MU-Migrazione

MU-Migration è un plug-in WP-CLI che ho creato mentre lavoravo su diverse migrazioni di client e successivamente reso open source da 10up. È stato concepito per semplificare il processo di spostamento dei siti da un singolo sito WordPress a un'istanza multisito (o viceversa). In sostanza, esporta tutto in un pacchetto ZIP che può quindi essere utilizzato per importare il sito nell'installazione di WordPress desiderata.

Funziona esportando il contenuto del sito e opzionalmente temi, plugin e carica le cartelle in un pacchetto zip che può essere facilmente importato in un'altra installazione di WordPress. Quando si utilizza MU-Migration, non è necessario preoccuparsi dei dettagli tecnici alla base della migrazione. Si occuperà semplicemente di tutto ciò per te in modo che tu possa concentrarti su ciò che è importante: fornire una migrazione di successo ai tuoi clienti.

Installazione di WP-CLI e MU-Migration

Per utilizzare MU-Migration, devi prima installare WP-CLI, lo strumento da riga di comando ufficiale di WordPress. Installare WP-CLI è semplice come eseguire i comandi seguenti sul tuo server:

 $ 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

Dopo aver eseguito questi passaggi, sarai in grado di eseguire WP-CLI digitando solo wp da qualsiasi installazione di WordPress, purché ti trovi all'interno della directory principale di WordPress.

Ad esempio, nella cartella di installazione di WordPress, prova a eseguire il comando seguente:

 $ wp theme status

È un comando semplice ed elencherà tutti i temi disponibili, evidenziando quale è attualmente attivo.

Infine, per installare MU-Migration, puoi sfruttare il comando package install . Utilizzare il comando seguente per scaricare e installare MU-Migration come plug-in WP-CLI.

 $ wp package install 10up/mu-migration

Esecuzione di una semplice migrazione

L'utilizzo di MU-Migration è abbastanza semplice. Per il nostro primo scenario, sposteremo un singolo sito WordPress in un'installazione multisito di WordPress.

Esportazione del sito unico

Inizieremo esportando il singolo sito. Per fare ciò, dobbiamo usare il comando export all :

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

Il comando sopra esporterà l'intero sito in un pacchetto ZIP, i flag --themes , --plugins e --uploads sono facoltativi e includeranno rispettivamente il tema corrente, tutti i plugin e la cartella dei caricamenti nell'esportazione. A seconda delle dimensioni del tuo sito, il completamento del processo può richiedere del tempo, ma per la maggior parte dei siti, il processo di esportazione non dovrebbe richiedere più di un paio di minuti.

Al termine, creerà un file chiamato single-site.zip contenente tutti i dati, i temi e i plug-in del sito, nonché la directory dei caricamenti. Il passaggio successivo è spostarlo sul server in cui risiede il multisito di WordPress. Puoi utilizzare il tuo client SFTP preferito o una soluzione più robusta come rsync .

Importazione del sito singolo in multisito

Con il file esportato nel tuo server multisito, tutto ciò che devi fare è utilizzare il comando di importazione dalla directory multisito di WordPress; inutile dire che sia WP-CLI che MU-Migration devono essere installati anche sul server di destinazione.

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

Il comando precedente prenderà il file single-site.zip , lo estrarrà e importerà tutto in multisite. Creerà un nuovo sito secondario nella tua rete. Il parametro --new_url è facoltativo; indicherà a MU-Migration di eseguire una ricerca e di sostituire per sostituire tutte le occorrenze dell'URL del sito esportato con quello specificato. Questo parametro è utile quando la migrazione include una modifica dell'URL o se stai importando in locale o anche in un ambiente di gestione temporanea.

Il processo di importazione di solito richiede più tempo e dipende dalle dimensioni del sito che stai importando, ma non temere, MU-Migration ti terrà aggiornato durante l'esecuzione della migrazione. Al termine del processo, MU-Migration ti comunicherà l'URL finale del tuo sito importato. Si consiglia vivamente di svuotare tutti i livelli di cache in esecuzione sul server, in particolare Memcache o Redis.

Rieseguire una migrazione

Quando si eseguono le migrazioni, è abbastanza comune eseguire prima una prova a secco allo scopo di testare le cose prima di eseguire la migrazione finale, il che di solito significa eseguire un'altra esportazione e reimportare nell'installazione multisito di destinazione. Tuttavia, si noti che nel nostro primo esempio di migrazione, MU-Migration ha creato un nuovo sito secondario all'interno della rete per importare il singolo sito su di esso. L'esecuzione dello stesso identico comando porterebbe alla creazione di un altro sito secondario, che non è esattamente quello che ci aspetteremmo.

Fortunatamente, è possibile specificare un blog_id , che dice a MU-Migration di sovrascrivere il sito secondario con il blog_id specificato. Si supponga, ad esempio, che il comando import precedente abbia creato un sito secondario con 2 come ID e si desideri eseguire nuovamente la migrazione. Potresti fare quanto segue:

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

Se non conosci blog_id , puoi ottenerlo tramite Impostazioni di amministrazione di rete o eseguendo $ wp site list .

Estrazione di un sito secondario da un'installazione multisito

MU-Migration supporta anche l'estrazione di siti secondari da installazioni multisito e l'importazione in un altro multisito o in un unico sito.

Per questi due scenari, eseguiremmo il comando export da un'installazione multisito e non da un singolo sito; questo significa che abbiamo bisogno di un modo per specificare quale sito secondario vogliamo esportare. Per fare ciò dobbiamo solo passare il parametro --blog_id al comando export:

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

In questo esempio, stiamo esportando un sito secondario con ID uguale a 3; questo creerà un file ZIP pronto per essere importato in un altro multisito o in un unico sito. Il comando per l'importazione in un sito singolo e multisito è esattamente lo stesso, MU-Migration rileverà se è in esecuzione su multisito o meno e si adatterà automaticamente a quello. In una nota a margine, durante l'importazione in un'altra istanza multisito, puoi anche specificare il parametro --blog_id per sovrascrivere un sito secondario esistente.

 $ 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= ]

Suggerimenti per eseguire grandi migrazioni

Sebbene gli esempi precedenti funzionino molto bene per migrazioni di piccole e medie dimensioni, la migrazione di siti di grandi dimensioni da o verso il multisito può richiedere un tempo ragionevole. In questa sezione, condividerò alcune lezioni apprese durante l'esecuzione di diverse migrazioni di tipo aziendale.

Crea un piano di migrazione

Le migrazioni dei dati sono spesso necessarie, ma sono una parte trascurata di molti progetti. Le migrazioni possono essere ingombranti e complesse, ma se pianificate in modo appropriato possono essere indolori. La creazione di un piano di migrazione dovrebbe essere il primo passo di qualsiasi progetto di migrazione.

Un tipico piano di migrazione include cose come:

• L'impatto della migrazione su tutti i processi editoriali di produzione (es. blocchi di contenuti, requisiti di migrazione differenziati).

• Quanto tempo dovrebbe durare la migrazione?

• Come verranno ripristinati i backup? Come verrà gestita una migrazione non riuscita?

• In che modo il processo di esportazione influirà sulle prestazioni del sito? Molti siti non possono permettersi un'esportazione di database durante le ore di punta.

Come regola generale, le migrazioni dovrebbero essere il più fluide possibile e, idealmente, il giorno del lancio, tutto il lavoro pesante sarebbe già stato completato e dovrebbero essere eseguiti solo i passaggi strettamente necessari. Ciò significa che dovresti migrare tutto ciò che puoi prima della data di lancio effettiva in quanto ti darà spazio per correggere errori e QAing. Se si tratta di una nuova build del sito e stai migrando i dati, spesso puoi beneficiare di una finestra di blocco dei contenuti e spostare i tuoi contenuti in anticipo. Puoi anche utilizzare strategie per spostare progressivamente i tuoi contenuti, se possibile. Dai un'occhiata alla sezione successiva per un esempio di questa tecnica.

Sebbene trascurato molte volte, un piano di migrazione adeguato può evitare un'ampia varietà di problemi su una migrazione. Non lasciare che circostanze impreviste causino il fallimento della tua migrazione, pianifica in anticipo! Per una discussione più approfondita sulla pianificazione di una migrazione, ti incoraggio a consultare la sezione sulla migrazione delle best practice di 10up.

Usa Rsync per copiare progressivamente i caricamenti

La cartella dei caricamenti di siti di grandi dimensioni può essere estremamente grande e comprimerla in un file ZIP per un'estrazione successiva non è sempre la soluzione migliore e più veloce. Esistono molti altri modi per copiare la cartella dei caricamenti sul server di destinazione. Uno strumento comunemente utilizzato per la migrazione di tipo aziendale è rsync , che può trasferire file tra server più velocemente rispetto all'utilizzo di una soluzione SFTP standard e, inoltre, può sospendere e ripristinare i trasferimenti. Tiene traccia di ciò che è già stato trasferito, il che significa che possiamo sincronizzare progressivamente i nostri file. Ad esempio, puoi iniziare a sincronizzare i file un paio di giorni prima della migrazione effettiva per guadagnare tempo. Quindi, il giorno della migrazione, tutto ciò che devi fare è sincronizzare i file per assicurarti che tutto ciò che è stato aggiunto dall'ultima sincronizzazione venga trasferito sul server di destinazione.

L'unico avvertimento di questo approccio è che dovrai spostare manualmente le sottodirectory dei caricamenti nel posto giusto poiché il multisito ha una struttura leggermente diversa per la cartella dei caricamenti: ogni sito ottiene la propria sottocartella in cui il nome è l'ID del sito .

Come ultimo esempio, vediamo come migrare un singolo sito di grandi dimensioni in un'istanza multisito. Inizieremo esportando il singolo sito in un pacchetto ZIP ed eseguendo un test di prova sul server di destinazione. A quel punto, il sito non sarebbe accessibile a nessuno poiché il dominio punta ancora al vecchio server, il che significa che puoi puntare in sicurezza il file del tuo host al nuovo server per testare la migrazione. Puoi anche abilitare un plug-in come Restrict Site Access sul sito di destinazione per assicurarti che non sia pubblicamente accessibile in alcun modo.

Per il nostro test di prova, esporteremmo il sito alcuni giorni o settimane prima della data di migrazione pianificata per testare e avere un'idea di quanto tempo impiegherà il processo. Tieni presente che la cartella dei caricamenti non è inclusa.

Prima fai una corsa a secco

Prima fai sempre una corsa a secco. Idealmente, una prova di funzionamento dovrebbe verificarsi sul server effettivo o in un ambiente di gestione temporanea con uno stack di server simile.

Considera l'utilizzo --mysql-single-transaction

Il comando import supporta anche un --mysql-single-transaction che avvolgerà l'esportazione SQL in un'unica transazione per eseguire il commit di tutte le modifiche dall'importazione contemporaneamente, impedendo alla scrittura di sovraccaricare il server del database, specialmente negli ambienti MySQL in cluster.

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

Con rsync , possiamo trasferire facilmente il file esportato generato:

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

Quindi eseguiamo il comando import sul server di destinazione:

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

Ora dobbiamo sapere qual è il blog_id del sottosito appena creato; possiamo ottenere queste informazioni eseguendo:

Dall'output del comando precedente sappiamo che il nostro sito è stato importato con l'ID 2. Ne avremo bisogno per spostare correttamente la cartella dei caricamenti usando rsync . Dal server del sito singolo, eseguiremmo quanto segue:

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

Il comando precedente copierà l'intera cartella dei caricamenti nel posto giusto su un'installazione multisito, che si trova sotto la cartella dei siti e all'interno di una cartella in cui il suo nome è solo l'ID del sito (in questo caso, 2). A questo punto, possiamo ora modificare il file dell'host in modo che punti il ​​dominio del sito singolo al server multisito; quindi possiamo eseguire alcuni test per garantire che la migrazione abbia funzionato come previsto.

Per la migrazione finale, tutto sarebbe lo stesso, con l'eccezione che --blog_id=2 al comando import:

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

E come vantaggio, la sincronizzazione dei caricamenti avverrà molto più velocemente poiché rsync trasferirà solo i file che sono stati modificati o aggiunti dall'ultima sincronizzazione.

Conclusione

La migrazione da o verso il multisito è difficile e lo strumento introdotto in questo articolo semplifica l'intero processo di migrazione riducendo lo sforzo a un paio di comandi CLI. MU-Migration è stato utilizzato attivamente nella produzione per più di un anno ed è un progetto completamente open source. Il plugin è sviluppato su Github e le richieste pull sono benvenute!