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.

Ähnliche Beiträge:

1. Rezension »WordPress – Das Praxisbuch« von Vladimir Simovic

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.

Teil zwei führt in das Template-System von WordPress ein. Anschließend stellt Simovic drei Themes, nämlich die zwei in der Standardinstallation mitgelieferten und ein selbstentwickeltes, im Detail vor. Alle im Theme enthaltenen Dateien werden detailliert mit Quelltext vorgestellt. So einiges ist hier allerdings redundant und hätte ohne Informationsverlust auch kürzer dargestellt werden können. Der Anschaulichkeit dieses Teils tut das aber keinen Abbruch. Der Abschnitt endet mit einem Tutorial, in dem die Verwendung von WordPress als CMS erklärt wird – ein Einsatzzweck, zu dem die Weblog-Software immer häufiger herangezogen wird.

Teil drei trägt den Titel »Pimp my WordPress« und gibt dem Weblog-Autor konkrete Tipps für Dienste und Plugins, mit denen der Funktionsumfang der Software gezielt erweitert oder der Erfolg überwacht werden kann.

In Teil vier finden wir schließlich die Referenz der Template-Tags, die das Buch damit neben dem eh schon gelungenen Inhalt auch noch zu einem kompakten Nachschlagewerk macht.

Eine nette Dreingabe ist die beiliegende Buch-CD. Sie enthält neben zwei unterschiedlichen Programmversionen von WordPress (2.3 war bei Redaktionsschluss noch nicht veröffentlicht ist enthalten) alle im Buch erwähnten Plugins sowie eine vom Autor geschnürte Komplett-Version von WordPress inkl. deutscher Sprachdatei. Dazu gibt es noch die SelfHTML-Dokumentation.

Die Zielgruppe

Das Buch ist ausdrücklich ein Praxisbuch. Es ist kein Einsteiger-, aber auch kein Profibuch. Der Leser sollte möglichst schon erste Erfahrungen mit einem Weblog oder sogar mit WordPress im Speziellen gesammelt haben. Aber auch für Leser, die sich noch gar nicht mit der Materie beschäftigt haben, ist der Schritt zum Verständnis des Buches nicht groß. Für die Umsetzung der Beispiele und das Verständnis der Templates sind zudem Kenntnisse in HTML, CSS und der in WordPress verwendeten Programmiersprache PHP sinnvoll.

Für ein Profibuch ist neben der Einführung der Template-Teil zu ausführlich. Dafür würde ich dann eher mehr zum Thema Programmieren von Plugins und einen tieferen Blick unter die Haube der Software erwarten.

Das Fazit

Als das, was es ist, finde ich das Buch sehr gelungen. Ist man in der umrissenen Zielgruppe, findet man ein anschauliches, sachliches aber nicht zu trockenes Stück Lesestoff und ein sinnvolles Nachschlagewerk.

Über den Autor

Vladimir Simovic aka Perun wohnt in Köln, arbeitet als freier Webworker, Blogger und Autor und er ist Mitglied der Webkrauts.

Links zum Buch

• Website des Autors
• Buch-Website
• Das Buch bei www.jpc.de

Technische Angaben

• WordPress
• Das Praxisbuch
• von Vladimir Simovic
• ISBN: 9783826617904
• mitp-Verlag, 12/2007
• 383 Seiten, mit zahlreichen Abbildungen und CD-ROM, Kartoniert/Broschiert

Ähnliche Beiträge:

1. Rezension »Little Boxes Teil 2« von Peter Müller
2. Rezension: »Web Usability – Das intuitive Web« (Don’t make me think!)
3. Rezension »Einführung in XHTML, CSS und Webdesign« von Michael Jendryschik