web-dev-qa-db-fra.com

Comment dois-je structurer un WP projet de site Web en utilisant git et mise à jour de WP tableau de bord?

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. une structure de répertoire non conventionnelle (wp-content en dehors du dossier parent WP) et 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 façon dont je gèrerais le repos 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 mes modifications de code tout en permettant à WordPress de se mettre à jour automatiquement?

  • 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 de vouloir contribuer de manière essentielle)?

  • Pour les plugins qui n'ont pas de dépôt 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? J'apprécierais vos commentaires sur la structure de mon projet proposé. Toute façon que vous pouvez 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.

updatesauto-updategit
12
Josiah Sprague

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. Été là, fait ça, ç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 une pile de sites complète avec des mises à jour natives. Cela ne va tout simplement pas bien ensemble car il tente d'atteindre différents objectifs dans des projets de différents niveaux (développeur sous contrôle par rapport à utilisateur final sous contrôle).

Si vous me demandez le meilleur pari pour la pile WordPress du site entier est actuellement Compositeur , mais les avis peuvent être méfiants. :)

Sur vos préoccupations spécifiques:

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

  2. WordPress Core 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 comme Composer.

6
Rarst

Vous pouvez regarder this issue et this issue.

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

Sur la base du dépôt ci-dessus, comme autre exemple d'installation Git/WP, j'ai créé this . J'ai choisi d'utiliser des liens symboliques pour les thèmes (j'essaie de le couvrir 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 les 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) et de faire ensuite un git force/reset du sous-module lorsque des mises à jour majeures sont publiées (peut-être une des réponses ici pourrait être utile… bien sûr, je pense, on voudrait cibler une balise spécifique WP lors de la mise à jour suivante) version majeure).

Une chose à noter est que si WP voit .git dans le (s) chemin (s), les mises à jour automatiques seront automatiquement désactivées. 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 nécessite également l'installation de la version OpenSSL.
  • 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 dépôt qui est 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.

3
mhulse

Ce type de développement relève du "pas si facile et nécessite un workflow personnalisé sur lequel il peut être long de se contenter".

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. Activer 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 actif qui met à jour automatiquement les mises à jour.

Cela vous permet également de copier/coller des dossiers pour vos propres dépôts à volonté, ce que je fais souvent. Cela facilite également le clonage/la destruction de plusieurs serveurs de transfert, git entre réellement en vigueur avec cette méthode car elle est distribuée.

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 git add + commit lors de l’application d’une mise à jour 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 mélange.

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 du temps investi.

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

Git ne doit pas être utilisé pour les sauvegardes, et d'une manière générale, vous n'avez pas besoin de cloner l'historique de commit de WP.

2
Wyck

Après mûre réflexion, étant donné que je veux absolument tirer parti des mises à jour WP natives pour me sauver des jambes, 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 ne peux plus savoir quels plugins et thèmes font partie du projet à partir du VCS, mais je n’en ai vraiment besoin que pour des raisons de sauvegarde, et j’utiliserai quand même une sorte de système de sauvegarde classique.

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

0
Josiah Sprague

Ok, en regardant le discours de Mark Jaquith ici , je suis peut-être sur la mauvaise voie. Voici un autre coup de poignard 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

J'imagine 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, car les plugins et les thèmes mal écrits ne peuvent pas trouver le répertoire de contenu.

0
Josiah Sprague