Inhalt
Revisr ist ein WordPress-Plugin, mit dem man seine Blog-Konfiguration über Git verwalten kann. Ist es auch für meine Entwicklungsumgebung geeignet?
Entwicklungsaktivität bei Revisr
Die letzte Major Release von Revisr (2.0.2) ist bereits vom Dezember 2015. Das bedeutet normalerweise nichts gutes, denn drei Jahre sind unter IT-Bedingungen eine Ewigkeit. Auch im Support-Forum findet man nur wenige neue Anfragen, und die letzte Antwort des Plugin-Autors ist über zwei Jahre alt.
Allerdings ist das Pluginlaut WordPress-Repository das letzte mal vor 2 Monaten upgedated worden und mit der aktuellen WordPress-Version (5.0.3) getestet.
Möglicherweise bestand dieses Update aber nur aus genau dieser Versionsinformation? Dieser Verdacht bestätigt sich beim Blick in den Development Log:
In den letzten 3 Jahren ist also nicht substanzielles an dem Projekt geschehen. Das muss nicht schlechtes bedeuten, denn fie Funktionalität von Git hat sich in dieser Zeit ja auch nicht revolutionär verändert. Es lässt aber nicht gutes für die Zukunft ahnen, wenn sich eventuell auf WordPress-Seite Änderungen ergeben, die ein inhaltliches Update des Plugins nötig machen würden.
Andererseits hat Revisr über 3.000 aktive installationen und recht stabile Download-Raten. Ein zweiter Blick auf ähnliche Plugins wie beispielsweise VersionPress kann aber in jedem Fall nicht schaden.
Voraussetzungen
Der Server deiner WordPress-Installation muss Git installiert haben. Das ist auch bei vielen Webhostern der Fall. Wenn Du nicht weißt, ob dein Hoster Git-Unterstützung installiert hat, stelle folgendes php-Script als Datei git-version.php in das root-Verzeichnis deines WordPress:
<?php
Header('Content-Type: text/plain');
$path = trim(shell_exec('which git'));
if (!$path) {
$path = str_replace('git is ', '', trim(shell_exec('type git')));
}
echo "git path: " . $path . "\n";
$version = shell_exec($path.' --version');
echo "git version: " . $version . "\n";
Wenn Du dieses Script mit https://wordpress.mydomain.tld/git-version.php aufrufst, sollte es etwa folgende Ausgabe erzeugen:
git path: /usr/bin/git git
version: git version 2.11.0
In diesem Fall (mein Webhoster ist Hetzner) ist also alles ok.
Installation
Das Plugin kann ganz normal über die WordPress-GUI aus dem Plugin-Repository installiert und aktiviert werden. So ist sichergestellt, dass immer die aktuelle Version installiert ist.
Lokale Konfiguration
Beim ersten Aufruf des Plugins aus der Menüleiste zeigt Revisr einen Diakog an, mit ldem man den Git-Client entweder mit einem existierenden Repository verbinden oder ein neues anlegen kann. Da wir ganz von vorn anfangen, erzeugen wir also ein neues Repository.
Im folgenden Dialog kann man auswählen, was Inhalt der Repos werden soll. Das ist immer von der eigenen Arbeitsweise abhängig. Hier wollen wir zunächst die gesamte Installation abdecken und lassen die Standard einstellungen unverändert. Damit werden alle Dateien und Datenbank-Tabellen aufgenommen.
Mit einem ersten Commit füllen wir das Repository mit dem aktuellen Status unserer WordPress-Installation
Remote Konfiguration
Das Repository soll auch auf einem entfernten Git-Server gespiegelt werden. Dazu müssen wir zunächst herausfinden, wie der remote Server angesprochen werden kann. In meinem Fall soll die Verbindung per ssh zum Gogs-Server aufgebaut werden. Ein Benutzer ist dort eingerichtet, ein leeres Repository ebenso.
Gogs verrät die URL des Repository in der Kurzanleitung, die bei einem leeren Repository im Dateien Tab angezeigt wird. Unter Dieses Repository klonen listet es die entsprechenden URLs für den http- und ssh-Zugriff. Möglicherweise müssen Servername und Port angepasst werden, wenn Gogs hier Angaben anzeigt, die nur innerhalb des Docker-Containers gültig sind.
Zugriff über SSH
In meinem Fall sieht die URL für den SSH-Zugriff etwa so aus:
ssh://<user>@<servername>:<port>/~/<userspace>/<repository>.git
Solange die Remote URL nicht korrekt ist, zeigt Revisr Remote not found… neben dem Eintrag an.
Jetzt müsste ich noch ein SSH-Key-Paar erzeugen und auf dem Webserver so ablegen, dass Revisr den Key benutzen kann. Die Anleitung beschreibt das allerdings nur für den Fall, dass man Shell-Zugriff auf den Webserver hat und den Key im SSH-Agent eintragen kann.
Ich habe keine Möglichkeit gefunden, den Key auf meinem Shared Server ohne Shell-Zugriff für Revisr zugänglich zu machen. Somit ist der SSH-Zugriff zum Git-Repository wohl nicht möglich.
Zugriff über https
Bleibt der Zugriff über verschlüsseltes http. Die Lösung halte ich für nicht so sauber, da man in der Konfiguration das Git-User-Passwort im Klartext in der URL ablegen muss.
Der Gogs-Server auf dem lokalen Port 3000 ist ohnehin schon über den reverse Proxy aus dem Internet über Port 443 erreichbar.
Für https sieht die URL, die auf der Revisr-Konfigurationsseite unter Revisr Settings Remote Remote URL eingetragen werden muss, in etwa so aus:
https://<git-user>:<passwort>@<server>/<git-user>/<repository>.git
Das akzeptiert Revisr klaglos. Auf dem Revisr-Dashboard kann man jetzt die comitted files mit Quick Actions Push Changes auf den remote Git-Server schieben. Der erste Versuch endet allerdings mit diesem Fehler:
error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413 Request Entity Too Large
fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly
Nach kurzem googeln findet sich die Lösung, in der Konfiguration des nginx-Proxies die maximale Größe des client body zu erhöhen. Die folgender Zeile in den erweiterten Optionen des reverse Proxy (die Größe von 50m kann noch optimiert werden) behebt das Problem:
client_max_body_size 50m;
Danach funktioniert der push auf den remote Server ohne Probleme, und das Repository ist im Gogs-Server sichtbar.
Arbeit mit Git und Gogs
Für die Entwicklung und Softwareverteilung wird Revisr auf allen beteiligten WordPress-Servern installiert. Auf dem Entwicklungssystem befinden sich die Netbeans-IDE inklusive weitere Entwicklungswerkzeuge und ein WordPress-Test-Server. Hier startet die Entwicklung eines neuen Projekts.
Der aktuelle Stand wird mit Netbeans direkt auf den Testserver synchronisiert, so dass man sofort testen kann. Das stellt man bei Project -> Properties -> Sources -> mit einem Haken bei Copy files from source foolder to another location und Angabe des (lokalen) WordPress-Plugin-Verzeichnisses ein.
Wichtige Entwicklungsetappen und die Release-Kandidaten werden entweder direkt aus Netbeans oder vom Test-Server auf das Git-Repository gespiegelt.
Der Staging-Server zieht sich das Repository vom Gogs-Server. Hier werden Tests unter produktionsnahen Bedingungen und Einbeziehung von Nutzern gefahren. Kleinere Änderungen können direkt dort vorgenommen und zum Repository zurückgespiegelt werden.
Bei größeren Änderungen kann man sich den aktuellen Stand auf den Test-Server zurückspiegeln und mit der Entwicklungsumgebung bearbeiten.
Schließlich wird der Produktionsserver über Revisr mit dem fertigen Stand aus Gogs bespielt. Bei unerwarteten Problemen kann man mit Revisr ohne weiteres auf einen älteren Stand des Repository zurückgehen.
Bei sehr kleinen Projekten kann der Staging-Server eventuell entfallen.
Sieht man von der mangelhaften SSH-Key-Unterstützung ab, schein sich Revisr gut für die Entwicklungsarbeit an WordPress-Projekten zu eignen. Wie es sich in der Praxis schlägt, wird die Zukunft zeigen.
Quellen:
- Übersicht zu WordPress-Git-Plugins: www.drweb.de
- Revisr Home Page: revisr.io
- Blog-Beitrag zum Fehler 413 bei stackoverflow.com