Comment structurer un projet de site Web WP à l'aide de git et d'une mise à jour à partir du tableau de bord WP

12

Depuis des mois, j'essaie de planifier une bonne structure de projet pour l'utilisation du contrôle de version git pour le développement de sites Web WordPress, sans sacrifier la possibilité de mettre à jour le noyau et les plugins via le tableau de bord WP, sans nécessiter de répertoire non conventionnel. structure (wp-content en dehors du dossier parent WP) et qui est facile à gérer et à déployer des sites Web entiers. J'ai lu des articles sur les sous-modules, les sous-arbres, les dépôts imbriqués, etc., et j'ai toujours du mal à tout mettre en place et à choisir la bonne stratégie.

Voici ce que je pense en ce moment, avec mes pensées sur la manière dont je gèrerais les pensions 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. Cela permettrait d'économiser beaucoup de temps et d'efforts pour garder mes sites à jour et sécurisés, mais il semble que cela gêne considérablement le suivi des modifications de code avec git. Est-il possible de suivre les modifications de mon code tout en permettant à WordPress de se mettre à jour automatiquement?

  • Le fait d'avoir des sous-arbres sous le référentiel principal WordPress m'empêche-t-il d'utiliser git pour fusionner de nouvelles mises à jour principales ou de repousser mes modifications dans le référentiel principal WordPress (si je décide un jour, j'aimerais devenir un contributeur principal )?

  • Pour les plugins qui n'ont pas de référentiel git public, les ignorer complètement crée le problème de l'impossibilité de cloner rapidement l'intégralité du 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 plug-in. Ces modifications ne sont pas suivies et peuvent facilement être perdues lors de la mise à niveau d'un plug-in.

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

PS, s’il existe un meilleur forum pour cette discussion, merci de me le signaler.

    
posée Josiah Sprague 31.12.2013 - 21:19

5 réponses

6

De mon point de vue, votre plan pose 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 outil médiocre pour les piles de sites entiers. Je suis allé là-bas, ça fait très mal.

  2. Ce que vous appelez une structure "non conventionnelle" avec un contenu séparé du coeur est un choix très conventionnel et robuste pour tout site sérieux depuis un certain temps.

  3. Il n’existe pratiquement aucun moyen clé en main de combiner toute la pile de sites avec les mises à jour natives. Cela ne va tout simplement pas ensemble car il tente d'atteindre différents objectifs dans des projets de différents niveaux (développeur sous contrôle vs utilisateur final sous contrôle).

Si vous me demandez quel est le meilleur pari pour l'ensemble du site, la pile WordPress est actuellement Composer , mais l'opinion peut être méfiante. :)

Sur vos préoccupations spécifiques:

  1. Comme ci-dessus - les mises à jour natives (et donc plus automatiques) ne fonctionnent pas bien avec des piles étroitement contrôlées.

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

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

réponse donnée Rarst 31.12.2013 - 21:45
3

Vous pouvez consulter le problème et cette question.

Consultez également les fichiers README de chaque dépôt:

Sur la base du dépôt ci-dessus, à titre d'exemple supplémentaire d'une configuration Git / WP, j'ai créé this . 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 cependant ... 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 existe un paramètre WP pour cela), puis de faire un git force / réinitialisation du sous-module lors de mises à jour majeures. sortir (peut-être une des réponses ici pourrait être de une 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 .git dans le (s) chemin (s), il désactivera automatiquement les mises à jour automatiques. Pour plus d'informations, voir:

  

Pour activer les mises à jour automatiques, 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 est exécutée en tant que SVN ou GIT, les mises à jour automatiques sont désactivées
  •   
  • Si les constantes DISALLOW_FILE_MODS ou AUTOMATIC_UPDATER_DISABLED sont définies, les mises à jour automatiques sont désactivées
  •   
  • Si la constante WP_AUTO_UPDATE_CORE est 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. Par conséquent, votre installation PHP a également besoin de OpenSSL installé et fonctionnel
  •   
  • 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 de mai 2015

J'ai créé ce référentiel , un moyen rapide de démarrer des projets WordPress. Ma dernière approche consiste à ne contrôler que les versions du ou des thèmes. En d’autres termes, j’installe WP localement (à l’aide de l’installation dans le référentiel susmentionné) et en production, puis je modifie le fichier de configuration sur chaque système et git tire mon thème pour obtenir un site fonctionnel.

    
réponse donnée mhulse 07.01.2014 - 21:52
2

Ce type de développement relève du "pas si facile et nécessite un flux de travail personnalisé qui peut prendre longtemps pour être satisfait".

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

Quelques pensées (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 des commits manuels + email:

Vous pouvez utiliser un serveur de transfert et envoyer des notifications de mise à jour par e-mail à vous-même, valider les mises à jour et transmettre au serveur en direct les mises à jour automatiques.

Cela vous permet également de copier / coller des dossiers pour votre propre dépôt à volonté, ce qui est souvent le cas. Cela facilite également le clonage / la destruction de plusieurs serveurs intermédiaires, git entre réellement en vigueur avec cette méthode car elle est distribuée.

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’envoie au serveur live. Vous pouvez également séparer les plugins / pensions de thème, puis faire en sorte que le script soit compilé / déplacé / quels qu’ils soient, et / ou utiliser Composer dans le mixage.

Automatiser un flux de travail comme celui-ci a également tendance à être inflexible et ne vaut la peine que si vous voyez un réel besoin de temps investi.

L'inconvénient: inflexible, il faut du temps pour créer.

Git ne doit pas être utilisé pour les sauvegardes et vous n'avez généralement pas besoin de cloner l'historique de commit de WP.

    
réponse donnée Wyck 01.01.2014 - 15:52
0

Après mûre réflexion, étant donné que je souhaite absolument tirer parti des mises à jour natives de WP pour me sauver des tâches légères, il n’a aucun sens 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 savoir quels plug-ins et quels thèmes font partie du projet depuis VCS, mais je n’en ai vraiment besoin que pour des raisons de sauvegarde, et j’utiliserai une sorte de système de sauvegarde standard. de toute façon.

Donc, la seule chose qui me manque vraiment, c’est la possibilité de déployer facilement l’ensemble de la pile sur différents serveurs sans utiliser FTP pour copier manuellement l’ensemble. Quelqu'un a une idée à ce sujet?

    
réponse donnée Josiah Sprague 01.01.2014 - 14:46
0

OK, regardez le discours de Mark Jaquith ici , je suis peut-être sur la mauvaise voie. Voici un autre coup dur 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 cette opération est la création d'un répertoire de contenu personnalisé, ce qui m'a déjà posé problème, les plugins et les thèmes mal écrits ne pouvant pas trouver le répertoire de contenu.

    
réponse donnée Josiah Sprague 01.01.2014 - 15:29

Lire d'autres questions sur les étiquettes