ononlinework

Mit Einführung in XHTML, CSS und Webdesign legt Autor Michael Jendryschik die 2. Auflage seines Buches vor. Diese Auflage entspricht dem gleichnamigen Online-Tutorial auf der Website des Autors.

Der Inhalt

Das Buch folgt einem strengen, sinnvollen Aufbau. Zu Beginn werden sehr ausführlich die Grundlagen vermittelt. Der Leser erhält Basiswissen zu allem, was in der späteren Arbeit mit XHTML und CSS vorausgesetzt wird. Die Grundlagen nehmen in ihrer Ausführlichkeit auch tatsächlich einen nicht unwesentlichen Teil des Buches ein. Man kann das viel finden, mich hat es jedoch begeistert. Nicht alles ist zwingend notwendig, um den später im Buch zu lernenden Stoff zu verstehen, ich empfehle jedoch, nichts in diesem Bereich zu überspringen. Interessant ist es allemal, so wird z. B. auch auf die Entstehung des Internets eingegangen.

Mir als gelerntem Schriftsetzer hat besonders der Teil »Typografie« gefallen. Es ist das erste Mal, dass ich in einem Buch zum Thema Webdesign in dieser Ausführlichkeit etwas über korrekte Gedankenstriche, Anführungszeichen und Apostrophe gefunden habe. Allein hierfür gebührt Michael mein Dank.

Der nächste Abschnitt widmet sich den zu verwendenden Hilfsmitteln beim Webauthoring. Verschiedene Editoren, Validatoren, Programme zur Bildbearbeitung und nützliche Tools werden vorgestellt. Gerade bei den Tools gibt es unglaublich viel, was dem Webautor die Arbeit erleichtert. Ich nenne nur Firebug, das aus meiner Arbeit nicht mehr wegzudenken ist.

Und dann geht es endlich in Medias Res; XHTML ist der Titel des nächsten Abschnitts. Michael Jendryschik geht ausführlich auf den grundsätzlichen Aufbau von XHTML-Dokumenten ein und erklärt die Syntax und das Vokabular. Hier beginnt dann auch der praktische Teil. Das obligatorische Hallo-Welt-Beispiel finden wir dann auch auf Seite 186.

Wir finden in diesem Kapitel nicht nur eine reine Auflistung von Elementen und den möglichen Attributen sondern der Autor gibt auch Tipps zur Arbeitsweise beim Schreiben und zur Anwendung der Elemente. Der Leser sollte anschließend in der Lage sein, das semantisch jeweils am besten passende Element für seinen Inhalt zu finden. In der gegebenen Form halte ich das auch für eine sinnvolle Wiederholung auch für den fortgeschrittenen Webautor.

In der gleichen Qualität geht es im Kapitel CSS weiter. Hier wird gezeigt, wie das von Präsentationseigenschaften freie XHTML-Dokument mit ansprechender Optik versehen wird. Eine kurze Einführung zum Thema, in der neben der Kaskadierung und Vererbung auch auf die Kommentierung der CSS-Dateien anhand von CSSDOC und auf Bugs und Hacks eingegangen wird, wird gefolgt von einer ausführlichen Auflistung der Eigenschaften und Werte. Auch hier finden sich wieder reichlich praxisrelevante Tipps wo andere Autoren sich oft nur auf die reine Erklärung beschränken.

Die Krönung des Buchs ist das letzte Kapitel (vom Anhang abgesehen). Mit der Kochbar wird eine ansehnliche Beispielwebsite erstellt. Das auf den bisher gelesenen Seiten erworbene Wissen kann hier direkt praktisch angewandt werden. Das äußerst ansehnliche Design von Manuela Hoffmann wird nun in sehr gut beschriebenen Schritten nachvollziehbar umgesetzt. Liegt die Zielsetzung anfänglich auf der reinen Information und damit der Auswahl der korrekten Elemente und deren Anordnung, wechselt Michael anschließend folgerichtig in die Umsetzung des Designs mit CSS. Auch hier ist jeder Schritt anhand des vorher Erlernten nachvollziehbar. Der Einsteiger hat am Ende des Kapitels das Erfolgserlebnis einer mit Webstandards umgesetzten Website, die er – von den eingebundenen Grafiken abgesehen – eigenhändig erstellt hat. Gerade zu Beginn einer Webautorenkarriere ist ein solches Erfolgserlebnis eine tolle Motivation, um in dieser Richtung weiterzumachen.

Das Buch schließt dann mit einem ausführlichen Glossar im Anhang.

Der Autor

Michael Jendryschik ist ein Vollblut-Webautor. Neben seiner Arbeit als Leiter der Webentwicklung bei der itemis AG zeichnet er für zahlreiche Fachartikel auf seiner Website und in den einschlägigen Fachzeitschriften verantwortlich. Ich kenne Michael dann auch noch als Webkraut und – was mir erst beim Lesen wieder bewusst wurde – als Regular der Newsgroup de.comm.infosystems.www.authoring.misc, in der ich gerade zu meinen Anfangszeiten in diesem Bereich fleißig mitgelesen und sporadisch mitgeschrieben habe.

Die Zielgruppe

Das Buch wendet sich an Einsteiger, wie aus dem Titel unschwer zu entnehmen ist. Wie so oft, ist aber auch für den Fortgeschrittenen Webautor etwas interessantes zu finden, und wenn es nur die Auffrischung bereits erworbenen Wissens ist. Wer sich allerdings Webdesigner nennt und immer noch mit Tabellenlayouts arbeitet, sollte sich zwingend mit diesem Buch beschäftigen. Hier lernt man, wie man es richtig™ macht!

Das Fazit

Lesebefehl für den ambitionierten Einsteiger

Links zum Buch

• Die Website zum Buch
• Die Website des Autors
• Das Buch bei www.jpc.de
• Das Buch als eBook bei www.jpc.de

Technische Angaben

• Einführung in XHTML, CSS und Webdesign
• Standardkonforme, moderne und barrierefreie Websites erstellen
• von Michael Jendryschik
• ISBN 9783827327390
• Addison-Wesley-Verlag, 12/2008
• 564 Seiten, gebunden

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.