ScriptBlogger

Gerade kam 'ne E-Mail von Tausendreporter .

[...] ein Administrator von Tausendreporter hat den Status Ihres Beitrags 
aus folgendem Grund geändert: spam

Gemeint war der Beitrag rel="nofollow" gehört verboten. Was an diesem Beitrag Spam sein soll, weiß wohl nur der Admin bei Tausendreporter. Absender der E-Mail war übrigens webmaster@pligg.com.

Tipp 1 an Tausendreporter: Beiträge (genau) lesen.

Tipp 2 an Tausendreporter: Pligg vernünftig konfigurieren.

Das freut doch zu lesen.

Sehr geehrte Damen und Herren,

wir haben letzte Woche eine Form-Mail Lizenz erworben und sind vom Script sehr begeistert. [...]

:-)

Kein Spammer schert sich darum, ob Links das Attribut rel="nofollow" besitzen oder nicht. Spammer scheren sich nicht mal darum, ob ein Formular überhaupt Felder für Links enthält oder ob ein Link auch tatsächlich auf der Seite erscheint. Formulare jeglicher Art werden wahllos mit Spam zugeschüttet. Das von Google erfundene Attribut ist völlig nutzlos.

Und wen triffts am Ende wieder mal? Den normalen Anwender. Man zwingt ihm JavaScript auf, um Kommentare schreiben zu können. Man stellt ihm unlesbare Captcha-Bilder in den Weg. Man gibt ihm Rechenaufgaben auf. Man sagt ihm, dass er bestimmte Felder ausfüllen muss, andere Felder aber auf keinen Fall ausfüllen darf. Und am Ende belohnt man ihn noch nicht einmal mit einen vernünftigen Link. 

Es wird Zeit, dass dieser Link-Geiz ein Ende hat. 

Subversion ist nicht nur generell ganz hilfreich, es macht sich auch besonders gut, wenn man in einem Branch eine neue Funktion einbauen möchte und später Branch und Trunk wieder zusammenfügen möchte.

Wir nutzen hier Tortoise SVN, welches das Arbeiten mit Subversion zum Kinderspiel macht. Was das Zusammenfügen zweier verschiedener Entwicklungsbäume angeht, ist die Doku allerdings nicht hundertprozentig klar.

In both the From Revision field and the To Revision field, enter the last revision number at which the two trees were synchronized. 

Oder mit anderen Worten, man fügt Branch und Trunk an der Stelle (Revisionsnummer) wieder zusammen, an der man Branch und Trunk ursprünglich getrennt hat.

Ist ja auch logisch. Subversion wird erst die Änderungen aus dem Branch in den seinerzeit unveränderten Trunk übertragen und dann die am Trunk gemachten Änderungen sukzessive nachholen. Im Buch "Version Control with Subversion" ist das Vorgehen übrigens besser erklärt.

Der Scriptblogger arbeitet so selten per Kommandozeile auf dem Server, dass er jedes mal die Kommandos für crontab und vi nachsehen muss. Damit er sich für die Zukunft das Suchen spart, sind hier die wichtigsten Kommandos aufgeführt:

Von Zeit zu Zeit tauchen in Weblogs oder Foren Listen mit Wegwerf-E-Mail-Diensten auf. Von diesen Dingern kann man übrigens nicht genug Auswahl haben, denn die Domains werden öfters mal von Website-Betreibern blockiert.

Viele Dienste dieser Art haben eine äußerst geringe Halbwertzeit, wie oben verlinkte Liste beweist. Ein guter Teil der Seiten ist nicht mehr erreichbar oder zeigt völlig andere Inhalte.

Und jetzt wird's interessant. Auf der Liste befinden sich mehrere Websites, die unser Wegwerf-E-Mail-Script einsetzen, und das gilt es zu zelebrieren. Wer zuerst die korrekte Anzahl dieser Websites in den Kommentaren hier unter dem Artikel schreibt, erhält eine Script-Lizenz kostenlos. Wichtig: E-Mail-Adresse zur Kontaktaufnahme nicht vergessen.

Nachtrag: Gewinnspiel beendet - Gewinner benachrichtigt

Aus dem Support:

Danke für Ihre Mühe und vor allem sensationell schnellen Reaktion, Wahnsinn!

B-)

Meistens hören wir von unseren Kunden und Nutzern nur, wenn Sie Probleme mit ihrem Script haben. Deshalb ist uns in den meisten Fällen auch gar nicht bekannt, ob das Script überhaupt noch in Benutzung ist.

Letztens kam mal wieder eine Bestellung aus Sleepy Hollow. Im darauf folgenden E-Mail-Verkehr trudelte dann dies hier ein:

A former coworker of mine got the schedule organizer for another building in my district in 2005. They are still using it today.

:-)

Im Großen und Ganzen ist phpMyAdmin schon in Ordnung, besonders wenn man bedenkt, wie viel Arbeit die Entwickler dort bereits hineingesteckt haben. Wenn man nicht gerade große Mengen an Daten im- oder exportieren muss, kann man mit phpMyAdmin Datenbanken administrieren, ohne jemals eine Eingabeaufforderung angefasst zu haben.

Wenn man allerdings ständig mit phpMyAdmin arbeitet, stößt man häufiger auf Dinge, die manchmal ganz schön nerven. Aber die phpMyAdmin-Entwickler schlafen nicht. Version 3.0.0 beta ist verfügbar und der eine oder andere Lichtblick ist zu erkennen.

Trotzdem.

Upload dauert Ewigkeiten

Der Umfang der aktuellen Version des Scripts beträgt etwas über 4 MB und rund 570 Dateien. Ohne Sprachdateien, wohlgemerkt. Mit Sprachdateien sind es knapp 13 MB, aber selbst Schuld wer die alle auf seinen Server lädt. Schnell mal auf den Server schieben ist also nicht.

Doppelter Index Key Warnung

Für jedes Feld, das mehrfach in einem Index vorkommt, zeigte phpMyAdmin eine Fehlermeldung an. Dabei gibt es dafür technisch gar keinen Grund, im Gegenteil. Mehrfach in Indices vorkommende Datenbankfelder sind nichts ungewöhnliches. Spätestens seit Version 2.11.8.1 gehören diese Warnungen allerdings der Vergangenheit an.

Select-Menü funktioniert nicht

Ein eher bizarres Problem. Wen man einen Datensatz bearbeitet, hat man die Möglichkeit, den Datensatz entweder zu speichern oder als neuen Datensatz in einzufügen. Im Mozilla lässt sich das Select-Menü nicht mit der Maus ändern, sondern man muss die Änderung per Pfeiltasten vornehmen. In der neuen 3er Version ist der Fehler erfreulicherweise behoben.

Bei EXPLAIN werden die Inhalte abgeschnitten

Mit EXPLAIN SELECT ... kann man sich anzeigen lassen, welche möglichen Indices der Optimizer von MySQL zur Verfügung hat und welchen Index dieser dann am Ende verwendet hat. Wenn die Liste der Indices recht lang ist, beschränkt phpMyAdmin die Anzeige auf eine bestimmte Zahl von Zeichen. Üblicherweise kann man die Felder mit Klick auf <- T -> "expandieren". Genau das aber funktionierte im "EXPLAIN-Modus" nicht. Ab Version 3.0.0 gibt es nun ein Optionsmenü, das dies ermöglichen wird.

Bei EXPLAIN fehlt der Refresh-Link

Bei normalen SQL-Abfragen zeit phpMyAdmin einen Link zum Neuladen der Seite an. Da das Script als Frame-Konstruktion daherkommt, ist der Link recht hilfreich. Im "EXPLAIN-Modus" fehlt dieser Link allerdings. Ab Version 3.0.0 kann man sich mit dem Optionsmenü behelfen und die Seite mit Klick auf den Formular-Button neu laden.

Strg+Pfeiltaste funktionieren nicht wie erwartet

Mit Strg+Pfeiltaste springt der Cursor in einem Eingabefeld normalerweise von Wort zu Wort. Nicht so bei phpMyAdmin wenn man einen Datensatz bearbeitet. Dort springt der Cursor zwischen den Feldern hin und her. Tastenkombinationen einbauen ist ja gut und schön, aber bestehende Tastenkombinationen klauen ist nicht die feine Englische Art.

Fazit

Offensichtlich sind die genannten Problemchen noch nicht nervig genug, sonst hätten wir sicherlich schon längst mal die Bugs gemeldet oder ein Patch erstellt. Aber die Entwickler von phpMyAdmin sind auch alleine schlau, wie man sieht. ;-) phpMyAdmin 3.0.0 ist unterwegs und findet hoffentlich bald den Weg zu den Webhostern und auf deren Server.

API-Keys (oder auch API-Hashes) gibt es allerorten. Man benötigt zum Beispiel einen, um Google Maps in seine Website einzubinden. Für Akismet braucht man ebenfalls einen. Die Liste ließe sich beliebig fortsetzen. Die Betonung liegt hier übrigens auf einem Api-Key. Kürzlich hatten wir es jedoch gleich mit drei API-Keys für dieselbe Anwendung zu tun. 

Ein Kunde von uns tauscht regelmäßig und automatisch per E-Mail Informationen mit seinen Geschäftspartnern aus. Die Zahl der teilnehmenden Partner ist dabei so groß, dass eine Standardisierung des E-Mail-Formats nicht möglich ist. Das ist auch kein Problem, denn die Systeme passen sich dann eben den E-Mails an. Das ist technisch keine große Hürde und funktioniert schon seit Jahren zuverlässig.

Ein neuer Geschäftspartner übermittelte kürzlich zusammen mit der eigentlichen E-Mail-Formatvorlage auch gleich noch drei API-Keys. Der erste war Teil der Ziel-E-Mail-Adresse. Der zweite war dem Geschäftspartner zugeordnet. Und der Dritte gehörte zu unserem Kunden. Alle drei Keys waren Bestandteil der E-Mail. :-o

Nun ja, die werden schon Ihre Gründe dafür haben, aber technisch sollte eigentlich auch ein einziger API-Key ausreichen. Alles andere schafft nur Verwirrung und erhöht die Fehleranfälligkeit. Weniger ist also mehr oder um es mit J.R.R. Tolkien zu sagen: One key to rule them all. :-)

Im Kunden-Support zu arbeiten ist nicht jedermanns Sache. Stets freundlich sein und immer die richtige Antwort wissen kann auf Dauer recht anstrengend sein. Darunter leidet nicht nur die Motivation des Support-Mitarbeiters sondern im Endeffekt auch die Qualität der Support-Arbeit selbst.

Richtig problematisch wird es dann, wenn Support nur einen Teil der Arbeit ausmacht. Da verdrängen dann vermeintlich wichtigere Dinge die Support-Arbeit. Anfragen stauen sich ungelesen und unbearbeitet auf und am Ende sind alle nur noch genervt.

Deshalb ein Tipp an dieser Stelle: Viele Support-Anfragen sind schneller erledigt als man denkt. Und wenn man erst einmal mittendrin ist, dann fällt es einem auch einfacher, die größeren Brocken zu bearbeiten. Wichtig dabei ist, Anfragen sofort beim Eintreffen zumindest erst einmal zu lesen. Wirklich Aufwändiges oder Kompliziertes lässt sich dann immer noch zurückstellen. Aber hoffentlich nicht zu lange. ;-)

Ein Kunde von uns betreibt eine Geschäftsplattform, die zwar einen halben Tag Auszeit verkraften kann, danach wird es aber kritisch. Um für den Fall der Fälle gewappnet zu sein, wird stündlich eine Sicherheitskopie der Datenbank erstellt. Zudem gibt es von der Anwendung generierte Dateien, die einmal wöchentlich gesichert werden.

Die Datenbank ist knapp ein Gigabyte groß; das ergibt eine rund 130 Megabyte große Zip-Datei. Bei den Dateien kommen wir insgesamt auf über 12.000 Stück - gepackt sind das 180 Megabyte. Die Backups werden dann regelmäßig per FTP auf einen Backup-Server übertragen.

Wir sind vor kurzem den Prozess der Wiederbelebung mal durchgegangen. Zuerst wurde die aktuelle Version der Anwendung auf den für den Ernstfall bereitstehenden Server übertragen. Rund 600 Dateien. Dann die Datenbank eingerichtet und das Datenbank-Backup eingespielt. Als nächstes wurden die von der Anwendung erstellten Dateien in das entsprechende Verzeichnis entpackt.

Das Ganze hat keine Stunde gedauert. Nun kann eigentlich gar nichts mehr passieren. B-)

Als Anbieter von Scripts für den Massenmarkt bekommt man hautnah den jeweils aktuellen Trend in der Branche mit. Vor ein paar Jahren zum Beispiel haben viele Anbieter die PHP-Funktion popen() gesperrt. Also schwenkten wir um und nutzen in unseren Scripten seitdem ausschließlich mail() zum E-Mail-Versand.

Aktuell heißt die Mode Return-Path. Der Mail-Header Return-Path enthält die E-Mail-Adresse, an die im Fehlerfall die Rückmeldung (Bounce) gesendet wird. Immer mehr Webspace-Provider verlangen, dass von Scripten versandte E-Mails diesen Header beinhalten. Und manche Provider benachrichtigen sogar ihre Kunden darüber.

Eine Sache kam jedoch nie in Mode: Register_globals = Off. ;-)

Das Testen von E-Mail-Funktionen mit richtigen E-Mails kann auf die Dauer recht umständlich sein. Man muss immer eine existierende E-Mail-Adresse verwenden und Zugriff auf das entsprechende E-Mail-Konto haben. Und wenn die E-Mail nicht gleich im Konto auftaucht, stellt sich die Frage, wo das Problem liegt. Bei der Anwendung, die man gerade testet, oder bei einem der Server unterwegs?

Mit einem lokalen Mail-Server ließe sich der "Mittelsmann" ausschalten, aber es geht noch einfacher: Die E-Mails werden einfach in eine Log-Datei geschrieben.

Als erstes legt man dazu eine PHP-Datei an, die den PHP input stream anzapft:

maillogger.php

<?php

$filename = '/temp/maillogger.txt';
$stdin = fopen('php://stdin', 'r');
$in = '';

while (!feof($stdin)) 
{
    $in .= fread($stdin, 1024); // read 1kB at a time
}

if ($in != '') {
   $in .= "\n\n--------------------------------------------------------------------\n\n\n";
   if (!$handle = fopen($filename, 'a')) {
         exit;
   }

   if (fwrite($handle, $in) === FALSE) {
       exit;
   }
    
   fclose($handle);
}

?>

Als nächstes benötigen wir eine Datei, welche die Datei maillogger.php bei Bedarf aufruft. Unter Windows wäre dies eine Batch-Datei mit folgendem Inhalt:

maillogger.bat

@echo off
c:\php\php.exe -f "c:\www\maillogger.php"

Die Pfade müssten noch den entsprechenden Gegebenheiten angepasst werden.

Zu guter Letzt muss noch der sendmail_path in der php.ini gesetzt werden.

sendmail_path = "c:\www\maillogger.bat"

Fertig. Alles in allem nur zwei kleine Dateien und ein Eintrag in der php.ini.

Das Umziehen eines gesamten MySQL-Datenbank-Servers unter Windows XP gestaltet sich erfreulich einfach.

Schritt 1

MySQL auf der neuen Maschine installieren.

Schritt 2

Den MySQL-Dienst auf der neuen Maschine anhalten.

Schritt 3

Das Verzeichnis, in dem MySQL auf der neuen Maschine installiert ist, in einem Datei-Manager aufrufen und eine Sicherheitskopie des Verzeichnisses /data/ anlegen.

Schritt 4

Das Verzeichnis, in dem MySQL auf der alten Maschine installiert ist, in einem Datei-Manager aufrufen.

Die Datenbanken befinden sich im Verzeichnis /data/. Die MyISAM-Tabellen (.MYI, .MYD) und die Dateien mit den Eigenschaften aller Tabellen (.frm) befinden sich in den Verzeichnissen. Die InnoDB-Tabellen hingegen befinden sich in der Datei ibdata1. Es können übrigens auch mehrere ibdata-Dateien existieren.

Jetzt kann man die Datei ibdata1 und die Verzeichnisse in das Verzeichnis /data/ kopieren. Dass dabei die Verzeichnisse (Datenbanken) mysql und test überschrieben werden, hat keine negativen Auswirkungen. Zumindest sind bei uns danach im täglichen Betrieb keine Probleme zu Tage getreten. Zur Not hat man ja immer noch die Sicherheitskopie.

Nicht überschreiben darf man die ib_logfile-Dateien. MySQL kann es gar nicht leiden, wenn diese Dateien ohne ihr Wissen geändert werden. Auch alle anderen Dateien (.err, .pid) können in Ruhe gelassen werden.

Fazit

Wer einen neuen Webserver aufsetzt (z.B. als Test- oder Entwicklungsumgebung) hat mit dem Übertragen der Datenbanken auf den neuen Rechner wirklich ein leichtes Spiel. Das Schreiben dieser Anleitung hat länger gedauert als das Installieren von MySQL und das Kopieren der Datenbanken selbst.