Español
Română
РусскийCome spostare facilmente un'installazione WordPress dall'ambiente di sviluppo a quello di produzione?
Faccio lo sviluppo su un server e uso un secondo server per la produzione. Al momento mi limito a esportare il database e poi faccio un trova e sostituisci per i cambiamenti degli URL; quindi copio i file e importo il nuovo SQL.
Ci sono modi migliori per fare questo?
@Insanity5902: Il deployment di un sito WordPress da un server a un altro è stato un incubo fin dal primo giorno in cui ho iniziato a lavorare con WordPress. (A dire il vero, era un incubo anche con Drupal per 2 anni prima di iniziare con WordPress, quindi il problema non è certo esclusivo di WordPress.)
Mi dava fastidio che ogni volta che dovevo spostare un sito, dovevo spendere così tanto sforzo spesso duplicato, e questo mi impediva di fare deploy in ambiente di test con la frequenza che avrei preferito. Quindi circa 4-6 mesi fa ho iniziato a lavorare su un plugin per risolvere il problema della migrazione tra webhost e ho menzionato le mie idee sul forum di WP Tavern.
Beh, tornando a oggi, ho praticamente fatto funzionare tutto e l'ho comodamente chiamato "WP Migrate Webhosts". Anche se il plugin è ancora molto in beta (probabilmente anche in alpha), vista la tua domanda, penso di essere pronto a far sì che la gente inizi a testarlo.
Lo scenario d'uso previsto è il seguente:
- prima lo sviluppatore carica tutti i file modificati di temi e plugin via FTP,
- poi carica l'intero database MySQL di sviluppo sul server di test e infine
- quindi esegue il plugin per migrare tutti i riferimenti dal dominio precedente a quello nuovo. (Il mio plugin non tenta di risolvere il merge di nuovi campi o tabelle del database con i dati live; QUESTO è un problema molto più grande che non sono sicuro di come risolvere.)
Puoi scaricare il plugin dal mio sito web e decomprimerlo nella directory dei plugin (se non sai come fare, questo plugin non fa per te perché richiede qualcuno che sappia cosa sta facendo per usarlo.) Terrò questo plugin online fino a quando non lo rilascerò su WordPress.org, dopodiché dovresti cercarlo lì.
Per usarlo, devi adottare un approccio diverso nel tuo wp-config.php rispetto al solito, commentando i quattro (4) define DB_NAME, DB_USER, DB_PASSWORD e DB_HOST e invece registrando i valori predefiniti per i webhost e poi registrando le informazioni su ogni webhost stesso. Ecco come potrebbe apparire quel segmento di wp-config.php (nota che la prima sezione è il codice non necessario commentato e nota anche che ho configurato il mio file hosts sulla mia macchina locale con domini di primo livello .dev non instradabili per rendere lo sviluppo quotidiano più semplice. Su Mac VirtualHostX rende tutto molto semplice):
// ** Impostazioni MySQL - Puoi ottenere queste informazioni dal tuo web host ** //
/** Il nome del database per WordPress */
//define('DB_NAME', 'wp30');
/** Nome utente del database MySQL */
//define('DB_USER', 'wp30_anon');
/** Password del database MySQL */
//define('DB_PASSWORD', '12345');
/** Hostname del database MySQL */
//define('DB_HOST', '127.0.0.1:3306');
require_once(ABSPATH . 'wp-content/plugins/wp-migrate-webhosts/wp-webhosts.php');
register_webhost_defaults(array(
'database' => 'example_db',
'user' => 'example_user',
'password' => '12345',
'host' => 'localhost',
'sitepath' => '', // '' se WordPress è installato nella root
));
register_webhost('dev',array(
'name' => 'Example Local Development',
'host' => '127.0.0.1:3306',
'domain' => 'example.dev',
'rootdir' => '/Users/mikeschinkel/Sites/example/trunk',
));
register_webhost('test',array(
'name' => 'Example Test Server',
'rootdir' => '/home/example/public_html/test',
'domain' => 'test.example.com',
));
register_webhost('stage',array(
'name' => 'Example Staging Server',
'rootdir' => '/home/example/public_html/stage',
'domain' => 'stage.example.com',
));
register_webhost('live',array(
'name' => 'Example Live Site',
'rootdir' => '/home/example/public_html/',
'password' => '%asd59kar12*fr',
'domain' => 'www.example.com',
));
require_once(ABSPATH . 'wp-content/plugins/wp-migrate-webhosts/set-webhost.php');
Spero che sia (per lo più) autoesplicativo. Ho cercato di rendere il codice il più pulito possibile, ma purtroppo richiede quelle due linee criptiche require_once() prima e dopo il blocco di codice di registrazione dei webhost, poiché non c'era modo per me di "agganciare" WordPress prima che wp-config.php fosse chiamato.
Una volta aggiornato il tuo wp-config.php, puoi semplicemente usare l'URL shortcut wp-migrate-webhosts per andare alla schermata di amministrazione in questo modo:
Il precedente ti porterà a una schermata di amministrazione come la seguente, che ha un bel po' di testo descrittivo e ti permette di migrare DA qualsiasi altro dominio webhost con un singolo clic dopo aver selezionato i domini da cui migrare (NOTA: questo esempio mostra la migrazione VERSO IL BASSO dai server di test/stage/live allo sviluppo locale, ma stai certo che può migrare VERSO qualsiasi dominio in cui si trova. Questo significa anche che il plugin sarà fantastico per prendere un sito live esistente e ottenere rapidamente un ambiente di sviluppo locale funzionante!):
Se non è chiaro, "migrazione" in questo contesto significa aggiornare tutti i riferimenti nel database corrente per essere appropriati per il webhost attualmente definito (e "corrente" viene rilevato ispezionando $_SERVER['SERVER_NAME']).
La cosa interessante di questo plugin è che implementa alcune migrazioni di base, ma chiunque può agganciarlo ed eseguire le proprie migrazioni. Ad esempio, se aggiungi un plugin per gallerie che memorizza percorsi completi alle immagini nel database, potresti agganciare l'azione migrate_webhosts a cui verranno passati il webhost "from" e il webhost "to" come array di metadati, e ti sarà permesso di eseguire qualsiasi operazione necessaria nel database usando SQL o qualsiasi funzione API di WordPress per fare la migrazione. Sì, qualsiasi di noi potrebbe farlo senza il plugin, ma senza il plugin ho scoperto che scrivere tutto il codice necessario era più fatica di quanto valesse. Con il plugin, è solo più semplice scrivere questi piccoli hook e finirla.
Potresti anche scoprire che le mie migrazioni falliscono in casi limite che non ho testato e magari puoi aiutarmi a migliorare il plugin? Chiunque può contattarmi via email tramite il mio account gmail (il mio alias è "mikeschinkel.")
Inoltre, il plugin è stato progettato per accettare metadati definiti dall'utente per i webhost, oltre a quelli che riconosce come database, user, password, host, domain, ecc. Un esempio perfetto potrebbe essere googlemaps_apikey, dove puoi memorizzare le diverse API key per ogni dominio che il tuo plugin Google Maps necessita per funzionare correttamente (chi tra voi che ha usato un plugin Google Maps non ha mai deployato un'app su un server live e dimenticato di cambiare il codice con la corretta API key? Suvvia, siate onesti... :) Con questo plugin, un elemento googlemaps_apikey nel tuo array register_webhost() e un piccolo hook personalizzato migrate_webhosts puoi eliminare efficacemente questo problema!
Beh, questo è tutto. Lancio questo plugin qui su WordPress Answer's Exchange perché la domanda di @Insanity5902 l'ha scatenato. Fatemi sapere se è utile, qui se appropriato o via email altrimenti.
P.S. Se decidi di usarlo, ricorda che è in alpha/beta e ciò significa che cambierà, quindi preparati a qualche piccola modifica se vuoi usarlo ora e poi usare la versione rilasciata una volta che sarà stata testata da molte mani.
P.P.S. Quali sono i miei obiettivi con questo? Mi piacerebbe vedere questo plugin integrato nel core di WordPress in modo che tutti possano accedervi. Ma prima che questo possa essere considerato, molte persone devono essere interessate a usarlo per assicurarsi che risolva più problemi di quanti ne possa potenzialmente creare. Quindi, se ti piace l'idea, allora usalo pure e aiutami a guadagnare slancio per una futura sperata inclusione nel core di WordPress.
Ottime soluzioni, ho comunque un paio di domande: 1) È ancora necessario definire WP_SITEURL per accedere all'area di amministrazione? 2) Lo strumento è visibile solo per gli utenti Administrator? (non sono sicuro se la sezione Strumenti sia visibile per i non amministratori)
Ryan Gibbons
Ciao @Insanity5902:
1) Non è necessario impostare WP_SITEURL, il plugin lo fa per te. In realtà lo stai impostando quando "registri" un "dominio" e un "percorso del sito" per un webhost. Nel normale funzionamento di WordPress, WP_SITEURL deve essere impostato nel codice o nel database per assicurarsi che nessuno possa falsificare l'URL e fare operazioni dannose a causa di un valore inaspettato in $_SERVER['SERVER_NAME']. Il plugin WP Migrate Websites imposta WP_SITEURL indirettamente in base a $_SERVER['SERVER_NAME'], ma lo farà SOLO se il dominio corrente corrisponde a uno dei domini definiti nel tuo file wp-config.php, nient'altro.
MikeSchinkel
2) Il collegamento rapido URL di cui ho parlato effettua un reindirizzamento alla console di amministrazione, quindi è solo per gli utenti loggati come amministratori. Non ho ancora implementato controlli specifici per i soli amministratori. Non ho mai aggiunto funzionalità di gestione dei ruoli a un plugin, ma dovrò approfondire come farlo nelle prossime settimane, quindi potrò lavorarci nel prossimo mese. Tuttavia, il plugin non è distruttivo; può SOLO migrare al dominio corrente e il processo è ripetibile, quindi anche se un non amministratore vi accedesse, non potrebbe fare alcun danno, almeno non che io possa immaginare.
MikeSchinkel
@Mike: Puoi aggiungerlo al repository dei plugin di WordPress? Penso che potrebbe raccogliere ulteriori feedback e supporto dagli sviluppatori.
hakre
@harke - Ho intenzione di farlo quando sarà maturo. Voglio che venga utilizzato da circa 5-10 persone per assicurarmi che sia robusto e verificare che i casi d'uso siano validi prima di sottoporlo al sistema di valutazione del forum dei plugin, perché penso che questo plugin abbia il potenziale per essere significativo se gestito correttamente. Voglio anche documentarlo completamente prima di pubblicarlo, e documentarlo mi obbligherà a validare molte delle ipotesi fatte durante lo sviluppo.
MikeSchinkel
Quando non sarebbe possibile impostare questi valori? Sembra leggermente più semplice rispetto a modificare le cose nel database.
jfklein
@jfklein Lavoro quasi sempre con una rete WordPress, che è incompatibile con queste costanti.
User
Sto facendo lo stesso. Sfortunatamente, non tutti i temi rispettano questa impostazione. Ad esempio, il tema 'Responsive Theme' da ThemeID. Cercare nel dump/tutte le tabelle per 'http://localhost' (o qualunque sia il nome locale scelto), specialmente in wp_options, e fare sostituzioni è spesso inevitabile.
Frank N
@FranKee Ho creato un plugin https://wordpress.org/plugins/pitta-migration/ che utilizza le costanti per aggiornare la tabella wp_options e dovrebbe coprire la maggior parte dei temi e plugin
icc97
@icc97: Fantastico. Gli darò un'occhiata. PS: Bella immagine di intestazione, rappresenta bene la situazione.
Frank N
Sì! Sono così felice di non essere l'unica persona ad averlo pensato! qualsiasi differenza tra dev e prod è negativa. Eliminare completamente quella differenza è molto meglio che cercare di aggirarla. E questa configurazione non richiede alcun lavoro. Si può persino fare testing su una macchina virtuale con file hosts modificato se necessario.
Alexander Bird
Mi piace molto questo metodo, ma come gestisci il push/pull del database?
Joel Peltonen
Per quanto riguarda il rischio di confondere dev con prod, io uso un plugin per Chrome che mostra l'indirizzo IP della pagina web. Saprai che sei in locale quando è 127.0.0.1
kosinix
È davvero un'opzione molto interessante e sarà ottima per molte persone! Naturalmente non funziona per gli URL incorporati né aiuta chi sviluppa localmente e vuole utilizzare un IDE con debugger. Se WPEngine riuscisse a creare un'interazione che integri anche un deploy locale, allora sarebbe davvero qualcosa di straordinario (Technosailor, stai ascoltando?)
MikeSchinkel
Concordo, sarebbe un'aggiunta fantastica.
Travis Northcutt
La funzionalità snapshot copia solo da produzione a staging, non il contrario. È ottima per testare le modifiche, ma non aiuta per il deploy in produzione.
sam
@sam in realtà, hanno recentemente iniziato a implementare la possibilità di copiare dall'ambiente di staging a quello di produzione. http://wpengine.com/2013/04/user-portal-v2-and-staging-to-production/
Travis Northcutt
Solo una nota, la mia chiamata sql potrebbe danneggiare i tuoi dati serializzati.
s:14:blogs.prod.com ha la lunghezza codificata come 14. Dopo aver eseguito il codice, ora abbiamo
s:14:dev.prod.com
che è corrotto. Dovrebbe essere
s:12:dev.prod.com
usa con cautela.
Andrew
Ho appena controllato il tuo script. Bello. Se ho capito bene, installa una nuova istanza di WP sul server. La domanda qui è come migrare dall'ambiente di sviluppo a quello di produzione. Può essere utile per questo?
Sruly
È questo? http://github.com/vluther/Autopress Suggerisco di creare link nelle tue risposte così le persone possono cliccare direttamente!
artlung
@Mike Lee: Sì, puoi votare positivamente i commenti. Vedi, ho votato positivamente il commento di artlung. Cerca la freccia verso l'alto che appare al passaggio del mouse a sinistra del commento.
MikeSchinkel
Sto lavorando a un modo per mantenere tutto sotto controllo delle versioni, e poi spingere da sviluppo a produzione. Sono già riuscito a farlo senza problemi per alcuni siti, ma ci sono ancora alcuni aggiustamenti che devo affrontare.
Vid Luther
Non sono sicuro che sia questo, ma c'è un plugin di WP Engine che viene utilizzato per la migrazione del sito tra host. Si chiama Snapshot (Link diretto).
joelhaus
Sembra che nessuno di questi progetti sia mai decollato?
icc97
Puoi utilizzare WordPress Skeleton wp-config.php che imposta una costante WP_LOCAL_DEV per ottenere qualcosa di simile
icc97
RAMP è pensato per la distribuzione di contenuti, a differenza della distribuzione di codice, ma concordo, sembra eccezionale. Ora hanno predisposto una demo di RAMP così puoi provare le funzionalità.
Emyr Thomas
La domanda riguardava la distribuzione di contenuti, non di codice, e ho iniziato la mia risposta dicendo "RAMP è un nuovo plugin per la distribuzione di contenuti..."
Ian Dunn
Quattro mesi fa, non riuscivo a far funzionare questo plugin... Ed è ancora alla versione 0.1 su code.google
brasofilo