Comment dois-je structurer un projet de site Web WP à l'aide de git et de la mise à jour à partir du tableau de bord WP?

Pendant des mois, j'ai essayé de planifier une bonne structure de projet pour utiliser le contrôle de version git pour le développement de sites Web WordPress qui ne sacrifie pas la possibilité de mettre à jour le noyau et les plugins via le tableau de bord WP, ​​ne nécessite pas de structure de répertoire non conventionnelle (wp -contenu en dehors du dossier parent WP) et qui est facile à gérer et à déployer des sites Web entiers. J'ai lu des informations sur les sous-modules, les sous-arborescences, les référentiels imbriqués, etc., et j'ai toujours du mal à tout assembler et à choisir la bonne stratégie.

Voici ce que je pense en ce moment, avec mes réflexions sur la façon dont je gérerais les dépôts git entre parenthèses.

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

Cela me laisse avec plusieurs problèmes / questions;

• Mises à jour automatiques; J'adore la nouvelle fonctionnalité de mises à jour automatiques, elle pourrait potentiellement économiser beaucoup de temps et d'efforts pour maintenir mes sites à jour et sécurisés, mais il semble qu'elle jette une clé dans le suivi des modifications de code avec git. Existe-t-il un moyen de suivre mes modifications de code tout en permettant à WordPress core de se mettre à jour automatiquement?

• Le fait d'avoir des sous-arborescences sous le référentiel de base WordPress m'empêche-t-il d'utiliser git pour fusionner de nouvelles mises à jour de base ou de repousser mes modifications vers le référentiel de base WordPress (si jamais je décidais que j'aimerais être un contributeur principal)?

• Pour les plugins qui n'ont pas de dépôt git public, les ignorer complètement crée le problème de ne pas pouvoir cloner rapidement tout le site sur un nouveau serveur sans copier manuellement les fichiers sur le serveur. Cela pose également un problème si je souhaite apporter des modifications au code de ce plugin, ces modifications ne sont pas suivies et pourraient facilement être perdues lors d'une mise à niveau du plugin.

Donc, pour résumer, qu'est-ce qu'une bonne configuration git + WordPress qui évite ces problèmes? J'apprécierais vos commentaires sur ma structure de projet proposée. Toute façon dont vous pouvez m'aider à améliorer cela serait très appréciée!

PS, s'il y a un meilleur forum pour cette discussion, veuillez me pointer là.

De mon point de vue, votre plan comporte deux problèmes: Git et la structure "conventionnelle". Donc, fondamentalement, tout. :)

1. Git (et le contrôle de version en général) est un mauvais outil pour les piles de sites entiers. J'y suis allé, j'ai fait ça, ça fait très mal.

2. Ce que vous appelez une structure «non conventionnelle» avec un contenu séparé du cœur a été un choix très conventionnel et robuste pour tout site sérieux pendant un certain temps.

3. Il n'y a pratiquement pas de moyens clés en main pour combiner la pile de sites entière avec des mises à jour natives. Cela ne va pas bien ensemble car il essaie d'atteindre des objectifs différents dans des projets de différents niveaux (développeur en contrôle vs utilisateur final en contrôle).

Si vous me demandez le meilleur pari pour l'ensemble du site, la pile WordPress est actuellement Composer , mais les opinions peuvent se méfier. :)

Sur vos préoccupations spécifiques:

1. Comme ci-dessus - les mises à jour natives (plutôt auto) ne fonctionnent pas bien avec des piles étroitement contrôlées.

2. Le noyau WordPress n'est pas développé dans Git et n'accepte pas les demandes de tirage, toutes les contributions sont (jusqu'à présent) via des fichiers correctifs vers Subversion.

3. Vous devrez probablement valider de tels plugins dans votre référentiel. Ou optez pour une autre approche comme Composer.

Vous pourriez jeter un œil à ce problème et à ce problème.

Jetez également un œil aux fichiers README dans chaque dépôt:

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

Sur la base des dépôts ci-dessus, comme un autre exemple d'une configuration Git / WP, j'ai créé cela . J'ai choisi d'utiliser des liens symboliques pour les thèmes (j'essaie de couvrir cela dans mon README ).

Je suis un peu dans le même bateau avec les mises à jour automatiques ... Mon plan était de mettre à jour manuellement le sous-module WP lorsque des mises à jour se produisent. Je pense que l'alternative est, en théorie (je n'ai pas encore testé moi-même), de laisser le sous-module se mettre à jour pour les mises à jour mineures (il y a un paramètre WP pour cela), puis de gitforcer / réinitialiser le sous-module lorsque des mises à jour majeures sortent ( peut-être qu'une des réponses ici pourrait être d'une certaine aide ... bien sûr, je pense, on voudrait cibler une balise WP spécifique lors de la mise à jour vers la prochaine version majeure).

Une chose à noter est que si WP voit .gitdans le (s) chemin (s), il désactivera automatiquement les mises à jour automatiques. Pour plus d'informations, voir:

• Mises à jour automatiques du cœur, une mise à jour

Pour que les mises à jour automatiques soient activées, il existe quelques exigences simples:

• Si l'installation utilise FTP pour les mises à jour (et demande des informations d'identification), les mises à jour automatiques sont désactivées
• Si l'installation s'exécute en tant que paiement SVN ou GIT, les mises à jour automatiques sont désactivées
• Si les constantes DISALLOW_FILE_MODSou AUTOMATIC_UPDATER_DISABLEDsont définies, les mises à jour automatiques sont désactivées
• Si la constante WP_AUTO_UPDATE_COREest définie sur false, les mises à jour automatiques sont désactivées
• Votre installation WordPress doit également pouvoir contacter WordPress.org via des connexions HTTPS, donc votre installation PHP doit également être OpenSSLinstallée et fonctionner.
• Wp-Cron doit être opérationnel, si pour une raison quelconque cron ne fonctionne pas pour votre installation, les mises à jour automatiques seront également indisponibles

Autres liens connexes:

• Mise à jour automatique WP 3.7
• Développement de thème de sous-module GitHub?
• Installer et gérer WordPress avec Git

Mise à jour de mai 2015

J'ai créé ce dépôt qui est un moyen rapide pour moi de démarrer des projets WordPress. Ma dernière approche consiste à contrôler uniquement la version du ou des thèmes. En d'autres termes, j'installe WP localement (en utilisant la configuration dans le référentiel susmentionné) et en production, puis je modifie le fichier de configuration sur chaque système et gittire mon ou mes thèmes pour obtenir un site fonctionnel.

Ce type de développement tombe dans le "pas si facile et nécessite un flux de travail personnalisé qui pourrait prendre beaucoup de temps pour être satisfait".

Je trouve des sous-arbres, des sous-modules ou des repos imbriqués, une énorme douleur dans le cul.

Quelques réflexions (tout suivre).

1. Activez les mises à jour automatiques avec git / svn en utilisant:
   add_filter( 'auto_upgrade_ignore_checkout_status', '__return_true' );

Méthode sûre via les validations manuelles + e-mail:

Vous pouvez utiliser un serveur de transfert et des notifications de mise à jour par e-mail pour vous-même, valider les mises à jour et pousser vers le serveur en direct dont les mises à jour automatiques sont désactivées.

Cela vous permet également de copier / coller des dossiers pour vos propres dépôts à volonté, ce qui est souvent la façon dont je le fais. Il facilite également le clonage / destruction de plusieurs serveurs de transfert, git prend vraiment effet avec cette méthode car il est distribué.

L'inconvénient: copier / coller des dossiers, gestion.

Méthode automatique

Configurez un script de construction (Phing, Ant, Bash, Capistrano, etc.) et du code personnalisé qui fera un git add + commit lorsqu'une mise à jour est appliquée et l'envoyer au serveur en direct. Vous pouvez également séparer les plugins / dépôts de thèmes, puis faire compiler / déplacer / quoi que ce soit le script, et / ou utiliser Composer dans le mix.

L'automatisation d'un flux de travail comme celui-ci a également tendance à être rigide et ne vaut la peine que si vous voyez un réel besoin pour le temps investi.

L'inconvénient: inflexible, prend du temps à créer.

Git ne doit pas être utilisé pour les sauvegardes, et en règle générale, vous n'avez pas besoin de cloner l'historique des validations de WP.

Après un peu de réflexion, puisque je veux vraiment profiter des mises à jour natives de WP pour me sauver les jambes, il n'est pas logique de suivre tout ce que WP mettra à jour à l'aide de git. Voici une idée révisée.

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

Bien sûr, je perds la possibilité de suivre les plugins et les thèmes qui font partie du projet depuis le VCS, mais je n'en ai vraiment besoin qu'à des fins de sauvegarde, et j'utiliserai quand même une sorte de système de sauvegarde normal.

Donc, la seule chose qui manque vraiment à ce que je veux, c'est la possibilité de déployer facilement toute la pile sur différents serveurs sans utiliser FTP pour copier manuellement le tout. Quelqu'un a des idées là-dessus?

Ok, en regardant le discours de Mark Jaquith ici , je suis peut-être sur la mauvaise voie. Voici un autre coup de couteau qui suit tout.

   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

Je suppose que le principal inconvénient de cela est d'avoir un répertoire de contenu personnalisé, ce qui m'a causé des problèmes dans le passé avec des plugins et des thèmes mal écrits ne pouvant pas trouver le répertoire de contenu.