ScriptBlogger

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. 

Um bei einem aktuellen Projekt zwischen Entwicklungs- und Produktionsumgebung zu unterscheiden, wurde auf dem Entwicklungs-Server eine spezielle Umgebungsvariable hinzugefügt. Im Code wird diese dann mit getenv() oder $_ENV abgefragt. Abhängig vom Wert werden dann verschiedene Bedingungen ausgeführt.

Es gibt drei Methoden, eine PHP-Umgebungsvariable zu setzen.

1. putenv() an einer zentralen Stelle im Code

2. SetEnv in einer .htaccess-Datei

SetEnv FOO bar

3. SetEnv in der Apache-Konfigurationsdatei httpd.conf

SetEnv FOO bar

Am besten dürfte sich Option Nummer 3 machen, da die httpd.conf selten Bestandteil des eigentlichen Projektes ist und damit die Gefahr gering ist, dass die Datei aus Versehen auf den Produktions-Server gelangt.

Ab und an fragen Neulinge im Geschäft, was ein angemessener Stundensatz wäre und wie man den Preis für ein Projekt berechnet. Nichts einfacher als das.

Stundensatz

Um den eigenen Stundensatz zu berechnen muss man wissen, wie viele abrechnungsfähige Stunden man im Monat schafft zu arbeiten. Dann teilt man sein gewünschtes monatliches Einkommen durch die Stundenzahl und voila - man hat seinen Mindeststundensatz. Den kann man dann noch beliebig nach oben anpassen, abhängig von:

• Eigene Fähigkeiten
• Marktgegebenheiten
• Kunde
• Projektlaufzeit

Projektpreis

Wer meint, in der Lage zu sein, den Arbeitsaufwand realistisch einschätzen zu können, multipliziert einfach seinen Stundensatz mit der Zahl der geschätzten Stunden.

Projektpreis = Stunden _* Stundensatz

Das macht man dann so lange bis man seine Rechnungen nicht mehr zahlen kann. Oder man gesteht sich gleich ein, dass das korrekte Schätzen des Arbeitsaufwandes bei Projekten ab einer gewissen Größe nahezu unmöglich ist. Also fügt man am besten eine Konstante ein, die das schlechte Augenmaß wieder ausgleicht.

Projektpreis = Stunden _* Stundensatz _* 2

Zugegeben, das macht einen recht wahllosen Eindruck. Die Erfahrung hat aber gezeigt, dass das dem Ergebnis am nächsten kommt. Wahlweise kann man es gern auch mit 1,5 oder 2,5 probieren.

Die Nutzung der Pear-Klasse Text_Wiki ist relativ simpel und mit wenigen Zeilen Code zu bewerkstelligen:

<?php

// Klasse laden
require_once 'Text/Wiki.php';

// Instanz der Klasse erzeugen
$wiki = new Text_Wiki();

// Beispiel-Wiki-Code
$content = "Dieser Text ist '''fettgedruckt'''.";

// Wiki-Code parsen und ausgeben
echo $wiki->transform($content);

?>

Möchte man stattdessen den Syntax vom MediaWiki verwenden, hilft die Klasse Text_Wiki_Mediawiki.

<?php

// Klasse laden
require_once 'Text/Wiki/Mediawiki.php';

// Instanz der Klasse erzeugen
$wiki = new Text_Wiki_Mediawiki();

// [...]

?>

Wer mit UTF-8 arbeitet, dürfte an dem Ergebnis jedoch wenig Freude haben. Mit Umlauten gibt es standardmäßig Probleme. Abhilfe schafft folgende Zeile:

<?php

// Zeichensatz festlegen
$wiki->setFormatConf('Xhtml', 'charset', 'UTF-8');

?>

Bei der Ausgabe der Inhalte als XHTML wird nämlich die PHP-Funktion htmlentities() ausgeführt. Standardmäßig wird dabei ISO-8859-1 als Zeichensatz verwendet, was bei UTF-8-formatiertem Text die Umlaute zerstört.

Tipp für diejenigen, die automatisch ein Inhaltsverzeichnis auf Basis der Textüberschriften (h2, h3, ...) anzeigen lassen möchten. Dazu fügt man [[toc]] an der Stelle im Text ein, an der die Übersicht erscheinen soll. Wem der Englische Titel "Table of Contents" nicht gefällt, kann mit folgender Zeile seinen eigenen Titel setzen.

<?php

$wiki->setRenderConf('Xhtml', 'toc', 'title', 'Inhaltsverzeichnis');

?>

Heute haben wir mal wieder die Dollar-Preise erhöht, da der US-Dollar schon seit einiger Zeit rund ein Drittel weniger wert ist als der Euro. Die bisher gleichen Preise für Dollar und Euro waren schon lange nicht mehr gerechtfertigt. In den letzten fünf Jahren ist der Preis für den Dollar von knapp 90 Euro-Cent mit einigem Auf und Ab zwischendurch auf jetzt 66 Euro-Cent gefallen. Das ist zwar gut für den Import, für den Export ist das alles andere als Ideal.

Nachdem wir vor einigen Monaten die Preise auf STADTAUS.com und GentleSource entsprechend angepasst haben, sind wir heute beim Schedule Organizer nachgezogen. Dadurch werden die Preise wieder gerechter für alle, die in Euro bezahlen. Denn wer in USD bezahlte, sparte bislang rund ein Drittel des Preises.

Dass PHP die beliebteste Programmiersprache ist, fanden eine handvoll Leute noch interessant. Der Beitrag wurde in ein paar Blogs zitiert und bei Webnews gab es 10 Gummipunkte.

Dass PHP 4 am 08.08.08 in die ewigen Jagdgründe einging interessierte hingegen niemanden, vom harten Kern der PHP-Entwickler mal abgesehen. Während die eingangs erwähnte Umfrage gewissen Zuspruch fand, blieb der Eintrag "Ruhe in Frieden PHP 4" nahezu unbeachtet.

Offensichtlich ist es den meisten Anwendern egal, was unter der Haube werkelt. Hauptsache es funktioniert. PHP 4 oder PHP 5 - wo ist der Unterschied. So oder so ähnlich dürfte die Antwort bei entsprechender Nachfrage lauten. :-(

Heute ist der 8. August und damit endet die Ära "PHP 4". Wie das PHP-Entwicklungs-Team letztes Jahr im Juli angekündigt hat, wird PHP 4 nach dem 8. August 2008 nicht mehr weitergepflegt. Neue Funktionen gab es schon seit letztem Jahr nicht mehr und unkritische Fehler wurden seitdem ebenfalls nicht mehr behoben.

Damit endet die vierjährige Übergangsphase von PHP 4 auf PHP 5. Endlich, möchte man sagen, denn für viele PHP-Entwickler bedeutete die Übergangszeit, zweigleisig fahren zu müssen. Während einige Kunden bereits nach Funktionen verlangten, die es nur in PHP 5 gab, musste auf Kunden Rücksicht genommen werden, deren Web-Server noch mit PHP 4 unterwegs waren.

Und selbst ein Jahr nach der Ankündigung der PHP-Entwickler hat eine große Zahl von Web-Hostern immer noch nicht umgestellt. Prinzipiell ist das für uns kein Problem. Dann halten wir unsere Scripte eben noch eine Weile länger rückwärtskompatibel. Leider funktioniert das nicht bei allen Scripten. Der Schedule Organizer zum Beispiel nutzt eine Funktion, die in PHP 4 fehlerhaft ist und nur in PHP 5 "repariert" wurde. Bisher war das allerdings noch kein Problem. Alle Kunden, bei dem sich der Fehler bemerkbar gemacht hat, konnten auf PHP 5 umsteigen. :-)

Bleibt zu hoffen, dass PHP 6 sich nicht ganz zu viel Zeit mit der Ablösung von PHP 5 lässt. Ein Jahr Übergang wäre völlig ausreichend. Man wird sehen. B-)

Dem einen oder anderen Zeitgenossen erschließt sich der Zweck eines Wegwerf-E-Mail-Dienstes wie unser IncognitoMail nicht immer gleich. Und manchmal werden wir gefragt, ob unser Dienst nicht vielleicht von Spammern missbraucht werden könnte.

Die Antwort: Spammer senden eine riesige Menge an E-Mails an eine ebenso riesige Menge von Empfängern. Unser Dienst ist dafür denkbar schlecht geeignet. Der einzige Weg, mit IncognitoMail eine E-Mail zu versenden, ist die Antwort-Funktion. Und die ist mit Akismet und einer Captcha-Funktion gesichert.

Damit ein Spammer mit dem Dienst eine Spam-Mail an einen einzigen Empfänger absetzen kann, müsste er folgende Schritte durchlaufen:

1. Neue Wegwerf-E-Mail-Adresse auf IncognitoMail generieren
2. Eine E-Mail mit der späteren Empfänger-E-Mail als Absender an die Wegwerf-Adresse schicken
3. Diese E-Mail bei IncognitoMail abrufen und auf Antworten klicken
4. Text in das Feld schreiben/kopieren
5. Captcha korrekt ausfüllen
6. Formular absenden
7. Jede ausgehende E-Mail wird mit Hilfe von Akismet auf Spam überprüft.

An dieser Stelle hat der Spammer gerade mal eine E-Mail an einen Empfänger geschickt. Viel zu kompliziert und zeitaufwändig. Deshalb nutzen Spammer in der Regel Bot-Netze mit Zombie-Rechnern oder offene Mail-Server, um ihre Spam-Nachrichten an Millionen von E-Mail-Adressen zu schicken. Und das in einem Zeitrahmen von wenigen Minuten und Stunden.

Aus diesen Gründen betrachten wir IncognitoMail und auch unser dahinter arbeitende Wegwerf-E-Mail-Script als Spam-sicher. Das heißt nicht, dass das Script auch mal von zwielichtigen Gestalten benutzt wird. Aber das ist eine andere Geschichte.

Nicht nur Anwender schreiben merkwürdige Dinge. Hier eine Antwort auf eine Support-Anfrage zum Schedule Organizer (vorletzter Satz):

When switching between appointment areas the value of the current week is being passed on. This won't work well if area B has a $future_last of 10 weeks but area A has only 3. The user will arrive in week 10 of area A only to realize that there is no week 10 in area A. Kind of a twilight zone.