Come aggiornare Wordpress e plugin quando si distribuisce utilizzando Capistrano?

Question

Spero che qualcuno possa confermare se il seguente scenario è un problema con la distribuzione di aggiornamenti sui siti WordPress e, in caso affermativo, avete una soluzione su come gestirla al meglio?

Le basi:

• Ho un progetto WordPress multisito per il quale io uso GIT e Capistrano per la distribuzione su messa in scena a distanza e la produzione server di sviluppo locale.
• Tutto ECCETTO le directory uploads e blogs.dir (nel contenuto di wp- ) sono in controllo di versione. Sì, il core WordPress, i temi , i plug-in, ecc. Vengono aggiornati localmente, impegnati, inviati e distribuiti. Questo significa che devo fare il login e attivare i plugin inizialmente - sono semplicemente installati tramite il Capistrano distribuire
• Le banche dati in materia di sviluppo, messa in scena e la produzione sono diverse e io non sono preoccupato per cercare di sincronizzare questi su

la mia preoccupazione:

Molti aggiornamenti di plugin e le WordPress nucleo eseguire anche gli aggiornamenti al database quando si fa un aggiornamento automatico tramite l'amministratore. Sto aggiornando core di WordPress e plugin localmente sulla mia installazione di sviluppo. Il codice per questi aggiornamenti finisce per essere impegnato, spinto e distribuito. Tuttavia, quando il codice viene distribuito, è semplicemente aggiungendo/eliminando/sostituendo i file modificati ai server di staging e di produzione. La produzione e la messa in scena sono prive di aggiornamenti del database poiché di solito fanno parte del processo di aggiornamento automatico, ad esempio disattivazione, aggiornamento, attivazione (eseguire eventuali aggiornamenti al database).

Le mie domande:

1. È la mia preoccupazione per i server di produzione e messa in scena con l'ultimo codice ma mancanti eventuali aggiornamenti del database necessari per l'ultima codice di preciso?
2. In tal caso, qualcuno ha dei pensieri su come posso modificare Capistrano per distribuire il codice per disattivare/riattivare i plug-in? Che ne è delle modifiche in WordPress, ad esempio da 3.2 a 3.3?
3. Se Capistrano non è lo strumento per questo - e ho bisogno di farlo più "manualmente" accedendo al admin - c'è una modalità di manutenzione strumento/plugin che un po 'di automatizzare la disattivazione/attivazione del plugin così tutti gli aggiornamenti all'attivazione vengono attivati?

Molte grazie,

Matt

Answer 1

E 'importante notare che non è necessario per attivare e disattivare i plugin quando l'aggiornamento del nucleo di WordPress da versione a versione. Here is an explanation from Ryan Boren on why. Tuttavia, a seconda del plug-in, alcuni di essi potrebbero avere un processo di aggiornamento integrato nello dell'aggiornamento, ovvero l'aggiornamento del plug-in, non di WordPress. Tuttavia, esaminerò le tue tre domande e risponderò nel modo più diretto possibile.

1.La mia preoccupazione riguarda i server di produzione e di staging con l'ultimo codice, ma mancano gli aggiornamenti del database richiesti per l'ultimo codice accurato?

Sì, durante l'aggiornamento, se è presente una modifica allo schema del database, WordPress non funzionerà correttamente a meno che il nuovo schema non esista. Quando si tenta di accedere al lato amministrativo di WordPress, se la versione db è inferiore a quanto previsto dalla propria versione di WordPress, verrà reindirizzato a una pagina di aggiornamento del database.

WordPress imposta un globale chiamato $wp_db_version nel file /wp-includes/version.php e mantiene ciascuno degli script di migrazione per aggiornare il database in modo incrementale da ciascuna delle versioni precedenti a quella successiva fino a quando il numero di versione è aggiornata, seen here. Ecco una lista più semplice in una FAQ che mostra come i numeri di revisione sono correlati a WordPress versions..

2. In tal caso, qualcuno ha dei pensieri su come posso modificare Capistrano per distribuire il codice per disattivare/riattivare i plug-in?

Come detto sopra, in genere non è necessario attivare/disattivare i plug-in dopo gli aggiornamenti core, a meno che non supponga che il plug-in richieda specificamente di farlo. Se lo schema cambia in WordPress, interrompi un plug-in, quindi gli sviluppatori di plug-in dovranno rilasciare una nuova versione. Quando si aggiorna il a quel plug-in, esso verrà spento e riavviato, e la sua responsabilità per gli sviluppatori è assicurarsi che tutto ciò che deve avvenire avvenga.

Tuttavia potrebbe essere necessario disattivare/attivare separatamente in ambienti distribuiti come il vostro, poiché il processo di aggiornamento effettivo si svolge su una macchina diversa, e quindi probabilmente un database diverso da quello su cui verrà infine utilizzato.

Forse la cosa migliore da fare sarebbe avere uno script di implementazione che colpisca un URI di un plugin all'interno di WordPress, un plugin che si scriverà che disattiverà/attiverà i plugin o uno esistente che già lo fa.

È possibile che alcuni plugin in uscita possano gestire parti di ciò che si sta cercando, ma prendo il componente chiave della domanda come automazione, evitando di dover accedere a ciascun ambiente e aggiornare i plug-in per ciascuno, in modo da sviluppare uno che fa esattamente ciò di cui hai bisogno potrebbe essere la strada da percorrere. Lo sviluppo di un plugin è possibile se si utilizzano gli strumenti già forniti da WordPress.

• activate_plugin()
• activate_plugins()
• deactivate_plugins()
• validate_plugin()
• Plugin_Upgrader class (forse)

Guardare attraverso l'intero file /wp-admin/includes/plugin.php per vedere che cosa si potrebbe trovare utile. Inoltre il codice di checkout che gestisce effettivamente i plug-in nel lato amministrativo in /wp-admin/plugins.php - solo per vedere come è fatto. Si consiglia di interrompere i ganci deactivate_plugin eliminando la configurazione del plug-in con plug-in che si ripuliscono da soli, quindi considerate di passare $silent come true quando si deseleziona il plug-in.

per rendere questo davvero chiazza di petrolio, probabilmente si vorrà per afferrare get_option('active_plugins') per vedere quali plugin sono stati già attivati, ed eseguire solo il tuo script su quelle (assicurarsi che il plugin stesso esclude dal processo)

3. Quali sono le modifiche a WordPress, ad esempio da 3.2 a 3.3?

Le modifiche da 3.2 a 3.3 devono essere considerate non diverse da qualsiasi altra serie di modifiche, quindi tutto ciò che viene detto qui si applica.

4. Se Capistrano non è lo strumento per questo - e ho bisogno di farlo più "manualmente" accedendo all'admin - c'è uno strumento/plugin in modalità manutenzione che automatizzerà un po 'la disattivazione/attivazione di i plugin quindi vengono attivati ​​tutti gli aggiornamenti all'attivazione?

Non credo che Capistrano farà nessuno dei lavori pesanti qui - ma non è certo neanche nel modo. Dovresti solo essere in grado di colpire un URI all'interno del plugin, e questo dovrebbe far girare le cose all'interno dell'applicazione. La cosa importante è che ovviamente tutte queste funzioni devono essere disponibili, quindi non puoi eseguirla come in uno script indipendente.