ScriptBlogger

Bei unserem News-Script verwenden wir die PEAR-Klasse XML_RPC, um Änderungen an die Ping-Dienste zu melden.

<?php

// Klasse laden
require_once 'XML/RPC.php';

// Liste mit Ping-Diensten
$list = array( 
    'ping.syndic8.com/xmlrpc.php',
    'blogsearch.google.com/ping/RPC2',
    'rpc.technorati.com/rpc/ping',
    'rpc.weblogs.com/RPC2'
    );

// URL des Weblogs
$baseURL = 'http://www.example.com/blog/';

// Name des Weblogs
$blogName = 'Mein Weblog';

// Die Liste der Ping-Dienste durchgehen und Daten senden
foreach ($list AS $key => $value)
{
    $value      = trim($value);
    
    // Ping-Dienst-URL in Host und Pfad trennen
    $pingHost   = substr($value, 0, strpos($value, '/'));
    $pingPath   = substr($value, strpos($value, '/'));
    
    // Blog-Name und URL als Prameter setzen
    $params     = array(
        new XML_RPC_Value($blogName, 'string'),
        new XML_RPC_Value($baseURL, 'string')
        );
    
    /**
     * weblogUpdates.ping als Modus auswählen. Alternativ könnte man auch
     * weblogUpdates.extendedPing verwenden und kann dann noch weitere Infos
     * übertragen.
     */
    $msg = new XML_RPC_Message('weblogUpdates.ping', $params);
        
    // Pfad und Host setzen
    $cli = new XML_RPC_Client($pingPath, $pingHost);

    // Daten übertragen
    $resp = $cli->send($msg);
        
    // Wenn ein Ping fehlgeschlagen ist, anzeigen welcher
    if (!$resp) {
        echo '<br />Ping fehlgeschlagen: ' . $value . ' -> ' . $cli->errstr;
        continue;
    }    

    if (!$resp->faultCode()) {
        /**
         * Wenn kein Fehlercode zurückgesendet wurde, hat vermutlich
         * alles geklappt
         */
        $val = $resp->value();
        echo '<br />Ping erfolgreich: ' . $value;
    } else {
        // Fehler anzeigen
        echo '<br />Ping fehlgeschlagen: ' . $value . ' -> ' . $resp->faultCode()
            . ' -> ' . $resp->faultString();
    }
}

?>

War diese Anleitung hilfreich? Über Hinweise oder Anmerkungen würden wir uns freuen.

In ein Kundenprojekt hatten wir eine Backup-Funktion eingebaut, die per FTP Datenbank und Dateien auf einen anderen Server überträgt. Das funktionierte auch bestens für mehrere Wochen. Dann meldete sich 1&1:

[...] unseren Server-Überwachungs-Tools ist eine Ihrer Anwendungen auf Ihrer Internet-Präsenz aufgefallen die einen "Dienst" auf jeder IP-Adresse die auf dem Server eingerichtet ist, installiert:

/.../cron/ftpbackup.php

Dies kann z.B. dadurch passieren, wenn Sie in Ihrem Script aktives statt passivem FTP verwenden.

Die Datei enthält ein Script, dass die PEAR-Klasse Net_FTP verwendet. Wir haben zu dieser Klasse bereits an dieser Stelle etwas geschrieben.

Und weiter:

Bitte haben Sie Verständnis und konfigurieren Sie deshalb Ihre Anwendung einfach um und zwar ausschliesslich auf die Ihnen von uns zugewiese IP-Adresse (zu finden z.B. im Konfigmenü Ihrer Präsenz unter dem Punkt "Technische Daten"), bzw verwenden Sie bitte ausschliesslich passives FTP in ihren Scripten.

Nichts einfacher als das. Haben wir also im PHP-Script passives FTP aktiviert. Dabei ist uns allerdings ein kleiner Fehler unterlaufen, welcher in der – aus unserer Sicht – irreführenden Bezeichnung der entsprechenden Methode der FTP-Klasse lag (siehe den Abschnitt "Fußangel"). Resultat war, dass passives FTP nicht aktiviert wurde. Das wusste zu diesem Zeitpunkt jedoch niemand. So schrieb dann der Support von 1&1 am nächsten Tag auch:

[...]unserem Überwachnungstool ist abermals Ihr cronjob /.../cron/ftpbackup.php aufgefallen.

[...]

Von dem Tool wird wohl wieder der Passive Mode für FTP bemängelt. Könnten Sie bitte nochmals danach schauen?

Nachdem wir also nun – aus unserer Sicht – extra auf passiv umgestellt haben, sollte das jetzt Auslöser des Problems sein? Merkwürdig. Aber kein Problem, haben wir also auf aktives FTP umgeschaltet.

Das hat das Problem wohl auch nicht gelöst. Deshalb kam erneut Post von 1&1:

[...]bitte das Script auf passives FTP umstellen. Die Umstellung auf passives FTP war schon richtig, weil durch passives FTP nur der FTP-Standard-Port benutzt wird und kein anderer Port. Nur hat in Ihrem Script der Passive Mode wohl nicht richtig gegriffen, sonst wäre dem Überwachungstool es nicht aufgefallen.

Und hier war dann der Support von 1&1 wieder auf der richtigen Spur. Nachdem wir tiefer in die Funktionsweise der Klasse und der PHP-Funktion ftp_pasv() eintauchten, wurde deutlich, dass passives FTP tatsächlich nicht aktiviert worden war. Ein kurzer Handgriff und auch das war erledigt.

Danke hiermit an den Support von 1&1 für die Hilfe und die Geduld. :-)

Die Nutzung der PEAR-Klasse Net_FTP ist prinzipiell gesehen relativ einfach, beinhaltet allerdigns eine kleine Fußangel. Zunächst jedoch der Beispiel-Code:

<?php 

// Klasse laden und Instanz erzeugen 
require_once 'Net/FTP.php'; 
$ftp = new Net_FTP(); 

// Einstellungen für Host, Port, Benutzernamen und Passwort 
$ftp->setHostname('example.com'); 
$ftp->setPort('21'); 
$ftp->setUsername('Benutzername'); 
$ftp->setPassword('pAss.w0rt'); 

// Verbindung zum Server aufbauen 
if ($res = $ftp->connect()) { 
     
    // Mit Benutzernamen und Passwort einloggen 
    if ($ftp->login()) {         
         
        // Passive Verbindung nutzen 
        $ftp->setPassive(); 
         
        /** 
         * Die Datei file.zip vom lokalen Server auf den anderen 
         * Server hochladen und in uploaded_file.zip umbenennen. 
         * Dabei wird eine eventuell bestehende Datei  
         * überschrieben (true). Im Falle einer Textdatei muss 
         * FTP_ASCII statt FTP_BINARY verwendet werden. 
         */ 
        $ftp->put('file.zip', 'uploaded_file.zip', true, FTP_BINARY); 
    } 
     
    // Verbindung trennen 
    $ftp->disconnect(); 
} 

?>  

Mit der Methode setPassive() wird auf passives FTP umgeschaltet. Dabei macht der Client die Verbindungen zum Server und legt den Port für den Datenaustausch fest. Bei aktivem FTP macht dies der Server, was jedoch erfahrungsgemäß zu Problemen mit der Firewall des Clients führen kann. Da in diesem Fall beide Rechner Server sind kann man annehmen, dass der Client mit einer Firewall ausgestattet ist. Passives FTP bietet sich also an.

Die Fußangel

Alle Einstellungen wie Host, Port, Benutzername und Password können über die jeweiligen Setter-Funktionen vor dem Öffnen der Verbindung festgelegt werden. Das passive FTP kann jedoch erst nach dem Login aktiviert werden (siehe Code-Beispiel). Der Methodenname setPassive() ist da etwas irreführend. activatePassive() oder ähnliches wäre da eventuell eine bessere Bezeichnung. Beim Aufruf der Methode wird der Modus nicht nur eingestellt, sondern es wird auch sofort das Kommando per ftp_pasv() an den Server gesendet. Das funktioniert logischerweise nur, sofern die Verbindung bereits besteht und der Benutzer eingeloggt ist.

War diese Anleitung hilfreich? Über Hinweise oder Anmerkungen würden wir uns freuen.

Wir betreiben den einen oder anderen Service für kurze URLs, die auf unserem Kurz-URL-Sript basieren. Primär testen wir damit neue Funktionen und beobachten die Scripte unter Live-Bedingungen.

Beim Auswerten der Statistiken von gentleurl.net und teenyweenyurl.com fielen uns ein paar interessante Zahlen und Fakten in die Hände.

Vor kurzem im Support-Forum aufgetaucht:

I have been using the short URL script for about two months on many posts. It has to be up there with some of the best systems I have encountered in several years. It works flawlessly, and of course, is very fast compared to the "Free Short URL Systems" on the internet. I am now master of of my URL's.

It is perfect.

:-)

Warum selbst machen, wenn andere es besser können. Prinzipiell kein schlechtes Motto. Außer vielleicht,  wenn man sein Können beweisen soll. Zum Beispiel als Informatikstudent.

Also if I wanted a be-spoke organiser from yourself based around this one how much would it cost? For example I would like a PHP script which makes appointments for a hairdresser, but it would need to look like a student create the PHP script. 

B-) 

Es gibt Situationen, da bietet sich die Nutzung des Telefon nicht nur an, sie zwingt sich sogar auf.

Ein Kunde von uns betreibt eine Website mit Informationen zum Thema Krankenversicherung. Besonders beliebt bei den Besuchern ist das Adressverzeichnis. Leider ist der Link zum Kontaktformular nicht weit und so passiert es nicht selten, dass sich die Leute mit Ihren Problemen an den Seitenbetreiber statt an ihre Krankenversicherung oder Krankenkasse wenden. Und das trotz eines deutlichen Hinweises oberhalb des Kontaktformulars.

So passierte es dann, dass kürzlich eine E-Mail eintrudelte, die mit EILT!!!!!!! eingeleitet wurde und im Wesentlichen erklärte, dass der Absender einen fünfstelligen Betrag an Krankenkassenbeiträgen doppelt überwiesen hatte. Mit Hinweis auf die "[...] fatalen Folgen für den weiteren Ablauf des Betriebes." bat man um Rücküberweisung.

Man kann nur hoffen, dass der Absender außer dieser E-Mail noch den Weg per Telefon und Post beschritten hat. Andernfalls...

Dass er sich in der Website vertan hat, ist in der Aufregung eventuell noch verständlich. Obwohl. Wer fünfstellige Beträge aus Versehen doppelt überweist... ;-)

Ein Nutzer unseres Gästebuch-Scripts erhielt eine erstaunliche E-Mail von seinem Webspace-Provider. Dieser schrieb ihm, dass die Datei sign.php des Gästebuch-Scripts Phishing-Material wäre:

We have received notification of phishing material in your account. Phishing files are usually placed through some type of exploit of out dated code, weak file and folder permissions. You must agree to remove this content and update any software that has resulted in security holes. To protect your account from further action you must agree to our request for compliance. Please respond to this message stating your intent to do so.

[...]

Failure to respond to this message within 72 hours will result in the suspension of the affected domain with us until such a time as this matter is resolved.

File path:

http://www.example.com/guestbook/sign.php*

Das ist ein ziemlich harter Ton, den der Provider dort anschlägt. Der Kunde bekommt nicht mal ansatzweise die Möglichkeit, eine Erklärung abzugeben oder die Ungefährlichkeit des Scripts zu versichern.

Das Script wird von Webmastern seit Jahren ohne Probleme auf unzähligen Servern installiert und läuft auf vielen auch heute noch. Erstaunlich ist, dass jetzt plötzlich jemand denkt, dass Script könnte für Phishing missbraucht werden. Man möchte meinen, dass bei über tausend Downloads jeden Monat irgendjemandem mal etwas aufgefallen wäre.

Eine Suche nach phishing "sign.php" ergab übrigens, dass es andere Scripte mit dem Namen sign.php gibt, die durch Sicherheitslücken für Phishing-Zwecke missbraucht werden können. Aber keine dieser Meldungen bezieht sich auf unser Gästebuch-Script.

Als Provider trotzdem gleich alle Scripte gleichen Namens von den eigenen Servern zu verbannen klingt nach Sippenhaftung. Oder Paranoia.

*) URL geändert

Wer seinen Server mit Plesk verwaltet, kann oder will den Server nicht per Kommandozeile administrieren.

Dieser Umstand scheint jedoch für die Entwickler von Plesk eine Neuheit darzustellen. Obwohl PHP 5 schon seit mehreren Jahren verfügbar ist, bietet die Plesk-Oberfläche keine Möglichkeit von PHP 4 auf PHP 5 zu aktualisieren. Von einem Parallelbetrieb beider Versionen ganz zu schweigen.

Stattdessen muss sich der Anwender mit yast, apt-get etc. herumplagen. Die Entwickler von Plesk sollten mal einen Blick auf die Verwaltungsoberfläche der Server von Domainfactory werfen. Dort stehen PHP 4 und PHP 5 jeweils in mehreren Versionen zur Verfügung.

Man kann offensichtlich nicht alles haben.

Microsoft spart wo es kann und verzichtet im Windows IIS unter PHP auf die Umgebungsvariable REQUEST_URI. Hier eine Lösung für das Problem:

<?php

/**
 * Request URI
 */
function my_request_uri()
{
    if (isset($_SERVER['REQUEST_URI'])
            and $_SERVER['REQUEST_URI'] != '') {
        return $_SERVER['REQUEST_URI'];
    }

    
    $path = '';
    if (isset($_SERVER['PATH_INFO'])
            and $_SERVER['PATH_INFO'] != '') {
        $path = $_SERVER['PATH_INFO'];
    }
    
    $query = '';
    if (isset($_SERVER['QUERY_STRING'])
            and $_SERVER['QUERY_STRING'] != '') {
        $query = '?' . $_SERVER['QUERY_STRING'];
    }
    
    if (isset($_SERVER['SCRIPT_NAME'])
            and $_SERVER['SCRIPT_NAME'] != '') {           
        return $_SERVER['SCRIPT_NAME'] . $path . $query;
    }
    
    if (isset($_SERVER['PHP_SELF'])
            and $_SERVER['PHP_SELF'] != '') {
        return $_SERVER['PHP_SELF'] . $query;
    }
    
    if (isset($_SERVER['SCRIPT_FILENAME'])
            and $_SERVER['SCRIPT_FILENAME'] != ''
            and isset($_SERVER['DOCUMENT_ROOT'])) {
        return str_replace($_SERVER['DOCUMENT_ROOT'], '', $_SERVER['SCRIPT_FILENAME']) . $path . $query;
    }
    
    return false;
}

if ($requestURI = my_request_uri()) {
    echo $requestURI;
}

?>

Beim Aufruf des Scripts unter http://www.example.com/test.php/my/path?test=123 würde folgendes ausgegeben:

/test.php/my/path?test=123 

Bei Open Source entwickeln wenige zum Nutzen vieler. Wir wenden ein ähnliches Konzept oft bei der Finanzierung von neuen Funktionen für unsere Scripte an. Sogar ganz neue Scripte sind dadurch entstanden. Der Link Manager zum Beispiel.

Wenn Kunden oder potentielle Kunden nach einer bestimmten Funktionalität fragen, erhalten sie ein Angebot. Dieses Angebot enthält den Preis für die Erstellung der Funktion zur exklusiven Nutzung. Soweit so unpsektakulär. Gleichzeitig bieten wir jedoch auch die Möglichkeit eines Preisnachlasses für den Fall an, dass wir die neue Funktion in die offizielle Version des jeweiligen Scripts übernehmen dürfen.

Neben dem bereits erwähnten Kostenvorteil ergibt sich für den Kunden folgender Nutzen:

• Wir pflegen die Funktion im Zuge von normalen Updates weiter.
• Durch die breitere Nutzung fallen Fehler eher auf und werden deshalb auch eher behoben.
• Bei allgemeinem Bedarf kann die Funktionalität sogar noch erweitert werden.
• Der Kunde hat immer eine offizielle Version. Im Falle neuer Versionen muss die Extraanfertigung nicht jedes Mal wieder nachgerüstet werden.

Bis jetzt konnte sich noch kein Kunde diesen Argumenten entziehen. :-)

Vor einer Weile erschien ein Artikel von Jane Copland über Nutzen und Fallstricke von Kurz-URL-Diensten.

Eine Option, die in dem Artikel nicht zur Sprache kommt, ist die Installation eines solchen Scripts auf dem eigenen Server.

Nutzen:

• Man kann (s)eine eigene Domain nutzen
• Man kann das Aussehen des Dienstes den Rest seiner Website angleichen
• Man muss nicht fürchten, dass der Dienst irgendwann eingestellt wird

Fallstrick:

• Die URL ist möglicherweise länger als üblich. Solange diese aber in eine Zeile einer E-Mail passt, sollte einem das keine schlaflosen Nächte bereiten.

Nachdem es hier in letzter Zeit überwiegend positives Feedback von Kunden zu lesen gab, ist's mal wieder Zeit für ausgleichende Gerechtigkeit.

Letztes Jahr im Oktober hatte ein Kunde unser Form Mail Script gekauft. Nach anfänglichen Schwierigkeiten lief das Script dann auch. Abschließend hatte der Kunde noch den Wunsch, dass die E-Mails jeweils an mehrere Empfänger gesendet werden sollen. Wie genau er sich das vorstellte, war mir jedoch nicht ganz klar. Und irgendwie war es auch nicht möglich, mal einen Blick auf die Templates (HTML und Mail) zu werfen.

Nach einigem Hin und Her mit Tipps und Rückfragen waren mittlerweile zwei Monate ins Land gegangen. Nach einer solchen Zeitspanne besteht immer die Gefahr, dass entweder der Kunde die Geduld verliert oder dass die Angelegenheit hier untergeht.

Am 3. Januar schrieb der Kunde seine vorerst letzte E-Mail in der er wissen wollte, mit welchem Zeichen er am besten mehrere Empfänger im Bcc-Header voneinander trennt. Die richtige Antwort wäre das Komma gewesen. Leider habe ich seine E-Mail nie beantwortet.

Dass das keine gute "Idee" war, sollte sich jetzt im September, neun Monate später herausstellen.

Betreff: 10 Months and still trying to get some support

This is really becoming a pain in my ass. I PAID for a product (invoice attached) that I EXPECT to work like it says it should. I can’t even register for your damn forums as when I click the “I agree to the terms button” all it does is refresh the page. It won’t even allow me in to register.

Now, here is my problem again.

I need the freaking form to mail to multiple people, it don’t. Why and how do I fix it.

Ooops.

Es wäre allerdings ganz hilfreich gewesen, wenn der Kunde mal etwas früher nachgehakt hätte. Aber ich stehe dazu, dass die Schuld bei mir liegt und habe mich für den Fauxpas entschuldigt:

You're right. I should have answered your support questions a long while ago. It appears that your e-mail has been overlooked. There is no real excuse for that but I'm getting a lot of e-mails and I occasionally miss an e-mail.

Die Sache hat jedoch einen Haken. Ein rüder Ton mag vielleicht bei anderen ziehen, nicht aber bei mir. Deswegen enthielt meine E-Mail noch folgenden Zusatz:

Anyway, $19 might be a lot of money for some people, but it's not enough for me to read words like "ass" "damn" and "freaking" in an e-mail. Therefore, I'll go ahead and cancel your order and refund your money. There are plenty of other Form Mail Scripts so that you'll have something to fall back on.

Thanks anyway for considering my script in the first place.

Es trudelten hier dann noch eine Hand voll weiterer böser E-Mails ein.

Und was lernen wir aus dieser Geschichte? Leiste vernünftigen Support, sonst machen die Kunden Ärger. Was jetzt allerdings auch wirklich keine bahnbrechende Neuigkeit ist. ;-)

Mal sehen übrigens, ob der (Ex-)Kunde folgende Drohung wahr macht:

Believe me, I will now go out of my way to make posts and reviews on my sites, blogs, article directories and anywhere else that I can find to state what kind of crap you offer.

Einige unser Kurz-URL-Dienste hatten eine kleine Auffrischung der Optik verdient. Bis dato nutzten sie noch das Standard-Layout des Kurz-URL-Scripts. Die Sache war fix erledigt, das Ergebnis kann man gelten lassen und viel gekostet hat's auch nicht (iStockPhoto lässt grüßen).

FlatURL.com

TeenyWeenyURL.com

KleinerLink.de