Allgemeines

Thunderbird ist das E-Mail-Programm der Mozilla Foundation. Hervorgegangen ist es aus der Netscape-Suite, welche heute in verschiedenen Formen existiert (SeaMonkey bzw. Iceweasel, es gibt aber auch immer noch Netscape). 2003 wurde die damalige Mozilla-Suite in den Standalone-Browser Firefox und das E-Mail-Programm Thunderbird aufgebrochen. Beides ist Freeware.

Die Version 2.0 von Thunderbird erschien 2007 und liegt mittlerweile in der Version 2.0.0.17 vor. Grundlage dieses und der folgenden Artikel ist eine Neuinstallation der deutschen 2.0.0.6-Version, da dieser Text viele, viele Monate sein Dasein auf meiner Festplatte gefristet hat. Erstaunlicherweise ist er aber immer noch aktuell, leider auch die Probleme, die ich im letzten Teil anspreche.

Warum sollte man Thunderbird benutzen? Die Frage lautet für mich eher: Was sonst? Ich möchte ein Standalone-Mailprogramm, also fällt Operas Mailer weg (der sonst recht vielversprechend klingt). Outlook Express (OE) wird nicht weiterentwickelt, und nach all den Jahren hat man all die Macken und Bugs auch mal satt. Dann gibt es noch einige nette Linux-Programme (nehme ich mal an), aber ich bin nun mal Windows-basiert. Die neuen Vista-Mailprogramme von Microsoft gehen auch nicht, da ich fürs erste bei XP bleiben werde. Dann gibt es noch Programme wie Eudora oder Pegasus Mail, die teilweise recht mächtig sind. Überzeugt haben sie mich allerdings nicht, vor allem auch wegen der Optik. Ich gebe zu, da bin ich oberflächlich *g*, aber im Jahr 2008 erwarte ich von einem Programm einfach eine Optik, die nicht nach Windows 95 aussieht. Ja, und so blieb mir dann letzten Endes der Wechsel zu Thunderbird nicht erspart.

Features

Thunderbird hat ein recht mächtiges Filtersystem eingebaut. Es lohnt sich, dieses anzuschauen. Damit kann man all das tun, was OE kann, aber auch noch einiges mehr. Vor allem kann man diese Filter auch auf beliebige Ordner anwenden, nicht nur auf Mails, die gerade vom Server geladen werden. Das macht sich z.B. gut, um am Anfang die aus OE importierten alten Mails in Ordner zu sortieren. Wenn man in einer geöffneten Mail einen Rechtsklick auf den Absender macht, bekommt man zudem die Option „Filter aus Nachricht erstellen“ angeboten.

Ebenfalls schon in Thunderbird integriert: Ein lernender Spamfilter. Dieser verschiebt automatisch Nachrichten in den „Junk“-Ordner, wenn man das in den Konten-Einstellungen so angegeben hat. Ab und zu sollte man dort mal kontrollieren, dass keine Mails falsch zugeordnet werden. Diese sollte man auf jeden Fall nicht nur wieder aus dem Ordner verschieben, sondern zuerst mittels des „Kein Junk“-Buttons dem Junkfilter seinen Irrtum auch mitteilen. Andersherum sollte man alle Junkmails, die im Posteingang übrig bleiben, nicht einfach löschen, sondern mittels des „Junk“-Buttons dem Filter übergeben, der daraus lernt und die Mails gleichzeitig in den „Junk“-Ordner entsorgt. Glaubt mir: Das allein ist den Wechsel von OE wert!

Thunderbird hat eine eingebaute Rechtschreibprüfung. Das deutsche Wörterbuch muss man sich aber erst herunterladen. Dabei sollte man daran denken, nicht einfach auf den Link im Browser zu klicken, sondern die xpi-Datei wie jede Thunderbird-Extension erst einmal lokal zu speichern und dann als normale Extension zu installieren. Danach ist unter Extras > Einstellungen > Verfassen > Rechtschreibung die Sprache „Deutsch“ ausgewählt.

Hinweise für OE-Umsteiger

Thunderbird ist auf den ersten Blick Ooutlook Express sehr ähnlich, auf den zweiten Blick unterscheidet es sich in vielen Details und auf den dritten Blick kann man es mit ein wenig Konfigurationsaufwand nicht nur auf das Niveau von OE heben, sondern sehr viel besser machen. Dazu müssen einige Einstellungen angepasst werden, außerdem helfen einem verschiedene Extensions dabei, das Verhalten von Thunderbird zu modifizieren. Zuerst hier ein paar Hinweise, was man wissen sollte, wenn man bisher Outlook Express gewöhnt ist.

Thunderbird bietet keine Option zum Exportieren der Mail-Konten, wie man es von OE her kennt. Allerdings ist dies bei Thunderbird auch gar nicht nötig. Dafür muss man wissen, dass die Daten des Programmes (z.B. „C:\Programme\Mozilla Thunderbird“) streng von den Benutzerdaten („C:\Dokumente und Einstellungen\[euer Nutzername]\Lokale Einstellungen\Anwendungsdaten\Thunderbird\Profiles\“) getrennt sind. Jeder Benutzer hat seinen eigenen Profil-Ordner (der Name ist eine kryptische Buchstaben- und Zahlenkombination). Wenn man Thunderbird auf einem neuen Rechner einrichten muss, kann man einfach den Inhalt seines Profilordners in den leeren Profilordner auf dem neuen Rechner kopieren. Wird Thunderbird deinstalliert, bleiben die Profilordner zudem liegen, so dass hier kein Datenverlust auftritt.

Thunderbird speichert jeweils alle Mails eines Ordners in einer einzigen sogenannten Mbox-Datei. Dies kann problematisch werden, wenn ein Virenscanner in der Datei einen Virus findet und diese unter Quarantäne stellt. Dann ist schlimmstenfalls der komplette Posteingang weg. Abhilfe: Das Antiviren-Programm eurer Wahl so einstellen, dass es den Profilordner von Thunderbird bei Scans der Festplatte ignoriert. Bei Norton Antivirus gibt es z.B. eine Liste von Ordnern, die NAV ignoriert (Optionen > Prüfungsausschlüsse, hier den Ordner „C:\Dokumente und Einstellungen\[euer Nutzername]\Lokale Einstellungen\Anwendungsdaten\Thunderbird\Profiles“ hinzufügen). Der Virenscan prüft ja trotzdem die Mails, bevor sie in den Posteingang gelangen und filtert dabei ggf. Viren heraus (zumindest sollte das ein gutes AntiViren-Programm können). Zusätzlich kann man die Zusammenarbeit von Thunderbird und Antiviren-Programm mit einer Option verbessern, die man unter Extras > Einstellungen > Datenschutz > Anti-Virus aktivieren kann.

Thunderbird versucht, Modifikationen der Mbox-Dateien so gering wie möglich zu halten. Deswegen werden gelöschte E-Mails nur aus dem „Inhaltsverzeichnis“ der Mbox-Datei gestrichen, aber nicht aus der Datei selbst. Erst wenn man den Ordner komprimiert, werden diese Mails wirklich gelöscht. Deswegen kann es euch z.B. passieren, dass ihr den Papierkorb gerade geleert habt und dass die Datei „Trash“ trotzdem 100 MB groß ist. Das muss einen in aller Regel nicht stören. Bevor man ein Backup macht, sollte man aber auf jeden Fall die Dateigröße reduzieren. Hin und wieder kann es auch nicht schaden, die Ordner zu komprimieren (auswählbar u.a. im Kontextmenü, wenn man auf einen Ordner klickt). Automatisieren kann man das mit der Option „Ordner komprimieren, wenn es mehr Platz spart als x KB“, zu finden unter Extras > Einstellungen > Erweitert > Netzwerk & Speicherplatz. Thunderbird fragt dann gelegentlich nach, ob er einen bestimmten Ordner komprimieren soll. Bei der einstellbaren KB-Zahl muss man selbst testen, welcher Wert angenehm ist. Ich arbeite fürs erste mit 1024 KB.

Thunderbird kann verschiedene Mail-Konten in einer gemeinsamen Ordnerhierarchie verwalten, wie man es von OE kennt. Es kann aber auch für jedes Mail-Konto eine eigene Hierarchie mit Posteingang, Gesendet, Papierkorb etc. erstellt werden. Dies kann man pro Konto festlegen, der Ordner für gemeinsame Konten heißt „Lokale Ordner“ (Name ist einstellbar). Normalerweise ziehe ich es vor, alles in einer Hierarchie zu verwalten, aber es kann z.B. sinnvoll sein, Arbeits- und private Mails komplett zu trennen.

Thunderbird verwaltet E-Mail-Konten und Postausgangsserver getrennt voneinander, während der SMTP-Server bei OE immer Bestandteil der Mailkonto-Definition ist. Das ist praktisch, wenn man mehrere Mail-Adressen des gleichen Anbieters hat, welche alle den gleichen SMTP-Server verwenden können. Den muss man dann nur einmal anlegen und kann ihn in den Einstellungen des Kontos einfach aus einer Liste auswählen.

Thunderbird kann ausgehenden Mails Signaturen anfügen. Anders als bei OE werden die jedoch nicht in den Programm-Einstellungen verwaltet, sondern man kann in den Konto-Einstellungen eine Datei angeben, die als Signatur dienen soll. Wenn man gar nicht weiß, wo man diese hinspeichern soll, legt man sie am besten mit in den Thunderbird-Profilordner.

Thunderbird verwaltet Passwörter genau wie Firefox zentral. Das heißt, man kann in den Konten-Einstellungen nirgends Passwörter eingeben. Vielmehr fragt Thunderbird beim ersten Herunterladen oder Senden von Maisl danach, und man kann sich dann entscheiden, ob Thunderbird sich die Passwörter merken oder jedes Mal nachfragen soll.

Thunderbird trennt HTML und Nur-Text beim Verfassen von E-Mails strikt. Im Konto wird eingestellt, in welchem Format Mails standardmäßig verfasst werden sollen. Drückt man Shift, während man auf den „Verfassen“-Button klickt, bekommt man das jeweils andere Format. Man kann jedoch nicht eine Mail zur Hälfte als HTML schreiben und sich dann entscheiden, dass man sie doch lieber als Nur-Text hätte, wie das ja bei OE z.B. sehr einfach geht. Dort kann man ja beliebig zwischen HTML und Text hin- und herwechseln. Thunderbird hat zwar eine ähnliche Einstellung unter Einstellungen > Format (nur im HTML-Editorfenster), aber diese regelt nur die Art des MIME-Formates: Ob also z.B. neben der HTML-Sicht noch eine Nur-Text-Sicht als „multipart: alternative“ mitgeschickt werden soll. Wählt man hier z.B: Nur-Text aus, wird die Mail zwar dann nur in der Text-Version versandt, aber man kriegt diese Ansicht selbst nicht zu sehen.

Ein ganz wichtiger Unterschied zwischen OE und Thunderbird: Mails werden in Thunderbird immer sofort abgeschickt, wenn man auf „Senden“ klickt. Nur im Offline-Modus ist vorgesehen, sie im Postausgang zu lassen, bis sie abgeschickt werden. Wenn man es gewohnt ist, dass man eine bestimmte Anzahl an Minuten Zeit hat, eine „abgeschickte“ Nachricht zu korrigieren, hat man hiermit vermutlich seine Probleme. Man kann das gewohnte OE-Verhalten mit einer Extension herzustellen versuchen (Magic SLR), aber es ist vermutlich besser, man gewöhnt sich einfach um. Das geht vergleichsweise schnell, man muss sich nur angewöhnen, die Mails gleich noch mal durchzulesen, bevor man auf „Senden“ klickt.

Man sollte sich am Anfang mal kurz belesen, was format=flowed ist, damit man davon nicht völlig verwirrt wird. Zusammen mit der QuoteColors-Extension ist das eigentlich recht verwendbar, man muss sich nur daran gewöhnen.

Weiter in Teil zwei und drei:

• Teil 2: Konten und Einstellungen
• Teil 3: Wunsch- und Meckerliste

Soweit nicht anders angegeben: © Johannes Ruthenberg. Lesen erwünscht, Zitieren erlaubt, Übernahme des kompletten Textes oder Einbinden des Feeds in andere Webseiten nicht gestattet! Für mehr Infos dazu siehe http://johannes-ruthenberg.de/infos.

Diesen Ostersonntag-Abend habe ich mir mal etwas Zeit genommen, das CMS TYPOlight zu testen. Auf den ersten Blick könnte man meinen, es würde sich dabei um eine abgespeckte Version von „Typo 3″ handeln, was aber nicht der Fall ist. Das CMS ist eine eigenständige Neuentwicklung auf Basis von PHP und erschien zuerst 2004. Entwickelt wird es hauptsächlich von dem Deutschen Leo Feyer.

Im Folgenden beschreibe ich kurz einen lokalen Test des Systems unter WAMPP. Achtung: Dies ist keine offizielle Installationsanleitung! Ich lerne das System auch gerade erst kennen. Ich habe auch absichtlich keine Doku gelesen, um mal zu schauen wie intuitiv das System ist.

Installation

Zur Installation legt man einfach den Inhalt des zip-Archivs im gewünschten Ordner ab und schaltet diesen im httpd.conf-File des Apache für den Webzugriff frei. Dann braucht man noch eine neue, leere Datenbank mit entsprechendem Nutzer (MySQL in meinem Fall). Und dann kann man im Browser einfach die Datei typolight/install.php aufrufen.

In einer sehr sauberen und einfachen Oberfläche wird man jetzt durch die verschiedenen Installationsschritte geführt. Erledigte Schritte sind dabei mit einem grünen Häkchen gekennzeichnet. Alles passiert auf einer Seite, die sich immer wieder neulädt.

Das Passwort für das Install-Script steht in der Readme im zip-Archiv. Als erstes fordert einen das Script auch auf, dieses PW zu ändern. Das klingt schon mal gut, Security ist ja wichtig. Dann wird ein Encryption-Key generiert (wozu auch immer). Dann kann man die DB-Daten eingeben und das Script schreibt die Tabellen in die Datenbank.

Man kann ein Template importieren. Für den Test nehme ich das mitgelieferte Example-Template. Habe noch keine Ahnung, was das genau heißt. *g* Da hier vor Datenverlust gewarnt wird, wird der Begriff „Template“ aber wohl nicht im üblichen Sinne verwendet.

Und das war’s mit der Installation auch schon. Relativ einfach.

Der erste Blick ins Backend

Unten auf der Installationsseite führt ein Link zum Backend-Login. Hier kann man die Sprache des Backends auswählen (Deutsch oder Englisch), was auch schon mal nett ist. Der Nutzername, den man hier zu benutzen hat, wurde offenbar zusammen mit dem Template importiert. Er steht am Ende der Installationsseite unter „Create an admin user“. Kann man leicht übersehen, aber dafür hat der Browser ja einen Zurück-Button.

Das Backend von TYPOlight präsentiert sich auf den ersten Blick ebenfalls sehr übersichtlich. Der Bildschirm ist in drei Bereiche geteilt. Eine schmale Kopfzeile enthält Links zum Frontend, zum Benutzerprofil und zum Logout. Links wird eine Seitenleiste angezeigt mit Links zu den verschiedenen Ansichten des Backends und dann gibt es den größeren Inhaltsbereich.

Kurz überprüft… Das HTML der Seite validert (XHTML 1.0 Strict), was leider keine Selbstverständlichkeit ist. Dass CSS-File validiert nicht, aber nur wegen der Benutzung von CSS-3-Tags und einiger Mozilla-Tags. Also schon mal ein guter Eindruck soweit.

Ok, erstmal der Inhaltsbereich. Ganz oben werde ich unter der Überschrift „Systemnachrichten“ darauf hingewiesen, dass zwei überfällige Aufgaben existieren. Es fehlt aber ein Link, der mich zu den Aufgaben oder den vollständigen Nachrichten bringt. Hm, dann eben nicht.

Weiter. Eine Erklärung der Tastaturkürzel. Nett zu wissen, muss meinetwegen aber nicht immer ganz oben im Backend stehen. Bei Webseiten benutze ich eigentlich nie Tastaturkürzel.

Es folgt eine Liste an Links zu den Verwaltungsseiten der verschiedenen Inhaltstypen (denke ich). Artikel, Nachrichten, „Flash Inhalte“ (sic – Deppenleerzeichen, autsch), Formulargenerator, Kalender/Events, Kommentare, Newsletter, FAQ. Hm, das deckt schon mal die Bedürfnisse der meisten kleineren Seiten ab. Nicht schlecht. Die spannende Frage, die sich mir hier wie bei jedem CMS-Test stellt: Wie kann man eigene Inhaltstypen definieren? Kann man den Seitentyp „Buch-Rezension“ anlegen, mit speziellen Feldern dafür? Muss man das in dem am Anfang importierten Template definieren? Ich bin gespannt…

Nach den Inhalten kommt die Rubrik „Layout“. Hier gibt es Module, Stylesheets, Seitenlayouts, Seitenstruktur und Templates zur Auswahl. Hm, ist klar soweit, interessiert mich aber im Moment noch nicht.

Dann kommen Links zur Benutzerverwaltung. Offenbar wird zwischen Website-Besuchern und Redakteuren unterschieden, es gibt zwei getrennte Seiten für die jeweiligen Benutzer und Benutzergruppen. Also interne und externe Nutzer gewissermaßen. Das handhabt jedes CMS scheinbar anders. Von WordPress her bin ich mittlerweile den Ansatz gewöhnt, nur eine Nutzerbasis zu haben, mit entsprechenden Rechten, und aus meiner Programmiererfahrung heraus ziehe ich das auch vor. Aber gut, hier muss ich ja nichts programmieren, also ist das auch ok.

Unter „System“ finden sich Links zu Dateiverwaltung, System-Log, Einstellungen, Systemwartung, Modul-Creator und einem Tool zum Finden fehlender Labels in Sprachdateien. Ganz unten sind dann noch drei Benutzerfunktionen, das interessanteste davon sicher das „Task Center“. Meine Güte, bestimmt schon das vierte überflüssige Leerzeichen auf einer Seite, und das nur beim Überfliegen gesehen.

Einstellungen

Ok, schaue ich mir mal die Einstellungen an. Auf einer einzelnen Seite kann man hier alles mögliche an Einstellungen eingeben. Seitentitel, Mail-Adresse des Admins. Da geht es schon los, meine lokale Mailadresse „sender@localhost“ wird nicht akzeptiert. Ja Jungs, eine andere habe ich hier aber nicht.

Weitere Optionen: Zeitformate, Zeitzone, lokaler Pfad, Zeichensatz, Datensätze pro Seite. Die Option „Maximale Frontend Bildbreite“ sieht nett aus. Nicht das Deppenleerzeichen natürlich, aber die Funktion klingt praktisch. Ich trage mal „700″ ein. Bilder, die größer sind, werden dann wohl entsprechend verkleinert. Es fehlt natürlich eine Angabe, welche Einheit gemeint ist oder ob man diese mit eingeben muss (CSS-Syntax?!).

Es gibt scheinbar wie bei WordPress ein Permalink-Feature. Nett.

„Fehler anzeigen“: Man kann auswählen, ob Fehler am Bildschirm angezeigt werden sollen, standardmäßig werden sie es nicht. Ein Fehlermanagement, sehr nett. Das hat WordPress z.B. nicht, und es bleibt dem Nutzer überlassen, seine PHP-Installation korrekt zu konfigurieren.

Die weiteren Optionen sind nicht so spannend. Nebenbei stelle ich noch fest, dass erweiterte Optionen eingeblendet werden, wenn sie benötigt werden, z.B. Felder für den SMTP-Server erst bei Auswahl der Option dafür. Man kann das Backend scheinbar stylen, auch wenn standardmäßig nur der Default-Skin zur Auswahl steht. Wenn man ein CMS für Kundenprojekte einsetzt, ist das eine wichtige Fähigkeit.

Ganz am Ende kann man noch eine einfache Matrix aus Rechten und Benutzergruppen managen. Ok, das hätte ich der Übersichtlichkeit halber auf eine eigene Seite gepackt.

Ok, kurzer Test. Beim Verlassen der Einstellungsseite wird nicht vor ungespeicherten Änderungen gewarnt. Obwohl ich nun keine Mailadresse eingetragen habe, hat sich TYPOlight erfreulicherweise alle anderen Einstellungen aber gemerkt. Sehr schön. Dabei stelle ich auch gleich noch fest, dass eine Inline-Hilfe existiert: Am von mir eingegebenen und offenbar falschen Datumsformat klebt ein kleines Fragezeichen-Achtung-Schild. Dahinter verbirgt sich ein Popup mit Erklärungen zu diesem Punkt. Sehr schön. Nicht so gut: Wenn man nicht auf „Speichern“ klickt und die Seite verlässt, kommt keine Warnung. Ebenfalls nicht ganz optimal: Den Speichern-Button gibt es nur einmal ganz unten, und die Seite ist recht lang. Ja, ich weiß, Tastaturkürzel. Aber wer hätte es gedacht, Alt+S ist in meinem Browser offenbar mit was anderem belegt.

Frontend

So, Zeit überhaupt mal das Frontend anzuschauen. „Objekt nicht gefunden“ sagt mir der Browser. Muss ich erst einen Inhalt anlegen? Aber das könnte mir das System ja auch mal sagen. Die FollowSymLinks-Option hatte ich im Apache eingetragen, das bin ich ja schon von den WordPress-Permalinks gewohnt. Ok, stellen wir die Permalink-Option erstmal wieder aus. Und siehe da, es geht. (Beim Gegenlesen fällt mir auf, dass ich das an diesem Abend dann nicht mehr weiter verfolgt habe.)

Die importierte Testseite nennt sich „Music Academy“. Irgendwie wundert es mich, dass der Seitentitel, den ich im Backend eingetragen hatte, nicht auftaucht. Ansonsten sehr hübsch. Brotkrumennavigation, „Print as PDF“-Feature… Die Demoseite enthält Erklärungen zu verschiedenen Features des CMS, aber ich schaue mich erstmal weiter im Backend um.

Taskcenter

Zeit, sich um die überfälligen Aufgaben zu kümmern. Im Taskcenter entpuppen sich diese als Beispieltasks. Ich lege aus Spaß mal eine neue Aufgabe an. Titel, Deadline, dann kann man die Aufgabe einem User zuweisen.

Ups, da haben wir einen Fehler erzeugt. Ja klar, ohne eingetragene Mailadresse oder laufenden Mailserver kann TYPOlight natürlich den Beispielnutzer auch nicht über seine Aufgabe benachrichtigen. Immerhin ist die Fehlerseite insofern hilfreich als sie direkt auf das Logfile hinweist. Dort stellt sich heraus, dass TYPOlight das Datumsformat nicht mag. Meine Güte, sollte das so einen Fehler auslösen? Kann man dann nicht einfach ein Standardformat nehmen? Was fehlt ist ein Link zurück zum Backend.

Zurück zu den Einstellungen. Ja, Hilfetexte sollte man auch lesen. TYPOlight mag mein favoritisiertes Datumsformat „d. M Y“ nicht. Gut, dann halt nicht.

Datumsformat geändert und jetzt klappt das Anlegen neuer Tasks. Sonst ist hier nichts spannendes, ich hatte eigentlich gedacht, das System würde einen hier vielleicht mit voreingestellten Tasks beim Anlegen der Seite unterstützen. Das wäre vielleicht sinnvoller als die vorhandenen Beispieltasks.

Artikel-Verwaltung

Ok, gehe ich mal weiter zur Artikelverwaltung. Hier kann man einen Baum aufklappen, der verschiedene Seiten bzw. Artikel enthält. Über Icons kann man den Artikel bearbeiten, verschieben, duplizieren, löschen etc. Klickt man auf „Bearbeiten“, kommt man zu einer Seite, welche die verschiedenen Elemente der Seite auflistet, z.B. Textbausteine und Überschriften.

Nebenbei bemerkt sind die Icons nicht gerade groß. Ob es das auch in „accessible“ für Leute mit schlechten Augen gibt? Vielleicht als spezielles Backend-Theme? Die Schrift kann man im Browser ja vergrößern, die Icons leider nicht.

Über die gleichen Icons kann man nun die einzelnen Seitenbausteine bearbeiten, löschen, verschieben etc. Ich editiere mal den ersten Baustein. Es wird eine neue Seite geladen. Das hätte ich jetzt fast per AJAX inline erwartet, aber die Seite enthält doch eine ganze Reihe an Infos. Meine Güte, da kann man ja einiges einstellen.

Das CMS kennt verschiedene Elementtypen, quasi die kleinsten Inhaltsbausteine. Das wären z.B. Überschrift, Text, HTML, Aufzählung, Tabelle, Akkordeon, Code, Hyperlink, Top-Link, Bild, Bildergalerie, Download, Downloads, Alias, Artikelteaser, Formular, Modul, Flashgalerie, Kommentare. Nicht schlecht, damit kann man ja schon einiges bauen. Von anderen System bin ich es gewohnt, dass ein Artikel doch relativ starr definiert ist. Hier ist das scheinbar pro Artikel variierbar.

Für die Überschrift kann man die Stufe von h1 bis h6 auswählen. Das irritiert mich. Ist es nicht Aufgabe des Templates zu entscheiden, mit welchem H-Tag die Überschrift ausgegeben wird? EDIT: Da hier beliebig viele Textbausteine kombiniert werden können, macht es schon Sinn, dass man eine Hierarchie für die Überschriften angeben kann, um z.B. unter einer H2 mehrere H3s schachteln zu können. Und ich nehme mal an, dass ein Template bei Bedarf die Überschrift auch anders ausgeben könnte, wenn z.B. die jeweils ersten Überschriften aller Artikel auf einer Seite dargestellt würden oder etwas in der Art. Dass die manuelle Vergabe der Überschriften-Hierarchie zumindest nicht ganz simpel ist, zeigt die Startseite der Beispiel-Seite, welche drei H1-Überschriften untereinander enthält (h1 ist der Default-Wert der Auswahl-Box).

Der Text des Artikels kann in einem graphischen Editor bearbeitet werden. Das wird doch nicht TinyMCE sein? Doch, ist es. Der Editor hat von WordPress her keinen guten Ruf, aber das kann auch an der Einbindung in WordPress liegen. Wird sich zeigen müssen, wie gut der Editor in diesem System funktioniert.

Man kann Artikeln natürlich auch Bilder hinzufügen. TYPOlight verwaltet Bilder im Dateisystem im Ordner tl_files, auf den ersten Blick offenbar ohne weitere Infos dazu in der DB zu speichern. Öffnet man den Dateimanager in einem Popup, kann man dort auch neue Bilder hochladen. Das Interface ist hier nicht direkt intuitiv, aber wenn man es erstmal kapiert hat, ist das kein Problem.

Das Folgende ist das erste, was mich an diesem CMS wirklich irritiert: Ich habe den Dateimanager in einem Popup geöffnet und ein Bild hochgeladen. Es gibt keinen Button, um dieses Bild zum Hinzufügen zum Artikel auszuwählen. Klickt man darauf, öffnet sich nur das Bild in einem weiteren Popup. Also versuche ich das erste Popup zu schließen und kriege eine merkwürdige Javascript-Meldung voller falsch codierter Umlaute. Klickt man auf „OK“ wird die Editorseite neu geladen (Warum???) und es sind tatsächlich gemachte Änderungen weg. Keine Ahnung, was das soll. Ok, beim zweiten Versuch nicht auf OK geklickt. Das Bild muss ich also ohne das Popup auswählen.

Im Folgenden kann man zum Bild noch einige Sachen eingeben wie ein alternativer Text und eine Bildunterschrift. Das ist für mich in Hinblick auf meine Highlanderseite wichtig, denn einer der größeren Nervfaktoren beim händischen Bearbeiten der Seite war das Managen der Bilder: Das gleiche Bild taucht oft auf verschiedenen Seiten auf und ich musste da dann immer wieder alt-Text und Untertitel ergänzen, entweder den gleichen oder einen neuen. Das zentral speichern zu können wäre wünschenswert.

Man kann einzelne Inhaltselemente nur bestimmten Nutzergruppen anzeigen oder für angemeldete Nutzer verstecken. Sehr nett.

Für die Bildanzeige im Frontend genau wie für AJAX-Funktionen im Backend wird im übrigen Slimbox verwendet, ein Lightbox-Klon. Funktioniert tadellos, gefällt mir persönlich vom Aussehen her aber nicht so gut. Das sich drehende Kleeblatt (oder was auch immer?!) beim Nachladen von Content via AJAX sieht im Backend auch etwas deplaziert aus, finde ich. Aber gut, das sind Details. Für JS-Effekte wird MooTools eingesetzt. Habe ich persönlich noch nichts von gehört, ich bin letztens eher bei jQuery auf den Geschmack gekommen.

Aufgrund der Länge des Artikels habe ich ihn in zwei Teile geteilt. Weiter geht es auf der nächsten Seite.

Soweit nicht anders angegeben: © Johannes Ruthenberg. Lesen erwünscht, Zitieren erlaubt, Übernahme des kompletten Textes oder Einbinden des Feeds in andere Webseiten nicht gestattet! Für mehr Infos dazu siehe http://johannes-ruthenberg.de/infos.

Dabei ist mir bewusst, dass eine weitere Seite mit XP-Tuning-Tipps nicht gerade das ist, worauf das Internet gewartet hat. Windows XP ist immerhin seit sechs Jahren auf dem Markt, der Nachfolger Windows Vista schon seit einem Jahr. Trotzdem denke ich, dass XP uns noch ein ganzes Weilchen erhalten bleiben wird. Diese Liste stellt auch nicht alles dar, was man an XP umkonfigurieren kann. Vielmehr sind das genau die Sachen, die ich selber an einem frisch installierten XP ändere und einstelle. Alle Tipps sind also ausprobiert, funktionieren und sind sinnvoll und nötig (aus meiner Sicht).

Trotzdem gilt natürlich: Ich übernehme keine Verantwortung, wenn es bei euch nicht funktioniert. Dies ist eine Beschreibung, was ich bei mir geändert habe. Wenn möglich, sollten vor den Änderungen Backups gemacht werden (z.B. bei Änderungen an der Registry). Außerdem ist das Einspielen aller Updates von Microsoft sinnvoll.

Vor der Installation

Wo wir schon dabei sind, ganz kurz ein paar Gedanken dazu. Als erstes: Nicht „drüber“ installieren, das kann kein gutes Ergebnis bringen. Die Partition, die Windows enthält, gehört formatiert, danach kann man Windows darauf frisch installieren. Aus diesem Grund empfiehlt es sich auch dringend, die Festplatte in mehrere Partitionen aufzuteilen, eine für das Betriebssystem und ggf. die Programme (Manche Leute trennen das auch noch mal, ich bin mir aber nicht sicher, wie viele der Programme nach einer Windows-Neuinstallation ohne die alte Registry noch laufen würden) und eine weitere für alle Daten (Dokumente, Musiksammlung etc.).

An den Anfang gehört immer eine primäre Partition, für die Windows-Installation. Danach kommt eine erweiterte Partition und da hinein dann beliebig viele logische Partitionen. Am besten als NTFS formatieren, das Dateisystem bietet etwas mehr als das ältere FAT32. Bei einer neuen Festplatte: Einfach beim Installieren von XP die erste Partition erstellen. Wenn XP dann läuft, kann man die restlichen Partitionen ganz einfach unter Systemsteuerung > Verwaltung > Computerverwaltung > Datenträgerverwaltung erzeugen oder ändern. Dort kann man auch bei Bedarf andere Laufwerksbuchstaben zuweisen.

Auf den folgenden Seiten findet ihr Einstellungen für alle Nutzer, Einstellungen für das eigene Nutzerkonto und Registry-Hacks.

Soweit nicht anders angegeben: © Johannes Ruthenberg. Lesen erwünscht, Zitieren erlaubt, Übernahme des kompletten Textes oder Einbinden des Feeds in andere Webseiten nicht gestattet! Für mehr Infos dazu siehe http://johannes-ruthenberg.de/infos.

Also dachte ich, man müsste die nötigen Infos doch auch einfacher herauskriegen können. Werden Fehler geloggt? Und wenn ja, wohin? Das sind die Fragen, die den PHP-Neuling interessieren (sollten), wenn ein Script nicht funktioniert oder nur die berühmt-berüchtigte weiße Seite zu sehen ist. Zum Glück gibt es die schöne PHP-Funktion ini_get, mit der man die aktuellen Einstellungen herauskriegen kann. Ich habe daraus mal ein kleines Script gebastelt, welches alle wichtigen Infos zum Thema Errorlogging ausgibt.

Download

Das Script kann hier heruntergeladen werden: Download.

Benutzung

• zip-Datei herunterladen und auspacken
• die datei errorlogging.php auf den Server oder in euren lokalen Webspace kopieren
• errorlogging.php aufrufen
• wenn ihr alle nötigen Infos habt, die Datei wieder aus dem Webspace löschen

Beschreibung

Das Script liest einige Informationen aus, und zwar folgende:

• Werden Fehlermeldungen am Bildschirm ausgegeben?
• Werden Fehlermeldungen in eine Datei geschrieben?
• Wo ist die Errorlog-Datei gespeichert?
• Fehler welcher Stufe werden geloggt bzw. ausgegeben?
• Existiert im aktuellen Ordner eine lokale php.ini-Datei?
• Lassen sich PHP-Direktiven mittels der ini_set-Funktion verändern?

Diese Informationen sind mit kurzen Kommentaren versehen und ggf. mit Hinweisen zur Verbesserung der Einstellungen. Zusätzlich werden mittels der phpinfo()-Funktion detaillierte Informationen über die Konfiguration ausgegeben.

Das Script ist nur 250 Zeilen lang und enthält ansonsten nichts Spannendes. Die Ausgabe könnte noch etwas aufregender gestylt werden, aber fürs erste geht es lediglich darum, diese wichtigen Informationen auch unerfahrenen Nutzern gezielt verfügbar zu machen.

Da die PHP-Konfiguration an den verschiedensten Stellen angepasst werden kann, können Einstellungen zum Errorlogging u.a. vom Ordner abhängen. Um Änderungen aus lokalen php.ini-Dateien zu erfassen und nicht nur die globalen Werte, solltet ihr die Datei am besten aus dem Ordner aufrufen, in dem sich euer fehlerhaftes PHP-Script befindet.

Hinweise

Dieses Script wird ohne jegliche Gewährleistung angeboten. Insbesondere kann ich nicht garantieren, dass das Script auf eurem System läuft und dass es keinen Fehler verursacht. Ich freue mich, wenn euch das Script weiterhilft, aber ich übernehme keine Verantwortung, falls es das nicht tut.

Aus Sicherheitsgründen solltet ihr das Script von eurem Webspace wieder löschen, wenn ihr die nötigen Infos gefunden habt.

Dieses Script ist nicht wirklich ein Meisterwerk, aber ich würde mich schon ärgern, wenn ich es unter fremdem Namen in irgendeiner Scriptsammlung wiederfinden würde. Deshalb: Ihr könnt damit im Prinzip machen, was ihr möchtet, aber lasst bitte die Namensnennung und den Link zu meiner Website drin.

Ich verwende eine kurze Methode, die den numerischen Errorlevel-Wert wieder in die entsprechenden Konstantennamen umwandelt. Die Methode wurde im PHP-Manual gepostet.

Kommentare

Ich freue mich über Kommentare zu diesem Script, insbesondere Hinweise zur Verbesserung.

Soweit nicht anders angegeben: © Johannes Ruthenberg. Lesen erwünscht, Zitieren erlaubt, Übernahme des kompletten Textes oder Einbinden des Feeds in andere Webseiten nicht gestattet! Für mehr Infos dazu siehe http://johannes-ruthenberg.de/infos.

Was Server betrifft werde ich mich hier übrigens auf den weitverbreiteten Apache beschränken, da ich mit IIS und anderen Servern noch nicht gearbeitet habe. Ich ergänze aber gerne relevante Infos zu anderen Servern.

Die Abschnitte des Artikels:

• PHP-Fehler
• Aktuelle Serverkonfiguration herausfinden
• Steuern des Loggings
• Die php.ini-Datei
• Logging direkt aus PHP heraus
• Fehlermeldungen verstehen
• Eigene Meldungen loggen
• Fazit
• Anmerkungen

PHP-Fehler

Wie in jeder Programmiersprache kann man in PHP Fehler erzeugen, durch falsche Übergabewerte oder direkte Fehler im Code. Diese Fehler können am Bildschirm angezeigt, in eine Datei geschrieben oder einfach ignoriert werden. Normalerweise wird empfohlen, in lokalen Testsystemen die Fehler am Bildschirm ausgeben zu lassen (in der HTML-Seite), im Produktiv-System auf dem Server aber in eine Datei schreiben zu lassen, im weiteren Errorlog genannt. Funktioniert dann das PHP-Script nicht erwartungsgemäß oder wird gar nur eine weiße Seite statt des erwarteten Outputs angezeigt, empfiehlt es sich immer, zuerst mal im Errorlog nach Fehlermeldungen zu schauen.

PHP unterscheidet sich in einer Hinsicht übrigens von vielen anderen Programmiersprachen: Da es nicht compiliert wird, fallen Fehler erst bei der Ausführung des Codes auf. Alle Fehler, die bei einem Java-Programm z.B. einen Compile-Fehler erzeugen würden, den man sofort sieht und beheben kann, können sich im PHP-Code lange verstecken und erst bei der Ausführung des Scriptes auffallen (wenn man Pech hat, fallen Sie dem Besucher und nicht dem Besitzer der Seite auf). Um so wichtiger ist es, die Fehlermeldungen zu sehen, um unnötiges Rätselraten zu vermeiden.

Und zum Thema ‚weiße Seite‘: Wenn bei der Abarbeitung eines Scriptes ein Fehler auftritt, wird das Script abgebrochen. Wenn kein übergeordnetes Script den Fehler fängt und loggt oder verwirft, wird die komplette Seitengenerierung an dieser Stelle unterbrochen. Das äußert sich zum Beispiel darin, dass plötzlich die Sidebar auf der Seite fehlt, wenn darin ein Fehler auftrat. Wenn der Fehler allerdings passiert, noch bevor HTML-Code für die Seite generiert wurde, bekommt man ggf. nur eine leere Seite vom Browser angezeigt. Dabei schickt der Server übrigens nicht zwangsläufig einen HTTP-Statuscode 500 (Interner Server-Fehler) zurück. Zumindest in meinen Tests gab es trotz des Fehlers einen 200er-Code (Status: OK).

Aktuelle Serverkonfiguration herausfinden

Ok, nehmen wir an, etwa funktioniert nicht wie erwartet. Wenn man sich nicht sicher ist, sollte man zuerst einmal herausfinden, wie der Server in Bezug auf den Umgang mit PHP-Fehlern eingestellt ist. Speichert folgenden kurzen Code als Datei „test.php“, ladet sie auf den Server und ruft sie auf:

<?php
  echo 'Und jetzt der Fehler: ';
  echo gibtsnicht();
?>

Das sollte eine Fehlermeldung wie diese ergeben:

PHP Fatal error: Call to undefined function  gibtsnicht() in xxx\test.php on line 2

Wenn euch die Meldung am Bildschirm angezeigt wird, ist euer Server so eingestellt, dass PHP-Fehler direkt ausgegeben werden. Das ist für ein lokales System ok, denn es erspart einem während der Entwicklung ständig eine Logdatei kontrollieren zu müssen. Auf einem Produktivsystem ist das jedoch eher unerwünscht: Fehlermeldungen können zum einen sensitive Informationen enthalten, die nicht jeder Besucher der Seite sehen soll. Zum anderen sehen sie natürlich unprofessionell aus und zerstören ggf. das Layout der Seite.

Wenn ihr nach dem Aufruf obiger Datei nur die erste Zeile ausgegeben bekommt („Und jetzt der Fehler: “), aber nicht die Fehlermeldung, schreibt euer Server die Meldung entweder in eine Logdatei oder ignoriert sie. Die Chancen sind gut, dass ihr nach dem Aufruf also eine Logdatei auf dem Server zu liegen habt.

Wo diese Datei zu finden ist und ob ihr darauf überhaupt zugreifen könnt, hängt stark von eurem Provider ab. Es könnte sich aber lohnen, einfach mal in den oberen Ebenen eures Webspaces zu schauen. Bei meinem Provider liegt die Datei z.B. unter „/kunden/xxxxx/logs/phperror.log“. Dieser Pfad ist aus dem Internet heraus nicht aufrufbar (die Webseiten liegen unter „/kunden/xxxxx/websites/“), aber per FTP oder WebDAV kommt man an die Datei heran.

Wenn ihr es genau wissen wollt, erstellt euch eine zweite Datei und speichert das folgende als „info.php“ ab:

<?php
  phpinfo();
?>

Diese Datei auf den Server laden und aufrufen. Es werden verschiedenste Informationen über die PHP-Installation ausgegeben. Die Einstellungen zum Logging sollten in der Tabelle unter der Überschrift „PHP Core“ zu finden sein. Die Namen der Direktiven sind die gleichen, die weiter unten im Detail erklärt sind, interessant sind dabei vor allem „error_log“, „display_errors“ und „log_errors“. Hinter „error_log“ steht der Pfad der Logdatei. Die Direktive „display_errors“ sollte auf „Off“ gestellt sein (=Anzeige von Fehlermeldungen am Bildschirm), „log_errors“ dagegen auf „On“ (=Fehlermeldungen in eine Datei schreiben). Ist „log_errors“ auf „Off“ gestellt, werden Fehler nicht in eine Datei geschrieben.

Ausschlaggebend ist hier übrigens der „Local Value“, falls sich „Local Value“ und „Master Value“ unterscheiden. Wenn euch beim Aufruf der info.php übrigens nichts angezeigt wird, dann ist in der PHP-Konfiguration dieser Befehl unterdrückt worden. Da könnt ihr dann erstmal auch nichts dran machen.

Steuern des Loggings

Wenn der Server nicht zufriedenstellend eingestellt ist, die Logdatei zum Beispiel nicht zu finden ist, sollte man sich etwas näher mit der Konfiguration des Errorloggings beschäftigen. Generell kann das an verschiedenen Stellen konfiguriert werden: In der php.ini-Datei, in .htaccess-Dateien, in der Apache-Konfiguration (httpd.conf) und sogar im PHP-Programm selber. Am üblichsten ist meines Wissens nach die Konfiguration in einer php.ini-Datei oder im PHP-Programm selbst. Auf .htaccess-Dateien und die Apache-Konfiguration gehe ich deswegen im folgenden nicht näher ein, auch mangels Erfahrungswerten. Bei den allermeisten Providern hat man diese Möglichkeit sowieso nur, wenn man sich einen komplett eigenen Server mietet. Ein paar Infos dazu gibt es aber im PHP-Manual: How to change configuration settings

Manche Anwendungen bringen eigene Error-Handler mit. Einstellungen dafür sind dann entweder direkt im Programm oder in Konfigurationsfiles dieses Programms zu tätigen. Eine grobe Übersicht, wie das funktionieren kann, bekommt man ebenfalls im PHP-Manual: Error Handling and Logging Functions. wenn dies der Fall ist, sollte das allerdings in der Dokumentation des PHP-Programmes ausreichend beschrieben sein. Für WordPress, welches mir den Anlass zu diesem Artikel gab, trifft das jedoch nicht zu, hier ist die in der Regel die php.ini ausschlaggebend.

Die php.ini-Datei ist eine Textdatei, welche Konfigurationseinstellungen für PHP enthält, u.a. auch für den Umgang mit PHP-Fehlern. Die einzelnen Einstellungsmöglichkeiten einer php.ini-Datei erkläre ich gleich noch. Zuerst muss man sie jedoch finden. Hier gibt es zwei Möglichkeiten: Es gibt eine globale Konfigurationsdatei, und wenn es erlaubt ist kann man diese lokal überschreiben.

Die globale php.ini-Datei liegt in der PHP-Installation, in manchen Systemen aber auch beim Apache-Server. Lokal unter XAMPP für Windows ist die php.ini z.B. unter „xampp/apache/bin“ zu finden. Die Datei im PHP-Pfad kann man ignorieren, sie wird nicht benutzt. Auf dem Server ist dies abhängig von der PHP-Installation und damit vom Provider. Wenn man nicht seinen eigenen Server hat, wird man an der globalen Datei normalerweise nichts verändern können. Je nach Provider sollten aber lokale php.ini-Dateien erlaubt sein.

Für andere Provider kann ich dazu nichts sagen, aber bei domainFACTORY ist es zum Beispiel so: php.ini-Dateien wirken in unteren Tarifen nur lokal im aktuellen Verzeichnis (siehe Anmerkung 1), man muss seine php.ini also in jedes Verzeichnis kopieren (ggf. per Script) welches PHP-Dateien enthält. In höheren Tarifen kann man die globale Datei aus dem Admin-Menü heraus bearbeiten. Mehr Infos gibt es in den FAQ.

Um herauszufinden, wo sich die php.ini-Datei befindet, schaut man sich am besten wieder den Output des phpinfo-Befehls an (die info.php von eben). Gleich in der ersten Tabelle sollte es einen Eintrag „Loaded Configuration File“ geben, dahinter steht der Pfad der geladenen php.ini-Datei. Ruft man dies aus einem Ordner mit einer lokalen Datei heraus auf, steht deren Pfad dort, ansonsten der Pfad der globalen Konfigurationsdatei. Wenn hier nur „php.ini“ ohne einen Pfad steht, hat PHP keine Datei gefunden und arbeitet mit Default-Einstellungen.

Bevor wir uns die php.ini-Datei im Detail anschauen, noch ein Hinweis: Wird die globale Datei geändert, muss der Apache-Server neugestartet werden. Änderungen in lokalen Dateien wirken sich dagegen sofort aus.

Die php.ini-Datei

Öffnet die Datei mit einem Texteditor eurer Wahl und sucht euch die Sektion „Error handling and logging“ heraus. Das Semikolon am Zeilenanfang kennzeichnet dabei übrigens einen Kommentar. Solchermaßen gekennzeichnete Zeilen haben also keine Auswirkung. Wenn ihr euch nicht sicher seid, macht vor Änderungen an der ini-Datei am besten eine Kopie.

Ok, die Anweisungen dieses Abschnitts im einzelnen. Im PHP-Manual gibt es auch eine Übersicht der php.ini-Direktiven, wo man zu einigen Direktiven weitere Infos bekommt. Aber im Prinzip sind alle Direktiven in der Datei schon recht ausführlich kommentiert.

; error_reporting is a bit-field.  Or each number up to get
; desired error reporting level
; 
; [...]
;
error_reporting = E_ALL & ~E_NOTICE

Hier wird eingestellt, was geloggt werden soll, also Meldungen welcher Stufe. Nicht jeder Fehler ist gleich wichtig, deshalb gibt es verschiedene Stufen: E_ERROR, E_WARNING, E_NOTICE und eine Reihe weiterer. Der Default-Wert ist „E_ALL & ~E_NOTICE“ (=alle Meldungen außer solchen der Stufe E_NOTICE). Das ist für den normalen Nutzer eine sinnvolle Einstellung. Wer auch Meldungen der Stufen E_Notice und E_Strict sehen möchte (das sind Hinweise, wenn PHP-Funktionen nicht ganz standardgemäß verwendet werden), stellt hier „E_ALL | E_STRICT“ ein. PHP ist normalerweise recht fehlertolerant, so dass kleinere Unregelmäßigkeiten nicht zwangsläufig zum Abbruch des Scriptes führen. Aber auf einem lokalen Testsystem können auch diese Meldungen interessant sein.

; Print out errors (as a part of the output).  For production
; web sites, you're strongly encouraged to turn this feature
; off, and use error logging instead (see below).  Keeping
; display_errors enabled on a production web site may reveal
; security information to end users, such as file paths on your
; Web server, your database schema or other information.
display_errors = On

; Even when display_errors is on, errors that occur during PHP's
; startup sequence are not displayed.  It's strongly recommended
; to keep display_startup_errors off, except for when debugging.
display_startup_errors = Off

; Log errors into a log file (server-specific log, stderr, or
; error_log (below)). As stated above, you're strongly advised to
; use error logging in place of error displaying on production web
; sites.
log_errors = Off

Dies drei Einstellungen betreffen die Frage, ob und wie geloggt werden soll. Obige Werte sind die Standardeinstellungen von XAMPP und bedeuten: Fehler werden auf dem Bildschirm (im Browser) ausgegeben, Startfehler werden nicht ausgegeben und es werden keine Fehler in eine Datei geschrieben. Diese Einstellungen sind in Ordnung für das lokale Arbeiten mit einer Testinstanz: Passiert ein Fehler, wird er einfach im Browser ausgegeben. Für den Einsatz auf dem Server sind diese Einstellungen wie oben schon erläutert nicht geeignet: Hier sollten Fehler mittels Off/Off/On immer in eine Textdatei geschrieben und nicht im Browser ausgegeben werden!

; Set maximum length of log_errors. In error_log information about
; the source is added. The default is 1024 and 0 allows to not
; apply any maximum length at all.
log_errors_max_len = 1024

; Do not log repeated messages. Repeated errors must occur in same
; file on same line until ignore_repeated_source is set true.
ignore_repeated_errors = Off

; Ignore source of message when ignoring repeated messages. When
; this setting is On you will not log errors with repeated messages
; from different files or sourcelines.
ignore_repeated_source = Off

; If this parameter is set to Off, then memory leaks will not be shown
; (on stdout or in the log). This has only effect in a debug compile,
; and if error reporting includes E_WARNING in the allowed list
report_memleaks = On

; Store the last error/warning message in $php_errormsg (boolean).
track_errors = Off

Diese Einstellungen regeln verschiedene Dinge, man muss sie im Normalfall nicht anpassen. Die maximale Länge einzelner Meldungen sowie das Loggen sich wiederholender Meldungen haben vor allem Einfluss auf die Lesbarkeit des Logfiles in Extremfällen (z.B. wenn der gleiche Fehler alle paar Sekunden auftritt).

Diese Einstellungen regeln die Ausgabe von Fehlermeldungen auf dem Bildschirm. Hat man dies bei „display_errors“ ausgestellt, kann man sie wie hier gezeigt einfach auskommentiert lassen. Auf seiner lokalen Testinstanz kann man damit erreichen, dass z.B. Fehlermeldungen zur entsprechenden Seite des PHP-Manuals verlinken etc. Im Normalfall kann man sie jedoch ignorieren.

; Log errors to specified file.
;error_log = "\xampp\apache\logs\phperror.log"

; Log errors to syslog (Event Log on NT, not valid in Windows 95).
;error_log = syslog

Und hier die wichtige Einstellung, wohin geloggt werden soll. Das wirkt sich natürlich nur aus, wenn oben „log_errors“ auf „On“ gestellt wurde. Dann kann man hier den Pfad zu einer Datei eintragen oder eben mit „syslog“ die Meldungen ins Systemlog schreiben lassen (was eher nicht so gut ist). Achtung: Beide Anweisungen stellen natürlich das gleiche dar und beide sind auskommentiert. Einfach bei einer davon das Semikolon entfernen und dann den Wert entsprechend anpassen, z.B. zu „C:\xampp\apache\logs\phperror.log“. Ihr könnt euch das Logfile aber auch dorthin legen, wo ihr es einfacher und ohne viel Geklicke wiederfindet, z.B. „D:\webapps\phperror.log“. Auf dem Server sollte hier ein Pfad eingetragen sein, der oberhalb eurer Webroots liegt, also aus dem Internet heraus nicht aufrufbar ist, z.B. „/kunden/xxxxx/logs/phperror.log“ (wenn eure Webseiten unter „/kunden/xxxxx/websites/“ liegen).

Wenn das Logging in eine Datei eingeschaltet, aber keine Datei definiert ist, landen die Meldungen übrigens mit einiger Wahrscheinlichkeit im Apache-Errorlog. Je nach eurer Serverkonfiguration findet ihr sie also vielleicht auch dort wieder. Da die Meldungen nicht ganz dem Apache-Format entsprechen, kann es Probleme geben, wenn ihr das Apachelog mit einem Tool auswerten wollt. Die PHP-Meldungen sind also besser in einer eigenen Datei aufgehoben, allein schon der Übersichtlichkeit wegen.

Logging direkt aus PHP heraus

Wenn eurer Provider euch die Steuerung per php.ini nicht erlaubt, könnt ihr es direkt mit PHP-Befehlen probieren. Dies müsstet ihr möglichst am Anfang aller Seiten einbinden, z.B. in eine gemeinsame Header-Datei. Mittels des Befehls ini_set könnt ihr Einstellungen für den Aufruf des aktuellen Scripts anpassen, z.B. so:

error_reporting(E_ALL);
ini_set('display_errors', 'Off');
ini_set('error_log', '/kunden/xxxxx/logs/phperror.log');

Die Namen der Direktiven entsprechen dabei wieder den eben diskutierten Einstellungen. Im Prinzip überschreibt ihr damit für die Dauer des aktuell ausgeführten Skriptes den Wert der Einstellung, der in der php.ini-Datei definiert ist.

Fehlermeldungen verstehen

Glückwunsch, euer System ist nun gemäß euren Wünschen eingestellt, was das Loggen von PHP-Fehlern betrifft. Und nun? Die geloggten Fehler zu verstehen, ist natürlich noch mal eine andere Sache, da die Meldungen generell Englisch und eher technisch gehalten sind. Aber das Loggen der genauen Fehlermeldung ist schon mal der halbe Schritt: Mit der Fehlermeldung könnt ihr z.B. per Google weitere Infos finden. Und wenn ihr in Foren um Hilfe bittet, erhöht es eure Chancen auf eine hilfreiche Antwort ungemein, die Fehlermeldung zu posten (dabei eventuelle sensitive Infos wie z.B. Passwörter natürlich maskieren).

Eigene Meldungen loggen

Wenn euer Logging an sich richtig eingestellt ist, könnt ihr auch beliebige Meldungen loggen. Es passiert kein Fehler, aber trotzdem funktioniert ein Programm nicht so wie es soll? Dann könnt ihr Variablen-Werte oder eigene Meldungen mittels der PHP-Funktion error_log ins Errorlog ausgeben. Das ist eine sehr simple Form des Debuggings. Wenn es haariger wird oder ihr höhere Ansprüche habt, dann gibt es da auch noch wesentlich mächtigere Debugging-Werkzeuge. Aber für einfache Fälle reicht error_log aus.

Die Beschreibung der Funktion aus dem PHP-Manual:

bool error_log(string $message[, int $message_type[, string $destination[, string $extra_headers]]]);

Auf jeden Fall mitgeben müsst ihr der Funktion die Meldung, die geloggt werden soll. Mit den optionalen Parametern kann das Verhalten der Funktion noch weiter gesteuert werden, aber normalerweise reicht ein Aufruf wie error_log('Wert der Variablen: ' . $variable); um mal schnell den Wert einer Variable zu bekommen oder zu schauen, ob eine if-Bedingung true ist etc.

Fazit

Ich hoffe, der Artikel hat euch an das Thema PHP-Errorlog etwas herangeführt und ich habe alle Zusammenhänge hier korrekt und verständlich dargestellt. Sorry wenn es etwas zu ausführlich geworden ist.

Anmerkungen

Anmerkung 1: Können lokale php.ini-Dateien auch für untergeordnete Verzeichnis gelten, ähnlich wie das bei .htaccess-Dateien der Fall ist? Kann ich also in den Ordner „A“ eine lokale php.ini-Datei legen und diese gilt auch für PHP-Scripte im Unterordner „A/B“? Bei meinem Provider ist das nicht so, aber es könnte generell natürlich sein, dass es geht und hier nur per Konfiguration verboten ist. Das kann ich leider im Moment nicht sagen, würde den Artikel aber gerne mit Erfahrungswerten anderer entsprechend anpassen.

Anmerkung 2: Nicht vergessen, die Testdateien test.php und info.php ggf. wieder vom Server zu löschen!

Soweit nicht anders angegeben: © Johannes Ruthenberg. Lesen erwünscht, Zitieren erlaubt, Übernahme des kompletten Textes oder Einbinden des Feeds in andere Webseiten nicht gestattet! Für mehr Infos dazu siehe http://johannes-ruthenberg.de/infos.

Wieso Norton?

Ich nutze Norton AntiVirus schon seit vielen Jahren und hatte damit nie Probleme. Obwohl es in Tests meist relativ schlecht abschneidet, was die Zeit bis zur Bereitstellung einer neuen Virussignatur betrifft, fühle ich mich bei Norton AntiVirus gut aufgehoben. Ist vielleicht auch einfach das über die Jahre aufgebaute Vertrauen, denn ich hatte in all der Zeit nur zwei ernsthafte Viren auf dem Rechner: Einen, weil ich bei der Neuinstallation des Rechners NAV nicht als erstes Programm installiert hatte (note to self: CDs von Kumpels immer zuerst scannen *g*), und der andere war so ein ganz fieser Geselle, der über einen Port auf meinen Rechner kam und damals allgemein viel Wirbel verursachte (deswegen sag ich auch immer, die einzig wirklich gefährlichen Viren sind die, die es bis in die Tagesschau schaffen *g*).

Ein Grund, warum ich nicht auf freie Virenscanner umsteige, ist übrigens, dass NAV ein- und ausgehende E-Mails überprüft, was mir wichtig ist. Mein Provider filtert seit neuestem zwar ebenfalls Virenmails, was ganz gut klappt, aber trotzdem kommt hin und wieder was durch. Und ehe man sich doch mal verklickt…

Update fällig

Ich habe bisher NAV 2003 benutzt und da mehrmals das Update-Abonnement erneuert. Diese ältere Version von NAV hatte zudem ein echt cooles Feature: Das Programm hatte ein Jahres-Abo der Updates fest eingebaut, ohne eine ID oder so, die bei Symantec registriert wäre. Wenn man also den Rechner neu aufsetzt und dafür die Systempartition formatiert, gewährt einem NAV automatisch ein neues Jahresabo. Ich bin normalerweise ein ehrlicher Kunde und habe kein Problem damit, für diese Abos zu bezahlen. Aber wenn das Programm es einem quasi schenkt, streite ich mich da natürlich auch nicht mit Symantec…

Anyway, da die Abo-Verlängerung fast so viel kostet wie ein neues Programm, habe ich mich dieses Jahr für eine Aktualisierung auf die neueste Version 2007 entschlossen. Die gab es bei computeruniverse.net zudem zum unschlagbar günstigen Preis von um die 19 Euro.

Allgemeiner Eindruck

Wirklich viel an Funktionsumfang ist verglichen zur 2003-Version nicht dazu gekommen, muss aber ja auch nicht. NAV blockiert jetzt auch Verbindungsversuche aus dem Internet („Internet Worm Protection“) und es gibt das „Protection Center“, welches den aktuellen Schutzstatus übersichtlich auflistet. Positiv fällt die etwas verspielte, aber gut durchgezogene Gestaltung des Programms auf: Keine langweiligen Standard-Windows-Fenster, sondern alles im Symantec-Stil auf gelb und abgerundet getrimmt. Das hat schon was.

Geschwindigkeitseinbußen, von denen man in Reviews manchmal liest, kann ich bei mir nicht feststellen. Das ist aber vermutlich sowieso eine sehr individuelle Sache.

Einstellungen ändern

Zu allererst: Einstellungen können nur mit Administrator-Rechten geändert werden. Wenn ihr also normalerweise mit eingeschränkten Rechten unter Windows arbeitet, müsst ihr euch als Admin anmelden, sonst zeigt das Programm einfach keine Links zu den Optionen an.

Es gibt zwei verschiedene Sets von Einstellungen. Die Optionen für das Protection Center finden sich im entsprechenden Tab ganz oben in relativ winziger Schrift verlinkt. Dort kann man einstellen, ob das Protection Center in der Taskleiste auftauchen soll, ob Meldungen vom Windows-Sicherheitscenter ausgegeben werden sollen und ob gewarnt werden soll, wenn man die Windows-Updates nicht auf „automatisch installieren“ stehen hat. Das war’s dort auch schon wieder.

Die eigentlichen Programm-Einstellungen sind auf dem „Norton AntiVirus“-Tab platziert. Dort gibt es den Punkt „Einstellungen“. Draufklicken zum Ausklappen und dann auf irgendeinen der Einträge klicken. Es wird ein Fenster mit den Buttons „Ausschalten“ und „Konfigurieren“ eingeblendet, hier „Konfigurieren“ wählen. Damit oder mit einem Klick auf „Viren- und Spyware-Schutzoptionen“ kommt man zu einem kleinen Fenster mit vielfältigen Programmeinstellungen. Hat man nur eingeschränkte Nutzerrechte, sieht man hier statt dessen übrigens nur eine kurze Beschreibung des jeweiligen Features.

Ausschalten des gelben Buttons in der Taskleiste

Nach der Installation taucht in der Taskleiste, ganz rechts neben dem System Tray, ein fetter gelber Button auf, der den aktuellen „System-Schutzstatus“ ausgibt. Der Button erfüllt praktisch keine sinnvolle Funktion, ist aber sehr auffällig und nimmt wertvollen Platz in der Taskleiste ein. Man kann diesen Button allerdings ausblenden – die Optionen dafür sind nur so versteckt, dass ich erst beim Support nachfragen musste, um sie zu finden. Ist aber eigentlich ganz einfach: Geht im NAV2007-Fenster auf das „Norton Protection Center“-Tab und dort in der obersten Zeile auf den winzigen, blauen Link „Optionen“. Dort gibt es dann eine Checkbox „Schutz-Status in Windows-Taskleiste anzeigen“. Häkchen entfernen, OK und der Button ist weg.

Allerdings taucht der Schutz-Status jetzt als Icon im System Tray auf, wo es ja schon das normale NAV-Icon gibt. Hier am besten einfach das normale NAV-Icon abschalten, da beide Icons eh zum gleichen Programm führen. Und Problem Nummer drei: Die allgemeinen NAV-Optionen gelten für alle User, aus irgendeinem bescheuerten Grund gelten die Protection-Center-Optionen aber für jeden User getrennt – und man kann sie nur als Administrator ändern. Durch Zufall habe ich herausgefunden, dass die Optionen zwar ausgeblendet sind, man an diese Funktion aber auch anders herankommt – der Symantec-Support scheint davon jedoch nichts zu wissen. Und zwar bekommt man mit einem Rechtsklick auf den Button bzw. das Tray-Icon ein Kontextmenü mit dem Eintrag „Schutz-Status in Task-Leiste anzeigen“. Damit kann man zwischen der Anzeige in der Task-Leiste und im System-Tray umschalten.

Warnungen der Internet Worm Protection

Ein Problem, für das ich keine echte Lösung gefunden habe, sind die ständigen Warnungen der Internet Worm Protection. Hier gab es bei anderen Kabel-Deutschland-Kunden offensichtlich infizierte Rechner, die ständig Sicherheitslücken auszunutzen versuchten. NAV erkennt das und blockiert die Zugriffsversuche, was soweit ja schön ist. Es blendet dann allerdings jedes Mal ein kleines Hinweisfenster ein, dass es eben einen Angriff blockiert hat, was im Minutentakt etwas nervt. Da fehlen leider jegliche Optionen, diese Nachrichten irgendwie einzuschränken.

Man kann dann, wenn das wie bei mir alle paar Minuten auftritt, eigentlich nur dafür sorgen, dass NAV damit nichts mehr zu tun hat. Ein vorgeschalteter Hardware-Router (z.B. WLAN-Modem) kann diese Anfragen gleich abfangen, dann hat man wieder seine Ruhe vor den PopUps. Oder man nutzt eine besser konfigurierbare Personal Firewall und schaltet das Worm-Protection-Feature in NAV einfach ab. Schade ist es aber schon, dass ein eigentlich nützliches Feature durch das Fehlen einiger simpler Optionen halbwegs unverwendbar wird.

Support

Die deutsche Website von Symantec hat mich ziemlich verärgert: Wenn einem die angeboten FAQ nicht ausreichen, wird man von verschiedensten Stellen auf eine Seite geleitet, die einen zum Auswählen einer „der folgenden Kontakt-Optionen“ auffordert, aber gar keine Optionen anbietet. Eine Sackgasse, ganz einfach.

Da hilft nur ein Besuch der englischen Seite, in dem man einfach in der URL „de“ ersetzt durch „en“. Der E-Mail-Support war dort dann auch Klasse: Innerhalb einer Stunde hatte ich eine Antwort in meinem Postfach, und sogar eine, die sich tatsächlich um das Problem gekümmert und eine hilfreiche Lösung angeboten hat. Im weiteren Verlauf zeigte sich leider, dass das Wissen über das Programm im Support-Center nicht sonderlich in die Tiefe reicht (siehe oben).

Soweit nicht anders angegeben: © Johannes Ruthenberg. Lesen erwünscht, Zitieren erlaubt, Übernahme des kompletten Textes oder Einbinden des Feeds in andere Webseiten nicht gestattet! Für mehr Infos dazu siehe http://johannes-ruthenberg.de/infos.

Modifizieren des WP-Kerns

Davon möchte ich explizit abraten. Natürlich ist WordPress letztlich auch nur eine Sammlung von PHP-Dateien, da steckt keine größere Magie dahinter. Aber so verlockend es vielleicht auch sein mag, einfach mal schnell was in Core-Dateien von WordPress anzupassen, das ist keine gute Idee. Das System wird nämlich aktiv weiterentwickelt und es gibt relativ häufig neue Releases, die man sich aus Sicherheitsgründen zumindest ab und an einspielen sollte. Und dann hat man den Ärger, die eigenen Modifikationen über das Update zu retten. Genau dafür gibt es Plugins, und zur Not schreibt man einfach selber eins.

Themes

Die einfachste Art, WordPress zu modifizieren, ist natürlich die Installation eines anderen Themes. Wahlweise kann man sich auch eines selber schreiben oder ein frei verfügbares anpassen. Zur Entstehung des Themes dieser Seite hatte ich ja schon ein bisschen was geschrieben. Neben dem Wunsch, ein „eigenes“ Design zu haben, wollte ich auch die einzelnen Seitenelemente etwas umsortieren. Ganz klassisch ist für Blogs ja ein zweispaltiges Layout mit einer festen Weite und der Sidebar auf der rechten Seite. Da ich aber doch eher die Webseiten des letzten Jahrtausends gewöhnt bin *g*, habe ich die Erscheinung des Themes optisch mehr einer normalen Website angepasst: Das Layout ist dreispaltig und hat keine feste Weite und der Kalender ist ausgeblendet. Als hauptsächliches Mittel der Navigation sind die Monatsarchive und die Tag-Wolke gedacht.

Plugins

Zu den von mir verwendeten Plugins hatte ich ebenfalls schon etwas geschrieben. Generell gibt es zu fast jedem Problem ein WP-Plugin als Lösung. Unterscheiden kann man dabei Plugins, welche sich auf die eigentliche Seite auswirken, und solche, die nur den Admin-Bereich ändern. Viele Plugins ergänzen übrigens unter „Einstellungen“ eine Optionen-Seite, auf der man sie konfigurieren kann.

Wer mit dem graphischen Editor TinyMCE arbeitet, hat mit dem Plugin TinyMCE Advanced die Möglichkeit, im Editor die Buttons einzublenden, die man tatsächlich braucht und andere auszublenden. Wer, was zu empfehlen ist, nur die Code-Ansicht nutzt, sollte sich mal das Plugin AddQuicktag anschauen, mit dem man weitere Quicktags zum Editor hinzufügen kann und sich so quasi beliebige HTML-Schnipsel zum Einfügen in den Beitrag bereithalten kann.

Ebenfalls wichtig: Das Flexible Upload-Plugin. Standardmäßig fehlen der WP-Upload-Funktion viele Features. So legt sie z.B. immer ein Thumbnail an, ob man eines braucht oder nicht. Die Größe des Thumbnails kann man dabei nicht bestimmen. Ebenfalls nervig: Wenn man ein hochgeladenes Bild zum Editor sendet, werden keine width- und height-Attribute eingefügt. Dieses Plugin ändert das alles, und zwar auf eine Weise, die sich möglichst unauffällig in WordPress einfügt.

Permalinks und Blog-Adresse

WordPress selbst bietet unter „Einstellungen“ einiges an Möglichkeiten, Erscheinung und Verhalten des Blogs zu ändern. Das meiste davon ist selbst erklärend, aber auf ein paar Punkte möchte ich näher eingehen. Zum einen die Permalinks: Hier sollte man sich für ein Format entscheiden und sich das vorher gut überlegen. Da ein Permalink ja eben permant sein soll, macht es sich nicht so gut, an diesen Einstellungen jede Woche etwas zu ändern. Ich habe mich für diese Seite entschieden, die Permalinks lediglich auf Post- und Seitentiteln aufzubauen. Damit kann man schön kurze URLs bauen, und die Chancen sind damit auch ganz gut, dass man eine Seite mal direkt anspringen kann, solange man sich an den Titel erinnert.

WordPress-Adresse vs. Blog-Adresse: Aus rein organisatorischen Gründen macht es sich gut, WordPress auf dem Server in ein Unterverzeichnis zu installieren, z.B. „/blog“. Sonst hat man nach einiger Zeit lauter andere Sachen in der WordPress-Installation liegen, die man nur mal schnell unter der Domain online stellen will, die mit WP aber gar nichts zu tun haben. Andererseits hat man dann in der URL seiner Seite immer diesen Ordnernamen stehen. Dieses Problem lässt sich erstaunlich einfach lösen, bei WordPress Deutschland ist das detailliert beschrieben. Die ganz kurze Fassung: Das Feld „WordPress-Adresse (URL)“ auf das Unterverzeichnis zeigen lassen, die Dateien dorthin verschieben, index.php und .htaccess ins Hauptverzeichnis der Domain zurück kopieren, die require-Anweisung in der neuen index.php anpassen und dann im Adminbereich auf „Permalink-Struktur aktualisieren“ klicken.

WordPress mit Firefox nutzen

Wer hauptsächlich mit Firefox arbeitet, sollte noch eine Modifikation an seiner user.js vornehmen, damit Ausschneiden, Kopieren und Einfügen im TinyMCE wie gewohnt funktionieren. Standardmäßig sind die nämlich aus Sicherheitsgründen deaktiviert. Mehr Infos gibt’s bei mozilla.org.

Soweit nicht anders angegeben: © Johannes Ruthenberg. Lesen erwünscht, Zitieren erlaubt, Übernahme des kompletten Textes oder Einbinden des Feeds in andere Webseiten nicht gestattet! Für mehr Infos dazu siehe http://johannes-ruthenberg.de/infos.