ScriptBlogger

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 

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

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>

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.

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.

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.

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');

?>

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-)

Im Online-Demo für unser Voting-Script fragen wir schon seit Jahr und Tag, in welcher Sprache der Besucher am liebsten programmiert. Das Ergebnis können wir ohne weiteres nachvollziehen. ;-)

ASP		253	5,62 %
Assembler		91	2,02 %
Basic		146	3,24 %
C/C++		326	7,24 %
Cobol		122	2,71 %
Fortran		127	2,82 %
Java		298	6,62 %
JavaScript		272	6,04 %
Pascal		141	3,13 %
Perl		138	3,07 %
PHP		1642	36,47 %
Prolog		74	1,64 %
Python		82	1,82 %
Visual Basic		189	4,20 %
Ich programmiere nicht		601	13,35 %

Stimmen gesamt: 4502

So ganz verlässlich ist diese Statistik natürlich nicht. Der eine oder andere Besucher wird das Script wirklich nur ausprobieren wollen und wahllos abstimmen.

Früher wurde alles noch manuell gemacht. Da haben wir Infos abgetippt oder bestenfalls kopiert und eingefügt. Bei einem Projekt zum Beispiel musste einmal in der Woche das Kinoprogramm auf den neuesten Stand gebracht werden. Die Daten kamen per Fax. :-O

Irgendwann hat's dann gereicht. 200 Zeilen PHP übernehmen nun den Job und "ziehen" sich die Daten automatisch von den offiziellen Kino-Websites. Ein Knopfdruck und keine 3 Sekunden später ist die Sache erledigt und das Kinoprogramm aktualisiert und online verfügbar.

Schon klar, das ist keine große Sache. Aber manchmal sind es die kleinen Dinge, die einem den Alltag angenehmer machen. ;-)

Ständig produzieren die Server von Domainfactory und Domaingo - Webspace und Managed Server - folgende Fehlermeldung:

Notice: session_start(): ps_files_cleanup_dir: opendir(/tmp) failed: Permission denied (13)

Lösungsvorschlag vom Support: Den Speicherort für die Session-Dateien per php.ini ändern oder Notices per error_reporting ausblenden. Beides wird sicherlich funktionieren, löst aber die Ursache des Problems nicht. :-(

Es gibt mindestens zwei Gründe warum man seinen Webhoster bitten sollte, auf PHP 5 zu aktualisieren.

Als erstes wären die verbesserten Leistungsmerkmale zu nennen. PHP 5 verarbeitet Scripte schneller und stabiler als PHP 4.

Und zweitens: Seit 1. Januar 2008 wird PHP 4 nicht mehr offiziell weiterentwickelt. Es werden nur noch kritische Sicherheitslücken geschlossen und die auch nur noch bis zum 8. August 2008. Neue Funktionen und unkritische Bug-Fixes werden nicht mehr in PHP 4 einfließen.

Letzteres betrifft zum Beispiel unseren Schedule Organizer, wie mehrere Support-Anfragen gezeigt haben. Ein Fehler in der Funktion html_entity_decode() verursacht eine Warnmeldung beim Aufruf des Scripts. Der Fehler wurde in PHP/5 behoben, nicht jedoch in PHP 4.

Wenn also Ihr Script folgende Warnmeldung anzeigt, ist es Zeit für das Update auf PHP 5:

Warning:  cannot yet handle MBCS in html_entity_decode()! [...]

Hier noch die Meldung der PHP Group, dass PHP 4 nicht mehr weitergepflegt wird und sich eine Aktualisierung auf PHP 5 empfiehlt.

PHP 4 end of life announcement [13-Jul-2007]

Today it is exactly three years ago since PHP 5 has been released. In those three years it has seen many improvements over PHP 4. PHP 5 is fast, stable & production-ready and as PHP 6 is on the way, PHP 4 will be discontinued.

The PHP development team hereby announces that support for PHP 4 will continue until the end of this year only. After 2007-12-31 there will be no more releases of PHP 4.4. We will continue to make critical security fixes available on a case-by-case basis until 2008-08-08. Please use the rest of this year to make your application suitable to run on PHP 5.

For documentation on migration for PHP 4 to PHP 5, we would like to point you to our migration guide. There is additional information available in the PHP 5.0 to PHP 5.1 and PHP 5.1 to PHP 5.2 migration guides as well.

Für 1&1 scheint das Versenden von E-Mails mittels PHP-Script eine Herausforderung darzustellen. Es wird Zeit, dass der Hoster diese endlich mal annimmt und die Probleme löst.

Bei E-Mails, die von unseren Projekten versandt werden, fehlt sporadisch der korrekte Absender. Stattdessen steht dort "CGI-Mailer". Unsere Kunden wiederum klagen über ernstere Probleme wie Timeouts beim Versenden von E-Mails. Das nervt nicht nur gewaltig, sondern kann unter Umständen auch Geld kosten.

Alternativ könnte man die E-Mails über einen anderen Server per SMTP versenden. Falls die Probleme anhalten, werden wir das sicherlich ausprobieren.