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
Réponses:
Git pour les plugins :
composer.json
.Ensuite, utilisez Git pour gérer
composer.json
et 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.
la source
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 update
fré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:
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.
la source
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.
la source
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.
la source
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
git
avec. Je vous suggère donc de l'utiliser avecgit
une 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-theme
ouwp-content\themes\your-theme
. Ainsi, dans la plupart desgit
plates-formes WordPress conviviales, lawp-content
pièce est séparée. Et ils tirent principalement sur le repo WordPresscomposer
. 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 WordPresscomposer
.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 -
J'espère que cela vous aide.
la source