Wie kann man ein lokales und Remote-WordPress-Blog mit Hilfe der Versionskontrolle synchronisieren?

German (Deutsch) translation by Katharina Grigorovich-Nevolina (you can also view the original English article)

Haben Sie sich jemals gefragt, wie Sie die Versionskontrolle mit WordPress verwenden könnten? Wenn Sie Ihre WordPress-Projekte lieber lokal bearbeiten möchten, diese aber remote synchronisieren müssen, ist dieses Tutorial genau das Richtige für Sie. Sie haben wahrscheinlich versucht, zwischen den beiden Setups zu synchronisieren, indem Sie die geänderten Dateien manuell hochgeladen und PHPmyAdmin zum Exportieren und Importieren Ihrer Datenbank verwendet haben, sobald diese geändert wurden, und (sehr wahrscheinlich) dabei etwas kaputt gemacht. In diesem Tutorial werden wir den Synchronisierungsprozess automatisieren. So können Sie sich auf das konzentrieren, was Sie tun sollen, anstatt mit endlosen Migrationen zu ringen.

Das Problem

Normalerweise starten wir die WordPress-Entwicklung auf unseren lokalen Computern. Es ist immer schneller und einfacher, insbesondere wenn Sie eine langsame Internetverbindung haben. Es gibt jedoch Situationen, in denen Sie remote arbeiten müssen. Vielleicht möchten Sie eine kleine Änderung vornehmen, Auffüllungen korrigieren oder einfach einen neuen Beitrag veröffentlichen. Die Änderungen werden nicht auf Ihrer lokalen WordPress-Computerinstallation gespeichert, und dann beginnt das Chaos.

Das Chaos beginnt, weil Sie möglicherweise eine neue Version veröffentlichen müssen und da Sie lokal arbeiten, müssen Änderungen, die Sie remote vorgenommen haben, offline geschaltet werden. Es ist ein echter Schmerz. Sie müssen herausfinden, welche Dateien Sie geändert haben, und sie herunterladen/per FTP herunterladen. Manchmal treten die Änderungen in der Datenbank auf, sodass Sie ein spezielles Tool wie phpmyAdmin benötigen, um die Änderungen zu übernehmen.

Dabei können Sie etwas beschädigen oder eine Änderung vergessen. Dann wird alles chaotisch. In diesem Fall benötigen Sie zwei Dinge: Versionskontrolle und Synchronisation. In diesem Tutorial werde ich die Lösung beschreiben, mit der ich meine Entwicklung und Synchronisierung zwischen meinem lokalen Computer und meinem Remote-Server organisiere.

Schritt 1 Einrichten der Stiftung

Den Plan erklären

Lassen Sie mich zunächst erklären, was wir tun werden. Unser Ziel ist die einfache Synchronisierung zwischen der Remote- und der lokalen Version. Sie arbeiten in der gewünschten Version und machen sie dann identisch. Dazu müssen wir zuerst die Unterschiede zwischen dem Remote- und dem lokalen Setup berücksichtigen.

WordPress speichert Informationen zu Ihrem Blog sowohl in statischen Dateien als auch in Ihrer Datenbank. Einige dieser Informationen beziehen sich auf Ihr aktuelles Hosting. Wenn Sie Ihr gesamtes WordPress-Verzeichnis hochladen und die Remote-Version ersetzen, funktioniert dies nicht.

Die Informationen sind leider in zwei Teile geteilt:

Statische Dateien: WordPress fügt Ihre Datenbankserverinformationen in die Datei wp-config.php ein.
Datenbank: WordPress fügt die Site- und Homepage-URL in die wp-options-Tabelle ein.

Für die Datei wp-config.php implementieren wir einen Prozess, der erkennt, ob wir uns auf dem lokalen oder Remote-Server befinden. Auf diese Weise funktioniert dieselbe Datei in beiden Umgebungen. Für die Datenbank integrieren wir sie in das Versionskontrollsystem und aktualisieren sie, um sie an die lokalen oder Remote-Host-Einstellungen anzupassen.

Versionskontrolle integrieren

Ich benutze Mercurial zur Versionskontrolle. Git ist in der Webentwicklung beliebter, aber in unserem Fall sind sie fast ähnlich: Sie benötigen lediglich ein Tool zur Versionskontrolle.

Ich habe Mercurial zur Versionskontrolle. Es verfügt über Tortoise, eine benutzerfreundliche Oberfläche zum Verwalten Ihrer Repositorys. Das Versionskontroll-Werkzeug muss sowohl auf Ihrem lokalen als auch auf Ihrem Remote-Computer installiert sein. Davon abgesehen benötigen Sie einen dedizierten Server oder einen VPS, um die Drittanbieteranwendung installieren zu können.

Geben Sie Folgendes in Ihre Konsole ein, um ein Repository in Mercurial zu initialisieren

1	cd /mydev_directory
2	hg init
3	hg add
4	hg commit

In der ersten Zeile ändern wir unser Arbeitsverzeichnis in den Ordner, in dem wir die Versionskontrolle aktivieren möchten. Das ist Ihr WordPress-Verzeichnis (in dem Sie WordPress installieren). Die nächste Zeile initialisiert das Repository. In der dritten Zeile wird mercurial angewiesen, alle Dateien im Verzeichnis zu versionieren. Das schließt auch Unterordner ein. In der letzten Zeile wird ein neuer Änderungssatz im Verzeichnis erstellt. Ihr Texteditor wird geöffnet und Sie werden aufgefordert, eine Beschreibung dieses Commits zu schreiben.

Dieses Tutorial behandelt nicht die Verwendung von Mercurial. Wenn Sie die Versionskontrolle nicht kennen, sollten Sie sie lernen. Das ist ein wichtiges Instrument, um Ihre Fähigkeiten zu erweitern. Hier sind einige Tutorials, die ich vorschlage:

Hginit: Auf jeden Fall das bisher beste Tutorial zu Mercurial.
Mercurial unter Ubuntu: Dieses Tutorial zeigt, wie Mercurial unter Ubuntu eingerichtet wird. Nützlich, wenn Sie Ubuntu auf Ihrem VPS oder dedizierten Server ausführen.

Schritt 2 Einrichten Ihres lokalen WordPress-Blogs

Wir werden WordPress auf unserem lokalen Computer neu installieren. Laden Sie die neueste WordPress-Version herunter, extrahieren Sie sie in ein leeres Verzeichnis Ihrer Wahl auf Ihrem Webserver und installieren Sie sie in Ihrem Browser oder durch Ändern der Datei wp-config.php.

Jetzt aktivieren wir die Versionskontrolle in Ihrem WordPress-Verzeichnis

1	cd /testpress
2	Hg init
3	Hg add
4	Hg commit

Diese Befehle initialisieren das Repository und erstellen den ersten Änderungssatz. Jetzt können wir dieses Repository einfach auf unseren Server klonen, WordPress installieren und zwischen der lokalen und der Remote-Distribution hin und her synchronisieren.

Es gibt jedoch Unterschiede, wie wir bereits sagten. Vor der Implementierung des Synchronisierungsprozesses müssen wir ein Skript implementieren, das überprüft, wo die WordPress-Installation ausgeführt wird, und die richtigen Einstellungen lädt.
Die Einstellungen, die geändert werden müssen, sind die Datenbankinformationen. Sie befinden sich in der Datei wp-config.php und WordPress lädt sie aus dieser Datei. Meine lokale Version sieht so aus

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'test');

/** MySQL database username */
define('DB_USER', 'root');

/** MySQL database password */
define('DB_PASSWORD', 'xxxxx');

/** MySQL hostname */
define('DB_HOST', 'localhost');

/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');

/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');

Beachten Sie, dass ich nur den wichtigen Teil kopiert habe. In meinem Remote-Server sollte sich dieser Teil geringfügig unterscheiden

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'user_blog');

/** MySQL database username */
define('DB_USER', 'root');

/** MySQL database password */
define('DB_PASSWORD', 'xyxyx');

/** MySQL hostname */
define('DB_HOST', 'localhost');

/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');

/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');

Der Trick besteht darin, Code zu schreiben, der erkennt, wo sich WordPress befindet. Die zu verwendende Variable ist die PHP-Variable _SERVER ["HTTP_HOST"]. Der Code wertet die Variable aus und weist die Datenbankeinstellungen zu.

/*
 * Unified variables
 */
$user_name = 'root';
$hostname = 'localhost';
$charset = 'UTF-8';
$collate = '';
/*
 * Check for the current environment
 */
if ($_SERVER["HTTP_HOST"] === 'onlineqrlab.com') {
  $db_name = 'user_wordpress';
  $password = 'xyxyxy';
} else if ($_SERVER["HTTP_HOST"] === 'localhost') {
  $db_name = 'test';
  $password = 'xxxxxx';
}

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', $db_name);

/** MySQL database username */
define('DB_USER', $user_name);

/** MySQL database password */
define('DB_PASSWORD', $password);

/** MySQL hostname */
define('DB_HOST', $hostname);

/** Database Charset to use in creating database tables. */
define('DB_CHARSET', $chartset);

/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', $collate);

Im obigen Beispiel haben sich nur zwei Parameter geändert: Datenbankname und Kennwort. Sie können mehr als das haben. Wenn Sie beispielsweise mySql auf einem externen Server hosten, müssen Sie den Hostnamen für Ihr Remote-Server-Setup ändern. Sie sollten den Zugriff auf das WordPress-Blog auch auf Benutzerebene mit eingeschränkten Funktionen anstatt auf Administratorebene beschränken.

Überprüfen Sie, ob Ihre lokale WordPress-Version funktioniert. Wenn ja, dann sind Sie halb fertig!

Schritt 3 Synchronisieren der Mercurial Repositories

Festlegen des Remote Server Repository

Sie können jetzt mit der Arbeit an Ihrer lokalen WordPress-Installation beginnen. Jedes Mal, wenn Sie eine größere Änderung vornehmen, verpflichten Sie sich bei Mercurial, die Änderungen zu verfolgen. Erstellen Sie auf dem Remoteserver unter der Annahme, dass Apache installiert ist, einen neuen Ordner, in den Sie Ihr WordPress-Repository hochladen.

1	cd /apache
2	mkdir mywp_repo
3	cd mywp_repo

Beachten Sie, dass diese Befehle auf Ihrem Remote-Server ausgeführt werden sollten. Sie benötigen einen SSH-Zugriff und eine Befehlszeile. Ich verwende Putty unter Windows, um eine Verbindung zu meinem Server herzustellen.
Sobald unser Repository initialisiert ist, können wir Änderungssätze aus anderen Repositorys verschieben (hochladen) und abrufen (herunterladen), um sie auf dem neuesten Stand zu halten. Damit dieser Vorgang ausgeführt werden kann, benötigen Sie entweder Ihren lokalen oder Ihren Remote-Server, um das Repository zu veröffentlichen, damit Sie es abrufen/verschieben können.

Auf dem Mercurial-Webserver fehlen einige wichtige Funktionen wie Zugriffskontrolle, Authentifizierung und SSL. Es ist daher unsicher, es auf Ihrem Remote-Server zu verwenden. Vorzugsweise müssen Sie den Mercurial-Webserver lokal ausführen und die Änderungen vom lokalen Server auf den Remote-Server übertragen.
Geben Sie auf Ihrem lokalen Computer Folgendes ein, um den Mercurial-Server auszuführen:

hg serve

Jetzt sollten Sie über Ihren Browser auf Ihr Repository zugreifen können. Geben Sie die URL ein, die in Ihrer Befehlszeile angezeigt wird. Normalerweise ist es localhost: 8000. Das Repository ist auch online verfügbar. Sie können von jedem Computer, der mit dem Internet verbunden ist, mit Ihrer IP-Adresse: 8000 darauf zugreifen.

1	Hg pull 192.xxx.xxx.xxx:8000
2	Hg update

Ich empfehle diese Methode jedoch nicht, da sie nicht sicher ist. Es gibt einen einfachen und sicheren Weg, dies zu tun. Es handelt sich um ein mittleres Repository, das von einem Drittanbieter gehostet wird. Ich verwende BitBucket. Es hat einen guten und zuverlässigen Service und bietet auch Bugs Tracking und ein Wiki.

Registrieren Sie sich und erstellen Sie ein Konto in BitBucket. Sie bieten unbegrenzt private und öffentliche Repositories mit bis zu 5 Benutzern kostenlos. Erstellen Sie ein neues Repository in BitBucket und Sie sollten zu dieser Seite weitergeleitet werden.

BitBucket unterstützt HTTPS und SSH. Wenn Ihr Repository privat ist, wie in meinem Fall, müssen Sie sich mit Ihrem Benutzernamen und Passwort authentifizieren, um Push- und Pull-Vorgänge aus dem Repository ausführen zu können.
Führen Sie nach dem Erstellen Ihres neuen Repositorys in BitBucket die folgenden Befehle auf Ihrem lokalen Computer aus

1	hg push https://username@bitbucket.org/username/repository

Sie werden aufgefordert, Ihr Passwort anzugeben, und das Repository wird auf BitBucket hochgeladen. Klonen Sie das Repository nach dem Hochladen auf BitBucket auf Ihren Remote-Server.

1	hg clone https://username@bitbucket.org/username/repository
2	hg update

Klonen Laden Sie die Dateien in ein neues Verzeichnis herunter (wobei der Name mit Ihrem Repository-Verzeichnis übereinstimmt). Sie können dieses Verzeichnis umbenennen. Das macht den ersten Schritt in diesem Abschnitt (in dem wir das WordPress-Setup-Verzeichnis erstellt haben) ziemlich veraltet.

Stellen Sie sich BitBucket als einen Vermittler zwischen Ihrem Computer und Ihrem Remote-Host vor. Es ist möglich, einen eigenen sicheren Mercurial-Server auf Ihrem Remote-Server zu haben. Das würde jedoch den Rahmen dieses Tutorials sprengen. Der Vorteil ist, unabhängig vom Mittelsmann zu sein. Auf diese Weise können Sie Änderungen direkt auf Ihren Webserver übertragen.

Wie ist das besser als FTP?

Sie müssen nicht herausfinden, welche Dateien sich geändert haben.
Es ist bequemer und benötigt weniger Zeit.
Viel schneller, da Mercurial nur die geänderten Dateien drückt.

Installieren des Remote Server-Blogs

Schon müde? Keine Sorge, wir sind fast da. Nachdem Sie das Repository entweder von Ihrem lokalen Computer oder von BitBucket abgerufen haben, müssen Sie die WordPress-Installation erneut ausführen. Diesmal auf der Remote-Server-Site. Stellen Sie sicher, dass die Einstellungen, die Sie in der zuvor vorgenommenen Datei wp-config.php vorgenommen haben, korrekt sind, und laden Sie Ihre WordPress-Remote-Site.

Sie werden aufgefordert, Ihr WordPress-Blog erneut zu installieren. Das liegt daran, dass Ihre Datenbank leer ist. Nach der Installation ist Ihr WordPress-Blog fertig. Sie können Änderungen in der Remote- oder lokalen Version vornehmen und diese mit Mercurial synchronisieren.

Es gibt jedoch noch ein wichtiges Problem: Die Datenbank wird nicht mit den Dateien synchronisiert. Dies ist wichtig, da Dinge wie Blog-Posts, Kommentare, benutzerdefinierte Plug-In-Tabellen in der lokalen und Remote-Version nicht identisch sind.
WordPress hat eine Import/Export-Funktion. Das ist jedoch nicht sinnvoll, da keine echte Synchronisierung durchgeführt wird. Was Sie brauchen, ist, zu Ihrem phpmyadmin zu gehen, alle Ihre WordPress-Tabellen auf einer Seite (remote oder lokal) zu exportieren und dann zur anderen Seite phpmyadmin zu gehen und die Tabellen zu ersetzen.

Danach werden Ihre WordPress-Datenbanken gleich. Sie müssen jedoch die Zeile site_url in der Tabelle wp_options ändern. Dieser Prozess wird schmerzhaft, wenn die Datenbank schwerer wird.

Schritt 4 Synchronisieren der Datenbanken

Wie wir bereits gesehen haben, ist die Datenbank etwas problematisch. Es wird nicht mit den Dateien synchronisiert, ist schwerer zu erreichen und erfordert bei jeder Synchronisierung die Aktualisierung von zwei Feldern. Es macht keinen Spaß, es immer und immer wieder zu tun. Automatisierung ist die Lösung; Das ist unser Job.

Was wir brauchen, ist ein Skript, das die lokalen und persönlichen Datenbanken synchronisiert, ohne etwas zu gehören. Die Idee, die mir in den Sinn kam, der Krieg, die Datenbank in der Revisionskontrolle. Der Datenbankinhalt wird in eine Datei exportiert, die von der Revisionskontrolle verfolgt wird. Jedes Mal, wenn wir Änderungen vornehmen, wird der Datenbankinhalt durch diese Datei ersetzt, wodurch unsere Datenbank auf dem neuesten Stand ist.

Da es einige Zeilen gibt, die sich von Host zu Host unterscheiden (die Site-URL und die Startseite-URL), benötigen wir ein anderes MySQL-Skript, das diese mit den richtigen Werten aktualisiert.
Ein weiterer wichtiger Punkt sind Konflikte. Wenn Sie arbeiten und Änderungen (Commits) sowohl an der Remote- als auch an der lokalen Version vornehmen, führt dies zu einem Konflikt. Ein typisches Szenario ist, wenn Sie arbeiten und sich auf Ihre lokale Version festlegen und jemand (online) Ihrem Blog neuen Inhalt hinzufügt. Ein typisches Erscheinungsbild ist, wenn Sie arbeiten und sich auf Ihre eigene Version fühlen und jemand (online) gehört Blog neuer Inhalt hin gehörtgt.

Stellen Sie zur Vermeidung von Konflikten sicher, dass Sie das Repository aus BitBucket abrufen, bevor Sie Änderungen vornehmen. und auch, um die Änderungen an BitBucket festzuschreiben und zu übertragen, nachdem sie vorgenommen wurden. Dadurch wird sichergestellt, dass BitBucket immer über die neueste Version verfügt und Sie auch an der neuesten Version arbeiten.

Dieser Schritt ist etwas empfindlich. Befolgen Sie daher die Schritte sorgfältig. Zunächst werde ich erklären, wie die Endlösung funktioniert. Sie werden zwei Skripte haben: Push und Pull. Abhängig von Ihrem Betriebssystem ist dies push.sh und pull.sh (Linux) oder push.bat oder pull.bat (Windows). Ich verwende Windows lokal und Linux (Ubuntu) remote, sodass dieses Tutorial beide Betriebssysteme abdeckt.

Das erste Skript überträgt die Änderungen auf den Bitbucket-Server. Wenn Sie einige Datenbankänderungen vornehmen, verwenden Sie das Push-Skript, um die Änderungen in Ihr BitBucket-Repository hochzuladen. Push speichert die aktuelle Datenbank in einer Datei (/db/db_sync.sql), die vom Versionskontrollsystem verfolgt wird. Die Datei wird zusammen mit den anderen Dateien übertragen und auf BitBucket hochgeladen.

Das zweite Skript ruft die Änderungen vom Bitbucket-Server ab. Das Pull-Skript liest auch die Datei (/db/db_sync.sql) und ersetzt die Datenbank. Dadurch wird die Datenbank mit der Version aktualisiert, mit der Sie gepusht haben. Da sie unterschiedliche Hostnamen haben, ändert das Pull-Skript die erforderlichen Felder, nämlich die Site-URL und die Startseite-URL.

Pushing zu BitBucket

Erstellen Sie auf dem Remote- und lokalen Server ein neues Verzeichnis mit dem Namen "db". Die exportierte Datenbankdatei wird dort gespeichert. Erstellen Sie auf Ihrem lokalen Server (ich gehe davon aus, dass Sie Windows verwenden) eine neue Datei mit dem Namen push.bat. Es spielt keine Rolle, wo Sie die Datei ablegen (stellen Sie einfach sicher, dass Sie die richtigen Pfade verwenden). Ich habe die Datei im Stammverzeichnis meines WordPress-Repositorys abgelegt.

1	mysqldump -u username -ppassword database_name > db/db_sync.sql
2	hg add db/db_sync.sql
3	hg commit
4	hg push https://username@bitbucket.org/username/repository

Sie können den Befehl "hg add db/db_sync.sql" entfernen, nachdem Sie das Skript zum ersten Mal ausgeführt haben. Das ist nur einmal erforderlich.

Auf der Serverseite (Linux/Ubuntu) sieht es nicht wirklich anders aus. Die Dateierweiterung ändert sich von .bat in .sh und möglicherweise in Benutzername, Kennwort und Datenbanknamen Ihres mySql-Servers. Der Dateiinhalt ist genau der gleiche.

Aus BitBucket ziehen

Das Ziehen ist etwas schwieriger. Dazu muss die SQL-Datei importiert und einige kritische Felder geändert werden, die sich von Umgebung zu Umgebung unterscheiden.

Erstellen Sie auf Ihrem lokalen Computer eine Datei mit dem Namen pull.bat

hg pull https://username@bitbucket.org/username/repository
hg update
cd db
mysql -u username -ppassword testpress < db_sync.sql
mysql -u username -ppassword testpress < db.sql

Fügen Sie in Ihrem Datenbankordner eine Datei mit dem Namen "db.sql" hinzu. Diese Datei enthält SQL-Anweisungen, die die erforderlichen Änderungen vornehmen, um den Hosteinstellungen zu entsprechen. Sie können bei Bedarf weitere Anweisungen hinzufügen.

1	USE testpress;
2	UPDATE wp_options SET option_value="http://localhost/testpress" WHERE option_name="siteurl";
3	UPDATE wp_options SET option_value="http://localhost/testpress" WHERE option_name="home";

Abgesehen von der Dateierweiterung, den MySQL-Einstellungen und dem Datenbanknamen ändert sich auf dem Remote-Server nichts wirklich. Das liegt daran, dass wir Programmbefehle ausführen. Die Befehle und ihre Verwendung sind plattformunabhängig. Stellen Sie sicher, dass Sie die richtigen Werte für die Website-URL in die Datei "db.sql" eingeben. Sie sollten mit Ihrer Blog-URL übereinstimmen, wenn Sie nicht sicher sind, ob Sie die Werte in der Tabelle wp_options überprüfen können.

Um die Skripte auszuführen, doppelklicken Sie in Windows auf die Datei ".bat" und führen Sie in Ihrem Remote-Server-Terminal den Befehl "sh script_name.sh" aus.

Der Prozess

Sie sollten jetzt 2 ausführbare Dateien in jeder Umgebung haben (Pull and Push). Sie sollten auch ein SQL-Skript (db.sql) haben, das nicht zur Versionskontrolle hinzugefügt werden sollte. Wir können jetzt unser kleines System testen.

Fügen Sie auf Ihrem lokalen Computer einen neuen Blog-Beitrag hinzu
Übertragen Sie die Änderungen von Ihrem lokalen Computer
Ziehen Sie die Änderungen in der Remote-Maschine
Überprüfen Sie, ob das Blog ordnungsgemäß ausgeführt wird und der Blog-Beitrag hinzugefügt wurde