4.
Januar
2009
Das automatische Update von WordPress
Seit WordPress 2.5 kann man die Plugins durch WordPress aktualisieren lassen. Bis dahin war das nur durch manuelles Downloaden vom Plugin-Directory, Entpacken und Uploaden ins eigene Plugin-Verzeichnis per FTP möglich. Einen anderen Weg konnte nur wählen, wer über einen SSH-Zugang zu seinem Webserver verfügt. Seit WordPress 2.7 ist dieses automatische Update nicht nur für die Plugins sondern auch für WordPress selbst möglich.
Nun ist schon in den Release-Notes zu WP 2.6 davon die Rede, dass es je nach Serverkonfiguration sein kann, dass der Updateprozess nach den FTP-Zugangsdaten fragt. Es gibt also auch Systeme, bei denen das Update direkt durchläuft, es also die gepackten Daten im Hintergrund lädt, entpackt und an entsprechender Stelle wieder entpackt. Dabei wird zu Beginn das Plugin deaktiviert und nach erfolgreichem Update wieder aktiviert.
Nun möchte allerdings nicht jeder seine FTP-Zugangsdaten der Software anvertrauen, die sie dann an den Update-Server übermittelt und das noch über eine ungesicherte Verbindung. Man schreibt die Daten ja auch nicht auf eine Postkarte. Fragt WordPress also nach den Zugangsdaten, ist der andere Weg offensichtlich versperrt. Möchte man seine Daten nun nicht preisgeben, bliebe also wieder nur der bekannte manuelle Weg.
Mal so, mal so. Aber warum?
Nun lässt sich aber feststellen, dass in manchen von mir betreuten WordPress-Installationen der direkte Updateweg funktioniert, in anderen nicht. Das lässt sich natürlich nur auf unterschiedliche Serverkonfigurationen und/oder Nutzerrechte zurückführen; das wird schnell klar. Leider lässt sich aber auch bei längerer Suche nichts dazu finden, welche Voraussetzungen WordPress erwartet, um auf die FTP-Zugangsdaten verzichten zu können. Zumindest ist mir das nicht gelungen. Man findet zwar reichlich User mit der gleichen Fragestellung aber keine zufriedenstellenden Antworten. Der Versuch gestern Abend über Twitter brachte mich trotz freundlich angebotener Hilfestellung auch nicht weiter.
Die Frage nach den Zugangsdaten stellt ja keinen Fehler dar, sondern ein von WordPress vorgesehenes Verhalten. Eine mir vorgeschlagene Suche in den Error-Logs würde also vermutlich keinen Erfolg bringen.
Blick in den Code
Bleibt also, sich mal anzusehen, nach welchen Kriterien WordPress entscheidet, ob der direkte Weg oder der über den FTP-Zugang gewählt wird. Was sind die Voraussetzungen? Vermutet hatte ich anfänglich etwas wie die cURL-Bibliothek oder unterschiedliche Rechte für PHP, z. B. bei allow_url_fopen. Ein Vergleich der unterschiedlichen Hosting-Umgebungen zeigte aber, dass beides als möglicher Unterscheidungsgrund ausscheidet. Auch fehlende Schreibrechte ließen sich schnell ausschließen, als ich kurzzeitig mal die Rechte aller infrage kommenden Dateien auf 0777 gesetzt habe.
Der Blick in den Code enthüllte mir, dass WordPress de Besitzer der gerade ausgeführten Datei abfragt und gleichzeitig eine neue Datei anlegt und auch deren Besitzer abfragt. Sollte bereits das Anlegen der neuen Datei wegen fehlender Benutzerrechte scheitern, ist der Fall eh klar.
Um das klarzustellen: WordPress fragt den Besitzer der gerade ausgeführten Datei ab, nicht den Ausführenden (getmyuid()). Das ist i. d. R. der User, der die Datei auf den Webserver hochgeladen oder das gepackte WordPress-Paket dort entpackt hat. Der User, der die neue Datei anlegt, ist dagegen der Apache-User, also die eigentliche Programmausführung.
Eine Lösung?
Nun unterscheiden sich diese Nutzer leider in vielen Serverumgebungen. Eine mögliche Lösung wäre es also, einfach den Besitzer aller Dateien und Verzeichnisse auf dem Server auf den Apache-User (z. B. wwwrun) zu setzen (chown). Ich habe das zwischenzeitlich getestet; es funktioniert. Das Update läuft anschließend ohne Abfrage der FTP-Zugangsdaten durch.
Problematisch ist dann allerdings, dass einem anschließend der FTP-Zugriff verwehrt wird, will man die die Rechte an allen Dateien und Verzeichnissen nicht entsprechend freigeben, was wieder Sicherheitsrisiken aufbringen würde. Für das Updaten der Plugins ließe sich das eventuell noch umgehen, indem man nur für das Plugin-Verzeichnis den Nutzer entsprechend setzt. So sollten die Updates klappen und man behält zumindest den FTP-Zugriff auf den Rest, sodass man z. B. Änderungen am Theme weiterhin hochladen kann. Damit die Abfrage von WordPress funktioniert, muss dann aber auch noch der Besitzer der abfragenden Datei (wp-admin/update.php müsste das sein) geändert werden und man muss ein temporäres Verzeichnis definieren (WP-Konstante ›WP_TEMP_DIR‹) oder man muss das wp_content-Verzeichnis für den Apache-User schreibbar machen. Das ist allerdings nur für das Update der Plugins eine Lösung, nicht für das Update der gesamten WordPress-Installation.
Wie gehabt
Bleibt für mich also weiterhin nur der Weg des manuellen Updates, wie ich es bisher ja auch schon lange praktiziert habe. Alternativ kann man natürlich auch seinen Hoster fragen, ob er den Apache-User an den FTP-User anpasst. Gerade bei preisgünstigen Hostern sehe ich da allerdings nicht viele Chancen. Ich werde das aber mal probieren. Schließlich wurde mir für all-inkl.com, zu denen ich vor kurzer Zeit gewechselt bin, ein Spitzenservice angekündigt.
Vielleicht nimmt mir aber auch jemand die Vorbehalte, was die Angabe der FTP-Zugangsdaten angeht. Eventuell überschätze ich da ja die Risiken und das Ganze stellt gar kein Problem dar. Selbst an einschlägigen Stellen finde ich nur die Vorteile, nicht aber eventuelle Nachteile dieser Methode.
Ich bin allerdings auch erst einmal zufrieden damit, jetzt zu wissen, warum es mal so, mal so geht.
[Update]
Vor ein paar Monaten hat schon jemand eine Lösung für das Problem gefunden, die jedoch nur über einen Eingriff in die Core-Dateien von WordPress funktioniert. Ich lasse von solchen Lösungen gern die Finger, weil man sonst nach jedem Update prüfen muss, ob die Änderung wieder überschrieben wurde, um ggf. den Eingriff zu wiederholen. Nebenbei funktioniert die beschriebene Lösung natürlich nur für die Plugins, nicht für Core-Updates.
Später wurde dann noch eine Lösung nachgeschoben, die zumindest bei Hosteurope befriedigend zu funktionieren scheint. Ich kann mir allerdings nicht vorstellen, dass diese Lösung für die Core-Updates läuft. Schreibrechte im temporären Verzeichnist dürften dafür nicht ausreichen und das Problem der unterschiedlichen User bleibt dabei ja bestehen.
[Update 2]
Ich habe das Problem für mich jetzt so gelöst, dass ich die gesamte WordPress-Installation über chown dem Apache-User zugeordnet habe und nur den Ordner mit dem von mir genutzten Template beim FTP-User lasse. So kann ich weiterhin Änderungen an Template-Dateien per FTP hochladen und kann ansonsten alle Vorzüge des automatischen Updates für Plugins und Core-Dateien nutzen.
Das Update auf WordPress 2.7.1 hat so schon einwandfrei funktioniert.
Vladimir Simovic (Perun) hat mit »Wordpress – Das Praxisbuch« sein zweites WordPress-Buch veröffentlicht. Der Inhalt teilt sich in vier Abschnitte. Teil eins übernimmt die Einführung in Weblogs, den Einstieg in WordPress und seine Administrationsoberfläche und endet mit den ersten Schritten als Blogger und Anpassungen am bestehenden Weblog.