ononlinework

Marketing-Fachmann Torsten Schwarz ist mal wieder als Herausgeber tätig geworden. Diesmal ist es der »Leitfaden Dialog Marketing«, in dem er laut Untertitel das kompakte Wissen der Dialogmarketing-Branche versammelt hat.

Es ist ein Marketingbuch, daher will ich das überflüssige Leerzeichen im Titel mal übersehen – nein, eigentlich will ich das nicht, wer mich kennt, weiß das mit Sicherheit. Schreibfehler im Titel weisen aber nicht zwingend auf fehlende Qualität im Inhalt hin, so auch hier. Ausgehend von den Grundlagen werden Kapitel für Kapitel weitere Bereiche des Dialogmarketings abgedeckt. Eine Reihe von Fallbeispielen ergänzt den Inhalt. Zu den über 80 Autoren der Sammlung gehören Namen wie Siegfried Vögele, Klaus Schober und der Herausgeber des Versandhausberaters, Martin Groß-Albenhausen – alles bekannte Namen in der Branche.

Selbst wenn für gestandene Profis unter den Marketing-Leuten nicht nur Neues dabei ist, dürfte es kaum einen Leser geben, der nicht noch Inspiration durch den einen oder anderen der gesammelten Artikel findet. Nähere Infos zum Buch gibt es auf der Webseite zum Buch und bei jpc.

Das Buch wurde mir von der marketing-BÖRSE GmbH als Rezensionsexemplar zur Verfügung gestellt.

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.

Pünktlich am 1. Dezember ist es wieder so weit. Der Adventskalender der Webkrauts läuft dieses Mal unter dem Motto »Das Beste aus der Praxis« oder »Best Practice im Web«. Das oben zu sehende, sehr schöne Banner für die Aktion wurde übrigens von Manuela Hoffmann erstellt.

Nachdem ich ja im letzten Jahr noch vertreten war, habe ich es in diesem Jahr nicht geschafft, einen Beitrag beizusteuern. Ich gelobe aber Besserung, auch im Hinblick auf Beiträge hier im Weblog. Auf jeden Fall freue ich mich aber auf die Praxistipps der Mitstreiter. Was aus der Themenliste bekannt geworden ist, klingt durchaus vielversprechend.

Christian macht sich in seinem Weblog gerade Gedanken darüber, ob seine nächste Anschaffung ein iMac oder doch wieder ein PC sein wird. Ich kann die Fragestellung verstehen, weil ich selbst bei jeder Neuanschaffung vor dieser Frage stehe.

Kurz zum Hintergrund bei mir: Meine PC-Historie fing vor vielen Jahren mit einem 386er und Windows 3.1 (später 3.11) an und ging dann über mehrere Stufen mit Updates auf OS und Hardware auch immer mit Windows-Rechnern weiter. Meine letzten drei Rechner waren dann Notebooks, erst von Medion, die letzten beiden von Dell. Den Text schreibe ich gerade auf einem 17-Zöller Notebook von Dell mit einem phantastischen Bildschirm mit 1920 x 1200 Pixel.

Parallel zu meinen privaten Windows-Rechnern habe ich beruflich aber lange Zeit an Macs gearbeitet. Ich habe die Ausbildung zum Schriftsetzer (heute heißt man dann Mediengestalter) an Power-PCs mit Mac OS 7.6 angefangen und habe mich vor mittlerweile fünf Jahren aus dem DTP-Bereich verabschiedet, wobei ich zum Schluss einen G4 mit dem letzten 9er-System auf dem Schreibtisch hatte. OS X kenne ich zugegebenermaßen nur von kurzen Ausflügen zurück in meine alte Abteilung. Die Bedienung im Produktiveinsatz kann ich daher nicht beurteilen.

In den etwa sieben Jahren des Parallelbetriebs beider Systeme konnte ich die Begeisterung meiner Kollegen für das Mac-OS nie verstehen. Viele von denen sind allerdings noch in einer Zeit an die Macs gekommen, als die Programme wie Photoshop, Illustrator und andere auf dem PC gar nicht oder nur mit eingeschränktem Funktionsumfang erhältlich waren. Das ist aber schon so lange vorbei, dass es schon gar nicht mehr wahr ist. Die einzigen Probleme zu dem Zeitpunkt waren noch gemischte Netze und untereinander nicht kompatible Schriften. Der Rest ist Gewöhnung. Ich kenne nicht viele, die so intensiv wie ich in beiden Welten gelebt und vor allen Dingen gearbeitet haben und sich daher wirklich ein Urteil bilden konnten.

Ich habe es in der damaligen Zeit nicht geschafft, eine Vorliebe für eines der beiden Systeme zu entwickeln. Manches fehlte am PC, was der Mac hatte und ungekehrt. Interessant fand ich in dem öffentlich ausgetragenen (und sehr albernen) Systemkrieg allerdings immer die Argumentation der Mac-Jünger. Während zu den eher grauen und rein produktionsbezogenen Zeiten vor OS X immer das fehlende »Klickibunti« als großer Vorteil herausgestellt wurde, weil man so etwas als professioneller Anwender ja schließlich nicht brauche, hat dann OS X genau das eingeführt und dann waren Animationen z. B. in Verbindung mit dem Dock auf einmal das Größte. Bei der Präsentation des Systems auf der Drupa wäre ich vor Lachen fast vom Stuhl gefallen. Aber wie gesagt: Das ist albern und kindisch. Wichtig ist die Bedienbarkeit und nicht die Optik.

Für meine privaten – und später auch Anschaffungen für meinen Nebenerwerb – hat dann wegen fehlender Vorlieben immer der Preis den Ausschlag gegeben: Mein aktuelles Notebook hätte bei Apple ziemlich genau das Doppelte gekostet. Mit der Vorstellung der neuen MacBooks stellt sich die Frage natürlich wieder erneut. Aber wie gut soll das Teil eigentlich sein, wenn ich dafür 2.500 Euro (17-Zöller) auf den Tisch legen soll? Wieviel produktiver soll ich damit sein, wenn der Großteil meiner Arbeit im Texteditor stattfindet und ich nur sporadisch ein paar Grafiken in CS3 aufbereiten muss? Da ich mit dem Teil kaum unterwegs bin (deswegen ist Größe und Gewicht auch kein Kriterium) kann ich noch nicht mal damit angeben.

Als offener Mensch lasse ich mich aber gern vom Vorteil überzeugen. Hat den jemand wirkliche Argumente für mich?

Ach ja: Ich werde das natürlich auch in Christians Weblog verfolgen. Für einen Kommentar an der Stelle war mir meine eigene Geschichte allerdings ein wenig lang.

[Update]

Arne schaltet sich jetzt nach seinem Kommentar unten mit einem sehr langen und sehr ausführlichen Artikel in die Diskussion ein. 30.000 Zeichen ohne jede Polemik.

Es liegt schon seit etwa drei Wochen auf meinem Tisch und dekoriert so vor sich hin. Und leider wird es da auch noch ein paar Wochen bleiben müssen.

Die Rezension für Stefan Münz’ Webseiten professionell erstellen muss wegen der zum Glück guten Auslastung in Haupt- und Nebentätigkeit noch eine Weile warten. Bisher kann ich nur sagen, dass es sich um ein mächtig dickes Stück Buch handelt und eine DVD mit Video-Trainings, Software und Dokumentationen enthält und einen äußerst wertigen Eindruck macht.

Der Beschreibung nach finden sich im gut 1200 Seiten starken Buch nicht nur Themen, die direkt mit der Erstellung von Webseiten zu tun haben sondern auch Grundlagen zu etlichen anderen Themen. Neben Client-Server-Architektur gibt es auch eine Einführung in Linux, Apache-Konfiguration, CGI-Programmierung, PHP, MySQL und einen Ausblick auf HTML 5. Es handelt sich um die 3. überarbeitete und erweiterte Auflage des Buchs.

Mehr gibt es dann demnächst.