ScriptBlogger

Ein Kunde, der das Form Mail Script gekauft hatte, schrieb:

I just wanted to say thank you for your awesome script. I just purchased a license after I tested it out and modified it to do exactly what I want. There is nothing like this on the Internet that offers so many options and the ability to modify it like I have done.

Keep up the great work, and once again thank you. 

:-)

Die PHP-Funktion nl2br() wandelt bekanntermaßen alle Zeilenumbrüche in <br /> um. Allerdings wird dabei nicht berücksichtigt, dass doppelte Zeilenumbrüche auch als Absatz formatiert werden können. Also mit <p> statt zweier <br />. Die folgende Funktion löst das Problem.

<?php  

function nl2p($text) 
{
    $text = '<p>' . $text . '</p>'; 
    $text = str_replace("\r\n\r\n", "</p><p>", $text); 
    $text = str_replace("\n\n", "</p><p>", $text); 
    $text = str_replace("\r\n", "<br />", $text); 
    $text = str_replace("\n", "<br />", $text);      

    return $text;
} 

$text = "Test 123 
Hallo Welt 

Test 8910"; 

echo nl2p($text);

?> 

Der HTML-Quellcode sieht damit wie folgt aus:

<p>Test 123<br />Hallo Welt</p><p>Test 8910</p>

Erst die Einladung zum Drink und jetzt dies:

DICKES LOB!! Super Support!!

Wenn Sie mal eine Leiter oder ein Gerüst brauchen, ...einfach an mich wenden.

Hm. Erst mal nicht, aber trotzdem danke. :-)

Ein Kunde schrieb:

Ralf you rock! Wish I could buy you a drink!

Wenn ich mal wieder in Minnesota, USA, bin bestimmt. :-)

Aus einem unerfindlichen Grund ist bei Plesk nicht vorgesehen, dass man per FTP auf die Server-Log-Dateien (Access-Log, Error-Log) zugreifen kann. Das Verzeichnis ist zu sehen, aber der FTP-Benutzer hat keinen Zugriff darauf.

Zum Auswerten der Log-Dateien muss die von uns verwendete Software aber per FTP auf die Log-Dateien zugreifen. Kann aber nicht. Abhilfe schafft chown. Einfach per SSH einloggen und den Eigentümer der Verzeichnisse statistics und logs auf den FTP-Benutzer ändern und alles ist wieder gut. B-)

Jemand muss mal wieder eine unserer E-Mail-Adressen als Absender seiner Spam-Mails verwendet haben. Ein paar Leute haben sich bei uns gemeldet und wollten aus der Mailing-Liste ausgetragen werden:

unsubscribe me from your mailing list A.S.A.P

Allerdings versenden wir keine Mailings. Und dass es sich irgendwann mal auch bis zum Letzten herumsprechen wird, dass Spammer in der Regel keine eigene E-Mail-Adresse als Absender verwenden, dürfte wohl auch für ewig ein Wunschtraum bleiben.

Nach dem Update auf Firefox 3  hat GoogleMail ständig Fehlermeldungen angezeigt und war praktisch unbedienbar. Es hat einiges Ausprobieren, Aktivieren und Deaktivieren der installierten Extensions gebraucht, um den Schuldigen zu finden.

Es stellte sich heraus, dass ich mich von meinem geliebten CookiePie verabschieden musste. CookiePie erlaubt es, auf derselben Website in verschiedenen Tabs mit verschiedenen Benutzerdaten eingeloggt zu sein. Das ist besonders hilfreich, wenn man gleichzeitig als Administrator und als eingeschränkter Anwender eingeloggt sein möchte. Dies wiederum ist ganz nützlich, um Anwendungen zu testen.

Muss ich wohl wieder auf andere Browser zurückgreifen. Mit Chrome von Google hat sich ja vor Kurzem die Auswahl vergrößert.

Scripte auf Windows-Servern (IIS und so) zu installieren ist immer eine Freude. Meistens ist kein MTA (Mail Transfer Agent) installiert, so auch im folgenden Fall. Der Kunde wollte sich drum kümmern und meldete sich wie folgt:

I put a simple SMTP service on to the server itself as a localhost. Can you put that in place?

Kein Problem. Änderungen vorgenommen und ausprobiert. Als Fehlermeldung spuckte mail() dann allerdings dies hier aus:

PHP Warning: mail() [function.mail]: SMTP server response: 555 This freeware lets you send not more than 10 messages a day

Der Kunde meinte dann

Ok. I'll fix that.

und schob dann später nach

BTW, This is getting embarrassing now.

:-)

Ständig dieser Hype um ReCaptcha. Oder zumindest positive Berichte darüber. Spiegel Online schreibt etwas von Schwarmintelligenz und lobt die Kostenlosigkeit. Dabei hat die Sache weniger mit Intelligenz, sondern eher etwas mit Arbeitskraft für lau zu tun.

ReCaptcha wurde an der Carnegie Mellon University in Pittsburgh, Pennsylvania, USA, entwickelt und soll beim Übersetzen von Büchern helfen. Website-Betreiber können ReCaptcha in ihr Forum/Weblog/Formular einbauen und so vor Spam schützen. In dieser Hinsicht funktioniert ReCaptcha wie ein ganz normales Captcha.

Zusätzlich wird jedoch noch ein zweites Wort angezeigt, das es zu erkennen gilt. Es stammt aus einem gescannten Buch und konnte von der Texterkennungs-Software nicht erkannt werden.

Problem Nummer 1: Das ansich schon nervige Captcha wird verkompliziert und benötigt mehr Zeit zum Lösen. Okay, man kann sich das zweite Wort sparen und kommt trotzdem durch. Wenn denn nur immer klar sein würde, welches das richtige Wort ist. Der Strich quer durchs Wort ist meistens eine Hilfe. Meistens.

Problem Nummer 2: ReCaptcha funktioniert nur mit JavaScript im Browser aktiviert. Was aber andererseits fast wieder egal ist, denn das halbe Internet funktioniert nur mit JavaScript aktiviert.

Einziger Lichtblick ist, dass ReCaptcha sich auch auf Ton umschalten lässt und so keine Barriere für Menschen mit eingeschränkter Sicht darstellt. Theoretisch zumindest, denn die Tonqualität steht der Bildqualität in nichts nach. 

Und schließlich wirft sich die Frage auf, wem das Ganze nützt, außer der Carnegie Mellon University. Wenn denn wenigstens eine deutsche Uni etwas in dieser Art anbieten würde. Es ist kaum anzunehmen, dass es hierzulande nichts zu digitalisieren gäbe. Aber das wird warscheinlich erst passieren, wenn Captcha Schnee von gestern ist und Spam entweder der Vergangenheit angehört oder auf andere Weise bekämpft wird.

Nachtrag:

ReCaptcha ist prinzipiell keine schlechte Idee, nur nervt der undifferenzierte Hype darum. Außerdem noch eine Korrektur zum Thema JavaScript. Wie zum Beispiel Twitter und die Website von ReCaptcha beweisen, kann man ReCaptcha so einbinden, dass es auch ohne eingeschaltetes JavaScript funktioniert. Das allerdings macht die Angelegenheit noch um einen Schritt komplizierter, da man nun nach erfolgreicher Lösung des ReCaptchas noch einen zufallsgenerierten Code in ein anderes Textfeld eingeben muss.

Damit Weblog Expert Google Chrome in seine Auswertung einbezieht, muss folgende Zeile in die Config/Browsers.cfg eingefügt werden. Neustart von Weblog Expert nicht vergessen. Andernfalls haben die Änderungen keinen Effekt.

Chrome = Google Chrome

Wichtig dabei ist, dass der Eintrag oberhalb des Eintrags für Safari erscheint.

Chrome = Google Chrome
Safari = Safari

Sieht dann in der Auswertung so aus.

Vor einiger Zeit meldete sich ein Kunde bei uns. Das von ihm erworbenen Wegwerf-E-Mail-Script funktionierte nicht. Wie sich herausstellte lag das Problem beim US-Webhoster GoDaddy, der Scripten keine Verbindung zu externen E-Mail-Accounts erlaubt. Unser Vorschlag, den Webhoster zu wechseln, kam nicht so gut an und der Kunde wollte sein Geld wiederhaben. Das war am 2. Februar.

Am 4. Februar haben wir ihm den Kaufpreis erstattet. Zum Dank hat er das Script in einem Raubkopiererforum zum allgemeinen Herunterladen freigegeben. Ist doch klar, dass wir uns dafür artig bei ihm bedankt haben.

Thanks for posting our Temporary E-mail script in a warez forum despite the fact that we spend hours trying to get the script running on your server and refunded your money on February 4. It's really great that we can trust our customers and that our effort is rewarded. 

Und wir haben sogar eine Antwort erhalten:

i posted it because i didn`t got my refund and it passed like 2 weeks and didn`t heard nothing from you ... i posted on the forum and nothing .. not an answer! 

Zwei Wochen? Der Thread im Forum sagt etwas anderes. Nach der letzten Forumsnachricht ging es übrigens per E-Mail weiter.

Seitdem fragen wir bei Support-Anfragen zum Wegwerf-E-Mail-Script stichprobenartig nach den Zahlungsinformationen. Die eine oder andere Anfrage hatte sich danach erledigt.

Vor ein paar Tagen haben wir von "stichprobenartig" auf "durchgehend" umgestellt. Wer von nun an Support erhalten möchte, muss bei der Registrierung im Forum die Zahlungs-ID/ Rechnungsnummer angeben. Allerdings gilt das nur für Scripte, die erst nach dem Kauf erhältich sind, wie Link Manager, Wegwerf-E-Mail, Schort URL und News Script.

Gerade eben wollte ich auf einer Website ein Formular absenden und sah mich mit folgender Frage konfrontiert:

What color is the sky.

Kurzer Blick aus dem Fenster und folgendes eingetippt:

grey

Das Formular hat mir nicht geglaubt und das Absenden verweigert. ;-)

Schocken kann uns gar nichts mehr, nicht mal folgende an Dreistigkeit kaum zu überbietetende Nachricht in einem Diskussionsforum irgendwo im Netz.

Die Links "USER DEMOS CLICK HERE" und "Admin Demo CLICK HERE" führen auf unsere eigene Demoseite. Die haben wir dann gleich mal entsprechend geändert und nun ist deutlicher gekennzeichnet, wo man das richtige Script kaufen kann. Außerdem haben wir als Antwort auf die Forumsnachricht unsere Web-Adresse gepostet. Mal sehen ob's was bringt. ;-)

Und noch ein Hinweis: Wir vergeben keine Master Resell Rights (MRR) und schon gar keine, die dermaßen günstiger als unsere eigenen Preise sind. B-)

Genaugenommen ist es keine unendliche Geschichte, sondern eher eine ziemlich langwierige.

Am Anfang ging's noch recht flink. Am 31. Mai traf die Anfrage zum Schedule Organizer ein und am 2. Juni die Bestellung für den Installationsservice. Fragebogen zusenden, Script hochladen, Layout anpassen, Änderungswünschen nachkommen - normalerweise ist das recht zügig erledigt. Und selbst wenn es nicht ganz so zügig geht weil es Unklarheiten gibt, ist das mitnichten ein Problem. Die paar extra E-Mails sind schnell geschrieben und nicht jeder Kunde ist vertraut mit den Dingen die das Webhosting so mit sich bringt. Unsere einzige Sorge ist, dass der Kunde irgendwann die Geduld verliert.

3. Juni - Leider fehlten im ausgefüllten Fragebogen die Zugangsdaten für FTP und MySQL, so dass da noch einmal nachgehakt werden musste.

4. Juni - Die FTP-Daten waren nun da, funktionierten aber nicht.

9. Juni - Bei der Rückfrage hatte ich mich missverständlich ausgedrückt und nach den korrekten Daten für den FTP-Server gefragt. Darauf die Antwort: "We do not have a ftp server."

10. Juni - Ich gab mir nochmal Mühe mit der Erklärung und erfuhr, dass der Kunde sich immer per Microsoft Frontpage einloggt. Der Kunde wollte mir dann die dafür verwendeten Zugangsdaten geben.

11. Juni - Die FTP-Zugangsdaten sind da.

Irgendwie war die Sache hier untergegangen, so dass sechs Tage bis zur nächsten Aktion vergingen.

17. Juni - Ich fand heraus, dass der FTP-Login auf ein anderes Verzeichnis auf dem Server zeigte, als die URL. Nach ungefähr zehn E-Mails war das Problem verstanden und gelöst.

19. Juni - Alles funktionierte soweit, so dass ich die Script-Dateien zum Server hochladen konnte. Der Aufruf der Installationsroutine zeigte allerdings: Es lief kein PHP auf dem Server.

23. Juni - PHP funktionierte jetzt, allerdings fehlte nun die MySQL-Extension.

24. Juni - Der Kunde hatte MySQL per php.ini aktiviert. Es kam leider immer noch diese Fehlermeldung: PHP Fatal error: Call to undefined function mysql_connect()

2. Juli - Jetzt wird's interessant. Der Kunde fragte:"Where do you need mysql installed on the server?" Da ich kein Windows System-Administrator bin und auch deren Infrastruktur nicht kenne, konnte ich nicht helfen.

7. Juli - Der Kunde meldet sich mit: "I've installed MySQL essentials build 5.0.51b on the web server." Leider hat das auch nichts gebracht. Die MySQL-Extension ist immer noch nicht verfügbar.

9. Juli - "I reinstalled PHP this time, and now I can see the MySQL extension when I load the phpinfo.php page." PHP hat jetzt tatsächlich Zugriff auf die MySQL-Extension. Leider stimmen die vom Kunden übermittelten MySQL-Zugangsdaten nicht. Access denied etc.

9. Juli - Die neuen MySQ-Zugangsdaten sind da - und sie funktionieren sogar. Das Script ist jetzt endlich installiert und funktioniert weitestgehend. Weitestgehend heißt in diesem Fall, dass das Script auf einem Windows-Server läuft und erwartungsgemäß kein Mailer installiert ist. Kein Problem, für diese Zwecke hat das Script eine SMTP-Funktion. Brauche ich vom Kunden nur noch die Daten für ein E-Mail-Konto. Ein Test mit einem unserer E-Mail-Konto verlief negativ (Timeout mit Fehlermeldung). Das lässt darauf schließen, dass externe E-Mail-Konten nicht genutzt werden können.

11. Juli - Weitere Details nachgefragt

26. August - Bisher keine Antwort erhalten und mal nachgehakt

26. August - "I am not sure if i want to continue with the installation. If is starting to become a problem with our server."

27. August - Script wieder vom Server gelöscht, Bestellung storniert und Geld zurückerstattet. :-[]

Ein Kunde aus Sydney (Australien) hatte kürzlich Probleme mit seinem Schedule Organizer. Angeblich waren alle bislang reservierten Termine auf einmal verloren gegangen. Vorfälle dieser Art hatten wir bereits dreimal zuvor, aber bislang konnten wir nicht viel dagegen ausrichten. Glücklicherweise handelte es sich jedesmal um ein einmaliges Ereignis und die Kunden konnten damit leben.

Nichtsdestotrotz wurde es Zeit, die Ursache des Problems zu finden und zu eliminieren. Das Gemeine an der Sache war, dass sie nicht durch falsche Einstellungen in der Konfiguration des Scripts hervorgerufen werden konnte. Andernfalls wäre es einfach gewesen, diese abzufangen. Also musste die Schuld irgendwo beim Server liegen.

Nach einigem Testen und Anzeigen aller möglichen Umgebungsvariablen probierten wir es mal mit date_default_timezone_get().

Ergebnis: America/Chicago. Was zum Henker?

Nun ist eine falsche Zeitzone kein Problem, solange sich nichts ändert. Aber genau das ist wohl geschehen, denn eine Änderung der Zeitzoneneinstellung verursacht exakt das oben beschriebene Verhalten. Die Lösung ist date_default_timezone_set(). Danach kann der Provider die Server-Einstellungen ändern wie er möchte, ohne das Script zu beeinflussen. Seit PHP 5.1.0 wird im E_STRICT-Modus sogar davor gewarnt, den Zeitzoneneinstellungen des Servers zu vertrauen. Offensichtlich sind den PHP-Entwicklern die Probleme bekannt.

Aus den reservierten Terminen ließ sich übrigens erkennen, dass sich die Zeitzone des Servers um fünf Stunden verschoben hatte. Chicago und Sydney liegen allerdings acht Stunden auseinander. Die Zeitzoneneinstellungen müssen also schon vorher falsch gewesen sein.