Wordpress avec Git


21

Je pose cette question car j'ai cherché sur internet mais je ne trouve pas la bonne solution. En fait, je veux une solution dans laquelle plusieurs développeurs peuvent travailler sur un seul projet wordpress sans créer de gâchis les uns dans les autres, mais comme nous savons que dans wordpress, tout est conservé dans la base de données comme quel plugin est actif et lequel ne l'est pas.

Si les développeurs installent des plugins dans leur projet local, comment ils communiquent entre eux, chacun devrait installer ce plugin ou ces plugins, etc., et certaines erreurs de communication peuvent casser le site des autres si tous les développeurs poussent / tirent le code.

Faut-il partager la base de données aussi, pour partager les paramètres du plugin / thèmes afin qu'il n'y ait pas de conflits ou peu de conflits entre les développeurs.

Merci


5
wp-cli.org vous aidera un peu avec votre flux de travail.
jgraup

1
Si possible, passez à jekyll ou similaire.
Jens Schauder

Jekyll est cuit dans github, ce qui fonctionne évidemment bien avec git ...
DaveRGP

FWIW, les collisions et les conflits ne sont pas complètement supprimés lors de l'utilisation de quelque chose comme Git, il vous permet simplement de garder lesdits conflits hors de votre chemin jusqu'à ce que vous soyez prêt à les "fusionner".

1
Tous les développeurs peuvent-ils partager une base de données commune hébergée publiquement et s'engager dans GIT pour le contrôle de version?
MonkeyZeus

Réponses:


18

Git pour les plugins :

Ensuite, utilisez Git pour gérer composer.jsonet les modifications dans le plugin TGM.

La partie la plus difficile est de synchroniser la base de données :

Certainement, nous devrions partager la base de données. Reconfigurer les paramètres / options d'un plugin n'est pas une bonne idée.

Il existe de nombreux plugins , gratuits et premium, qui peuvent vous aider.

Si vous voulez essayer quelque chose manuellement, incorporez wp-cli avec la réponse de @Wyck.


8

Mon équipe a été confrontée à un problème similaire. Nous utilisons git pour versionner notre propre code personnalisé tel que les plugins et le thème que nous écrivons. Nous utilisons Composer pour gérer les dépendances telles que les plugins que nous n'avons pas écrits. Nous vérifions les fichiers composer.json et composer.lock dans git pour garder tout le monde synchronisé. On s'attend à ce que chaque développeur tire la branche git master et s'exécute composer updatefréquemment sur son parc pour que tout le monde reste à jour.

Dans la base de données, les développeurs se soucient principalement de la configuration, et nous utilisons souvent WP-CLI pour garder la configuration synchronisée. Par exemple, nous avons un script shell qui exécute une commande WP-CLI pour activer ou désactiver les plugins par hôte; certains plugins ne sont utilisés que sur notre hôte de transfert de contenu, par exemple, de sorte que le script peut être exécuté sur n'importe quel hôte et n'activera que l'ensemble approprié sur cet hôte. Certaines configurations qui prennent trop de temps à scripter sont juste documentées et reproduites manuellement si nécessaire.

Nous avons également un script perl qui clonera complètement la base de données de notre serveur de transfert de contenu sur un hôte QA ou dev. Les développeurs peuvent l'utiliser périodiquement s'ils veulent tout le contenu actuel, bien que ce soit généralement moins important que d'avoir le code et la configuration. Le script effectue ces tâches:

  • vidage mySQL de la base de données du serveur de transfert de contenu, modification des noms de table, chargement dans la base de données du serveur cible
  • utiliser wp-cli pour modifier les références au serveur de transfert dans la base de données pour faire référence au serveur cible
  • synchroniser le répertoire des téléchargements sur le serveur cible avec les téléchargements du serveur de transfert de contenu

Il existe des solutions prometteuses pour réellement versionner la base de données qui arrivent rapidement. VersionPress et Mergebot sont les deux que je connais et il peut y avoir d' autres.

J'ai écrit des détails plus techniques sur la façon dont nous avons configuré WordPress pour fonctionner avec git et Composer sur mon blog. Il était nécessaire d'exécuter avec WordPress core dans son propre répertoire pour faire une séparation nette entre le code que nous voulons maintenir dans git et WordPress core. Nous traitons WordPress lui-même comme une dépendance et le gérons avec Composer.


7

La meilleure solution que j'ai vue à ce sujet est d'utiliser Bedrock ( https://roots.io/bedrock/ ).

Les autres réponses à cette question (Composer, et quelque chose pour gérer vos plugins) sont de bonnes réponses; mais Bedrock fournit une manière systématisée, prise en charge, documentée et continuellement améliorée de le faire, ce qui est préférable à la vôtre.

Rappelez-vous également que vous pouvez avoir plus d'un dépôt git - un pour votre thème, un pour chaque plugin personnalisé que vous développez, puis un «maître» pour l'installation de Bedrock / Wordpress lui-même.


"Bedrock fournit une manière systématisée, prise en charge, documentée et continuellement améliorée de le faire, ce qui est préférable à la vôtre.". Peut confirmer, Bedrock est super! Utilisez-le avec Sage (développé par les mêmes personnes, Roots) et le développement personnalisé au sein d'une équipe est décemment gérable. Il y a encore des hoquets, et la réponse @ Dan9 est plus complète, mais je ne peux pas chanter les louanges de Bedrock assez!
samrap

En tant que développeur MVC, je suis d'accord, mais le type de travail sur lequel je fais des sites WordPress est fortement basé sur le front-end, de sorte que la configuration de la gestion des actifs dans Sage vaut la mauvaise pratique du monde occasionnel.
samrap

0

S'il est absolument nécessaire que vous ayez tous les mêmes plugins installés en travaillant sur le thème ou un plugin personnalisé, je partagerais également la base de données.

Nous utilisons git et composer pour maintenir à jour les différents environnements de développement. Tirez simplement les dernières modifications et relancez le compositeur et vous êtes prêt à partir.


0

Pour cela, nous devons d'abord comprendre la structure du répertoire WordPress. La structure du répertoire WordPress n'est pas très conviviale pour l'utiliser gitavec. Je vous suggère donc de l'utiliser avec gitune architecture modifiée plutôt conviviale. Non, pas besoin de paniquer. Vous n'avez pas nécessairement à créer cela. Il y a beaucoup de ce genre de système standard ou WordPress structuré. Choisissez-en un et commencez à coder.

Venons-en maintenant à l'écriture d'un code bien organisé ou d'un code viable. Nous avons effectivement mis notre code sur wp-content\themes\your-themeou wp-content\themes\your-theme. Ainsi, dans la plupart des gitplates-formes WordPress conviviales, la wp-contentpièce est séparée. Et ils tirent principalement sur le repo WordPress composer. Cela rend le projet complet beaucoup plus propre.

La synchronisation des plugins est une autre partie importante. Il serait préférable que vous installiez votre plugin composer. Cela rend le code du projet beaucoup plus propre. Ici, vous aurez un aperçu de l'installation des plugins WordPress composer.

Venons-en maintenant à la partie la plus cruciale, comment synchroniser la base de données. Je pense que cela pourrait être plus facile à faire de moins de 2 façons -

  • Tous les développeurs doivent utiliser une base de données distante. Et créez fréquemment une sauvegarde de celui-ci.
  • Automatisez la fonction d'importation et d'exportation de WordPress. Cela semble compliqué, mais ce n'est pas le cas. Faites juste un peu de google, j'espère que vous pourrez le faire.

J'espère que cela vous aide.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.