ScriptBlogger

Bei einem Kundenprojekt empfängt und verarbeitet die Anwendung E-Mails mit Hilfe der IMAP-Funktionen von PHP. Dabei wird auch der Zeichensatz ausgelesen und die E-Mail bei Bedarf konvertiert. Der Konverter hat nicht besonders viel zu tun, da die Anwendung iso-8859-1 nutzt und die meisten E-Mails ebenfalls in iso-8859-1 oder ähnlichem daherkommen.

Kürzlich gab es Probleme mit utf-8-kodierten E-Mails, die jedoch nicht als solche erkannt wurden. Stattdessen behauptete imap_fetchstructure() steif und fest, die E-Mail wäre US-ASCII. Allerdings nur auf dem live Linux-Server. Auf unserem lokalen Server (Windows) wurden die E-Mails korrekt als utf-8-kodiert erkannt.

In den Kommentaren zu imap_fetchstructure() lässt sich ein Hinwis dazu finden:

If you are getting CHARSET as US-ASCII even if the header has a Content-Type: field, make sure the header also has a MIME-Version: field.

For example, the following header will correcty report charset as KOI8-R

MIME-Version: 1.0
Content-Type: text/plain; charset="koi8-r"

Without the MIME-Version it will be reported as US-ASII

Und tatsächlich. Folgendes Script hat den Beweis erbracht.

$headers  = "MIME-Version: 1.0\n";
$headers .= "Content-Type: text/plain; charset=\"utf-8\"";

mail('info@example.com', 'Subject', 'Text', $headers);

Mit der Kopfzeile MIME-Version: 1.0 in der E-Mail hat der Server den Zeichensatz korrekt als utf-8 erkannt. Ohne die Zeile nicht.

Nachdem bei der letzten Umfrage unter unseren Besucher herauskam, dass PHP die beliebteste Programmiersprache ist wo gibt, gab's in den letzten Wochen folgendes zu entscheiden:

Welches ist, Ihrer Meinung nach, das beste Weblog-Script?

1.170 Leute konnten sich nicht zurückhalten und haben für das eine oder andere Weblog-System gestimmt. Gewonnen hat "Keine Ahnung" (18%) gefolgt von Wordpress (10%) b2evolution (9%) und DotClear (4,7%). Am Ende der Rangliste streiten sich Serendipity und Wheatblog mit jeweils 2,22% um die rote Laterne.

Keine Ahnung		213	18,21 %
Wordpress		121	10,34 %
b2evolution		110	9,40 %
DotClear		55	4,70 %
Other		53	4,53 %
LifeType		53	4,53 %
Geeklog Details		52	4,44 %
Battle Blog		51	4,36 %
PSG		51	4,36 %
FlatPress		50	4,27 %
Forest Blog		48	4,10 %
Jlog		47	4,02 %
ExpressionEngine		43	3,68 %
Pivot Details		39	3,33 %
Loudblog		36	3,08 %
LightPress		34	2,91 %
Movable Type		32	2,74 %
dasBlog		30	2,56 %
Serendipity		26	2,22 %
Wheatblog		26	2,22 %

Wie immer an dieser Stelle der Hinweis: Diese Abstimmung wurde auf den Demo-Seiten für unser Voting-Script durchgeführt und setzt sich aus diesen beiden Datenquellen zusammen. Damit ist die Umfrage als repräsentativ zu betrachten und Mess-, Rechen- oder Rundungsfehler können ausgeschlossen werden. :-)

Auf IncognitoMail setzen wir unser Wegwerf-E-Mail-Script ein - als Ausstellungsraum sozusagen. Wir würden IncognitoMail als ganz nützlich bezeichnen. Funktional. Mehr allerdings auch nicht.

Letztens sind wir über eine Pressemeldung einer unserer Kunden gestolpert. Die Überschrift lautete wie folgt (Domain geändert):

Example.com is Helping to Stop Email Spam – and Offering a Chance to Win a Pair of Mp3 Players

Soweit so unspektakulär.

Allerdings bezeichnete man sich im Verlauf der Pressemeldung ganz selbstbewusst als "... the Internet’s Premier Spam Fighting, Free Temporary Email Service ..." und "... the web’s most versatile Spam Stopping Disposable Email Address Service ...".

Dass unser Script gut ist, wussten wir ja. Aber, dass es so gut ist... ;-)

Wenn Scripte zu Spam-Schleudern werden, ist das alles andere als lustig. Ab und zu kommen Anfragen, ob diese Gefahr bei unseren Scripten besteht. Kürzlich kam ein konkreter Hinweis, dass angeblich zwei unserer Scripte Spam versenden. Das Abstimmungs-Script und das Kommentar-Script.

Zum Glück ist das beim Voting Script gänzlich unmöglich - es fehlt schlicht eine Mail-Funktion. Beim Comment Script gibt es für den Admin die Möglichkeit, sich über neue Kommentare per E-Mail informieren zu lassen. Da allerdings Daten aus dem Formular ausschließlich im Body der E-Mail landen, dürfte es für einen Angreifer nur schwer möglich sein, weitere Empfänger in den Header der E-Mail zu schleusen.

Der Nutzer hatte den Header der Spam-E-Mail im Forum veröffentlicht und darin lies sich folgende Zeile finden:

X-PHP-Script: example.com/example/general.php

Spätestens hier war Entwarnung angesagt. In keinem der beiden Scripte ist eine Datei namens general.php enthalten. :-P

Um Dateien zum Server hochzuladen, bietet sich Zend_File_Transfer_Adapter_Http an. Hier ein Code-Beispiel aus dem Manual.

$adapter = new Zend_File_Transfer_Adapter_Http();
$adapter->setDestination('/beispiel/pfad');
if (!$adapter->receive()) {
    $messages = $adapter->getMessages();
    echo implode("\n", $messages);
}

Erstes Problem: Aus einem unerfindlichen Grund nahm der Validator an, dass die Datei nicht hochgeladen wurde und eine "Attacke" vorliegen müsse.

Da das definitiv nicht der Fall war und ich erst einmal weiter machen wollte, habe ich den Validator kurzerhand abgeschaltet. Hinweis: Machen Sie das zu Hause bitte nicht nach. ;-)

$adapter->clearValidators();

Das hat zwar die Fehlermeldung verschwinden lassen, aber die Datei kam trotzdem nicht an, wo sie sollte. Vielleicht hilft ja die Aktualisierung auf Version 1.7 (von 1.6.2).

Mitnichten. Nun gab's eine Fehlermeldung dass ein Array-Index nicht existierte. Ein Bug, und laut ZF Bug-Tracker im SVN gefixt. OK, schnell mal (10 min, 60 MB) den aktuellen Trunk ausgecheckt. Und wer hätte es gedacht, nun funktioniert's.

In den letzten beiden Tagen - wie oft nach dem Wochenende - war wieder einiges los im Support. Die Arbeit hat sich aber auf jeden Fall gelohnt.

Add me to your list of satisfied customers, Can't wait to try out your other scripts.

:-)

Da viele Webhoster noch nicht auf PHP 5 umgestellt haben und es auch nicht danach aussieht, dass sich dass demnächst ändert, haben wir den Schedule Organizer in der aktuellen Version wieder kompatibel mit PHP 4 gemacht. Das kam leider zu spät für eine Kunden, die schon seit einer Weile versucht hat, ihren Webspace auf PHP 5 aktualisieren zu lassen.

Zwischenzeitlich hatte nämlich die Hosting-Firma reagiert und mehr oder weniger (eigentlich nur weniger) elegant das Update auf PHP 5 mit Hilfe einer Sub-Domain bewerkstelligt.

Vorteil für den Hoster: Er kann den Rest des Servers im PHP-4-Winterschlaf belassen. Nachteil für die Kundin: Irgendjemand muss das Script vom bisherigen Verzeichnis in das neue Verzeichnis kopieren. Haben wir dann gemacht. Ergebnis waren kaputte Link- und Bildpfade, was wiederum weitere Anpassungen erforderte.

Wer glaubt, dass dies das Ende war, sieht sich getäuscht. Der Hoster hat gleich nochmal zugelangt und berechnet der Kundin jetzt 5 US-Dollar monatlich extra für den FTP-Zugang zum Verzeichnis, auf das die Sub-Domain geschaltet wurde.

Und einen letzten Hinweis hat der Hoster noch gegeben. PHP 5 funktioniert nur, wenn die Dateien über das neue FTP-Konto auf den Server geladen werden. Dateien, die mit dem alten FTP-Konto hochgeladen werden, werden stattdessen nur mit PHP 4 geparst.

Ah ja. Wäre nur interessant zu wissen, wie das funktionieren soll. Zudem ist der Hinweis überflüssig. Das alte FTP-Konto hat gar keinen Zugriff auf das neue Sub-Domain-Verzeichnis, wie unsere Tests gezeigt haben. Zugriff verweigert. :-O

Was wäre das Leben des Webmasters ohne den Google PageRank?

Es gäbe keine endlosen Diskussionen in Foren in denen Mythen gepflegt, Halbwahrheiten verdreht und der Algorithmus nicht verstanden werden.

Fehlen würden auch die zahllosen Artikel auf diversen Websites zum Thema Suchmaschinen und Website-Promotion. Wäre eigentlich gar nicht so schlimm, denn die kauen auch nur die Mythen und Halbwahrheiten wieder.

Google findet über einhundert Millionen Stellen mit dem Wort "Pagerank". "Usability" hingegen findet nur knapp 25 Millionen Stellen. Der eigentliche Website-Nutzer hat offensichtlich nur nachrangige Bedeutung.

Der PageRank ist nicht nur eine Handvoll grüner Pixel, sondern vereint gleich mehrere Funktionen in sich.

Der PageRank ist eine Währung. Da wird gehandelt und geschachert. "Gib mir einen PR4-Link und ich gebe dir zwei 2er." Nach diesem Schema.

Und natürlich nutzt jeder den PageRank, um den Wert einer Website zu bestimmen. Zum Beispiel beim Kauf oder Verkauf einer Website oder beim Bestimmen von Preisen für Link-Anzeigen. Neuerdings geben das allerdings immer weniger zu. Man habe sich angeblich vom Joch des PageRanks befreit und lebe nun viel ruhiger, weil man nicht mehr auf ihn achte.

Für viele Website-Betreiber scheint der PageRank trotzdem noch eine Droge zu sein. Sie sind dem kleinen grünen Balken verfallen und leiden unter Entzugserscheinungen, wenn der Balken abnimmt oder gar weiß oder grau wird. Manche Foren sind wie riesige Gruppentherapien, in der sich gegenseitig Mut gemacht wird. Und Schuld sind ja sowieso immer andere (Google selbst, Bad Neighbourhood, Werbe-Link-Netzwerke).

Wenn man es allerdings genau betrachtet, ist der PageRank nichts anderes als eine ansteckende Krankheit. Wie ein Virus infiziert es miteinander verlinkte Websites. Bis am Ende jede Seite mit Scida Viridis diagnostiziert wird. Wie grüner Herpes, der nie wieder weggeht.

Zugegeben: Wenn der PageRank nicht bereits existierte, man müsste ihn erfinden. Womit würden sich die Scharen an Website-Betreiber und Suchmaschinenoptimierer und Link-Tauscher und Link-Käufer und Link-Verkäufer sonst beschäftigen?

Und für Google hat's sich auf jeden Fall gelohnt.

Es gibt englische Wörter, für die gibt es einfach keine sinnvolle deutsche Entsprechung. Wie "Link" zum Beispiel Man könnte Verknüpfung oder Verweis schreiben, aber Link ist weniger sperrig und versteht auch jeder.

Allerdings sollte man es sich nicht zu einfach machen und eventuell doch mal ein Wörterbuch bemühen. Dann ist es gar nicht so schwierig, eine Anwendung oder Website komplett in deutsch zu beschriften. Linklift zum Beispiel macht das ziemlich gut und bedient sich durchweg deutscher Wörter bis hin zu Skript (mit k statt mit c).

Leider erlaubt sich Linklift dann aber doch einen stattlichen Aussetzer.

Bevor ein Werbe-Link auf der eigenen Website erscheint, muss dieser vom Betreiber freigeschaltet werden. Statt aber prüfen, bestätigen, akzeptieren, annehmen oder freischalten zu schreiben, heißt es in der URL, der Überschrift und auch in einer Link-Grafik: Anzeige approven.

Liest sich merkwürdig und klingt komisch. Sagt auch sonst kein Mensch. Witzigerweise steht in der Benachrichtigungs-E-Mail dann wiederum folgendes:

Sie haben nun die Möglichkeit, die Anfrage unter https://www.linklift.de/anzeigen-approven/ innerhalb von einem Werktag zu prüfen und entweder zu bestätigen oder abzulehnen.

Geht doch, wenn man nur will. ;-)

Ein Kunde unseres News Scripts schrieb, dass beim Aufruf des Scripts im Browser nichts angezeigt würde.

Eine kurze Recherche zeigte dann auch etwas ungewöhnliches. Normalerweise erstellt die Smarty-Template-Engine die vorkompilierten Scripte mit Dateinamen wie diesem:

%%83^83B^83B7EFCA%%layout.tpl.html.php

Beim Kunden sahen die aber so aus:

wrt490a1737906fe

Kein Wunder also, dass nichts ausgegeben wird, wenn die Template-Dateien nicht gefunden werden. Haben wir dem Kunden auch ausführlich so erklärt und empfohlen, sich an den Webspace-Provider zu wenden.

Darauf kam dann folgendes:

Do you have any idea's on where the problem is coming from?

Hm. Wir dachten eigentlich, es wäre offensichtlich, dass der Server da seine Finger zwischen hat. Hätten wir vielleicht explizit in der E-Mail erwähnen sollen.

Aber der Kunde war uns trotz allem wohlgesonnen, ...

I really feel your product is the best fit for us and I would like to get it to work.

... und konnte dann das Problem sogar selbst lösen:

I reset the permissions on the entire "events" folder to Read/Write & Execute. I also changed the permissions on the cache to Full Control. Since I am working off of an IIS server I checked to apply permissions to all child objects for both the cache folder and the "events" folder.

IIS. Das erklärt natürlich einiges. ;-)

Am Anfang der Woche haben wir eine neue Version des Schedule Organizer veröffentlicht. Das Update enthält eine Menge neuer Funktion, die von den Anwendern schon lange gewünscht wurden.

So ist es nun möglich, standardmäßig alle Termine zu blockieren und nur ausgesuchte Zeiten manuell freizugeben. Und falls diese Freigaben allzu spärlich ausfallen, gibt es einen Button, der den Anwender zum jeweils nächsten offenen Termin führt.

Das Script kann nun mit Zeitzonen umgehen. Die Anwender legen bei ihrer Registrierung ihre Zeitzone fest (kann später noch geändert werden) und das Script zeigt dann alle Uhrzeiten entsprechend den Zeitzoneneinstellungen an. Sehr hilfreich ist diese Funktion für Unternehmen, die Europa- oder Weltweit agieren. Die Funktion verlangt allerdings nach PHP 5.

Die Registrierungsfunktion ist nun vollwertig inklusive Aktivierung des Benutzerkontos. Außerdem lässt sich einstellen, ob Administrator, Operator, Nutzer oder alle bei Registrierung eine Benachrichtigungs-E-Mail bekommen.

Optional kann der Admin jetzt Links zum Script generieren, um den Anwender direkt zu einer bestimmten Woche, einem ausgewählten Reservierungsgrund, Terminbereich oder direkt zum Formular zu leiten. Diese Links können dann auf der Website oder in E-Mails platziert werden.

Im Admin-Bereich kann eine Termin-ID angezeigt werden (inklusive Suchfeld in der Terminliste).

Wenn ein Termin mehrmals reservierbar ist, wird nun farblich gekennzeichnet, wenn bereits Termine gebucht wurden. Dadurch sieht der Anwender, ob für eine bestimmte Uhrzeit bereits Termine gebucht wurden.

Das Script besitzt jetzt eine erneuerte Update-Routine. Die erkennt automatisch, ob der Betreiber die Script-Dateien aktualisiert hat und zeigt ein Update-Formular an. Nachdem der Betreiber die MySQL-Zugangsdaten eingegeben hat, aktualisiert das Script die Datenbanktabellen. Sobald das geschehen ist, hat der Admin wieder Zugang zum Admin-Bereich.

Die neue Version verfügt auch über einen Wartungsmodus, der im Admin-Bereich eingeschaltet werden kann. Dabei wird die Benutzeroberfläche abgeschaltet, damit der Admin eine neue Version des Scripts zum Server hochgeladen und installieren oder andere Einstellungen vornehmen kann, ohne dass es auf Anwenderseite zu Komplikationen oder Fehlermeldungen kommt.

Administratoren können jetzt entscheiden, ob Sie Termine löschen oder lediglich absagen. Im letzteren Fall bleiben die Termine erhalten und erschienen durchgestrichen in der Terminliste. Bisher war nur jeweils eine der beiden Optionen möglich.

In der Vergangenheit kam es ab und zu mal vor, dass ein Admin sich selbst ausgesperrt hat. Deshalb wird vor dem Löschen eines Benutzers mit Admin-Rechten deutlicher als bisher gewarnt.

Das Benutzeroberfläche gibt jetzt valides XHTML aus.

Das Script ist jetzt wieder abwärtskompatibel zu PHP 4 und wird es auch zukünftig bleiben. Einige optionale Funktionen wie Zeitzonen funktionieren dann allerdings nicht.

Und zu guter Letzt eine etwas exotische Funktion. Administratoren können Dateien hochladen und diese einem Benutzer oder Termin zuordnen. Denkbar wäre der Einsatz, um Patienten auf diesem Wege das Ergebnis von Tests oder Untersuchungen zukommen zu lassen.

Weiterführende Informationen  zum Schedule Organizer.

Eine Anwendung funktioniert nicht so wie sie soll. Und an wem liegt das? Eine begehrte These lautet wie folgt:

Der Fehler sitzt meistens vor dem Computer

Gegenthese:

Wenn der Anwender Probleme mit einem Programm hat, waren die Entwickler nicht in der Lage, das Programm entsprechend benutzerfreundlich zu gestalten.

Ein frustrierter Support-Mitarbeiter dürfte ähnlich der ersten These argumentieren. Und für den Programmierer ist es ebenfalls eine recht komfortable Sichtweise.

Entwickler einer Software sollten jedoch jeden Handgriff des Benutzers antizipieren. Für viele Programmierer sind jedoch Dinge wie Usability und intuitiv bedienbare Software nur Buzzwords. Bedienoberflächen, Hilfetexte und Anleitungen müssen jedoch so gestaltet sein, dass sie jeder (wirklich jeder) versteht.

Bei keinem unserer Scripte gab es je einen Fall, bei dem sich der Anwender zu dumm angestellt hätte. Das Problem ließ sich immer auf eine unlogische Benutzerführung, oder eine unklare Anleitung zurückführen.

Wenn man konsequent jede Rückmeldung eines Nutzers in die Verbesserung der Software einfließen lässt, steht am Ende eine Anwendung, die für jeden bedienbar ist und keine Fragen offen lässt. Die Anwender sind zufrieden und es gibt weniger frustrierte Support-Leute. Nicht zu vergessen die finanziellen Vorteile für das Unternehmen.

Ein Thema, dass bereits jetzt schon einen Teil der Support-Anfragen ausmacht und sicherlich in Zukunft eine Rolle spielen wird, ist die UTF-8-Kodierung von Text in PHP-Scripten. Probleme treten immer dann auf, wenn zum Beispiel die UTF-8-kodierten Sprachdateien von Scripten, vom Anwender geöffnet und bearbeitet werden. Nach dem Speichern der Datei befindet sich plötzlich folgendes Zeichen am Anfang der Datei:

   

Das Teil nennt sich Byte-Order-Mark (BOM) und markiert den Text als UTF-8-kodiert. Das Zeichen wird von den Editoren meist automatisch eingefügt. Der Nachteil ist, dass das BOM an den Browser ausgegeben wird (und störend wirkt) und unter Umständen mit Funktionen wie session_start() oder header() in Konflikt gerät.

Möglichkeit 1: Idealerweise bietet der Editor die Möglichkeit, UTF-8-Kodierung ohne BOM einzustellen. Notepad++ zum Beispiel kann das. Einfach eine der Optionen mit ... without BOM auswählen.

Möglichkeit 2: Die UTF-8-kodierten Dateien mit dem normalen Editor bearbeiten und später mit einem einfachen Editor öffnen und das BOM manuell entfernen.

Möglichkeit 3: Ganz normal mit dem bisherigen Zeichensatz (z.B. iso-8859-1) arbeiten und dann die Datei mit Hilfe der PHP-Funktion utf8_encode() umwandeln.

Deutschland lebt manchmal wirklich hinter dem Mond, so scheint's. Besonders stark drängt sich dieser Gedanke auf, wenn man sich die Szene der Seiten für gesellige Neuigkeiten (neudeutsch Social News) ansieht. Für die Betreiber von Yigg oder Webnews muss das frustrierend sein. Da programmiert man sich die Finger wund und schafft es sogar, sich von großen Medienunternehmen kaufen zu lassen, und trotzdem kommt man nicht aus dem Knick. Die Top-Stories bei Webnews reichen kaum mal an 50 Punkte heran und mehr als lediglich eine Handvoll Kommentare ist auch eher selten drin. Wenn überhaupt.

Besonders deprimierend muss der Blick in die Vereinigten Staaten sein. Die dort angesiedelten Digg und Reddit spielen in einer ganz anderen Liga. Hunderte, manchmal Tausende Votes für einen Beitrag. Die Zahl der Kommentare ist meist dreistellig. Diskussionskultur pur.

Der Vergleich mit Digg und Reddit mag vielleicht etwas unfair erscheinen. Schließlich hat die Deutsche Sprache nicht mal annähernd die Reichweite wie die Englische. Aber trotzdem. Gerade mal zweistellige Votes und ein paar Kommentare für eine Top-Story bei über 40 Mio Internetnutzern in Deutschland? Während bei den Amis prächtige Diskussionen gedeihen, herrscht bei den hiesigen Diensten nur tote Hose.

Andere Dienste in Deutschland haben es da besser. Zumindest was die Nutzerzahlen angeht. StudiVZ zum Beispiel. Soll ja recht beliebt bei den Studenten sein, was man so hört.

Es scheint noch nicht einmal was zu bringen, dass Seiten wie Spiegel, Zeit oder Süddeutsche Links zu Yigg und Co. einbauen. Die meisten Leser ahnen wahrscheinlich nicht einmal, wozu diese Links gut sein sollen. Zeit also für Aufklärungsarbeit? Viel Glück dabei!

Andere Website, andere Sorgen. Während bei den einen Flaute herrscht, geht’s den anderen zu gut. Kürzlich kündigte heise.de an, alle Kommentare löschen zu wollen die älter als zwei Jahre sind. Unglaublich. Welche Ressourcen da verloren gehen. Die Community fand das erwartungsgemäß überhaupt nicht witzig. Und wer den Mob in den Heise-Foren kennt, weiß, da war einiges los.

Am Ende scheint sich in den Heise-Foren doch noch eine Lösung abzuzeichnen. Und was die Social-News-Seiten angeht: Für die einen ist es der Arbeitsplatz. Andere haben viel Geld damit verdient. Und wieder andere verbringen Ihre Freizeit (oder vielleicht auch Arbeitszeit, wer weiß) dort. Also doch alles gut?

Nachtrag: Deutscher Reddit-Klon

Ist das nicht nett? O'Reilly bietet einige Bücher kostenlos als PDF-Datei für jedermann zum Herunterladen und Lesen an. Die Liste enthält neben Titeln zu PHP und Ruby auch einiges zu Linux und anderen Open-Source-Projekten.

Neu dabei ist das Werk „Praktischer Einstieg in MySQL mit PHP“ von Sascha Kersken. Das Buch hat 368 Seiten und die PDF-Datei wiegt rund 15 MB.

Wie der Titel schon sagt geht es um MySQL und PHP. Das Buch richtet sich an Anfänger und erklärt neben der Installation von Apache auch die Grundlagen von PHP und MySQL. Inklusive Installationsanleitung. Achja, phpMyAdmin wird auch erklärt.