Wordpress mit Git


21

Ich stelle diese Frage, weil ich im Internet gesucht habe, aber keine passende Lösung gefunden habe. Eigentlich möchte ich eine Lösung, bei der mehrere Entwickler an einem einzigen WordPress-Projekt arbeiten können, ohne sich gegenseitig zu verwirren, aber da wir wissen, dass in WordPress alles in der Datenbank so gepflegt wird, wie welches Plugin aktiv ist und welches nicht.

Wenn Entwickler Plugins in ihrem lokalen Projekt installieren, als wie sie miteinander kommunizieren, sollte jeder das bestimmte Plugin oder die Plugins usw. installieren, und eine falsche Kommunikation kann die Site anderer beschädigen, wenn jeder Entwickler den Code drückt / zieht.

Sollten wir auch die Datenbank freigeben, sollten die Plugin / Themes-Einstellungen freigegeben werden, damit es zu keinen Konflikten oder kleinen Konflikten zwischen den Entwicklern kommt.

Vielen Dank


5
wp-cli.org hilft Ihnen bei Ihrem Workflow.
JGRAUP

1
Wenn möglich auf jekyll oder ähnliches umsteigen.
Jens Schauder

Jekyll ist in Github gebacken, was offensichtlich gut mit Git ...
DaveRGP

FWIW, Kollisionen und Konflikte werden nicht vollständig entfernt, wenn Sie so etwas wie Git verwenden. Sie können diese Konflikte nur so lange aus dem Weg räumen, bis Sie bereit sind, sie "zusammenzuführen".

1
Können alle Entwickler eine gemeinsame, öffentlich gehostete Datenbank gemeinsam nutzen und sich für die Versionskontrolle auf GIT festlegen?
MonkeyZeus

Antworten:


18

Git für Plugins :

Verwenden Sie dann Git, um composer.jsondie Änderungen im TGM-Plugin zu verwalten.

Am schwierigsten ist es, die Datenbank zu synchronisieren :

Auf jeden Fall sollten wir die Datenbank gemeinsam nutzen. Das Neukonfigurieren von Plugin-Einstellungen / -Optionen ist keine gute Idee.

Es gibt viele kostenlose und Premium- Plugins , die helfen können.

Wenn Sie etwas manuell ausprobieren möchten, fügen Sie wp-cli mit der Antwort von @Wyck ein.


8

Mein Team hatte ein ähnliches Problem. Wir verwenden git, um unseren eigenen benutzerdefinierten Code wie Plugins und das von uns geschriebene Thema zu versionieren. Wir verwenden Composer , um Abhängigkeiten wie Plugins zu verwalten, die wir nicht geschrieben haben. Wir überprüfen die Dateien composer.json und composer.lock in git, um alle synchron zu halten. Von jedem Entwickler wird erwartet, dass er den Git-Master-Zweig composer updatezieht und regelmäßig auf seinen Playpens läuft, damit jeder auf dem neuesten Stand bleibt.

In der Datenbank kümmern sich die Entwickler hauptsächlich um die Konfiguration, und wir verwenden häufig WP-CLI , um die Konfiguration synchron zu halten. Zum Beispiel haben wir ein Shell-Skript, das einen WP-CLI-Befehl zum Aktivieren oder Deaktivieren von Plugins auf Hostbasis ausführt. Einige Plugins werden beispielsweise nur auf unserem Content-Staging-Host verwendet, sodass das Skript auf jedem Host ausgeführt werden kann und nur den entsprechenden Satz auf diesem Host aktiviert. Einige Konfigurationen, deren Skripterstellung zu zeitaufwändig ist, werden nur dokumentiert und bei Bedarf manuell reproduziert.

Wir haben auch ein Perl-Skript, das die Datenbank vollständig von unserem Content-Staging-Server auf einen QA- oder Dev-Host klont. Die Entwickler können dies regelmäßig verwenden, wenn sie den gesamten aktuellen Inhalt benötigen, obwohl dies normalerweise weniger wichtig ist als der Code und die Konfiguration. Das Skript führt folgende Aufgaben aus:

  • mySQL-Dump der Datenbank des Content-Staging-Servers, Ändern der Tabellennamen, Laden in die Datenbank des Zielservers
  • Verwenden Sie wp-cli, um Verweise auf den Staging-Server in der Datenbank zu ändern und auf den Zielserver zu verweisen
  • Synchronisieren Sie das Upload-Verzeichnis auf dem Zielserver mit den Uploads des Content-Staging-Servers

Es gibt einige vielversprechende Lösungen für die eigentliche Versionierung der Datenbank, die schnell verfügbar sind. VersionPress und Mergebot sind die beiden, die ich kenne, und es kann auch andere geben.

Ich habe weitere technische Details darüber, wie wir WordPress für die Arbeit mit Git und Composer eingerichtet haben, in meinem Blog geschrieben. Es war notwendig, mit WordPress Core in einem eigenen Verzeichnis zu laufen, um eine saubere Trennung zwischen dem Code, den wir in Git und WordPress Core beibehalten wollen, zu erreichen. Wir behandeln WordPress selbst als eine Abhängigkeit und verwalten es mit Composer.


7

Die beste Lösung, die ich dafür gesehen habe, ist die Verwendung von Bedrock ( https://roots.io/bedrock/ ).

Die anderen Antworten auf diese Frage (Composer und etwas zum Verwalten Ihrer Plugins) sind gute Antworten. Bedrock bietet jedoch eine systematisierte, unterstützte, dokumentierte und kontinuierlich verbesserte Methode, die Sie vorziehen, Ihre eigenen zu rollen.

Denken Sie auch daran, dass Sie mehr als ein Git-Repo haben können - eines für Ihr Thema, eines für jedes von Ihnen entwickelte benutzerdefinierte Plugin und eines für die eigentliche Installation von Bedrock / Wordpress.


"Bedrock bietet eine systematisierte, unterstützte, dokumentierte und kontinuierlich verbesserte Methode, die Sie Ihrem eigenen vorziehen." Kann bestätigen, Bedrock ist großartig! Die Verwendung mit Sage (von denselben Leuten, Roots, entwickelt) und die benutzerdefinierte Entwicklung in einem Team ist anständig beherrschbar. Es gibt immer noch Schluckauf und die Antwort von @ Dan9 ist vollständiger, aber ich kann Bedrocks Lob nicht genug singen!
Samrap

Als MVC-Entwickler bin ich damit einverstanden, aber die Art der Arbeit, auf der ich WordPress-Sites betreibe, basiert stark auf dem Front-End. Daher ist das Asset-Management-Setup in Sage die schlechte Praxis eines gelegentlichen globalen Unternehmens wert.
Samrap

0

Wenn es absolut notwendig ist, dass Sie dieselben Plugins für das Thema oder ein benutzerdefiniertes Plugin installiert haben, würde ich auch die Datenbank freigeben.

Wir verwenden Git und Composer , um die verschiedenen Entwicklungsumgebungen auf dem neuesten Stand zu halten. Ziehen Sie einfach die neuesten Änderungen und führen Sie den Composer erneut aus, und schon kann es losgehen.


0

Dazu müssen wir zunächst die Verzeichnisstruktur von WordPress verstehen. Die Verzeichnisstruktur von WordPress ist nicht besonders benutzerfreundlich git. Daher würde ich Ihnen empfehlen, dies mit einer eher gitfreundlich modifizierten Architektur zu verwenden. Nein, kein Grund zur Panik. Sie müssen dies nicht unbedingt erstellen. Es gibt viele dieser Arten von Kesselplatten oder strukturierten WordPress-Systemen. Wählen Sie einfach einen aus und beginnen Sie mit dem Codieren.

Kommen Sie nun zu dem Punkt, an dem Sie gut organisierten Code oder verwaltbaren Code schreiben. Wir setzen unseren Code tatsächlich auf wp-content\themes\your-themeoder wp-content\themes\your-theme. In den meisten gitbenutzerfreundlichen WordPress-Versionen ist das wp-contentTeil also getrennt. Und meistens ziehen sie das WordPress-Repo durch composer. Es macht das gesamte Projekt viel sauberer.

Die Plugins-Synchronisierung ist ein weiterer wichtiger Teil. Es wäre besser, wenn Sie Ihr Plugin durch installieren composer. Es macht den Projektcode viel sauberer. Hier erhalten Sie einen Überblick über die Installation von WordPress-Plugins composer.

Kommen wir nun zum wichtigsten Teil, wie die Datenbank synchronisiert wird. Ich denke, es könnte auf zwei Arten einfacher gemacht werden -

  • Alle Entwickler sollten eine entfernte Datenbank verwenden. Und häufig ein Backup davon erstellen.
  • Automatisieren Sie den Import und Export von WordPress. Es scheint kompliziert zu sein, aber es ist nicht so. Mach einfach ein bisschen google, hoffe du schaffst das.

Hoffe das hilft dir.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.