Nach wie vor lässt sich der docroot des Webservers über ein http://localhost/~username aurufen, aber PHP läuft dort nicht mehr und ein installiertes MySQL unter /usr/local/ ist auf den ersten Blick auch nicht mehr da. Was ist passiert?

Der neue Apache

Der Apache Webserver wurde auf die Version 2.2.11 aktualisiert. Damit wurden jedoch die Einstellungen in der httpd.conf und vor allem unter /extra/httpd-vhosts.conf zurückgesetzt. Das bedeutet, trotz eines mitgelieferten PHP 5.3 funktionieren PHP-Dateien im docroot unter /Users/{username}/Sites/ erstmal nicht. Eine Abhilfe schafft ein kurzer Sprung in die Konsole, um in der Apache-Konfiguration das Laden des PHP-Moduls wieder zu aktivieren (Bei solchen Sachen lohnt es sich, immer mal ein Backup der aktuellen Konfiguration anzulegen):

#~> sudo cp /private/etc/apache2/httpd.conf .
    ~/backup/httpd.conf.20090909.001
#~> sudo vi /private/etc/apache2/httpd.conf

In der Datei suchen wir nach der Zeile, in der das PHP-Modul geladen wird. Die Zeile muss etwa so aussehen:

#LoadModule php5_module    libexec/apache2/libphp5.so

Durch Entfernen des vorangestellten #-Zeichens und einem Neustart des Apaches wird nun das PHP-Modul geladen. Danach sollte eine im docroot des Webservers abgelegte PHP-Datei mit dem Aufruf der Funktion phpinfo() brav die nagelneue Version 5.3 anzeigen.

Aktivieren der php.ini

Bei einem Blick in die Aufstellung in der PHPInfo stellen wir fest, dass keine php.ini-Datei geladen wird. Stattdessen verwendet das Modul die Standardeinstellungen. Im Verzeichnis /private/etc/ finden wir aber mehrere inaktive Versionen, die wir schnell aktivieren können:

#~> ls /private/etc/php.in*
/private/etc/php.ini.default
/private/etc/php.ini-5.2-previous
/private/etc/php.ini.default-5.2-previous
#~> cd /private/etc/
#~> sudo cp php.ini.default php.ini
#~> sudo chmod u+w php.ini
#~> sudo apachectl restart

Jetzt können wir an der Datei Änderungen vornehmen. Eine wichtige Neuerung in PHP5.3 ist sicherlich das Date/Timezone-Objekt. Das wirft nämlich massenweise Kompatibilitätsfehler aus, wenn Applikationen noch mit den date()-Funktionen von PHP5.2 und kleiner arbeiten. Um diese Fehler zu verhindern, sollte in der php.ini zumindest die Standard-Timezone gesetzt werden. Die unterschiedlichen Angaben (für Europa) findet man in der PHP-Dokumentation. Man öffnet die php.ini, sucht die Definition für date.timezone im Abschnitt [date], setzt den Wert entsprechend (bei mir Europe/Berlin) und kommentiert die Zeile aus. Nach Speichern der Datei und eines Neustarts des Apaches sollten die Fehler verschwunden sein. Ich rate jedoch jedem Entwickler, sich die Definition des neuen Date/Timezone-Objektes anzusehen.

MySQL

Ich hatte vorher eine eigene MySQL-Installation unter /usr/local/mysql laufen. /mysql war dabei ein symbolischer Link auf die Bibliotheken unter mysql-5.0.1a-osx10.5-x86. Das Snow Leopard Update hat zwar die Bibliotheken wiederhergestellt, aber den symbolischen Link vergessen:

#~> cd /usr/local/
#~> sudo ln -s mysql-5.0.1a-osx10.5-x86 mysql

Nebenbei sollte ich die MySQL-Version vielleicht auch einmal aktualisieren – zunächst mal klappt aber wieder der Zugriff über den Client.

PHP kann aber noch nicht auf MySQL zugreifen. Zunächst sind in der php.ini die entsprechenden mysql-Module freizuschalten (im Bereich Dynamic Extensions). Danach erscheint der Abschnitt MySQL zwar wieder brav in der phpinfo, es konnte jedoch immer noch keine Verbindung zur lokalen Datenbank hergestellt werden. Das liegt daran, das in der php.ini.default der Wert für das mysql.default_socket auf /var/mysql/mysql.sock steht. In meiner Installation liegt das Socket aber unter /private/tmp/mysql.sock. Schnell den Wert ändern, Apache neu starten und der Zugriff auf die lokale MySQL-DB klappt wieder:

mysql.default_socket = /private/tmp/mysql.sock
mysqli.default_socket = /private/tmp/mysql.sock

Von meinen virtuellen Hosts hatte ich ausreichend Backups, darum war die Wiederherstellung der httpd-vhosts.conf nicht so schwer. Wer lokale TLDs verwendet und die Zugriffe durch Einträge in der /private/etc/hosts ermöglicht, muss übrigens die hosts-Datei nicht noch einmal anfassen: Die Einträge darin werden von Snow Leopard übernommen.

Danke für die Hilfe

Sehr viel geholfen haben mir dabei die Einträge von tady im WordPress-Forum und der Artikel Snow Leopard: Umstiegshürden eines Web-Entwicklers in Wookkies Blog. Danke dafür.

Ich weiss, dass ihr alle in Mac OS X unterwegs seid und finde das auch ganz toll, aber bitte, bitte nehmt euch die paar Sekunden und erstellt saubere ZIP -Archive, die auf beliebigen Systemen einfach auspackbar sind. Ich verzweifle besonders, wenn es sich um komplexere Daten (wie z. B. Webseiten-Dummies oder Prototypen) mit mehreren Verzeichnissen und Dateien handelt.

Ja, ich weiss mir selbst zu helfen, aber es erweckt bei mir immer den Anschein einer leichten Inkompetenz, wenn ich ein ZIP-Archiv entpacke und mir die Mac OS X-spezifischen Datei-Leichen entgegenhüpfen. Bitte packt eure Zips mit ausreichender Sorgfalt.

Wie das geht, weiss Google, es gibt spezielle (und freie) Software dafür, es existieren auch einfache PlugIns für euren Automator. Das gilt natürlich auch für Windows-Nutzer, bei denen ich die ominöse Thumbs.db oder noch besser, eine picasa.ini finde.

Unsaubere ZIP-Archive kommen bei mir direkt nach “Ausdrucken von E-Mails und Webseiten”.

Das musste ich mal loswerden. Danke.