Normalerweise sind die WordPress Core- und Plugin-Updates relativ stabil und daher kann man ohne große Sorge sein, dass bei einem der zahlreichen Updates alles gut gehen wird.
Natürlich ist es hilfreich die Update-Notes vorab zu lesen um den Umfang des Updates abzuschätzen und zu wissen, was man genauer prüfen sollte. Wenn es dann wirklich schief geht, hat man normalerweise durch Backups vorgesorgt.
Bei kritischen Updates erscheint dieser Weg jedoch unbefriedigend, weil man keine Möglichkeit hat vorab alles in Ruhe zu testen. Hier hilft nur der Weg über ein Staging-System. Aber wenn der primäre Update-Prozess über das Live-System geht, wie kann man dann ein solches Staging-System realisieren?
Dazu habe ich mir einen nützlichen Workflow bereitgestellt.
Updates übers Live-System?!
Bevor ich meinen Workflow beschreibe, gehe ich kurz auf die Frage ein, warum ich überhaupt die Updates nicht generell über ein Staging-System vorbereite. Das ist grundsätzlich ja der saubere Weg und damit spart man sich viele der Überraschungen, die mit Code-Anpassungen einhergehen könnten.
Die Antwort ist einfach: weil es praktikabler ist das in dieser Weise zu tun. Da mein WordPress über Plesk mit dem WordPress Toolkit aufgesetzt ist, kann ich darüber bequem Core-Versionen, Plugins, Themes und viele Einstellungen zentral verwalten, ohne mich in die einzelnen WordPress-Instanzen einloggen zu müssen. Da die meisten Updates unkritisch sind, ist es nicht sinnvoll jedesmal den großen Bogen über das Staging-System zu nehmen.
Der Aufwand das über ein Staging-System zu machen, lohnt also nur bei kritischen Updates, wie etwa beim Plugin Enlighter neulich:
Lokales Staging-System
Für das lokale Staging bietet sich die bestehende Entwicklungsumgebung an. Da ich der einzige Entwickler bin, kommt es nicht zu Code-Konflikten und daher ist die Einrichtung einer weiteren Umgebung unnötig. Es gibt auch nicht oft parallele Entwicklungen und notfalls kann man das gut mit Branches abdecken.
Ich habe bereits an anderer Stelle meine Entwicklungsumgebung beschrieben. Grob gesagt, habe ich eine lokale SSL-fähige Domain https://blog.gruniversal.mars eingerichtet, die das Live-System weitestgehend spiegelt.
Zudem habe ich mir hier ein nützliches Script erstellt um den Code vollständig vom Live-System zu importieren. Das kommt jetzt direkt zum Einsatz.
Was noch fehlt ist natürlich ein aktueller Abzug der Datenbank. Diesen kann ich einfach aus Plesk exportieren. Alternativ kann man natürlich auch z.B. Adminer im Live-System einrichten und dann dies nutzen.
Live-Stand lokal einrichten
Bevor ich den Live-Stand einspiele, macht es Sinn im Git nochmal aufzuräumen und einen eigenen Branch für das Update anzulegen. Weiterhin ist ggf. ein Datenbank-Backup des bestehenden Entwicklungssystems sinnvoll.
Danach kann ich über das oben angesprochene wget-Script den kompletten Code-Stand aus dem Live-System übertragen. Hierbei ist zu beachten, dass z.B. Zugangsdaten für die Datenbank überschrieben werden. Die sind also in der wp-config.php dann wieder anzupassen.
Statt die Datenbank direkt einzuspielen, wird die bestehende Datenbank zunächst umbenannt und dann eine neue leere Datenbank mit gleichem Namen wieder erstellt. Auf diesem Weg spart man sich ein Backup der Datenbank vorher und kann bei Bedarf leicht zwischen dem alten und neuen Daten-Stand wechseln. Außerdem gibt es dadurch keine Konflikte beim Einspielen des Dumps, weil die Tabellennamen schon existieren.
Damit der Datenbank-Dump von Live auf dem Staging-System funktioniert, muss auch innerhalb der Datenbank die Konfiguration angepasst werden. Konkret betrifft das die Einträge siteurl und home in der Tabelle wp_options. Hier muss die URL angepasst werden:
Test des Staging-Systems
Als nächstes gilt es zu prüfen, ob alles funktioniert. Dazu rufe ich einfach die gerade eingetragene URL auf bzw. das entsprechende WordPress Backend.
Wichtig ist hier zu prüfen, ob nicht an irgendeiner Stelle die URL wieder aufs Live-System wechselt. Bei korrekter Konfiguration sollte das nicht der Fall sein, aber es schadet nicht ein paar Seiten durchzuklicken.
Wenn alles klappt, macht es Sinn diesen Stand jetzt im Git zu sichern und damit ist die Einrichtung abgeschlossen und das eigentliche Update des Plugins kann beginnen.
Enlighter Highlighting auf v4 updaten
Das Enlighter Plugin nutze ich im Blog zum Highlighting von Quelltext und anderen Textbausteinen oder Kommandozeilenaufrufen. Warum ich mich dafür entschieden habe, habe ich in diesem längeren Artikel bereits geschrieben.
Bisher kam hier Version 3.10 zum Einsatz und nun stand hier das Update auf Version 4.1 an. Die Change-Notes lesen sich hierzu etwas bedrohlich und es gibt eine spezielle Upgrade-Anleitung mit folgender Einleitung:
Enlighter v4 has arrived – including a new highlighting engine, languages and theme.
Andi Dittrich
Sadly..there is no full-automatic upgrade path available caused by its new architecture. Custom themes, css modifications and most of the settings have to be manually converted!
Please take some time for testing before applying the v4 release to your website!
Entsprechend vorgewarnt habe ich mir die aktuelle Version 4.1 des Plugins auf der Website abgeholt und das bestehende Plugin unter wp-content/plugins/enlighter damit ersetzt.
Wieder zurück im Backend musste ich wie angenommen die Konfiguration erneut durchführen, z.B. das Hover-Menü über den Code-Blöcken deaktivieren, weil ich es nicht benötige. Außerdem aktiviere ich noch die Funktion das Highlighting nur auf Seite einzubinden, wo auch tatsächlich Code-Blöcke enthalten sind. Alle anderen Einstellungen waren für mich soweit OK.
Bühne frei für den Staging-Stand
Nach diesen Einstellungen folgte ein erster Test und erfreulicherweise funktioniert das Plugin soweit wie gewünscht. Allerdings gibt es ein Problem, welches schon in den Change-Notes genannt wurde. Das Theme “Mocha” ist nicht mehr verfügbar und muss entsprechend ersetzt werden. Sonst erscheint die Darstellung nur im unscheinbaren Fallback-Modus ohne Highlighting.
Ich verwende im Blog neben dem Standard Enlighter Theme noch Mocha als dunkles Theme um Dateien und Kommandozeilenaufrufe optisch voneinander abzugrenzen. Demnach brauche ich ein anderes Dark-Theme als Ersatz für Mocha. Die neue Version bietet zwei andere Dark-Themes: Monokai und Dracula. Da ich Monokai auch im Sublime nutze, gefällt mir dieses besser.
Die nächste Aufgabe ist also alle Code-Blöcke von Mocha auf Monokai umzustellen. Hierzu gibt es, neben dem händischen Weg, die theoretische Möglichkeit das über ein kleines Datenbank-Script zu erledigen. Dazu müsste in allen Einträgen dieser Art “mocha” durch “monokai” ausgetauscht werden:
<!-- wp:enlighter/codeblock {"language":"php","theme":"mocha"} -->
<pre class="EnlighterJSRAW" data-enlighter-language="php" data-enlighter-theme="mocha" ...
Eine nette Idee, aber wahrscheinlich bin ich auf manuellem Weg schneller. Also passe ich einen Beitrag entsprechend an und wie erwartet scheint der Code im neuen Theme. Sieht schick aus, aber irgendwas passt trotzdem nicht. Hmm.
Guter Support ist Gold wert
Es stellt sich raus, dass Monokai eine Schriftgröße von 15px nutzt, Mocha jedoch 12px. Obwohl Enlighter zahlreiche Möglichkeiten zur Konfiguration des CSS über den Theme Customizer anbietet, gelingt es mir nicht die Schriftgröße entsprechend wieder auf 12px zu reduzieren. Irgendetwas fehlt hier.
Nachdem ich das Problem weitestgehend eingegrenzt habe, entscheide ich mich dafür den Entwickler zu kontaktieren und erstelle ein entsprechendes Ticket. Kurze Zeit später erhalte ich die Info, dass das Problem schon an anderer Stelle aufgefallen ist und nur Stunden vorher bereits eine Lösung dafür implementiert wurde.
Trotzdem wird mein Ticket als zusätzliches Enhancement aufgenommen und binnen 30 Minuten (sic!) gefixt. Einen Tag später gibt es im GitHub im Master-Branch eine neue Version 4.2, die den Fix enthält. Das probier ich gleich mal aus!
Und tatsächlich kann ich in der neuen Version auf Anhieb die gewünschte Schriftgröße einstellen. Die Reaktionszeit des Entwicklers ist wirklich eindrucksvoll. Das ist man von kommerziellen Anbietern so häufig nicht gewohnt.
Fazit
Wie man anhand meiner Beschreibung sieht, war es eine gute Entscheidung auf ein lokales Staging zu setzen und das Plugin-Update erstmal lokal zu prüfen. Das Vorgehen verschafft einen doppelten Boden, wenn man glaubt, dass man einen benötigt. Und im Fehlerfall verschafft es Zeit, bis eine Lösung besteht.
Wobei hier die Lösung wahrlich sehr schnell ging. Großes Kompliment an den Entwickler Andi Dittrich, der sich offenbar ehrlich über Feedback freut und Probleme zeitnah und zielgerichtet löst.
Ich könnte jetzt den GitHub-Stand entsprechend ins Live-System bringen, aber da es kein Security-Update ist, warte ich einfach bis die neue Version auch über den normalen Update-Weg verfügbar wird.
In der Zwischenzeit habe ich übrigens doch noch ein kleines Script für die Migration der Enlighter Codeblöcke mit alten Themes geschrieben. Das hat zwar länger gedauert als der händische Weg, aber ist weniger fehleranfällig und nachhaltiger. Außerdem hatte ich einfach Lust dazu :)
Schreibe einen Kommentar