ScriptBlogger

Eine Support-Anfrage sollte idealerweise in einem freundlichen Ton geschrieben sein, ausführlich das Problem beschreiben und als Sahnehäubchen noch einen Link zum nicht funktionierenden Script beinhalten. Soweit so gut.

Ein Konzept, das an folgendem Fragesteller jedoch komplett verloren gegangen ist:

your programme has given me problems for the past one week. i really need to vote but its jamming. I cant vote for reasons i don't know so please fix this problem because I really need to vote urgently!!!!!!!!!!!!!!!!!!!

;-)

Vor einem Monat haben wir einen Konfigurator für unser Voting-Script online gestellt. Statt mit einer Konfigurationsdatei zu hantieren, kann der Anwender das Script bequem per Browser einstellen und im Anschluss die fertige Konfigurationsdatei herunterladen.

Allerdings scheinen wir damit ein Problem gelöst zu haben, dass eigentlich keines war. Von einer Hand voll Zugriffen abgesehen oxidiert das Tool ungenutzt vor sich hin. Gerade mal eine einzige "richtige" Konfiguration wurde damit vorgenommen.

$vote_title             = 'Presidential Elections';
$vote_text              = 'Who will win the Presidential Elections';

$vote_option[]          = 'Barack H. Obama';
$vote_option[]          = 'John S. McCain III';

B-)

Ab und an landen Besucher auf dieser Seite, die nach einem Script-Blogger für Mozilla (Firefox und Konsorten) suchen.  Was sie allerdings tatsächlich finden wollen ist ein Script-Blocker. Sehr löblich. Wir empfehlen NoScript:

NoScript - Allow active content to run only from sites you trust, and protect yourself against XSS attacks. 

Die Entwickler von NoScript sind recht aktiv. Ständig gibt's neue Updates. Kann man jedem nur raten.

Auf Grund eines Bugs in PHP 4, der von der PHP-Group verständlicherweise nicht mehr behoben wird, verlangt unser Schedule Organizer nach PHP 5. Zwar haben viele Webspace-Provider bestehende Webspace-Konten noch immer nicht von PHP 4 auf PHP 5 umgestellt, aber das war auch kaum zu erwarten. Umgestellt wird dann zumindest, wenn man den Provider darum bittet. Meistens jedenfalls.

Ein Kunde von uns sah sich allerdings mit folgender Antwort konfrontiert:

To parse php scripts in PHP5 please rename your PHP scripts to have a .php5 extension.

Eine völlig inakzeptable Antwort. Vor vier Jahren, als PHP 5 erst bei wenigen Webhoster parallel zu PHP 4 angeboten wurde, hätte man das vielleicht noch durchgehen lassen können. Und das obwohl es mit .htaccess einen weitaus besseren Weg gibt, .php-Dateien als PHP 5 parsen zu lassen.

Der Kunde hat sich dann nochmal an den Support des Webhosters gewandt und folgendes als Antwort bekommen:

Dear Customer,

The script that you have provided for a .htaccess file is written for the Apache mod_rewrite facility, this will not work correctly however as we do not run Apache on our hosting cluster instead we run Zeus on our hosting package which does not support mod_rewrite. Alternatively you can use rewrite.script which is Zeus's version of mod_rewrite however we cannot support the coding itself.

Ein Script "... written for the Apache mod_rewrite facility ..."? Was hat mod_rewrite mit PHP zu tun? Da fragt man sich, wie kompetent der Webhoster reagieren wird, wenn es mal ein ernsteres Problem gibt.

Wir haben uns dann nochmal reingehängt und versucht eine Lösung zu finden. Leider ohne Erfolg. Deswegen baten wir den Kunden, nochmal bei seinem Provider nachzufragen, ob sich PHP 5 wirklich nicht standardmäßig für den Webspace-Account einstellen ließe. Was wir uns da wieder gedacht haben ...

At this point in time we have to keep PHP 4 the default version due to our hosting being a shared environment. If we changed to PHP 5 as default on our servers it would be disastrous as thousands of our customers websites would go down. Some time in the near future we will look at moving over to PHP5 as default however for the time being you will need to rename all of your scripts to .php5 to parse them in PHP version 5.

Offensichtlich ein weiterer Webhoster, der jahrelang gepennt hat, statt sich vernünftig auf PHP 5 vorzubereiten. Es ist ja schließlich nicht so, als wenn PHP 5 über Nacht über das Internet hereingebrochen ist. :-O

.. ist für den anderen ein Server, der nicht wie gewünscht funktioniert.

Wir haben bei Host Europe einen virtuellen Server, der in den letzten Monaten anstandslos seinen Dienst verrichtete. Wenn mal etwas klemmte, war immer zu starker Traffic schuld.

Das letzte Mal allerdings ließ sich Traffic als Störfaktor¹ ausschließen. Die Symptome waren wie folgt:

HTTP: Die Seiten benötigten zum Teil mehrere Sekunden (5-10) zum Laden

FTP: Verbindung zum Server war anfangs nur sehr zäh, später gar nicht möglich

Plesk: Verbindung war sehr, sehr zäh

Mail: Funktionierte ohne Probleme

Ein Neustart des Systems hat die Probleme nur kurzfristig gelöst. Host Europe hat dann "[...] einige Optimierungen am Wirtssystem durchgeführt.", was aber auch nichts gebracht hat.

Nächste Antwort von Host Europe:

Leider lassen sich solche Geschwindigkeitsschwankungen bei geteilten Systemen wie dem VPS nicht generell vermeiden. [...]

Ausfall von FTP ist keine Geschwindigkeitsschwankung. Und Ladezeiten von Plesk und HTTP von über zwei bis drei Sekunden sind weder akzeptabel noch normal. Host Europe macht da seine Systeme schlechter als sie tatsächlich sind. Der Server lief in den letzten Monaten anstandslos.

Ein Neustart am nächsten Tag hat die Probleme zunächst gelöst. Wir werden sehen, wie lange das anhält.

Update: Es gibt Anzeichen, dass das Problem möglicherweise bei Kabel Deutschland lag. Unser Server bei Domainfactory machte plötzlich ebenfalls Zicken. Nach dem Wechsel auf die Telekom-Leitung hatte sich dass allerdings erledigt. Sorry hiermit an den Support von Host Europe. ;-) Das ändert jedoch nichts an der Tatsache, dass der Support von Host Europe ernsthaft der Meinung ist, dass man Ladezeiten von drei bis fünf Sekunden für eine Web-Seite in Kauf nehmen muss.

¹) Prinzipiell gesehen sind zuviele Besucher ein Luxusproblem. Man kann eigentlich nie genug Traffic haben. ;-)

Ein Nutzer unseres Datei-Download-Scripts liefert damit Filme aus. Die Dateien sind jeweils um die 10 GB groß und liegen deshalb auf einem extra Server mit günstigerer Bandbreite.

Der Nutzer äußerte nun den Wunsch, das Script auf dem Server mit der eigentlichen Website (Server A) zu installieren und auf die Filmdateien auf Server B zugreifen zu lassen. Er hätte gern alles unter einer einheitlichen Domain gehabt. Allerdings ist das Script dafür nicht ausgelegt, sondern kann nur Dateien ausliefern, auf die es über einen lokalen (Netzwerk-)Pfad zugreifen kann.

Für den Nutzer hat sich dieser Umstand jedoch als positiv herausgestellt, denn da gab es einen kleinen Denkfehler seinerseits. Wenn nämlich das Script auf Server A installiert ist und auf die Dateien auf Server B zugreift, werden die Dateien immer über Server A geschleust. Das Script liest dabei die gesamte Datei ein und gibt sie an den Browser aus. Und das kostet dann gleich zweimal Bandbreite - einmal auf Server B und einmal auf Server A. Das schien dann doch nicht so ganz im Sinne des Erfinders zu sein. Sah dann auch der Nutzer so:

Thanks a lot for your support! double bandwidth ..... grrhhhhh.nope!

Zumal man einfach eine Sub-Domain einrichten kann, welche dann auf Server B gerichtet ist.

Sofern das eigene Weblog über diese Fähigkeit verfügt, kann man Ping-Server per XML-RPC über neue Beiträge informieren. Motiviert durch eigenen Bedarf haben wir unsere Liste mal durch neue Dienste erweitert und durchgetestet. Dabei haben wir alles rausgeworfen, was nicht erreichbar und offensichtlich den Geist aufgegeben hat.

Tadaaaaa:

• http://rpc.blogrolling.com/pinger/
• http://rpc.technorati.com/rpc/ping
• http://rpc.weblogs.com/RPC2
• http://api.my.yahoo.com/RPC2
• http://services.newsgator.com/ngws/xmlrpcping.aspx
• http://api.moreover.com/RPC2
• http://www.blogpeople.net/servlet/weblogUpdates
• http://bblog.com/ping.php
• http://ping.feedburner.com/
• http://ping.syndic8.com/xmlrpc.php
• http://blogsearch.google.com/ping/RPC2    
  
• http://rpc.icerocket.com:10080/    
  
• http://rpc.pingomatic.com/
• http://xmlrpc.bloggernetz.de/RPC2
• http://bblog.com/ping.php
• http://blog.goo.ne.jp/XMLRPC
• http://api.my.yahoo.co.jp/RPC2
• http://xping.pubsub.com/ping/
• http://rpc.reader.livedoor.com/ping
• http://ping.wordblog.de/
• http://blogsearch.google.at/ping/RPC2
• http://ping.weblogalot.com/rpc.php
• http://ping.bloggers.jp/rpc/
• http://blogsearch.google.de/ping/RPC2
• http://ping.namaan.net/rpc
• http://rpc.technorati.jp/rpc/ping
• http://zhuaxia.com/rpc/server.php
• http://www.bloglines.com/ping
• http://rpc.bloggerei.de/ping/

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.

:-)