Flusso di lavoro di WordPress e Git

So che questa domanda è stata posta mille volte, ma sto davvero cercando di capire come ottenere il meglio da Git quando si lavora con WordPress.

Ho setacciato il web e letto dozzine di articoli, tutto ciò che sembra coprire brevemente l'argomento. Ecco alcuni dei più importanti che ho letto di recente.

- Versione che controlla WordPress

- Gestione delle distribuzioni di temi WordPress con Git

- Gestisci il tuo tema WordPress personalizzato usando git anziché FTP

Attualmente, il mio flusso di lavoro è simile al seguente.

• Installa WordPress localmente
• Sviluppa tema
• Esporta database WordPress dal server locale
• Importa database WordPress su server remoto
• Carica file e temi WordPress tramite FTP
• Il cliente apporta modifiche
• Scarica file e temi WordPress tramite FTP ed esporta database WordPress dal server remoto
• Sostituisci i file localmente
• Apporta modifiche allo sviluppo
• Ricaricare via FTP, esportare e importare database su server remoto

Mi rendo conto che Git può semplificare questo processo. Sembra che il modo migliore per farlo sia avere un file .gitignore che ignori alcune directory che non hanno bisogno di essere rintracciate, oltre ad avere un file wp-config.php sia locale che remoto.

Ma come gestite i database? I clienti di solito effettuano modifiche (post / pagine / plugin). Devo ancora esportare dal database remoto e importare nuovamente sul mio server locale?

Qualcuno può suggerire il miglior flusso di lavoro per me qui? E accompagnami attraverso i passaggi.

Inoltre, probabilmente mi piacerebbe usare Bitbucket perché i repository privati ​​sono gratuiti, a differenza di GitHub.

Qualsiasi aiuto sarebbe apprezzato.

Grazie in anticipo!

Sono uno degli sviluppatori di WP Migrate DB Pro e vorrei rispondere alla domanda di @ Ennui:

"Sai se lo script di sostituzione dell'URL db tiene conto delle stringhe serializzate?"

Sì, gestisce i dati serializzati. In effetti, questa è la ragione principale per cui ho sviluppato la versione gratuita del plugin nel 2009. :)

Purtroppo ho solo una reputazione di 41, quindi non ho potuto rispondere al commento di @ Ennui. Scusa per quello.

Sono al limite del voto per chiudere questo come "non costruttivo" in quanto sembra essere il tipo di cosa che solleciterà il dibattito e l'opinione piuttosto che le risposte. Ma...

Questo non è l'aspetto del mio flusso di lavoro e rende il mio approccio (e la mia risposta) diverso dalla maggior parte delle altre risposte finora.

1. Installa WordPress localmente
   1. Questo viene clonato da un repository Git nudo locale contenente l'ultima versione stabile.
   2. Conservo anche una copia locale dell'ultima versione di alcuni plugin che installo quasi sempre.
2. Crea il tema e tutti i plug-in necessari
3. Carica su un server di gestione temporanea pubblico
   1. Il client ha accesso ma non può cambiare il codice e ha detto che le modifiche al database non verranno trasferite al sito di produzione.
   2. Ciò significa che non esiste alcun motivo per scaricare nuovamente il codice sul server di sviluppo.
   3. E nessun motivo per risincronizzare il database locale
4. Apporta modifiche al sito locale in base al nostro personale e al feedback del cliente.
5. Carica le modifiche
6. Ripetere se necessario (ma con resistenza crescente :))
7. Se forniamo contenuto, il che non è sempre il caso, noi (non il client) puliremo il database sul server di gestione temporanea e cariceremo il contenuto.
8. Distribuire caricando il codice locale sul sito di produzione.
9. Se abbiamo creato contenuto, il contenuto viene esportato dal sito di gestione temporanea tramite lo strumento di esportazione vaniglia e importato nel sito di produzione.
   1. Questa è l'unica volta in cui devo spostare il database ed è fatto con strumenti piuttosto standard. Userò Velvet Blues Aggiornamento URL per ripulire il database, se necessario.
10. mettere a punto
11. Fine

Fondamentalmente, tengo il cliente lontano dalle mie cose il più possibile finché non consegniamo il sito.

Il codice si sposta in un modo, dal locale alla stadiazione o alla produzione. Non si muove mai diversamente. Ciò elimina alcuni dei tuoi passi e mi dà un po 'di tranquillità. Non voglio essere incolpato per il tintinnio del client nel mio codice e non voglio importare alcuni file compromessi, che è una possibilità diversa da zero.

E il database si sposta solo una volta, se non del tutto, il che riduce notevolmente il problema. Quindi immagino di gestire il problema dello "spostamento del database" riducendo o eliminando la necessità di spostare il database. Riduce inoltre i problemi di corruzione del database che possono sorgere e riduce le possibilità di importare un hack.

È vero, devo configurare il sito di produzione - permalink, menu, ecc. - ma questo mi costringe a lavorare sul sito di produzione, quindi lo considero una specie di debug. Mi aiuta a confermare che le cose funzionano sul sito di produzione come dovrebbero.

https://github.com/nathanielks/Wordpress-Capistrano-Deploy

Non l'ho provato da solo (ancora), ma afferma di distribuire tutto, DB incluso.

C'è anche un tutorial da seguire: Tutorial parte 1 | parte 2

Dai un'occhiata allo stack di roccia fresca . Utilizza il compositore per gestire la versione di Wordpress e plugin di terze parti e include anche capistrano per le distribuzioni e vagabondo / rispondente per la configurazione di server, inclusi i server virtuali locali per lo sviluppo.

Di recente ho fatto molti test su questo e qui è il flusso di lavoro che uso, che fa praticamente quello che stai chiedendo:

• Uso wp-cli per gestire il core di wordpress e aggiornare wordpress.
• Uso il compositore insieme a http://wpackagist.org per gestire le dipendenze di plugin e temi.
• Uso git e inserisco i file core di wp in .gitignore. Quindi per lo più wp-config.php e file di temi figlio sono in git.

Non ho familiarità con gli strumenti di migrazione db ma sarebbe un'ottima aggiunta a questo flusso di lavoro.

Ecco i dettagli completi sul flusso di lavoro http://geekpad.ca/blog/post/maintainble-portable-wordpress-using-composer-wp-cli

Per quanto riguarda la "clonazione" del database, utilizzo WP Migrate DB Pro: http://deliciousbrains.com/wp-migrate-db-pro/

È un servizio a pagamento, ma non costa molto e ti consente di estrarre o inviare facilmente il tuo database dal tuo sviluppatore al tuo server live e viceversa. Cambia gli URL e tutto il resto che deve cambiare sulla strada.