Quando un sito passa in produzione su un altro hosting, chi prepara l’ambiente deve sapere cosa serve: quanto spazio, quale PHP con quali impostazioni, come è configurato WordPress, quali servizi di terzi collegare. La dashboard lo scrive in una relazione da scaricare in PDF o in Markdown.
La produzione è sempre su un altro hosting, sul dominio scelto dal cliente: web1 resta l’ambiente di lavoro e ogni sito, lì, chiede la password di anteprima. Su un server di produzione gestito da questa dashboard il sito si pubblica dalla stessa pagina, con Pubblica il sito…: vedi Produzione e cassaforte.
Dove si trova
Nella scheda del sito, sezione Manutenzione, voce Messa in produzione → Apri la relazione. La vedono gli amministratori e, con la categoria Manutenzione, gli amministratori con riserva. La pagina si apre subito: la relazione arriva dopo qualche secondo, il tempo di leggere il sito, i plugin e i controlli; i download partono subito perché riusano quello che la pagina ha appena letto.
Esportare il sito per il nuovo hosting
In cima alla pagina, Esporta per il nuovo hosting prepara i due file da portare sul nuovo hosting. Basta scrivere il dominio di produzione (per esempio esempio.it, con o senza www) e premere Prepara l’esportazione: parte un lavoro di qualche secondo o qualche minuto, secondo la grandezza del sito: nella pagina del lavoro una riga ogni dieci secondi dice a che punto sono il database e lo zip. Il sito di sviluppo non cambia: il database si lavora su una copia, che poi si cancella.
| File | Cosa contiene |
|---|---|
| dominio-sito.zip | Tutta la cartella del sito, da estrarre nella cartella principale del nuovo hosting: wp-admin, wp-includes, wp-content e i file in radice. wp-config.php è già pronto per la produzione: mancano solo nome, utente, password e host del database del nuovo hosting; chiavi e salt sono nuovi, il debug è spento, le impostazioni del server di sviluppo sono tolte. C’è anche il .htaccess di WordPress. Restano fuori cache, log, copie di backup e copie di wp-config. |
| dominio-database.sql.gz | Il database con l’indirizzo di sviluppo sostituito da quello di produzione ovunque, anche nei dati serializzati, da importare con phpMyAdmin o con mysql. I motori di ricerca sono riattivati, sessioni e dati temporanei tolti; funziona con MySQL 5.7 e successivi e con MariaDB 10 e successivi. |
I file restano sul server 24 ore, al massimo tre esportazioni per sito: si scaricano con Sito e Database, o dalla pagina del lavoro. Gli avvisi accanto al dominio dicono cosa controllare a mano: per esempio un file del tema con l’indirizzo di sviluppo scritto dentro, o un valore del database dove l’indirizzo non si è potuto sostituire. Esportano gli amministratori e, con la categoria Manutenzione, gli amministratori con riserva: ogni scaricamento è nel registro.
Il resto lo dice la relazione: PHP, servizi di terzi, licenze, DNS e certificato.
Cosa contiene la relazione
| Sezione | Cosa dice |
|---|---|
| In breve | Spazio, PHP, WordPress, plugin, servizi da collegare, quante cose da fare. |
| 1. Ambiente richiesto | Spazio di file e database, versione di PHP con le impostazioni una per riga e le estensioni, database, indirizzo su web1, cron. |
| 2. wp-config.php | Le costanti con i loro valori; password, chiavi e token compaiono solo come «impostata». I percorsi di web1 sono segnalati da adattare. |
| 3. Servizi di terzi | Email (SMTP), pagamenti, licenze, CDN e cache, statistiche, antispam e altri, con cosa serve per collegarli. |
| 4. Plugin e tema | Ogni plugin con versione e stato; quelli a pagamento hanno la licenza da riattivare. |
| 5. Da fare sul nuovo hosting | Le caselle da spuntare: PHP, database, file, wp-config, l’indirizzo di web1 da sostituire nel database con il dominio del cliente (lo fa già l’esportazione), servizi, licenze, DNS e certificato. |
I servizi si riconoscono dai plugin attivi e da alcune impostazioni. Quelli scritti nel codice del tema o in codice su misura vanno verificati a mano. Se non c’è un plugin per l’invio delle email, la relazione lo dice: su un hosting senza server di posta moduli e ordini non manderebbero email.
I controlli interni
In cima alla pagina, solo per noi, ci sono i controlli interni: vulnerabilità, aggiornamenti disponibili, plugin disattivati, allarmi, WP_DEBUG attivo, chiavi e salt mai rigenerate. Non entrano mai nei file: la relazione esce pulita. Conviene risolverli prima di consegnarla.
Chiavi e salt
Rigenera chiavi e salt cambia solo le 8 chiavi di wp-config.php. Chi è collegato a WordPress deve rientrare; password e database restano come sono. La relazione riporta la data dell’ultima rigenerazione. «Cambia i segreti» nei Rimedi invece cambia anche la password del database e quella di anteprima.
Da shell
sudo site-scan.py provisioning studio-bianchi.it # i dati della relazione, in JSON
sudo site.sh rotate-salts studio-bianchi.it # solo chiavi e salt
sudo site.sh export studio-bianchi.it esempio.it # file e database per un altro hosting
sudo site-export.py elenco studio-bianchi.it # le esportazioni ancora disponibili