In unserer Düsseldorfer WordPress Community ging es am 13.02.2018 um die Remoteverwaltung mehrerer Wordpress Installationen. Jeder, der eine WordPress-Installation betreut weiss, dass hier nahezu täglich Updates anstehen, die man nicht ignorieren sollte. Ob Themes, Plugins oder WordPress selbst: viele Entwickler verbringen viele Stunden mit der Optimierung und dem Debugging ihrer Produkte. Davon wollen wir profitieren. Daher machen wir ordentlich und gewissenhaft Updates, bestenfalls zum "richtigen" Zeitpunkt.
Trivial ist das Update-Management bei WordPress leider nicht. Angenommen man hat einen Shop per WooCommerce in Produktion, der ordentlich Umsatz generiert. Dieser sollte möglichst nicht mehrere Tage ausfallen, weil beispielsweise Zahlungen nicht mehr funktionieren. Bevor man nun also ein WordPress-Update durchführt, möchte man sicher sein, dass WooCommerce weiterhin sauber mit der neuen Version funktioniert. Auch das Theme, sämtliche WooCommerce-Extensions und Plugins wie beispielsweise Germanized müssen mit der neuen Versionen kompatibel sein. Derart komplexe Kausalitäten testet man bestenfalls vorab in einem Staging ~ einer Testumgebung. Dabei müsste man dann aber Sorge tragen, dass bei Veröffentlichung Stage > Life nichts desynchronisiert. Sessions, Warenkörbe und Zahlungsprozesse dürften nicht verlorengehen. Und Backups sind natürlich auch Pflicht, falls doch mal was schiefgehen sollte.
Es erfordert also jede Menge Planung und Erfahrung um WordPress und alles was da dran hängt ausfallsicher zu administrieren. Von 20 Teilnehmern die mehrere WordPress-Installationen betreuen benutzen daher gerade mal 6, also 30%, Remote-Verwaltungs-Tools, und genausoviele verzichten bewusst auf selbige. Das hat natürlich Gründe.
Kompromitierungs-Eskalation
Angenommen, man hat mit einem Parent-Administrations-Tool wie InfiniteWP 30 Child-Installationen verknüpft. Findet ein unberechtigter Zugriff auf das Parent-Admin-Panel statt, sind dadurch gleichzeitig alle dreissig verknüpften Childs kompromitiert, da der Angreifer diese manipulieren kann. Siggi Becker benutzt daher einen lokalen Laragon Webserver um die Kompromittierungswahrscheinlichkeit zu minimieren. Ich würde den wohl in einer VM einrichten, die nur dann laufen würde, wenn Remote-Administrations-Aufgaben anstünden.
Bedienungsfehler
Manchmal sind Menschen müde, verkatert, emotional instabil oder einfach nur unkonzentriert und machen Fehler. Vielleicht läuft auch die Katze im falschen Moment über die Tastatur.
Wenn sich ein unbedachter Klick negativ auf sämtliche, betreute WordPress-Installationen auswirken kann, dann ist das bedenklich. Diesbezüglich hatten wir uns MainWP angeguckt. Das macht einen sehr übersichtlichen Eindruck was zumindest Unachtsamkeits-Fumbles minimieren sollte.
Komplexität bzw. mangelnde Homogenität
Je gleichförmiger die betreuten WordPress-Installationen sind, desto einfacher wäre die Einrichtung automatisierter Administrations- und Update-Aufgaben von einem zentralen Tool aus. Bei meinen Kunden ist das leider nicht gegeben. Themes, Plugins, Page-Builder, Domain- bzw. Multisite-Struktur, vertragliche Regelungen und Pflege-Motivation auf Kundenseite ~ das ist bei mir derart "Kraut und Rüben", dass ich arge Bedenken hege ob eine konsolidierte Remote-Administration in meinem Fall Sinn macht.
Fazit
Die Verwendung einer Remote-Administrations-Lösung muss meiner Ansicht nach gründlich konzipiert und konfiguriert werden, damit sie eher Lösung als Problem darstellt. Ich werde das sehr interessante Meetup in Ruhe verdauen und gründlich darüber Nachdenken, ob ich sowas vielleicht nicht auch in Betracht ziehen sollte. In jedem Fall möchte ich erneut anregen an Communities teilzunehmen. Der persönliche Austausch bei derartigen Events ist unglaublich wertvoll und lehrreich.