Artikel

PHP Lokal unter Windows

Wer PHP-Scripte lokal austesten will, muß sich dafür auf seinem Rechner einen Webserver installieren und PHP einbinden. Manche Scripte laufen dann aber dennoch nicht korrekt. Welche Konfigurationshürden mitunter dann noch genommen werden müssen, versuche ich hier zu beschreiben.

Es läuft! Wenn man diese Seite des Apache sieht ist man schon mal froh. Die erste Hürde geschafft. PHP noch hinzugefügt. Die erste PHP-Seite geöffnet und auch diese läuft. Hurra, dann müßte eigentlich alles laufen. Doch was ist das: Bei einem Script das man aus dem Internet heruntergeladen hat, funktioniert etwas nicht. Hat der Scriptautor einen Fehler gemacht, oder habe ich etwas falsch gemacht. Bei meinem Webhoster läuft das Script fehlerfrei. Was kann also los sein?

Alle folgenden Konfigurationseinstellungen die ich erläutere, beziehen sich auf die Datei php.ini. Die im allgemeinen unter Windows bei der Installation von PHP in das Systemverzeichnis, also z. B. C:\Windows oder C:\WINNT gesetzt wird.

Eine erste Stolperfalle kann sich bei Benutzung von Sessions ergeben. Standardmäßig ist in der php.ini der Wert für session.save_path auf /tmp gesetzt. Dies funktioniert unter Unix/Linux Systemen problemlos. Dieser Wert gibt an, wo die Sessioninformationen im Dateisystem des Servers abgespeichert werden sollen. Unter Windows gibt es aber diesen Pfad nicht. Daher müssen Windowsnutzer diesen Pfad entsprechend ihrem System anpaßen. Gültige Angaben können z. B. sein: C:\WINDOWS\TEMP oder C:\WINNT\TEMP. Letzlich muß irgend ein Ordner auf dem Rechner angegeben werden, in dem temporäre Dateien abgelegt werden können.

Ein weiterer Hemmschuh kann register_globals sein. Was hat es mit dem in letzter Zeit in PHP-Kreisen vieldiskutierten Thema mit register_globals auf sich?

PHP wollte es dem Programmierer einfach machen. Der Name eines Formularelements in HTML wird bei der Verarbeitung in PHP einfach als Variablenname übernommen. Dies geschieht indem die Variable als global definiert wird. Diese Methode warf in letzter Zeit jedoch auch Sicherheitsbedenken auf, da es dadurch möglich ist, sehr einfach falsche Daten an ein Script zu schicken. Ist das Script schlampig programmiert, könnte dies, je nachdem was mit den Daten gemacht wird, fatale Folgen haben. Um die Sicherheit zu erhöhen ist daher seit PHP 4.2 der Wert von register_globals Standardmäßig auf OFF gesetzt. Dadurch ist es nicht mehr möglich, daß eine Variable von außen einen beliebigen Wert zugewiesen bekommt. Der Zugriff geschieht nun über spezielle Array's (Array's sind Datenlisten) die auch unterscheiden ob Daten beispielsweise via GET oder via POST gesendet wurden. Das Problem daran: Viele Scripte wurden nicht daraufhin optimiert mit register_globals auf OFF zu arbeiten. Bei allen mir bekannten Webhostern ist die Standardeinstellung von register_globals unabhängig von der verwendeten PHP-Version auf ON eingestellt. Somit gibt es bei diesen Webhostern auch mit diesen Scripts keine Probleme. Wenn jedoch eine PHP-Version ab 4.2 lokal benutzt wird ist register_globals erst mal auf OFF gesetzt. Die von mir angebotenen Scripts funktionieren inzwischen alle auch noch wenn register_globals auf OFF steht. Falls es jedoch mit anderen Scripts Probleme gibt, sollte man es mal mit der Einstellung ON probieren.

Eine weitere Problemquelle kann der Mailversand sein. Auf Unix/Linux-Systemen erfolgt der Mailversand von Scripts im allgemeinen über das Programm Sendmail. Dieses ist in der php.ini auch schon vorkonfiguriert. Wer Windows nutzt muß stattdessen aber einen SMTP Server zum Mailversand angeben. Dazu muß in der php.ini die Adresse des SMTP-Servers unter SMTP angegeben werden und unter sendmail_from eine Emailadresse welche als Absender dient.

Wer sich dafür gleich auch noch zum Webserver einen SMTP-Server ebenfalls lokal installieren will, dem kann ich zu diesen Zweck beispielsweise den PostCast Server empfehlen. Der PostCast Server ist ein Freeware SMTP Server für Windows.

Eine weitere Fehlerquelle: Ein zu scharf geschaltetes Error-Reporting. Das Errorreporting wird in der php.ini festgelegt und bestimmt ob beispielsweise nur Fehler gemeldet werden, die zum Abbruch führen oder auch Warnungen ausgegeben werden oder sogar jede "Unregelmäßigkeit" die während der Laufzeit des Scripts auftritt. Ein sauber programmiertes Script sollte auch bei noch so scharf geschalteten Error-Reporting keine Fehlermeldungen produzieren. Was aber wenn man es mal mit einem nicht so sauber programmierten, aber prinzipiell lauffähigen Script zu tun hat? Hier kann man einfach mal in der php.ini nachsehen wie der Wert für error_reporting ist. Standard ist das sowohl kritische Fehler als auch Warnungen, aber nicht Laufzeitnotizen (z. B. nicht gesetzte Variable) gemeldet werden. Mit dieser Einstellung dürfte es keine Fehlermeldungen geben. Falls auch Laufzeitnotizen ausgegeben werden (z. B. ungesetzte Variable) kann man den Wert auf: E_ALL & ~E_NOTICE verändern.

Autor des Artikels: René Maroufi, php2009@maroufi.net

Weiterführende Links:
PostCast Server als lokaler SMTP Server
PHP Konfiguration auf www.php.net

Zurück

Wenn Sie stets über Updates meiner Scripte informiert werden wollen, können Sie den Newsletter bestellen. Der Newsletter informiert ausschließlich nur über das neueste zu meinen PHP-Scripts und erscheint daher unregelmäßig, je nachdem wie häufig es Updates gibt.

Wenn Sie den Newsletter bekommen wollen, können Sie sich hier eintragen:

Aus dem Newsletter wieder austragen.

Wer macht diese Seite?