Wordpress con Git


21

Sto ponendo questa domanda perché ho cercato su Internet ma non riesco a trovare la soluzione giusta. In realtà voglio una soluzione in cui più sviluppatori possano lavorare su un singolo progetto wordpress senza creare alcun disordine l'uno nell'altro, ma come sappiamo che in wordpress ogni cosa viene mantenuta nel database come quale plugin è attivo e quali no.

Se gli sviluppatori installano plug-in nel loro progetto locale rispetto al modo in cui comunicano tra loro che ognuno dovrebbe installare quel particolare plug-in o plug-in ecc., E alcune comunicazioni errate possono interrompere il sito di altri se ogni sviluppatore invia / estrae il codice.

Dovremmo condividere anche il database, per condividere le impostazioni di plugin / temi in modo che non ci siano conflitti o piccoli conflitti tra gli sviluppatori.

Grazie


5
wp-cli.org ti aiuterà un po 'nel tuo flusso di lavoro.
jgraup,

1
Se possibile, passa a jekyll o simili.
Jens Schauder,

Jekyll è cotta in github, che ovviamente funziona bene con git ...
DaveRGP

FWIW, le collisioni e i conflitti non vengono completamente rimossi quando si utilizza qualcosa come Git, consente solo di tenere lontani i conflitti fino a quando non si è pronti a "unirli".

1
Tutti gli sviluppatori possono condividere un DB comune ospitato pubblicamente e impegnarsi in GIT per il controllo della versione?
MonkeyZeus,

Risposte:


18

Git per plugin :

Quindi, usa Git per gestire composer.jsone le modifiche nel plugin TGM.

La parte più difficile è sincronizzare il database :

Sicuramente, dovremmo condividere il database. Riconfigurare le impostazioni / opzioni di un plug-in non è una buona idea.

Ci sono molti plugin , sia gratuiti che premium, che possono aiutarti.

Se vuoi provare qualcosa manualmente, incorpora wp-cli con la risposta di @Wyck.


8

La mia squadra ha affrontato un problema simile. Usiamo git per versioni il nostro codice personalizzato come plugin e il tema che scriviamo. Usiamo Composer per gestire dipendenze come plugin che non abbiamo scritto. Controlliamo i file composer.json e composer.lock in git per mantenere tutti sincronizzati. Ogni sviluppatore dovrebbe estrarre il ramo master git ed eseguire composer updatefrequentemente le proprie box in modo che tutti rimangano aggiornati.

Nel database, gli sviluppatori si preoccupano principalmente della configurazione e spesso utilizziamo WP-CLI per mantenere sincronizzata la configurazione. Ad esempio, abbiamo uno script di shell che esegue un comando WP-CLI per abilitare o disabilitare i plug-in su base per host; alcuni plugin vengono utilizzati solo sul nostro host di gestione temporanea dei contenuti, ad esempio, quindi lo script può essere eseguito su qualsiasi host e abiliterà solo il set appropriato su quell'host. Alcune configurazioni che richiedono troppo tempo per lo script sono solo documentate e riprodotte manualmente se necessario.

Abbiamo anche uno script perl che clonerà completamente il database dal nostro server di gestione temporanea del contenuto su un QA o un host di sviluppo. Gli sviluppatori possono usarlo periodicamente se vogliono tutto il contenuto corrente, anche se di solito è meno importante che avere il codice e la configurazione. Lo script esegue queste attività:

  • dump mySQL del database del server di gestione temporanea del contenuto, modifica dei nomi delle tabelle, caricamento nel database del server di destinazione
  • utilizzare wp-cli per modificare i riferimenti al server di gestione temporanea all'interno del database per fare riferimento al server di destinazione
  • sincronizzare la directory dei caricamenti sul server di destinazione con i caricamenti del server di gestione temporanea del contenuto

Ci sono alcune soluzioni promettenti per il controllo delle versioni del database che stanno arrivando rapidamente. VersionPress e Mergebot sono i due che conosco e ci possono essere altri.

Ho scritto maggiori dettagli tecnici su come abbiamo configurato WordPress per lavorare con git e Composer sul mio blog. Era necessario funzionare con il core di WordPress nella sua directory per fare una netta separazione tra il codice che vogliamo mantenere in git e il core di WordPress. Trattiamo WordPress stesso come una dipendenza e lo gestiamo con Composer.


7

La migliore soluzione che ho visto a questo è usare Bedrock ( https://roots.io/bedrock/ ).

Le altre risposte a questa domanda (Compositore e qualcosa per gestire i tuoi plugin) sono buone risposte; ma Bedrock fornisce un modo sistematico, supportato, documentato e continuamente migliorato di fare ciò, che è preferibile al proprio.

Inoltre, ricorda che puoi avere più di un repository git: uno per il tuo tema, uno per ogni plug-in personalizzato sviluppato e poi uno 'master' per l'installazione Bedrock / Wordpress stessa.


"Bedrock offre un modo sistematico, supportato, documentato e continuamente migliorato di fare ciò, che è preferibile far rotolare il tuo". Posso confermare, Bedrock è fantastico! Usalo con Sage (sviluppato dalle stesse persone, Roots) e lo sviluppo personalizzato all'interno di un team è gestibile in modo decente. Ci sono ancora dei singhiozzi e la risposta di @ Dan9 è più completa, ma non riesco a cantare abbastanza le lodi di Bedrock!
Samrap,

Come sviluppatore MVC, sono d'accordo, ma il tipo di lavoro su cui svolgo i siti WordPress è fortemente basato sul front-end, quindi la configurazione della gestione patrimoniale in Sage vale la cattiva pratica del globale occasionale.
Samrap

0

Se è assolutamente necessario che tu abbia tutti gli stessi plugin installati lavorando sul tema o su un plugin personalizzato, allora condividerei anche il database.

Usiamo git e compositore per mantenere aggiornati i diversi ambienti di sviluppo. Basta tirare le ultime modifiche e rieseguire il compositore e il gioco è fatto.


0

Per prima cosa dobbiamo capire la struttura delle directory di WordPress. La struttura delle directory di WordPress non è così facile da usare git. Quindi suggerirei di usarlo con gitun'architettura modificata piuttosto amichevole. No, non c'è bisogno di andare nel panico. Non devi necessariamente creare questo. Esistono molti di questi tipi di piastre di caldaia o sistemi WordPress strutturati. Basta sceglierne uno e iniziare a scrivere codice.

Adesso arriva al punto di scrivere un codice ben organizzato o un codice modificabile. In realtà abbiamo inserito il nostro codice su wp-content\themes\your-themeo wp-content\themes\your-theme. Quindi nella maggior parte della gitamichevole piastra di WordPress la wp-contentparte è separata. E per lo più tirano il repository WordPress attraverso composer. Rende l'intero progetto molto più pulito.

La sincronizzazione dei plugin è un'altra parte importante. Sarebbe meglio se installi il tuo plugin attraverso composer. Rende il codice del progetto molto più pulito. Qui avrai una panoramica di come installare i plugin di WordPress composer.

Ora vieni alla parte più cruciale, come sincronizzare il database. Penso che potrebbe essere fatto più facilmente in due modi:

  • Tutto lo sviluppatore dovrebbe utilizzare un database remoto. E spesso crearne una copia di backup.
  • Automatizza la funzione di importazione / esportazione di WordPress. Sembra complicato, ma non lo è. Basta fare un po 'di Google, spero che tu possa farlo.

Spero che ti aiuti.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.