Come devo strutturare un progetto di sito Web WP usando git e l'aggiornamento dalla dashboard di WP?

Per mesi ho cercato di pianificare una buona struttura di progetto per l'utilizzo del controllo versione git per lo sviluppo di siti Web WordPress che non sacrifichi la possibilità di aggiornare core e plugin attraverso il dashboard di WP, non richiede una struttura di directory non convenzionale (wp -content al di fuori della cartella principale di WP) e che è facile da gestire e distribuire interi siti Web. Ho letto di sottomoduli, sottotitoli, repository nidificati, ecc., E faccio ancora fatica a mettere tutto insieme e scegliere la giusta strategia.

Ecco cosa sto pensando in questo momento, con i miei pensieri su come gestire i repository git tra parentesi.

root (main project repo)
|-- wordpress (public git repo added as subtree)
|    |-- wp-content 
|    |    |-- plugins
|    |    |    |-- my-custom-plugin (git repo added as subtree)
|    |    |    |-- other-plugin-with-git-repo  (git repo added as subtree)
|    |    |    +-- other-plugin-without-git-repo (ignored/untracked)
|    |    |-- themes
|    |    |    |-- my-custom-theme (git repo added as subtree)
|    |    |    |-- other-theme-with-git-repo  (git repo added as subtree)
|    |    |    +-- other-theme-without-git-repo (ignored/untracked)
|    |    +-- uploads (ignored/untracked)
|    |-- wp-admin
|    +-- wp-includes
|-- wp-config.php (ignored/untracked)
+-- other-files.txt

Questo mi lascia con diversi problemi / domande;

• Aggiornamenti automatici; Adoro la nuova funzionalità di aggiornamenti automatici, che potrebbe potenzialmente risparmiare un sacco di tempo e sforzi nel mantenere i miei siti aggiornati e sicuri, ma sembra che getta una chiave nel monitoraggio delle modifiche del codice con git. Esiste un modo per tenere traccia delle modifiche al mio codice pur consentendo l'aggiornamento automatico del core di WordPress?

• Avere sottotitoli nel repository core di WordPress mi impedisce di usare git per unirmi a nuovi aggiornamenti core o rimandare le mie modifiche al repository core di WordPress (se dovessi mai decidere che vorrei essere un collaboratore principale)?

• Per i plug-in che non dispongono di un repository git pubblico, ignorarli completamente crea il problema di non poter clonare rapidamente l'intero sito su un nuovo server senza copiare manualmente i file sul server. Inoltre, causa un problema se voglio apportare modifiche al codice di quel plug-in che tali modifiche non vengono monitorate e potrebbero essere facilmente perse in un aggiornamento del plug-in.

Quindi, per riassumere, cos'è una buona configurazione git + WordPress che evita questi problemi? Gradirei il tuo feedback sulla struttura del mio progetto proposto. Qualunque modo tu mi possa aiutare a migliorare questo, sarebbe molto apprezzato!

PS, se esiste un forum migliore per questa discussione, ti prego di indicarmi lì.

Dal mio punto di vista ci sono due problemi con il tuo piano: Git e la struttura "convenzionale". Quindi praticamente tutto. :)

1. Git (e il controllo della versione in generale) è uno strumento scadente per stack di siti interi. Ci sono stato, fatto, ha fatto molto male.

2. Quella che tu chiami una struttura "non convenzionale" con contenuti separati dal core è stata per un po 'una scelta molto convenzionale e solida per qualsiasi sito serio.

3. Non ci sono praticamente modi chiavi in ​​mano per combinare l'intero stack del sito con aggiornamenti nativi. Semplicemente non va bene insieme poiché cerca di raggiungere obiettivi diversi in progetti di diversi livelli (sviluppatore nel controllo vs utente finale nel controllo).

Se mi chiedi la migliore scommessa per l'intero stack di WordPress sul sito è attualmente Compositore , tuttavia le opinioni potrebbero essere caute. :)

Per le vostre preoccupazioni specifiche:

1. Come sopra - gli aggiornamenti nativi (molto più automatici) non funzionano bene con stack strettamente controllati.

2. Il core di WordPress non è sviluppato in Git e non accetta richieste pull, tutti i contributi sono (finora) tramite file patch su Subversion.

3. Probabilmente dovrai impegnare tali plugin nel tuo repository. O segui un altro approccio come Composer.

Potresti dare un'occhiata a questo problema e questo problema.

Dai un'occhiata anche ai file README in ogni repository:

• markjaquith / WordPress-Skeleton
• davidwinter / wordpress-with-git

Sulla base dei repository sopra, come altro esempio di una configurazione Git / WP, ho creato questo . Ho scelto di utilizzare i collegamenti simbolici per i temi (provo a trattarlo nel mio README ).

Sono un po 'nella stessa barca con gli aggiornamenti automatici però ... Il mio piano era di aggiornare manualmente il sottomodulo WP quando si verificano gli aggiornamenti. Penso che l'alternativa sia, in teoria (devo ancora mettermi alla prova), lasciare che il sottomodulo si aggiorni da solo per gli aggiornamenti minori (c'è un'impostazione WP per questo) e quindi eseguire una gitforzatura / azzeramento del sottomodulo quando escono importanti aggiornamenti ( forse una delle risposte qui potrebbe essere di qualche aiuto ... ovviamente, penso, si vorrebbe targetizzare un tag WP specifico quando si aggiorna alla prossima versione principale).

Una cosa da notare è che se WP vede .gitnel / i percorso / i, disattiverà automaticamente gli aggiornamenti automatici. Per maggiori informazioni, vedi:

• Aggiornamenti core automatici, un aggiornamento

Per abilitare gli aggiornamenti automatici, ci sono alcuni semplici requisiti:

• Se l'installazione utilizza FTP per gli aggiornamenti (e richiede credenziali), gli aggiornamenti automatici sono disabilitati
• Se l'installazione è in esecuzione come checkout SVN o GIT, gli aggiornamenti automatici sono disabilitati
• Se le costanti DISALLOW_FILE_MODSo AUTOMATIC_UPDATER_DISABLEDsono definite, gli aggiornamenti automatici sono disabilitati
• Se la costante WP_AUTO_UPDATE_COREè definita come falsa, gli aggiornamenti automatici sono disabilitati
• La tua installazione di WordPress deve anche essere in grado di contattare WordPress.org tramite connessioni HTTPS, quindi anche la tua installazione di PHP deve essere OpenSSLinstallata e funzionante
• Wp-Cron deve essere operativo, se per qualche ragione cron non funziona per l'installazione, anche gli Aggiornamenti automatici non saranno disponibili

Altri collegamenti correlati:

• Aggiornamento automatico di WP 3.7
• Sviluppo del tema del sottomodulo GitHub?
• Installa e gestisci WordPress con Git

Aggiornamento maggio 2015

Ho creato questo repository che è un modo rapido per avviare progetti WordPress. Il mio ultimo approccio è quello di controllare solo la versione dei temi. In altre parole, installo WP localmente (usando setup nei repository di cui sopra) e in produzione, quindi modifico il file di configurazione su ciascun sistema e gittiro i miei temi per ottenere un sito funzionale.

Questo tipo di sviluppo rientra nel "non così facile e richiede un flusso di lavoro personalizzato che potrebbe richiedere molto tempo per essere soddisfatto".

Trovo Subtrees, sottomoduli o repository nidificati, un enorme dolore nel culo.

Alcuni pensieri (traccia tutto).

1. Abilita gli aggiornamenti automatici con git / svn usando:
   add_filter( 'auto_upgrade_ignore_checkout_status', '__return_true' );

Metodo sicuro tramite commit manuali + e-mail:

È possibile utilizzare un server di gestione temporanea e le notifiche di aggiornamento tramite posta elettronica a se stessi, eseguire il commit degli aggiornamenti e passare al server live che non ha gli aggiornamenti automatici.

Questo ti consente anche di copiare / incollare le cartelle per i tuoi repository a piacimento, che è spesso il modo in cui lo faccio. Inoltre, semplifica la clonazione / distruzione di più server di gestione temporanea, git diventa davvero efficace con questo metodo poiché è distribuito.

Il rovescio della medaglia: copia / incolla cartelle, gestione.

Metodo automatico

Imposta uno script di build (Phing, Ant, Bash, Capistrano, ecc.) E un codice personalizzato che eseguirà un git add + commit quando verrà applicato un aggiornamento e lo invierà al server live. Puoi anche separare plugin / repository di temi e quindi compilare / spostare / qualunque sia lo script e / o usare Composer nel mix.

Anche l'automazione di un flusso di lavoro come questo tende ad essere poco flessibile e ne vale la pena solo se si vede una reale necessità per il tempo investito.

Il rovescio della medaglia: inflessibile, richiede tempo per creare.

Git non dovrebbe essere usato per i backup e in generale non è necessario clonare la cronologia di commit di WP.

Dopo qualche altro pensiero, dal momento che voglio sicuramente sfruttare gli aggiornamenti nativi di WP per salvarmi le gambe, non ha senso tenere traccia di tutto ciò che WP aggiornerà usando git. Ecco un'idea rivista.

root (main project repo)
|-- wordpress (ignored/untracked)
|    |-- wp-content 
|    |    |-- plugins
|    |    |    |-- my-custom-plugin (git repo not connected to parent)
|    |    |    |-- other-plugin (ignored/untracked)
|    |    |    +-- modified-plugin (unignored, added to main project repo)
|    |    |-- themes
|    |    |    |-- my-custom-theme (git repo not connected to parent)
|    |    |    |-- other-theme (ignored/untracked)
|    |    |    +-- modified-theme (unignored, added to main project repo)
|    |    +-- uploads (ignored/untracked)
|    |-- wp-admin
|    +-- wp-includes
|-- wp-config.php (ignored/untracked)
+-- other-files.txt

Certo, poi perdo la capacità di tracciare quali plug-in e temi fanno parte del progetto all'interno del VCS, ma ne ho davvero bisogno solo per scopi di backup e userò comunque una sorta di normale sistema di backup.

Quindi, l'unica cosa che mi manca davvero è la possibilità di distribuire facilmente l'intero stack su server diversi senza utilizzare FTP per copiare manualmente tutto. Qualcuno ci ha pensato?

Ok, guardando i discorsi di Mark Jaquith qui , forse sono sulla strada sbagliata. Ecco un'altra pugnalata che tiene traccia di tutto.

   root (main project repo)
    |-- wordpress (repo as subtree)
    |-- wp-config.php (ignored/untracked)
    |-- wp-content 
    |    |-- plugins
    |    |    |-- my-custom-plugin (repo as subtree)
    |    |    |-- other-plugin-with-git-repo (repo as subtree)
    |    |    +-- plugin-without-git-repo
    |    |-- themes
    |    |    |-- my-custom-theme (repo as subtree)
    |    |    |-- other-theme-with-git-repo (repo as subtree)
    |    |    +-- theme-without-git-repo
    |    +-- uploads (ignored/untracked)
    +-- other-files.txt

Immagino che il principale svantaggio di questo sia avere una directory di contenuto personalizzata, che in passato mi ha causato problemi con plugin e temi scritti male che non riuscivano a trovare la directory di contenuto.