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à.
la source
install.phproutine personnalisée ou quelque chose et d'utiliser des mécanismes de mise à jour normaux à partir de là. La pile Composer peut très bien gérer les mises à jour dans l'abstrait, mais elle repose sur la qualité des packages que vous utilisez et des choses comme le proxy de dépôts WP officiels car elle n'est pas encore tout à fait mature.Vous pourriez jeter un œil à ce problème et à ce problème.
Jetez également un œil aux fichiers README dans chaque dépôt:
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:Autres liens connexes:
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.la source
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).
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.
la source
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.
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?
la source
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.
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.
la source