Andrea Beggi

La miglior difesa contro la logica è l'ignoranza.

WordPress: cambiare hosting

A T T E N Z I O N E ! Questo post ha piu' di sei mesi. Le informazioni contenute potrebbero non essere aggiornate.

Quello che segue è un esperimento: si tratta di appunti presi in tempi diversi per preparare la mia presentazione al WordCamp di Milano. Ho deciso di lasciare il post in forma di appunti “grezzi”, un po’ perché sono pigro, un po’ perché si tratta di note prese a braccio in previsione di fare una presentazione e non sono nate in forma di post. Dato che le informazioni sono utili e completano la mia chiacchierata al WordCamp, le ho pubblicate comunque. Non ci sarebbe stato il tempo materiale di trattare tutto “live”, quindi parecchio di quello che c’è qui è stato omesso dalla presentazione, che andrà su Slideshare tra poco.

Cosa vogliamo fare:

Trasferire una installazione standalone attiva e funzionante di WordPress da un hosting (per brevità chiamo hosting anche un VPS o un dedicate server) ad un altro.

Desiderata:

  • Non perdere l’indicizzazione;
  • mantenere la struttura dei permalink;
  • rendere lo spostamento il più possibile “trasparente” al netto del tempo di propagazione dei DNS;
  • non disorientare gli utenti, gli autori e i lettori (trasparenza);
  • non perdere post e commenti durante il processo (consistenza).

Cosa implica quello che vogliamo fare:

  • Gestire nuovo hosting/server;
  • gestire DNS;
  • salvare file, db e impostazioni da una parte;
  • ripristinare file, db e impostazioni dall’altra;
  • controllare e testare che tutto funzioni;
  • lavorare in fretta durante la fase di propagazione dei DNS.

Cosa ci serve:

E’ importante controllare che che le caratteristiche dell’hosting siano compatibili con WordPress e che ci sia un congruo spazio per il database. Nel dubbio, scegliamo un server linux, Apache, MySQL, PHP. Per entrambi gli hosting avremo bisogno di:

  • Accesso al pannello di controllo;
  • credenziali FTP (o SSH ove supportato);
  • credenziali accesso al database (e PHPMyAdmin);
  • accesso alla gestione del DNS del dominio;
  • eventuale Auth Code per il trasferimento del dominio.

Domains in the .com, ,net, .org, .biz and .info TLDs (aka .CNOBI) use a registry protocol called “EPP” to communicate between the registrars and registry. Under this protocol, a domain “auth code” is a small random code assigned to each domain name and is required in order for a domain name to be transferred from one registrar to another. All registrars are supposed to furnish registrants with the auth code for their domains, either by supplying it when requested, or better yet, providing a mechanism in their user interface to either view it or have it sent to the domain’s administrative contact.

Which means in order to successfully transfer a domain name from one registrar to another, you need at least 3 things in place:

  • the administrative contact email address for the domain should be working and an address you can receive mail at;
  • the “registrar lock” or “transfer lock” needs to be turned off at the time the transfer is initiated. Otherwise, when your new registrar tries to start the transfer, it will fail immediately. Again, your current registrar should either unlock this for you on request or provide a mechanism in the UI to do it. NOTE: it is in your best interests to leave this domain transfer lock on most of the time. You should only turn it off when you have to in order to facilitate a transfer;
  • the EPP code or auth code. You will need this to “confirm” that the transfer request is a legitimate one and not a domain hijacking attempt.

When a domain is registered with a domain name registrar, the zone administrator provides a list of name servers (typically at least two, for redundancy) that are authoritative for the zone that contains the domain. The registrar provides the names of these servers to the domain registry for the top level domain containing the zone. The domain registry in turn configures the authoritative name servers for that top level domain with delegations for each server for the zone. A NS record or (name server record) tells recursive nameservers which name servers are authoritative for a zone. Recursive nameservers look at the NS records to work out who to ask next when resolving a name.

Quando dobbiamo agire:

Il processo può essere distinto grossolanamente in tre fasi:

  • Prima del cambio registrar;
  • durante il tempo di propagazione dei DNS;
  • dopo l’avvenuta propagazione.

Prima:

Aggiornare WordPress iniziale. La prima cosa da fare è aggiornare il blog di partenza all’ultima versione: è sempre meglio farlo per questioni di supporto, compatibilità, sicurezza e praticità. Se c’è qualche motivo per il quale l’aggiornamento non è possibile, è necessario procurarsi la stessa versione che stiamo usando. Qui http://wordpress.org/download/release-archive/ si trovano tutte, anche le beta e le RC.

Backup. Prima del cambio registrar ci si limita a fare successivi e ripetuti backup dei file e del database. Per quanto riguarda i file è abbastanza banale: via FTP o se si ha accesso shell, via SSH / rsync. S3 via S3tools ecc. ecc.

Backup database. I backup possono anche essere schedulati: o tramite pannello, se l’hosting lo prevede, o tramite riga di comando, o tramite script PHP (PHPMyBackupPro). L’importante è essere assolutamente sicuri che i backup vengano fatti e che siano “consistenti”, cioè utili per un restore.

Quali sono gli strumenti per salvare il database?

  • PHPMyAdmin;
  • XML / WXR;
  • Command line;
  • Script tipo PHPMyBackupPRO.

http://www.noupe.com/how-tos/10-ways-to-automatically-manually-backup-mysql-database.html

In realtà la gestione dell’esportazione/importazione via XML fa discretamente schifo. File di dimensioni ingestibili per una interfaccia web (limiti di upload e timeout degli script), inoltre la cosa peggiore è che non salva le impostazioni del blog, che per installazioni complesse è un inconveniente non da poco. Salva solo 9 cose (posts, pages, comments, custom post types, cstom taxonomies, custom fields, categories, tags, and users) e non salva la configurazione e l’aspetto del blog. Impostazioni del tema, widget, menu personalizzati, tutte le impostazioni dei plugin, tutto quello che non è nel feed RSS non viene salvato.

Fate anche, e perché ve lo spiego dopo, uno screenshot di tutti i plugin installati e della loro configurazione, più gli screenshot di tutti i widget, tutti i menu, e tutte le personalizzazioni fatte tramite l’interfaccia di amministrazione di WP. E’ una noia, lo so, ma è una precauzione.

Alla fine gli strumenti che vi consiglio sono PHPMyAdmin oppure da riga di comando con mysqldump, se abbiamo accesso SSH. Le impostazioni da usare sono importanti: vanno disabilitati inserimenti estesi e inserimenti completi. Ad ogni buon conto, procediamo anche a una esportazione XML, tanto per essere più sicuri. E’ meglio essere paranoici con i backup. Non ci vuole molto a salvare il db ed è meglio avere diverse opzioni nel caso qualcosa vada storto.

Scenari dominio:

Per quanto riguarda il nome a dominio, i possibile scenari sono diversi. Nel caso più comune il registrar del domino, (A domain name registrar is an organization or commercial entity, accredited by a generic top-level domain registry (gTLD) and/or by a country code top-level domain (ccTLD) registry, to manage the reservation of Internet domain names in accordance with the guidelines of the designated domain name registries and offer such services to the public.) è anche l’hoster, cioè il fornitore dello spazio, ma nulla osta che il dominio sia registrato presso un’altra entità. Il trasferimento del blog può o meno prevedere anche il trasferimento del dominio.

Tecniche per accedere al nuovo non ancora visibile:

Riuscire o meno ad accedere allo spazio prima che la modifica dei DNS si sia propagata è una variabile che dipende dalla configurazione dell’hoster di destinazione. Si va da un “no” secco a un “non c’è il minimo problema”, con tutte le sfumature intermedie. L’ideale sarebbe acquistare il nuovo spazio, fare tutto il lavoro possibile con calma, e successivamente avviare le pratiche di trasferimento del dominio o il cambio dei name server presso il registrar.

Ci sono alcune tecniche che permettono di accedere prima ad un dominio non ancora interamente propagato:

  • File hosts (bisogna conoscere l’IP);
  • Name server del nuovo registrar usato come resolver;
  • domini “mirror”.

Usare i campi “home” e “siteurl” (via admin, wp-config.php o cambiando la tabella wp-options del db a mano con PHPMyAdmin).

DNS:

Quando si trasloca il proprio dominio da un hosting ad un altro, c’è un lasso di tempo durante il quale il cambio di indirizzo IP si propaga attraverso tutti i server DNS in internet; normalmente dura circa 24/36 ore durante le quali il dominio è “ballerino” e il nome punta al vecchio o al nuovo server a seconda che il DNS utilizzato abbia già aggiornato il record relativo.

http://www.whatsmydns.net

http://www.andreabeggi.net/2010/08/03/di-domini-hosting-e-dns/

http://www.andreabeggi.net/2006/01/24/tcp-in-pillole-dns/

http://www.andreabeggi.net/2008/09/26/tumblr-su-dreamhost/

Durante:

Chiudere vecchio. Non appena avviata la burocrazia per il trasferimento del nome a dominio o appena effettuato il cambio dei DNS (caso di dominio registrato altrove), è buona norma “chiudere” l’accesso al blog in dismissione. Io uso un plugin apposito, WP-Maintenance-mode. Questo plugin chiude l’acceso e mostra un messaggio ai visitatori; nel contempo l’accesso al blog e al pannello di amministrazione è sempre possibile per l’amministratore. Vi consiglio di accordarvi con il proprietario del blog e fare del terrorismo spietato paventando guasti irreparabili nel caso qualcuno tocchi qualcosa.

Un altro aspetto di cui essere consci è il fatto che dopo il trasferimento del nome a dominio, non è affatto certo di riuscire ad accedere alla vecchia installazione, con tutto quello che ne consegue se ci fossimo dimenticati dei pezzi.

Appena messo il “coperchio” sul blog di partenza ci si occupa del nuovo: in un mondo ideale saremo già riusciti ad accedere al nuovo spazio, aver trasferito i file e almeno il dump del db.

Spostare i file:

Ma cosa devo trasferire? Non tutto, dovrebbe bastare la cartella wp-content e eventuali cartelle aggiuntive se sono state fatte personalizzazioni non standard. Il resto dei file è meglio riscaricarli (http://wordpress.org/download/release-archive/) vi ricordo che la versione deve essere identica. Anche il wp-config.php va ripopolato con i dati corretti, non usate quello che copiate dal vecchio blog. I file vanno copiati via FTP o trasferiti via SSH se si può. Per precauzione è meglio salvare tutti i file sul vecchio hosting.

Creare il database:

Poi c’è il db. In un momento X in cui avrete avuto accesso al pannello di controllo, avrete creato un db vuoto con la stessa “collation” di quello da importare. Due parole sul problema della codifica vs. le diverse versioni di WP.

Importare il database:

Il database va reimportato. Se non si ha accesso shell, potremmo i essere nei guai perché facilmente il dump supera le dimensioni ammesse di una query uploadabile su PHPMyAdmin. Se non avete voglia di spezzare il file a mano e, fidatevi, *non* ne avete voglia, esiste uno script apposito: bigdump.php

http://www.wanderings.net/notebook/Main/HowToImportLargeMySQLDataFiles

http://www.sohailriaz.com/how-to-import-large-mysql-dump-files-using-bigdump/

c’è anche DOSQL, ma è un pelo più complesso anche se meno rozzo; ma visto che va a maneggiare il db in modi che potrebbero essere pericolosi, meglio il primo.

Se avete accesso shell siete nella situazione ideale. Dopo aver messo il dump del db fatto precedentemente con PHPMyAdmin o da riga di comando nella cartella principale del nuovo hosting, si farà accesso alla shell e:

mysql -h server -u user -p database < blog.bak.sql

e il vostro db sarà popolato in pochi secondi e comunque in una frazione del tempo che impiegherebbe PHPMyAdmin. Controllate che ci siano lo stessoo numero di record e la stessa grandezza per ogni tabella, rispetto al db originale.

Se per qualche malaugurato caso non si sia riusciti a importare direttamente il db, va lanciato il processo di installazione di wp da zero (è tutto pronto e non si perde la wp-content), dopodiché si importa il file XML, (che va spezzato se troppo grande) e poi, forti degli screenshot fatti sulla vecchia installazione, si reimposta tutto a mano. XML non è adatto a uno spostamento.

Test in produzione. Una volta uppati i contenuti, popolato il db, configurato wp-config, se abbiamo accesso tramite un url alternativo dovremo modificare i campi home e siteurl nei modi visti prima. Se riuscissimo ad accedere via truschini DNS, non dobbiamo fare nulla e possiamo provare a lanciare la homepage sul nuovo hosting. Se tutto è andato come doveva, il blog apparirà esattamente come prima, con lo stesso tema, tutti i plugin e i widget al loro posto. In caso di problemi controllate i permessi dei file, che sono spesso causa di malfunzionamenti.

Controllo configurazione:

Procediamo poi a controllare la configurazione di ciascun plugin e a salvare la configurazione di tutti tramite il tasto “save”, anche se spesso non è necessario sempre che non ci siano mappati dentro i percorsi assoluti delle cartelle, che saranno quasi certamente diversi.

Dopo

Monitorare i DNS

Appena i DNS cominceranno a propagarsi, le persone cominceranno a vedere il nuovo blog e non più il vecchio. http://www.whatsmydns.net

Tuning. Reimpostare i backup.

 

Tags: , , , ,

12 Commenti

flod | #

Un paio di appunti:
* se non si copia .htaccess dalla root si perde la struttura dei permalink, per cui bisogna riconfermare la relativa opzione nella Dashboard;
* occhio a plugin come wp-supercache che salvano percorsi assoluti e non relativi nei file di configurazione;
* attenzione ad alcune impostazioni di WordPress (ad es. cartella Upload), mi è capitato di trovarci percorsi assoluti.

P.S. ogni volta che scrivi “schedulati” e “uppati” uno Zanichelli muore :P

NicK | #

[quote]
… Il resto dei file è meglio riscaricarli …
[/quote]

Ma quale sarebbe il problema a riusare gli stessi files?
Se funzionavano prima, e la copia è stata fatta bene, perchè andare a cambiarli?
Magari si è solo cambiata una virgola e non ce lo ricordiamo più …

Andrea | #

E’ vero, è una fisima mia. Se posso uso sempre file “freschi”.

Fabio | #

Ciao Adrea stoi trasferendo tutto su un server dedicato, sto giocando con mio file host e tutto sembra andato per il verso giusto….. l’unico problema e che la struttura dei permalink non funziona quando clicco su un post ricevo il seguente errore:

The requested URL /titolo-articolo/ was not found on this server

Ivandesign | #

sto per spostare un sito perfettamente indicizzato ma estremamente lento causa hosting truffaldino… fatemi gli auguri.

Roberto Iacono | #

E chiamali “ppunti grezzi”, complimenti Andrea! È probabilmente uno degli articoli più completi in materia… La prossima volta non perderò nessun tuo intervento al WordCamp :)

Lascia un Commento

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *

È possibile utilizzare questi tag ed attributi XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>