Letzten Montag hat es mich nach einer längeren Pause wieder auf den Webmontag Kassel verschlagen. Als Entschuldigung habe ich auch eine Session über DDEV gehalten, die ich leider nicht so gut vorbereiten konnte, wie ich mir das vorgestellt hatte. Sie wissen schon: Familie, Wochenende und alles, was so dazwischenkommt.

Meine Folien kann man hier einsehen, die der anderen Sessions sind bestimmt auf der MeetUp-Seite zu finden. Die Vorträge über Ethical Design, GraphQL und Event Storming waren klasse und das Format des Webmontags so als kleines Appetithäppchen zwischen den ganzen Konferenzen und Barcamps, die man so verfolgen kann, genau richtig.

Open Source lebt ja nicht nur von der Idee, dass die Software quelloffen und damit für jeden einseh- und bewertbar ist, sondern auch davon, dass die Möglichkeit gegeben sein kann, dass jeder mitmachen kann. Jedenfalls, wenn der Autor der Software mitmacht und sogenannte "Pull Requests" entgegennimmt.
"Pull Requests" sind Quellcode-Schnippsel (oder auch Assets), die von Entwicklern beigesteuert werden können, die keine Schreibrechte im Repository haben. Sie dienen vor allem dazu Bugs zu beseitigen, aber auch um Features ein- oder auszubauen. Oder um Dokumentationen zu pflegen.

Das Hacktoberfest wird 2018 zum fünften Mal von GitHub und DigitalOcean organisiert (und dieses Jahr ist auch zum ersten Mal Twilio als Supporter dabei) und zelebriert einen Monat lang Open Source Software. Man kann daran weltweit teilnehmen, indem man im Oktober fünf Pull Requests in offenen Projekten auf GitHub postet. Die müssen noch nicht einmal angenommen werden, nur sollten sie nicht in Fake-Repositories landen oder aus Spam bestehen.

Meine Pull-Requests sind bis jetzt in die Repositories von Oh My Zsh, DDEV und gitignore.io gewandert. Vielleicht finde ich diese Woche auch noch ein wenig Zeit. Am Freitag gab es jedenfalls noch ein Hacktoberfest-Meetup in den heilligen Hallen der Micromata hier in Kassel, bei dem ich auch ein paar Stunden anwesend war. Hat Spaß gemacht und wieder Lust gemacht, die Webmontage zu besuchen, die dort auch abgehalten werden.

Für mich ist das wichtigste Werkzeug nach einer Entwicklungsumgebung eine gut funktionierende Shell. Ohne diese könnte ich diverse Dinge in meinem täglichen Workflow gar nicht oder nur schwer umsetzen. Klar gibt es eigentlich für alle Befehle, die man in einer Shell abfeuert, in der ein oder anderen Weise eine Ersetzung in Form von graphischen Oberflächen oder Integrationen in die IDE, aber diese sind entweder kompliziert zu konfigurieren oder bieten in den meisten Fällen nur einen geringen Teil der notwendigen Befehle oder Parameter.

Die Zeiten, in denen so eine Shell nur aus einem blinkenden Cursor bestand, man sich mühsam die Syntax von Befehlen merken musste und sie sich gefühlt nicht in den Workflow integrieren lies, sind auch vorbei. Und mit "Oh My Zsh" existiert sogar noch ein "Konfigurations"-Framework, das eigentlich keine Wünsche offen lässt, weil man es einfach selber erweitern kann.

Zwar kann man Oh My Zsh auch im Terminal von macOS verwenden, aber wenn man schon mal dabei ist, kann man ja auch gleich noch einen Ersatz dafür installieren: iterm2. Ein Ersatz für das macOS-Terminal, das neben einer Suche, Profilen und einer Historie über seine unzähligen Parameter so konfigurierbar ist, dass es sich wie bei Quake von oben öffnet. Was will man mehr?

Es gibt ja nichts Schlimmeres, als Code nicht ordentlich debuggen zu können. Nicht nachvollziehen können, warum der vermaledeite Code, den man gerade mit Herzblut und Schweiß geschrieben hat, verdammt noch mal nicht das hinten rauswirft, was er soll.

Da PHP größtenteils zur Laufzeit und dann auch noch von einem serverseitigen Daemon beziehungsweise Webserver interpretiert wird (Caches jetzt mal außen vorgelassen), benötigt man eine Erweiterung in Form von Xdebug, die sich dazwischen schaltet und Informationen an die IDE liefert. Unter macOS kann man das Installieren sowieso recht bequem per Homebrew erledigen:

brew install php71-xdebug

Wie man den Rest (Apache, MySQL und PHP) installiert, hatte ich hier mal beschrieben, auch wenn man anstelle der MariaDB lieber Mysql 5.6 installieren sollte.

Okay, zurück zu Xdebug, dass zwar jetzt schon installiert, aber noch nicht konfiguriert ist. Im Verzeichnis /usr/local/etc/php/7.1/conf.d sollte sich die Datei ext-xdebug.ini befinden, in die man folgendes schreiben sollte:

[xdebug] zend_extension="/usr/local/opt/php71-xdebug/xdebug.so" xdebug.max_nesting_level = 500 xdebug.idekey = PHPSTORM xdebug.remote_host = 127.0.0.1 xdebug.remote_enable = 1 xdebug.remote_port = 9000 xdebug.remote_handler = dbgp xdebug.remote_mode = req xdebug.auto_trace=1 xdebug.collect_includes=1 xdebug.collect_params=1 xdebug.collect_return=1 xdebug.extended_info=1

Da Xdebug sich nach meinem Gefühl schon verlangsamend auf den PHP-Interpreter auswirkt, auch wenn kein aktiver Debugging-Prozess läuft, installiert man sich am Besten noch den Xdebug Toggler per

brew install xdebug-osx

Danach kann man dann per

xdebug-toggle on/off

Xdebug einfach ein- und ausschalten. Schlußendlich installiert man dann noch den Xdebug Helper in Chrome oder dem Browser seiner Wahl.

Fehlt jetzt nur noch die Konfiguration von PhpStorm und das Mapping von TYPO3-Core bzw. Erweiterung. Nehmen wir einfach an, dass eine Erweiterung debuggt werden soll die per composer in ein TYPO3-Projekt eingebunden ist. Ich verwende composer bei der Entwicklung von Erweiterungen so, dass zu entwickelnde Erweiterungen als Symlink eingebunden sind, damit sich die git-Repositories nicht in die Quere kommen. Könnte man auch mittels Submodule realisieren, aber ich mache es halt am Liebsten so.

In PhpStorm sollte man in der Konfiguration unter Languages & Frameworks > PHP > Debug die Optionen

• Force break at first line when no path mapping specified
• Force break at first line in when a script is outside the project

entfernen. Zusätzlich sollte man in den Einstellungen von PhpStorm unter Languages & Framework > PHP die korrekte Version und Cli-Interpreter angegeben und das "vendor/typo3/cms"-Verzeichnis als "External Library" eingebunden haben.

Wenn man nun die Debugging-Session in PhpStorm aktiv schaltet und zum Beispiel das Frontend von TYPO3 neu lädt, sollte sich PhpStorm mit einem Mapping-Hinweis zu Wort melden und auch gleich entsprechende Dateien zur Auswahl geben. Für das Frontend wählt man am Besten die index.php aus dem Hauptverzeichnis des TYPO3 Cores.
Fröhliches Debuggen!

Diese Woche lag im Zeichen des Frühlingsanfangs und irgendwie gab es wenig Artikel, die ich mir überhaupt zum Lesen markiert habe. Lag vielleicht aber auch daran, dass ich wenig dazu kam, meine RSS-Feeds zu scannen.

• Wunschliste für die Integration von composer in TYPO3 Alexander Schnitzler hat auf Github einige Zeilen geschrieben, wie er sich selber die Integration von composer für TYPO3 vorstellt. Die Kommentare sind lesenswert, weil sie noch mehr Punkte aufgreifen.
• Karabiner-Elements Tool, mit dem ich die Media-Tasten von macOS auf meine Pok3r-Tastatur legen konnte. Endlich.
• Interview mit Donald Trump mit dem Time-Magazin Auf der einen Seite total faszinierend, wie so jemand Präsident eines riesengroßen und vor allem bunten Staat werden kann. Auf der anderen Seite beängstigend.
• OpenEmu - Emulator für diverse Systeme Auf der Suche nach einem SNES-Emulator für den Raspberry Pi drauf gestoßen, ausprobiert und für gut befunden. Alte Spiele auf macOS mit dem PlayStation-Controller spielen. Wunderbar.
• RetroPie - Emulator für den Raspberry Pi Ich habe es noch nicht ausprobiert, aber das scheint genau das zu sein, was ich für den Mini-Rechner benötige. Wenn das wirklich mit einem PlayStation-Controller zu koppeln ist, wird mein Sohnemann das hoffentlich wie ich hervorragend finden.
• Der letzte Brand Faszinierendes Interview eines Workaholic und in Perfektion versessenen Mannes, der nicht zum ersten Mal alles hinschmeisst, weil es nur noch betriebswirtschaftliche Maximierung für seine Tätigkeit gibt. Nicht nur, dass ich Monkey 47 immer noch allen anderen Gins bevorzuge, weil er für mich die schönste, fruchtig-würzige Geschmacksnote hat, ich würde gerne mal so einen Williams aus seiner Brennerei probieren. Leider unbezahlbar.

Irgendwie habe ich es vergessen für die zehnte Woche meinen Reader zu entrümpeln. Auf der anderen Seite komme ich momentan gerade sowieso kaum dazu, Artikel mehr als die Phase des Scannens zu gönnen. Was sie echt nicht verdient haben. Die meisten jedenfalls.

• KoN (King of Nothing) ist ein Rogue-like der in sieben Tagen aus der Feder von TINYTOUCHTALES und Max Fiedler. Die Macher des hervorragenden Smartphone-Kartenspiels haben dann auch nur fünf Tage für die Umsetzung eines Threes-Rogue-Likes benötigt. Scotty wäre stolz.
• Thimbleweed Park wird endlich veröffentlicht Ich habe ja seit der ersten Ankündigung es so gut wie vermieden, Screenshots, Videos oder Artikel über das neue Machwerk von Ron Gilbert (unter anderem) anzuschauen und zu lesen. Auch wenn es nicht der große Wurf wird, möchte ich das Spiel ohne irgendwelche Beeinflussung genießen. Der Anspruch an ein neues Grafik-Adventure besonder in dem Stil ist einfach nicht zu erfüllen, das ist mir jetzt schon klar. Aber vielleicht werde ich ja eines Besseren belehrt. Hoffentlich.
• Is design dead? Zu meiner Schande muss ich gestehen, dass ich diesen langen Artikel noch gar nicht gelesen habe, aber wenn es dort wirklich um die Praktiken des Extreme programming (XP) und Software-Design geht, habe ich das auf jeden Fall vor.
• CSS Grid Layouts werden der neue Scheiss Die Unterstützung von Flexbox ist mittlerweile so stark, dass man es ohne Nachdenken verwenden kann und auch "Frameworks" wie Bootstrap verwenden diese Methode in Version 4. Der "Nachfolger" steht nun schon in den Startlöchern und erlaubt unter anderem zweidimensionale Grids anzulegen, die man so auch nicht mit Flexbox hinbekommt. Jedenfalls nicht mit purem CSS. Hier und hier gibt es noch ein paar Infos.
• Die MiniDisc Ich wollte damals immer einen MiniDisc-Player haben, aber die waren für einen Schüler einfach viel zu teuer.

Der Frühling ist da. Sagt mein Körper. Und geht mir seit Tagen auf die Nerven, indem er mich total lahmlegt. Grippegefühl, Fieber, Muskelschmerzen und die Lunge tut weh. Allergiker kennen sowas. Nicht-Allergiker schauen einen immer unverstanden an. So von wegen "ist doch nur Frühling?". Egal, mal wieder zu nichts gekommen, noch nicht mal zum Zocken. Mit Kopfschmerzen und einer Reaktionszeit eines schmelzenden Gletschers kommt man Computerspielen nicht weit.

• Kleiner Rand über Docker Die technischen Probleme kann ich so zwar nicht nachvollziehen, die Hürde Docker in einem relativ kleinen Entwicklungsteam, das überwiegend Websites oder Teile von Websites entwickelt, ist aber viel höher als der Nutzen.
• Passwort-Apps auf Android und ihre Lücken Ein Team des Fraunhofer Instituts für Sichere Informationstechnologie hat mal die gängigen Passwort-Manager-Apps auf Android-Basis auseinandergenommen. Jetzt hätte ich gerne mal so ein Dossier für iOS-Apps. Danke.
• Schöne Anleitung zum Deployen per FTP und Bitbucket Pipelines Boah, FTP, da bekomme ich immer noch Gänsehaut, warum das im 21. Jahrhundert scheinbar immer noch die gängige Methode ist, um sich mit Webspace zu verbinden. Schlimm das. Die YAML-Konfiguration kann man sich aber auch einfach auf SSH zurechtbiegen.
• git flow als einfaches Branching-Model Kleine Teams brauchen geringen Overhead beim Entwickeln. Wenn man dann eigentlich noch einen Manager fürs Versionieren und Deployen brauchen würde, was zwar eigentlich sinnvoll wäre, würde das Budget kleinerer Projekte nicht mehr reichen.
• Ein weiteres einfaches Branching-Model für git Ich habe es mir noch nicht durchgelesen, aber beim Überfliegen habe ich es so verstanden, dass immer im Master entwickelt wird. Das ist für mich keine Option, weil mein Deployment auf gewisse Branches aufsetzt. Wenn in diese gepushed wird, wird das entsprechende Deployment ausgelöst und der Master-Branch ist halt gleichzusetzen mit dem Stand im Livesystem.
• Kleines und feines Best Practices in Extbase Oliver Klee hat sich die Mühe gemacht und eine Menge Tips und Tricks zum Entwickeln in Extbase zusammengestellt. Kann man einiges lernen und sich für seine eigene Entwicklung abschauen.

An dieser Stelle fange ich mal an, meine Pocket-Liste zu entschlacken, in dem ich erwähnenswerte Sites in solchen Artikeln wochenweise zusammenfasse. Vielleicht gibt es ja den ein oder anderen, der auch gefallen an manchen Artikeln findet. Mich selber soll es dazu bringen, Dinge, die ich mir für später merken möchte, auch wirklich abzuarbeiten. Und sei es nur, sie einfach ungelesen zu löschen.
Den Anfang machen folgende Artikel:

• TYPO3-Extension zum einfachen Löschen des kompletten Caches im Backend Mag manchmal im Entwicklungskontext ganz hilfreich sein. So richtig gestört hat mich das alte Aufklappmenü nicht. Erst seit 8.5 glaube ich, nervt es mich, dass die Klickfläche von der UI her zu weit unten anfängt. Nämlich erst beim Blitz/Buchstaben und nicht schon nach dem Trennstrich.
• Concept-Arts aus Monkey Island II Es gibt ja eigentlich kein besseres Adventure. Bis heute nicht. Selbst Sam & Max kommen da nicht ran. Das mag zwar alles durch trübe Erinnerung, Pubertät und so verklärt sein, aber das Spiel kann ich sogar heutzutage noch rauskramen und ich bekomme feuchte Augen.
• Die ersten Schritte von Brody Dalle Wer Brody Dalle ist? Sie hier neben Shirley Manson. Die Sängerin von Spinnerette, die Sängerin der leider aufgelösten Band The Distillers und auch Solo ziemlich gut.
• cssreference.io und htmlreference.io Muss man keine großen Worte verlieren, kann man immer mal wieder gebrauchen.
• TYPO3 8.6 ist draußen Hell yeah! Ein Projekt läuft schon unter 8, die nächsten zwei sind gerade in der Umsetzungsphase und es setzt der gleiche Effekt wie beim Sprung auf TYPO3 4.5 oder 6.2 ein: man will die alten Backends einfach nicht mehr sehen, wenn man die aktuelle Version schon verwendet hat.
• Wie schlägt man sich als OpenSource-Software-Entwickler durchs Leben und füttert seine Familie? Am Beispiel von TYPO3-Extension-Entwicklern und deren Möglichkeiten an Geld (neben Ruhm und Ehre) ranzukommen.
• Das Schlimmste zum Schluss: Das Transkript und Video einer Pressekonferenz im Weißen Haus von Donald Trump Mir fehlen einfach die Worte, dazu etwas zu sagen.

Jahrelang war ich stinkend faul und habe als Basis zum Entwickeln MAMP Pro benutzt. Weil ich keine großartige Lust hatte, mich mit dem Installieren und Pflegen von Apache, MySQL und PHP herumzuschlagen. Aber auch habe ich jahrelang geflucht, wenn ein Update der Software irgendetwas kaputt gemacht hat, die Dienste nicht mehr richtig liefen oder Konfigurationsdateien zerstört wurden und man den lauffähigen Zustand aus einem Backup wiederherstellen musste. Auch wenn diese Vorkommnisse in letzter Zeit weniger geworden sind.

Im Zuge meiner aluhutbedingten Einschränkungen meines Benutzerkontos auf einen Standardbenutzer unter macOS verweigerte MAMP Pro aber seinen Dienst, was seinen Ursprung wahrscheinlich darin hat, dass es Zugriff unter anderem auf die hosts-Datei haben möchte. Ich habe kurz geschaut, ob ich mich mit Vagrant oder Docker anfreunden könnte und ob die Entwicklung in virtuellen Maschinen in den Arbeitsablauf zur Agentur, in der ich arbeite, passt. Kurze Antwort: nein. Aus diversen Gründen verlagert man einfach nur das Problem der Versionierung und der Pflege des Systems in eine VM und erleichtert beziehungsweise verbessert man das Entwickeln dadurch nicht. VMs haben schon ihre Daseinsberechtigung wenn es darum geht so einen Container einfach in die Cloud zu packen und wenn dort Systeme laufen, die dadurch einfacher skaliert werden können.

Es sollte daher ein "natives" Apache/MySQL/PHP-System auf macOS-Basis werden. Mit verschiedenen PHPs zum einfachen Wechseln, PHP-Cache und Xdebug. Letzteres bin ich noch schuldig, wie man den Rest recht einfach installiert bekommt, habe ich mal im Folgenden aufgeschrieben. Einfach die folgende Anleitung von oben nach unten abarbeiten und als Erfolg sollte man ein funktionierendes und stabiles System vorfinden. Dafür lege ich meine Hand aber nicht ins Feuer, kann nur sagen, dass es so bei mir geklappt hat.

Xcode installieren

Xcode muss man per App-Store installieren, auch wenn man von dem ganzen Paket lediglich den gcc-Compiler benötigen. Dieser wird mit den "Xcode command line tools" mitgeliefert, die man nachträglich installieren muss.

// Ist Xcode überhaupt installiert, Befehl sollte den Pfad zu Xcode auswerfen
xcode-select -p

// Xcode command line tools nachträglich installieren
xcode-select --install

Ohne Homebrew läuft nix

Homebrew ist ein Paket-Manager ähnlich wie apt unter Debian/Ubuntu und wird folgendermaßen per Terminal installiert:

ruby -e "$(curl -fsSL raw.githubusercontent.com/Homebrew/install/master/install)"

Apropos Terminal: ich benutze ja schon seit Jahren iterm und bin damit mehr als zufrieden. Vor allem kann man das Fenstermanagement so einstellen, dass sich das Terminal wie die Quake-Konsole im oberen Bereich des Monitors öffnet.

Externe Repositories für brew hinzufügen

Weil das Master-Repository von Homebrew nicht alle Ressourcen beinhaltet, muss man durch folgende Befehle unter anderem PHP und Apache hinzufügen:

brew tap homebrew/dupes
brew tap homebrew/versions
brew tap homebrew/php
brew tap homebrew/apache

Nach dem Hinzufügen der Repositories muss folgender Befehl abgesetzt werden, damit Homebrew sich die neuesten brews zieht:

brew update

Apache installieren

macOS bringt zwar von Hause aus einen Apache mit, der ist aber in vielen Dingen beschnitten und sollte durch einen "richtigen" Apache ersetzt werden.
Mit folgenden Befehlen wird erst der macOS-Apache beendet, aus dem Startskript entfernt und der "neue" Apache per brew installiert:

sudo apachectl stop
sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist 2>/dev/null
brew install httpd24 --with-privileged-ports --with-http2

Das Ganze kann ein wenig dauern, weil der Apache von Grund auf kompiliert wird. Nach dem Kompilieren bekommt man eine ähnliche Nachricht angezeigt, die WICHTIG ist:

/usr/local/Cellar/httpd24/2.4.25: 212 files, 4.5M, built in 2 minutes 28 seconds

An der Kompilierungszeit erkennt man, dass ich das Ganze auf einem kleinen MacBook erledigt habe.
Der Pfad /usr/local/Cellar/httpd24/2.4.25, der sich wahrscheinlich je nach Apache-Version in den letzten Zahlen unterscheiden kann, wird in den nächsten Befehlen entsprechend angepasst. Diese Befehle dienen dazu, den Apache in den Autostart-Daemon von macOS aufzunehmen.

sudo cp -v /usr/local/Cellar/httpd24/2.4.25/homebrew.mxcl.httpd24.plist /Library/LaunchDaemons
sudo chown -v root:wheel /Library/LaunchDaemons/homebrew.mxcl.httpd24.plist
sudo chmod -v 644 /Library/LaunchDaemons/homebrew.mxcl.httpd24.plist
sudo launchctl load /Library/LaunchDaemons/homebrew.mxcl.httpd24.plist

Apache konfigurieren

Erster Schritt ist nun, das DocumentRoot-Verzeichnis auf einen Ordner unterhalb des Benutzer-Verzeichnisses umzubiegen, damit man dort die Verzeichnisse für die virtuellen Hosts erstellen kann. Mit

open -e /usr/local/etc/apache2/2.4/httpd.conf

öffnet man das Konfigurationsfile in TextEdit. In diesem nach "DocumentRoot" suchen, diesen und den Eintrag "Directory" unterhalb ändert man und zeigt auf ein Verzeichnis (bei mir "Sites") in seinem Benutzerordner:

DocumentRoot "/Users/DEINBENUTZERNAME/Sites"

Innerhalb des Directory-Eintrages gibt es die Einstellung AllowOveride, die steuert, welche Konfigurationseinstellungen man per htaccess überschreiben darf. Diesen stellt man auf All.

#
# AllowOverride controls what directives may be placed in .htaccess files.
# It can be "All", "None", or any combination of the keywords:
#   AllowOverride FileInfo AuthConfig Limit
#
AllowOverride All

Weil ohne mod_rewrite unter anderem keine lesbaren URLs per RealUrl möglich ist, muss man dieses noch laden, per Default wird dieses nicht eingebunden. Also Zeile suchen und den Hash entfernen, damit die Zeile nicht auskommentiert ist:

LoadModule rewrite_module libexec/mod_rewrite.so

Berechtigungen für Benutzer und Gruppe

Zwar haben wir Apache schon angewiesen, in welchem Verzeichnis er Dateien findet, aber die Berechtigungen stimmen noch nicht. Apache läuft standardmäßig mit dem daemon-User und der daemon-Gruppe. Diese haben aber keinen Zugriff auf die Verzeichnisse in deinem Benutzerverzeichnis.
Als User also den Benutzernamen eintragen und als Gruppe "staff":

User DEINBENUTZERNAME
Group staff

Nach einem beherzten Neustart des Apache-Daemons sollte der Webserver laufen und auf das angegebene Verzeichnis verweisen.

PHP installieren

Ohne PHP geht gar nichts und wir benötigen für die unterschiedlichen TYPO3-Versionen auch unterschiedliche PHP-Versionen. Diese werden mit folgenden Befehlen schon einmal installiert:

brew install php56 --with-httpd24
brew unlink php56
brew install php70 --with-httpd24
brew unlink php70
brew install php71 --with-httpd24

Sollten vorher schon per brew PHP-Versionen installiert worden sein, sollte man diese per "brew uninstall" deinstallieren. Der ganze Install-Zirkus hat bei mir knapp eine halbe Stunde gebraucht, da PHP aus den Sourcen kompiliert wird. Danach findet man die Konfigurationsdateien von PHP in folgenden Verzeichnissen:

/usr/local/etc/php/5.6/php.ini
/usr/local/etc/php/7.0/php.ini
/usr/local/etc/php/7.1/php.ini

In den php.ini-Dateien sollte man für den reibungslosen Betrieb von TYPO3 schon einmal folgende Einstellungen vornehmen (keine vollständige Liste):

max_execution_time = 240
max_input_time = 240
memory_limit = 256M
date.timezone = Europe/Berlin
upload_max_filesize = 128M
post_max_size = 128M
always_populate_raw_post_data = -1
max_input_vars = 1500

Apache mit PHP konfigurieren

In der schon bekannten Datei /usr/local/etc/apache2/2.4/httpd.conf sind im Bereich "Dynamic Shared Object (DSO) Support" von den Install-Skripten von PHP für die einzelnen Versionen die Modul-Dateien hinterlegt worden.
Diese können wir auch für spätere Updates von PHP auf einen anderen Ort verweisen lassen. Da man immer nur eine PHP-Version laufen lassen kann, werden wir erstmal PHP 5.6 laufen lassen und die anderen beiden Zeilen auskommentieren. Gleich werden wir noch Skripte erstellen, die es uns erlauben, mit einer Befehlszeile zwischen den Versionen zu springen.

LoadModule php5_module    /usr/local/opt/php56/libexec/apache2/libphp5.so
#LoadModule php7_module    /usr/local/opt/php70/libexec/apache2/libphp7.so
#LoadModule php7_module    /usr/local/opt/php71/libexec/apache2/libphp7.so

Damit PHP-Dateien korrekt ausgeführt werden werden in der Apache-Konfiguration die Handler entsprechend gesetzt (nach "IfModule dir_module" suchen und entsprechend ersetzen):

    DirectoryIndex index.php index.html



    SetHandler application/x-httpd-php

PHP switcher

Findige Leute haben einen Gist für den PHP Switcher bereit gestellt, den wir clonen und ausführbar machen werden:

curl -L gist.github.com/w00fz/142b6b19750ea6979137b963df959d11/raw > /usr/local/bin/sphp
chmod +x /usr/local/bin/sphp

Pfade prüfen, Terminals schließen

Homebrew sollte alle Pfade, die es benötigt in die PATH-Variable geschrieben haben. Das kann man mit folgendem Befehl überprüfen, es sollten auf jeden Fall /usr/local/bin und /usr/local/sbin enthalten sein:

echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/go/bin:/usr/local/MacGPG2/bin

Vor den nächsten Schritten sollte man alle Terminal-Sessions schließen, ansonsten kann es zu Problemen führen. Also: turn it off and on again!

LoadModule-Angaben für PHP-Switcher ändern

Die vorhin gemachten Änderungen im LoadModules-Bereich der Apache-Konfiguration müssen erneut angepasst werden (open -e /usr/local/etc/apache2/2.4/httpd.conf) und mit folgenden zwei Zeilen ersetzt werden. Nur diese zwei Zeilen, auch wenn mehr PHP-Versionen installiert sind, die Zeile für PHP7 ist auch auskommentiert:

# PHP Switcher
LoadModule php5_module /usr/local/lib/libphp5.so
#LoadModule php7_module /usr/local/lib/libphp7.so

Mit dem Befehl "sphp 70" kann dann zum Beispiel zur 7.0 von PHP gewechselt werden. Was eine ähnliche Ausgabe im Terminal erzeugen sollte:

$ sphp 70

PHP version 70 found
Unlinking old binaries...
Linking new binaries...
Linking /usr/local/Cellar/php70/7.0.15_8... 17 symlinks created
Linking new modphp addon...
/usr/local/lib/libphp7.so
Fixing LoadModule...
Updating version file...
Restarting homebrew Apache...
Done.

PHP 7.0.15 (cli) (built: Feb  5 2017 12:27:57) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies

MySQL installieren

Datenbanken brauchen wir auch, von daher wird noch MySQL installiert. Es wird MariaDB verwendet, was nichts weiter als MySQL ist (sogar von einigen ehemaligen MySQL-Entwicklern).
Folgende zwei Befehle im Terminal abfeuern:

brew install mariadb
mysql_install_db

Nach dem Installieren kann der MySQL-Server mit folgenden Befehlen gestartet und gestoppt werden:

// MySQL-Daemon starten
mysql.server start

// MySQL-Daemon stoppen
mysql.server stop

// Root-Passwort für den MySQL-Server setzen
/usr/local/bin/mysql_secure_installation

Apache Virtual Hosts

Um virtuelle Hosts á la meinsuperwebprojekt.server.tld einzurichten, muss man im Apache noch das vHost-Alias-Modul laden, was bei Default nicht der Fall ist. In der Apache-Konfigurationsdatei /usr/local/etc/apache2/2.4/httpd.conf folgende zwei Parameter auskommentieren:

LoadModule vhost_alias_module libexec/mod_vhost_alias.so

# Virtual hosts
Include /usr/local/etc/apache2/2.4/extra/httpd-vhosts.conf

Danach kann man in der Datei /usr/local/etc/apache2/2.4/extra/httpd-vhosts.conf entsprechende Einträge erstellen.

    DocumentRoot "/Users/DEINBENUTZERNAME/Sites/DEINESEITE.TLD"
    ServerName DEINESEITE.TLD

Nach einem Neustart des Apache-Servers weiß der zwar, wohin er mit Anfragen zu seite.machbar hin soll, der Rechner zuckt aber lediglich mit den Schultern. Von daher benötigen wir noch eine Schnittstelle, die die Netzwerkanfragen zum Apache umbiegt: Dnsmasq.

// dnsmasq per brew installieren
brew install dnsmasq

// Alle anfragen an *.TLD annehmen
echo 'address=/.TLD/127.0.0.1' > /usr/local/etc/dnsmasq.conf

// dnsmasq starten
sudo brew services start dnsmasq

// Nameserver für *.TLD starten
sudo mkdir -v /etc/resolver
sudo bash -c 'echo "nameserver 127.0.0.1" > /etc/resolver/TLD

"TLD" sollte man mit der Domain ersetzen, die man normalerweise zum Entwickeln verwendet.

APCu und Zend OPcache installieren

Um PHP-Caching zu verwenden, um das Kompilieren um einen merkbaren Faktor zu beschleunigen, installieren wir noch APCu und OPcache. Das muss für jede installierte PHP-Version einzeln geschehen, aber das Wechseln funktioniert mit dem Switcher ja ganz einfach.

// Cache-Systeme für PHP 5.6 installieren
sphp 56
brew install php56-opcache
brew install php56-apcu

// Cache-Systeme für PHP 7.0 installieren
sphp 70
brew install php70-opcache
brew install php70-apcu

// Cache-Systeme für PHP 7.1 installieren
sphp 71
brew install php71-opcache
brew install php71-apcu

Nach einem Neustart des Apache-Servers sollte in der phpinfo() Hinweise zum Zend OPcache und APCu zu finden sein.

Fertig!

Fertig ist man ja nie, aber das jetzt installierte System ist schon einmal eine gute Basis, um TYPO3-Systeme zu installieren. Zum Entwickeln fehlt zum Beispiel noch Xdebug, PEAR und was man noch so alles für Projekte braucht und gewisses Feintuning von PHP-Konfigurationseinstellungen. Die sind aber bei jedem nach Belieben anders, von daher gehe ich da erstmal nicht drauf ein.