PEAR ist ein Framework und ein Distributionssystem mit dem PHP Softwarepakete verteilt und installiert werden können.

Die Installation an sich ist super einfach:

# root Rechte mit "richtigem einloggen" und in das richtige Verzeichnis wechseln
 sudo su -
 cd /usr/local
 
# PEAR Installer herunterladen und ausführen
 curl http://pear.php.net/go-pear > go-pear.php
 php go-pear.php
 rm go-pear.php

Danach können wir eigentlich alles bestätigen und PEAR sollte installiert werden, dennoch lohnt es sich vorher die Pfade zu überprüfen.

Last but not least muss noch die Konfigurationsdatei von PHP angepasst werden.Dazu kann man die mitgelieferte php.ini.default benutzen oder alternativ können zwei verschiedene php.ini (für Development und Production) unter http://wiki.php.net/rfc/newinis gefunden werden.

# PHP.ini editieren
 cp /etc/php.ini.default /etc/php.ini
 vim /etc/php.ini

Dort den include_path anpassen auf: .:/usr/local/PEAR und falls noch nicht geschehen date.timezone setzen (z.B. auf Europe/Berlin). Zu guter letzt noch ein Neustart des Apache Webservers via apachectl restart

 

Die ganze Zeit habe ich PHP als FastCGI über mod_fcgid laufen gehabt und war eigentlich auch ganz zufrieden. Auf dem jetzigem Server war ich über die Performance aber doch sehr enttäuscht. So wurden durchschnittlich nur 0,49 Requests/Sek. verarbeitet, laut ab -n1000, was meiner Ansicht nach doch etwas sehr wenig ist. Darum habe ich mich entschlossen kurzer Hand wieder mod_php einzusetzen und siehe da, die Requests pro Sekunde sprangen auf 1,89 Requests/Sek.

Apache ITK

Da mir aber auch an Sicherheit gelegen ist soll PHP aber nicht als www_data respektive apache laufen. Außerdem fand ich es bei PHP als FastCGI doch sehr angenehm, dass man sich seine eigene php.ini anlegen konnte. Mit dem ITK Patch für Apache ist es möglich einem vHost einen Benutzer und eine Gruppe zu zuweisen unter welchem Sie laufen sollen, also wird nicht erst der PHP Prozess sondern direkt der vHost, respektive der Apache Prozess, unter diesem Benutzer ausgeführt. Einen schönen einführenden Artikel zu Apache ITK hat Stuart Herbert in seinem Blog geschrieben.

AssignUserID user group

Dies ist die einzige Ergänzung die im vHost gemacht werden muss um ihn einem speziellen Benutzer zu zuordnen.

PHP mit eigener php.ini

Wenn Apache ITK läuft brauch man nur noch mod_php zu aktivieren und PHP läuft nun auch unter dem angegebenem Benutzer, dennoch hat mod_php die Eigenschaft eine gemeinsame php.ini zu verwenden. Aber auch hierfür gibt es Abhilfe! Bei askapache.com gibt es einen netten Artikel über Custom php.ini tips and tricks über den ich eine Lösung für das Problem der php.ini gefunden habe. Im vHost Container muss einfach folgende Direktive gesetzt werden:

<span style="text-decoration: line-through;">PHPIniDir /path/to/php_ini/</span>

Nun wird die php.ini welche sich in diesem Verzeichnis befindet geladen.

Leider muss ich das oben geschriebene revidieren, da das Setting PHPIniDir nicht pro vHost sondern global gilt. Es scheint bis jetzt so, als wäre es nicht möglich mit mod_php für jeden vHost eine eigene php.ini festzulegen.

Fazit

Durch Apache ITK und einigen Einstellungen ist es möglich ein wesentlich performanteres PHP zu bekommen, dass zudem Vergleich zur FastCGI Variante auch noch mehr Features besitzt und nicht unter dem generellen Benutzers des Apache Webservers läuft.

 


Generelles zu Filtern

In der kleinen AsciiArt unten kann man erkennen wie Filter funktionieren. Von links kommt das Request an die Applikation, dieses wird vom Dispatcher bearbeitet, der das Request und seine Daten durch die Globalen Filter schickt, diese leiten es dann an die entsprechende Action weiter, welche wiederum das ganz durch ihre eigenen Filter schickt. Jetzt wird erst das Output generiert und die Filter werden danach in umgekehrter Reihenfolge wieder durchlaufen.

Agavi's Filters are like an Onion

Agavi's Filter sind wie eine Zwiebel

Bei allen Filtern ist es so, dass die Auflistung die Reihenfolge der Ausführung bestimmt. Weiter unten ein kleines Beispiel dazu.

Globale Filter

Was sind globale Filter? – Globale Filter gelten für das Request an die Applikation. Als Beispiel kann hier der FormPopulationFiler dienen. Dieser Filter ist in der Lage eine HTML mit Werten zu füllen, was aber erst gemacht werden kann, nachdem das ganze Request durchgelaufen ist und das Output generiert worden ist. Somit ist es möglich in dem Request weitere ActionContainer zu kreieren und weiter Actions auszuführen.

Die Konfiguration der Globalen Filter findet in der global_filter.xml im Konfigurationsverzeichnis der Applikation statt. Hierbei bestimmt die Reihenfolge in welcher sie in der Datei aufgelistet werden in welcher Reihenfolge sie ausgeführt werden.

<filter name="FirstFilter"/>
<filter name="SecondFilter"/>

Hier würde der Filter mit dem Namen FirstFilter zuerst, danach dann der SecondFilter ausgeführt. Die Globalen Filter werden vom Controller geladen und auf gerufen. Hierbei gilt, dass der Controller explizit den Filter AgaviDispatchFilter registriert und ihn dann gleich danach aufruft. In diesem wird das Response gesetzt, aus dem was noch kommt.

Action Filter

Action Filter sind, wie der Name auch schon sagt, für die Action gedacht. Die Grafik oben verdeutlicht dieses sehr gut. Eine Action generiert uns ja in der passenden View das Output, welches vor der Ausgabe dann noch mit dem FormPopulationFilter bearbeitet wird.

Bei den Action Filtern gibt es eine Besonderheit. Zum einen gibt es die Action Filter, die für jede Action aufgerufen werden und Spezial Action Filter die nur für eine bestimmt Action aufgerufen werden. Die Spezialfilter werden im app/Modulverzeichnis/config/action_filters.xml spezifiziert. Die Filter die für alle Actions gelten sollen werden in app/config/action_filters.xml spezifiziert.
Zur der Reihenfolge der Ausführung ist zu sagen, dass erst die generellen und dann die speziellen.

Noch etwas sehr wichtiges, dass man bei dem entwerfen eines Action Filters nicht vergessen darf, ist das jeder Slot, jede ForwardAction ihre eigene FilterChain hat, welche die Filter nochmal durchläuft. Deswegen gibt es zwei Verschiedene Methoden in der Klasse. Die eine, executeOnce, wird immer für die “main” Action auf gerufen, die andere execute wird dann in den restlichen FilterChains auf gerufen. Sollte man aber wollen, dass der Filter beim ersten bis zum letzten Aufruf immer gleich aufgerufen wird, bedient sich die Klasse AgaviFilter dem Trick, dass executeOnce einfach execute aufruft. ExecuteOnce muss als explizier überschrieben werden.

Aufbau eines Filters

Filter sollten immer die Klasse AgaviFilter erweitern. Dort sind schon einmal die grundlegenden Funktionen definiert wie die oben beschriebene executeOnce Methode.

In dem nachfolgenden Beispiel implementieren wir die Klasse FooBarFilter. Diese kann entweder wie im Beispiel ein Klasse sein die sowohl Global als aus Action Filter ist oder nur eines von beiden. (Hier ist es zu Demonstrationszwecken so gewählt)

<?PHP
class FooBarFilter extends AgaviFilter implements AgaviIActionFilter, AgaviIGlobalFilter {
 
public function executeOnce(AgaviFilterChain $filterChain, AgaviExecutionContainer $container)
{
    /* Stuff to be done before the Rest of filters and Output generation is executed */
 
    /* Now we continue with the other filters. THIS MUST BE DONE!!! */
    $filterChain->execute($container);
 
    /* now to the Stuff which needs to be done afterwards. ie. Output transformation etc. */
}
}
?>

Das Beispiel oben hat zu dem nur die Methode executeOnce, was also heißt das der Filter pro Kontext nur einmal ausgeführt würde.

Weiter Infos zu und um Agavi gibt es auf http://www.agavi.org. Auch zu empfehlen ist der Agavi FAQ in dem einige interessante Themen rund um Agavi behandelt werde.

ENGLISH TRANSLATION WILL FOLLOW!

Generelles zu Filtern

In der kleinen AsciiArt unten kann man erkennen wie Filter funktionieren. Von links kommt das Request an die Applikation, dieses wird vom Dispatcher bearbeitet, der das Request und seine Daten durch die Globalen Filter schickt, diese leiten es dann an die entsprechende Action weiter, welche wiederum das ganz durch ihre eigenen Filter schickt. Jetzt wird erst das Output generiert und die Filter werden danach in umgekehrter Reihenfolge wieder durchlaufen.

Agavi's Filters are like an Onion
Agavi’s Filter sind wie eine Zwiebel

Bei allen Filtern ist es so, dass die Auflistung die Reihenfolge der Ausführung bestimmt. Weiter unten ein kleines Beispiel dazu.

Globale Filter

Was sind globale Filter? – Globale Filter gelten für das Request an die Applikation. Als Beispiel kann hier der FormPopulationFiler dienen. Dieser Filter ist in der Lage eine HTML mit Werten zu füllen, was aber erst gemacht werden kann, nachdem das ganze Request durchgelaufen ist und das Output generiert worden ist. Somit ist es möglich in dem Request weitere ActionContainer zu kreieren und weiter Actions auszuführen.

Die Konfiguration der Globalen Filter findet in der global_filter.xml im Konfigurationsverzeichnis der Applikation statt. Hierbei bestimmt die Reihenfolge in welcher sie in der Datei aufgelistet werden in welcher Reihenfolge sie ausgeführt werden.

<filter name="FirstFilter"/>
<filter name="SecondFilter"/>

Hier würde der Filter mit dem Namen FirstFilter zuerst, danach dann der SecondFilter ausgeführt. Die Globalen Filter werden vom Controller geladen und auf gerufen. Hierbei gilt, dass der Controller explizit den Filter AgaviDispatchFilterregistriert und ihn dann gleich danach aufruft. In diesem wird das Response gesetzt, aus dem was noch kommt.

Action Filter

Action Filter sind, wie der Name auch schon sagt, für die Action gedacht. Die Grafik oben verdeutlicht dieses sehr gut. EineAction generiert uns ja in der passenden View das Output, welches vor der Ausgabe dann noch mit demFormPopulationFilter bearbeitet wird.

Bei den Action Filtern gibt es eine Besonderheit. Zum einen gibt es die Action Filter, die für jede Action aufgerufen werden und Spezial Action Filter die nur für eine bestimmt Action aufgerufen werden. Die Spezialfilter werden im app/Modulverzeichnis/config/action_filters.xml spezifiziert. Die Filter die für alle Actions gelten sollen werden inapp/config/action_filters.xml spezifiziert.
Zur der Reihenfolge der Ausführung ist zu sagen, dass erst die generellen und dann die speziellen.

Noch etwas sehr wichtiges, dass man bei dem entwerfen eines Action Filters nicht vergessen darf, ist das jeder Slot, jede ForwardAction ihre eigene FilterChain hat, welche die Filter nochmal durchläuft. Deswegen gibt es zwei Verschiedene Methoden in der Klasse. Die eine, executeOnce, wird immer für die “main” Action auf gerufen, die andere execute wird dann in den restlichen FilterChains auf gerufen. Sollte man aber wollen, dass der Filter beim ersten bis zum letzten Aufruf immer gleich aufgerufen wird, bedient sich die Klasse AgaviFilter dem Trick, dass executeOnce einfach execute aufruft. ExecuteOnce muss als explizier überschrieben werden.

Aufbau eines Filters

Filter sollten immer die Klasse AgaviFilter erweitern. Dort sind schon einmal die grundlegenden Funktionen definiert wie die oben beschriebene executeOnce Methode.

In dem nachfolgenden Beispiel implementieren wir die Klasse FooBarFilter. Diese kann entweder wie im Beispiel ein Klasse sein die sowohl Global als aus Action Filter ist oder nur eines von beiden. (Hier ist es zu Demonstrationszwecken so gewählt)

<?PHP
class FooBarFilter extends AgaviFilter implements AgaviIActionFilter, AgaviIGlobalFilter {
 
public function executeOnce(AgaviFilterChain $filterChain, AgaviExecutionContainer $container)
{
    /* Stuff to be done before the Rest of filters and Output generation is executed */
 
    /* Now we continue with the other filters. THIS MUST BE DONE!!! */
    $filterChain->execute($container);
 
    /* now to the Stuff which needs to be done afterwards. ie. Output transformation etc. */
}
}
?>

Das Beispiel oben hat zu dem nur die Methode executeOnce, was also heißt das der Filter pro Kontext nur einmal ausgeführt würde.

Weiter Infos zu und um Agavi gibt es auf http://www.agavi.org. Auch zu empfehlen ist der Agavi FAQ in dem einige interessante Themen rund um Agavi behandelt werde.

 

SysCP ist ein prima Tool um einfach und schnell eine Webhostingumgebung zu managen. Besonders seine “keep it simple” Idee macht es zu dem was es ist. Leider sieht es unter der Haube etwas anders aus. Dort ist es seit einiger Zeit so, dass der Code ein Stadium erreicht hat, in dem er alles andere als simpel zu verwalten ist.

Darum habe ich mich entschlossen eine Fork von SysCP zu starten, der vorerst unter dem Namen SysCP-ng laufen wird. Ziel der Version 1.0 ist es die derzeitige Funktionalität von SysCP (1.4.2) nachzubauen.

Mal sehen was drauß wird.

 

Appels OS X hat leider nur die Version 2.6.16 von libxml und 1.1.12 von libxslt von Haus aus an Bord. Ich hatte letztens das Problem, dass Agavi nicht will it diesen Verionen von libxml.

Das Problem lässt sich für PHP relativ einfach lösen und zwar in dem wir uns die neusten Verionen von libxml und libxslt compilen. Zu finden sind die neusten Versionen auf dem FTP von xmlsoft. Eine gute Anleitung hat James Clarke geschrieben. Da ich öfters gelesen habe, dass man die aktuelle Version von Leopard nicht einfach ersetzen kann, habe ich mich dazu entschieden, nach dem Compile der Programme die dynamischen Links entsprechend zu ändern.

Compile von PHP 5.3

Ich habe vergeblich versucht, PHP mit dem xmlreader zu compilen, aber keine Chance da anscheinend die Version der System libxml und libxslt zu alt sind. Zum Erfolg hat folgender configure command geführt.

CFLAGS="-arch x86_64 -I/usr/local/include -I/usr/local/php5/include/" LDFLAGS="-L/usr/local/include -L/usr/local/php5/include/" ./configure  \
'--prefix=/usr/local/php5.3' \
'--with-apxs2=/usr/sbin/apxs' \
'--with-config-file-scan-dir=/usr/local/php5.3/php.d' \
'--with-openssl=/usr' \
'--with-zlib=/usr' \
'--with-zlib-dir=/usr' \
'--with-gd' \
'--with-ldap' \
'--with-xmlrpc' \
'--enable-exif' \
'--enable-soap' \
'--enable-sqlite-utf8' \
'--enable-wddx' \
'--enable-ftp' \
'--enable-sockets' \
'--with-bz2=/usr' \
'--enable-zip' \
'--enable-pcntl' \
'--enable-shmop' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--enable-sysvmsg' \
'--enable-mbstring' \
'--enable-bcmath' \
'--enable-calendar' \
'--with-mhash=shared,/usr/local/php5' \
'--with-kerberos=/usr' \
'--with-libxml-dir=/usr/local/' \
'--with-xsl=/usr/local/' \
'--with-gettext=/usr/local/php5' \
'--with-curl=shared' \
'--with-png-dir=/usr/local/php5' \
'--with-jpeg-dir=/usr/local/php5' \
'--enable-gd-native-ttf' \
'--with-freetype-dir=/usr/local/php5' \
'--with-mysql=mysqlnd' \
'--with-mysqli=mysqlnd' \
'--with-pdo-mysql=mysqlnd' \
'--with-pgsql=shared,/usr/local/php5' \
'--with-pdo-pgsql=shared,/usr/local/php5' \
'--with-mcrypt=shared,/usr/local/php5' \
'--with-iconv' \
'--without-pear' \
'--disable-xmlreader'

Post Compile

Wie ich schon erwähnt hatte, müssen nach dem compilieren noch die dynamischen Links geändert werden.

# Show dynamic links
otool -L libs/libphp5.so
# Change the dynamic links
install_name_tool -change /usr/lib/libxml2.2.dylib /usr/local/lib/libxml2.2.dylib libs/libphp5.so
install_name_tool -change /usr/lib/libxslt.1.dylib /usr/local/lib/libxslt.1.dylib libs/libphp5.so
install_name_tool -change /usr/lib/libexslt.0.dylib /usr/local/lib/libexslt.0.dylib libs/libphp5.so

Nicht vergessen das ganze nocheinmal zu verifizieren, ob auch alles geklappt hat. So jetzt noch mit “make install” PHP installieren, Apache neustarten und testen.

 

Wenn man den FormPopulationFilter (kurz FPF) des Agavi Frameworks benutzt, gibt es einige Sachen auf die man achten sollte.

Keine HTML Special Charaters verwenden

Warum nicht? Nun ja, ich habe mein Output auf XHTML & UTF-8 eingestellt, so dass ich mit dem FPF meine Formulare dynamische ausfüllen kann. Nun ist das Problem, wenn man z.B. eine Navigation erstellt, dass man Sonderzeichen wie “>>” oder “<<” benutzen möchte für Vor und Zurück. Das Problem welches hierbei auftritt ist, dass der FPF denkt, dies seien Open- bzw. Endtags was ihn letztendlich aus der Bahn wirft und uns einer Exception beschert. Aber nicht nur diese Zeichen auch an “&rarr;” verschluckt sich der FPF.

Deswegen ist es am besten, wenn man Sonderzeichen benutzen möchte, den numerischen Code dieser zu verwenden. Eine gut strukturierte Übersicht findet der interessierte Leser unter http://webdesign.about.com/library/bl_htmlcodes.htm

 

PHP im Apache aktivieren

PHP 5.2.6 wird standartmäßig mit OSX Leopard ausgeliefert. Damit der lokale Apache PHP nutzen kann muss dieses noch nachträglich in der /etc/apache2/httpd.conf aktiviert werden. Dies geschiet dadurch, dass man die # vor LoadModule php5_module libexec/apache2/libphp5.so wegnimmt. Nun noch die Konfigurationsdatei von PHP kopieren und den Apache Webserver neustarten.

sudo cp /etc/php.ini.default /etc/php.ini
sudo apachectl restart

MySQL installieren

Die Installation von MySQL gestaltet sich relativ einfach. Einfach unter http://dev.mysql.com/downloads/mysql/5.0.html#macosx-dmg das richtige Packet herunterladen, mounten, installieren und fast fertig. Ich habe mich für die x86_64 Variante entschieden, da mein Core2Dou ja ein “64bit” Prozessor ist.

Nach der Installation dann noch einen Doppelklick auf MySQL.prefpane um MySQL dann später bequem aus den Systemeinstellungen starten zu können.

Um die MySQL Installation abzuschießen kopieren wir noch die Konfigurationsdatei nach /etc.

sudo cp /usr/local/mysql/support-files/my-small.cnf /etc/my.cnf

Man kann sicherlich auch eine andere cnf wählen, aber da es sich nur um eine lokale Entwicklungsumgebung handelt, sollte die small Konfiguration ausreichen.

Nun ist MySQL installiert und bereit gestartet zu werden. Dies wir einfach über die Systemeinstellungen -> MySQL gemacht. Wer den MySQL Server automatisch starten möchte kann dies dort durch setzen des Harkens bei Autostart erledigen.

PHP 5.3 installieren

Nach der MySQL Installation kann man PHP 5.2.6 mit MySQL benutzen, wem das genügt der kann hier nun aufhören zu lesen und sich ans entwicken machen.

Vorbereitungen

Nun gut: Here we go, bleeding edge of PHP.
Zur Vorbereitung benötigen wir ein Leopard PHP Packet von entropy.ch und die Xcode Tools von Apple. Das aktuellste entropy.ch Packet, welches ich beim schreiben des Artikels gefunden habe, ist Version 5.2.5-6-beta. Wichtig sind für uns allerdings nur die Bibliotheken des Packetes.

sudo -s
cd /usr/local
curl -O http://www2.entropy.ch/download/php5-5.2.5-6-beta.tar.gz
tar -xzvf php5-*-beta.tar.gz

Nun laden wir uns einen Snapshot von PHP 5.3 herunter und entpacken dann auch diesen in /usr/local und wechseln in das Verzeichnis.

Compilen von PHP

Kommen wir nun zum Compilen von PHP. Als erstes benötigen wir ein Configure Command, welches wir der einfachheit halber aus dem Entropy.ch Packet übernehmen.

/usr/local/php5/bin/php -i | grep "Configure Command"

Nun müssen wir noch das richtige –prefix und –with-config-file-scan-dir setzen. (Achtung nicht die Pfade zu den Bibliotheken verändern!). Ein fertiges Configure Command könnte dann so aussehen:

CFLAGS="-arch x86_64 -I/usr/local/php5/include/" LDFLAGS="-L/usr/local/php5/include/" ./configure  \
'--prefix=/usr/local/php5.3' \
'--with-apxs2=/usr/sbin/apxs' \
'--with-config-file-scan-dir=/usr/local/php5.3/php.d' \
'--with-openssl=/usr' \
'--with-zlib=/usr' \
'--with-zlib-dir=/usr' \
'--with-gd' \
'--with-ldap' \
'--with-xmlrpc' \
'--enable-exif' \
'--enable-soap' \
'--enable-sqlite-utf8' \
'--enable-wddx' \
'--enable-ftp' \
'--enable-sockets' \
'--with-bz2=/usr' \
'--enable-zip' \
'--enable-pcntl' \
'--enable-shmop' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--enable-sysvmsg' \
'--enable-mbstring' \
'--enable-bcmath' \
'--enable-calendar' \
'--with-mhash=shared,/usr/local/php5' \
'--with-kerberos=/usr' \
'--with-libxml-dir=/usr/local/php5' \
'--with-xsl=/usr/local/php5' \
'--with-gettext=/usr/local/php5' \
'--with-curl=shared,/usr/local/php5' \
'--with-png-dir=/usr/local/php5' \
'--with-jpeg-dir=/usr/local/php5' \
'--enable-gd-native-ttf' \
'--with-freetype-dir=/usr/local/php5' \
'--with-mysql=mysqlnd' \
'--with-mysqli=mysqlnd' \
'--with-pdo-mysql=mysqlnd' \
'--with-pgsql=shared,/usr/local/php5' \
'--with-pdo-pgsql=shared,/usr/local/php5' \
'--with-mcrypt=shared,/usr/local/php5' \
'--with-iconv' \
'--without-pear'

Der -arch Parameter bei CFLAGS kann auch weggelassen werden, er deutet nur an für welche Architektur PHP compiled wird. Wer noch weitere Optionen für PHP aktivieren will, der kann sich mit

./configure --help

einen Überblick über die Optionen verschaffen.

Nachdem der Configure Command ohne Probleme durchgelaufen ist, kommt nun ein gepflegtes

make -j4

und wir holen uns erstmal einen Kaffe.

Post make

Nachdem make durchgelaufen ist müssen wir noch etwas an den dynamischen Links von PHP ausbesseren. Um sich die dynamischen Links anzeigen zu lassen kann otool verwendet werden.

# show dynamic links
otool -L libs/libphp5.so
 
# correct linking
install_name_tool -change /usr/lib/libxml2.2.dylib /usr/local/php5/lib/libxml2.2.dylib libs/libphp5.so
install_name_tool -change /usr/lib/libxslt.1.dylib /usr/local/php5/lib/libxslt.1.dylib libs/libphp5.so
install_name_tool -change /usr/lib/libexslt.0.dylib /usr/local/php5/lib/libexslt.0.dylib libs/libphp5.so
 
# backup der libphp5.so von leopard
mv /usr/libexec/apache2/libphp5.so /usr/libexec/apache2/libphp5.so.leopard
 
# Installation der neuen PHP version
make test
make install
 
# Kopieren des neuen Apache Modules in unser Standalone Packet
cp /usr/libexec/apache2/libphp5.so /usr/local/php5.3

Abschließende Konfiguration

So und fertig ist die Installation von PHP 5.3 unter Mac OS X. Einen letzter Feinschliff muss jedoch noch an der Installation durchgeführt werden. Dies aber nur schnell Stichpunkt artig.

cp php.ini-recommended /usr/local/php5.3/lib/php.ini
mkdir /usr/local/php5.3/php.d
cp /usr/local/php5/php.d/* /usr/local/php5.3/php.d
sed -e 's/php5/php5.3/g' -i "" /usr/local/php5.3/php.d/10-extension_dir.ini
sed -e 's/20060613/20071006/g' -i "" /usr/local/php5.3/php.d/10-extension_dir.ini
apachectl restart

Um PHP nach den eigenen Wünschen zu konfigurieren einfach die entsprechenden Werte in der /usr/local/php5.3/lib/php.ini ändern.

Quellen:

 

Pear einzurichten unter Leopard gestaltet sich als relativ einfach. Eine gute Anleitung hier für hat das phpmagazin.de geschrieben. Die Installation sollte am besten als SuperUser druchgeführt werden. Um SuperUser zu werden benutzt man am besten das Command sudo -s.

© 2011 Börngen-Schmidt IT Consulting Suffusion theme by Sayontan Sinha