Dobbiamo essere molto chiari su questo: i tempi in cui impiegavo un pomeriggio per fare un trasferimento di un sito web, sono fortunatamente finiti. Oggi ci sono plugin e piattaforme (wpmanage.com ad esempio) che lavorano al trasferimento del sito web mentre noi sorseggiamo un thè verde senza sforzo alcuno. E queste sono le tecniche da utilizzare oggi: è inutile impazzire a fare questa operazione manualmente, quando non c'è bisogno di farlo.

Ma questo articolo non parla di quando tutto funziona bene. Della rilassante sensazione che proviamo il 90% delle volte, quando guardiamo la progress bar che avanza verde sullo schermo. Questo articolo parla di quella volta nella quale la progress bar è ferma da un pò. Cominciamo ad avere timore che tutto si stia bloccando, ma ad un certo punto riparte e torniamo a sorridere. Poi si ferma ancora, appare il popup "Trasferimento non riuscito, riprova!".

Quando il trasferimento fallisce

Cosa fare a questo punto? Sicuramente riproviamo. E se fallisce ancora, cosa dobbiamo fare?

Ci sono tanti motivi per cui un trasferimento può fallire. Ma sicuramente avremo tutti fatto caso che fallisce più spesso quando il sito o il database è più pesante in termini di megabyte, o quando il numero dei prodotti in WooCommerce è alto.

Ma la maggior parte delle volte, anche in queste condizioni avverse, tutto funziona. Clicchiamo più volte il bottone "Riprova" e ad un certo punto... funziona!

Ma a volte continua fallire, e allora che fare?

La teoria: i passaggi generici per trasferire un sito web

In generale, dobbiamo copiare tutti i file del sito web dal vecchio al nuovo hosting, e poi dobbiamo scaricare il database, cambiare tutti i puntamenti del vecchio url al nuovo url, e adattare wp-config.php per utilizzare il database corretto.

Vediamo diversi modi per eseguire questa operazione.

Diverse tipologie di collegamenti

La prima cosa da fare è accedere all'hosting di partenza per prelevare i file da spostare sull'hosting di destinazione. Quindi dobbiamo effettuare connessione e trasferimento con uno dei metodi che seguono.

Trasferimento via FTP

Il plus di usare l'FTP è che è uno strumento semplice. Non c'è bisogno di certificati (dopo vediamo cosa sono) è necessario solo nome utente e password e un programma tipo FileZilla. Il minus è che quando i file sono tanti, non tutti vengono scaricati. In particolare, avrete notato che spesso viene perso il .htaccess (perchè è un file nascosto nei file system unix) o più probabilmente avrete notato che la configurazione dei permalink è rotta (è perchè si è perso il file .htacces...).

Un altro minus dell'utilizzo dell'FTP è che a volta impiega proprio tanto tempo. Possiamo ottimizzare questo tempo evitando di scaricare le cartelle wp-admin e wp-includes, e limitarci a scaricare solo wp-contents; recupereremo wp-admin e wp-includes dal file zip che scarichiamo dal sito di WordPress. Andremo quindi a caricare una cartella alla volta nell'hosting di destinazione facendo attenzione a controllare che tutti i file siano stati caricati.

Per aumentare l'ottimizzazione, possiamo cancellare i temi inutilizzati. Prima di scaricare il sito o prima di ricaricarlo, basta andare in wp-contents/themes e cancellare le cartelle di cui non abbiamo bisogno, lasciando solo quella del tema in uso. Questo renderà il trasferimento più veloce.

Però in wp-contents rimangono tutti i file "media" nella cartella wp-contents/uploads. Questi file vanno necessariamente trasferiti, e a volte sono proprio tanti. E questo ci porta alla tecnica del trasferimento via SSH.

Connessione via FTP

Muniamoci di un software di trasferimento file come FileZilla, clicchiamo sul bottone in alto a sinistra "Connessioni" e creiamone una. Avremo bisogno dell'host che di solito è l'indirizzo del sito web; anche se a volte vi dicono che è ftp.sitoweb.com in realtà molto spesso funziona anche digitando solo l'indirizzo del sito web, perchè quello di cui ha veramente bisogno, è l'indirizzo ip del server. Del nome utente e della password. La porta di default è la 21 e solitamente non cambia.

Una volta effettuata la connessione, potete navigare nei file con il comodo FileZilla, come se fosse una cartella nel proprio computer. Selezionate la cartella del sito web e trascinatela nella colonna di sinistra per scaricare tutto sul vostro computer.

Trasferimento via SSH

Il plus è che non perdi alcun file che serve; ma bisogna collegarsi usando il terminale e digitando dei comandi come si fa in ambito sistemistico. E' davvero facile commettere un errore nel terminale. Un errore che può fare un vero danno (come cancellare tutti i file della cartella). Ad esempio, se sveniamo sulla tastiera e scriviamo rm * finiamo per cancellare tutti i file della cartella corrente, senza possibilità di recupero (non c'è il Cestino).

Insomma, questa tecnica è la migliore, ma è necessario prestare molta attenzione e sapere come utilizzarla.

ATTENZIONE: i pericoli dell'SSH

• in ssh non vengono chieste conferme. Nell'esempio di prima (scrivere rm * e premere il tasto invio) tutti i file della cartella corrente verranno eliminati senza che il sistema dica "confermi di voler eliminare i file?"
• crontab -e permette di accedere ad importanti configurazioni riguardanti script che girano autonomamente, ma crontab -r (basta sostituire la e con la r che sono anche vicine sulla tastiera) elimina tutte le impostazioni senza nemmeno chiedere conferma
• uno spazio o un apice, un punto o un altro carattere di troppo, invaliderà o cambierà il significato di un'istruzione
• il carattere "accapo" che di solito non si vede nei nostri computer, se copiato per sbaglio e incollato, avvierà l'istruzione

Effettuare una connessione SSH e inviare delle istruzioni, è un'operazione delicata, e un errore in questo momento può avere conseguenze nefaste: perdita di file, informazioni, bloccare l'esecuzione del sito web e tanto altro.

E' sicuramente un potente strumento che va utilizzato con cautela. Per esprimere la quantità di cautela necessaria, posso dire che nei 15 anni di utilizzo di questo strumento, ho già fatto tutti gli errori che potevo fare. Errori che non rifarò, e questo mi da una certa sicurezza. Ma comunque, ancora oggi, quando entro in un server via ssh, accendo i 5 sensi come fossi un Navy Seal che entra in una stanza buia.

Connessione via SSH

Per la connessione, non possiamo dire molto perchè dipende dal servizio di hosting: a volte possiamo effettuare solo con nome utente e password, altre volte è necessario generare anche un certificato (un file contenente una chiave che garantisce a noi che stiamo entrando nel server giusto, e al server che noi siamo autorizzati). Consiglio di vedere l'help dell'hosting di partenza e quello di destinazione per capire come fare la connessione, anche perchè, se per l'FTP la porta è quasi sempre 21, in ssh questa porta varia sermpre: la porta di default è la 443 ma appunto, dipende. Ad esempio, per siteground è la 18765.

Come è evidente, 18765 è parecchio diverso da 443 e spesso troverete numeri a caso al posto della 443. Quindi l'istruzione per la connessione non è sempre la stessa, ma possiamo vedere una tipica istruzione:

ssh -i [nomefilecertificato] -p18765 -o ServerAliveInterval=15 [nomeutente]@[nomesitoweb.com]

Da qui in poi sarà necessaria un pò di conoscenza base della console per eseguire le istruzioni; consiglio comunque prima di capire cosa è necessario fare e valutare se procedere a farlo.

Cosa fare una volta che la connessione SSH è stabilita

Adesso dobbiamo vedere (1) cosa abbiamo e (2) dove siamo.

Quindi lanciamo il primo comando per vedere cosa abbiamo:

ls -l

E poi:

pwd

per vedere dove siamo.

Adesso dobbiamo creare un file tar cioè un unico file che contiene tutti i file del sito web senza alcuna compressione. Sarà un comando simile a questo. Le parole fra parentesi quadre vanno sostituite con i nomi giusti:

tar -cvf [miositoweb].tar [miositoweb]

dove [miositoweb] è il nome della cartella da recuperare.

Una volta finito, comprimiamo il file appena creato:

gzip [miositoweb].tar

In questo modo, avremo un unico file contenente tutti i file e le cartelle.

Un file che scarichiamo via FTP. Velocemente e senza perdere nulla. Certo, possiamo scaricare questo file anche attraverso una connessione SFTP con FileZilla, ma non complichiamo oltre le cose.

Il file poi andrà caricato via FTP nell'hosting di destinazione, e dovrà essere decompresso con un comando simile a questo:

tar -xvf [miositoweb].tar.gz

Riuscire correttamente a seguire questa procedura senza le basi necessarie, è come riuscire ad applicare un bypass. Anche se sono al telefono con un chirurgo, la vedo dura. Ma seguiamo il tutorial quantomeno per capire cosa ci aspetta.

Come trasferire il database WordPress

Come estrarre il database con phpMyAdmin

Il servizio di hosting di partenza sicuramente offre phpmyadmin, uno strumento per interagire col database. Da lì possiamo selezionare il database nella lista a sinistra, e poi cliccare sul bottone Esporta nel menu in alto. Continuando nella procedura, avremo un file .sql che possiamo utilizzare per ricreare il database nell'hosting di destinazione.

Come estrarre il database senza phpMyAdmin

Ci colleghiamo via SSH come fatto sopra, e esportiamo il file sql con questo comando (attenzione alle parole con le parentesi quadre, devono essere sostituite prima di lanciare il comando).

mysqldump -u [nome-utente-mysql] -p [nome-database] > [nome-file-export].sql

Una volta avviato questo comando, ci verrà chiesto di inserire la password dell'utente mysql. La inseriamo e il sistema crea il file [nome-file-export].sql che sarà molto simile a quello generato da phpmyadmin (diverso per alcuni aspetti tecnici che non approfondiremo in questa sede).

Adattare gli URL

Con o senza phpmyadmin, abbiamo ora un file contenente il database, che potremo utilizzare per trasferire il sito web, ma se il nostro sito era all'indirizzo www.miositowebtest.com e ora dobbiamo spostarlo in www.miositowebdiproduzione.com allora dovremo fare una piccola procedura aggiuntiva per adattare le URL contenute nel file del database. Se invece le URL rimangono le stesse, non abbiamo bisogno di fare questa procedura, e dovremo invece configurare i DNS.

Possiamo scaricare il file sul nostro computer e aprirlo con un normale editor per fare cerca/sostituisci da www.miositowebtest.com a www.miositowebdiproduzione.com, ma se il file fosse molto grande (a volte i file di esportazione sono più di 100 megabyte) allora l'editor sul nostro computer potrebbe non bastare.

Ma nessun timore: la risolviamo con la solita ssh.

Come fare find/replace del vecchio dominio col nuovo su file grandi

Basterà lanciare questo comando opportunamento adattato:

sed -i 's/old-text/new-text/g' input.txt

old-text è il vecchio dominio (miositowebditest.com) mentre new-text è quello nuovo (miositowebdiproduzione.com) ma attenzione perchè i punti sono caratteri importanti per il comando sed e quindi dobbiamo far capire a sed che non abbiamo cattive intenzioni: mettiamo una barra prima del punto, in questo modo:

sed -i 's/miositowebditest\.com/miositowebdiproduzione\.com/g' [nome-file-export].sql

Per tagliare corto, diciamo che il database a questo punto va ricaricato. Sperate di avere phpmyadmin per ricaricarlo. Ma se è un giorno in cui piove, tira vento e c'è lo sciopero dei mezzi pubblici, allora dovrete imparare a caricare il file con mysqldump (si, sempre via ssh).

Ultimi ritocchi: configurare wp-config.php

La buona notizia è che ora rimane l'operazione più semplice: nel file wp-config.php sono presenti le credenziali di connessione al database. Avendo trasferito dal vecchio hosting al nuovo, queste credenziali saranno sicuramente variante. E probabilmente sarà cambiato anche il nome del database.

Quindi dovremo cercarle in wp-config.php e sostituirle.

E i DNS del dominio?

Si, se il dominio rimane lo stesso e cambiamo il server, dovremo configurare i DNS. Se il dominio puntava ad un server a adesso ad un altro, bisognerà comunicare l'indirizzo ip del nuovo server. Anche in questo caso, l'interfaccia di modifica del DNS varia molto fra un fornitore (aruba, netsons, godaddy, etc) e un altro, quindi sarà necessario informarsi per capire come utilizzare l'interfaccia di configurazione DNS del fornitore.

E' tutto?

NO, non è tutto. E non potrebbe essere altrimenti.

Le operazioni via SSH con il fido mysqldump sono effettivamente complicate da fare senza un'adeguata base propedeutica. Inoltre, anche se i passi generali sono questi che ho spiegato, la procedura deve essere adattata alle caratteristiche del server di partenza e quello di desinazione: ad esempio, una volta effettuata la connessione ssh (vedi capitoli sopra) la procedura prevede subito la creazione di un file .tar ma non sempre, effettuata la connessione, ci troveremo subito sopra cartella da comprimere. Nella maggior parte dei casi, il server ssh che accetta la connessione ci porterà proprio lì, ma mi è capitato tante volte di trovarmi nella cartella /home dell'utente che avevo utilizzato per connettermi (cioè, nel posto sbagliato) e per trovare la giusta cartella bisognerà leggere in maniera approfondita la knowledge base offerta dal servizio di hosting. E questo è solo un esempio, ci sono 1000 altre cose che potrebbero non funzionare come spiegato in questo tutorial.

Va considerato che nell'hosting di destinazione bisognerà creare un database e un utente mysql con relativa password e permessi adatti a WordPress; anche questa operazione di solito si può fare con i pannelli messi a disposizione dai vari servizi di hosting, pannelli che cambiano in base al fornitore del servizio (netsons, siteground, aruba, etc) quindi anche in questo caso bisognerà leggere la knowledge base per capire dove cliccare.

Potremmo trattare la creazione di un database, un utente MySql e l'associazione di queste due entità attraverso la ben nota console ssh e mysql, ma sarebbe davvero oltre lo scopo di questo articolo.

Consiglio a chi vuole avventurarsi con queste operazioni, di capire bene cosa sta facendo anche cercando su Google per approfondire, perchè senza delle basi propedeutiche sarà impossibile seguire questa parte della guida con successo e senza fare danni.

Decidere dove posizionare gli elementi in pagina, interpretare la psicologia di acquisto del target, consigliare il cliente su tutte le complessità necessarie a realizzare un buon lavoro di comunicazione, è un lavoro che qualunque tech guy non dovrebbe mai fare. Perchè non è capace.

E allo stesso modo, queste operazioni in ssh sono per techie: il mio consiglio è di farle fare almeno la prima volta ad una persona che può vantare l'esperienza necessaria, così da imparare il più possibile a padroneggiare questo potente strumento che risolve problemi quando tutti gli altri strumenti non possono risolvere, e poi approfondire l'argomento prima di sperimentare nella realtà le istruzioni contenute in questo tutorial.