Wer wie ich Websites mit PHP und MySQL bzw. MariaDB für einen Apache Webserver entwickelt, der/die nutzt sicher auch irgendeine Form von lokalem Webserver. Für den Einsatz auf dem Mac habe ich bis kürzlich viele Jahre lang MAMP PRO genutzt – bis nach dem Update auf MacOS Sonoma Probleme auftauchten. Deshalb habe ich mich nach einer Alternative umgesehen und bin bei DDEV hängen geblieben.
Aber lasst mich kurz etwas weiter ausholen, für Mitlesende die vielleicht gerade erst in die Webentwicklung mit PHP einsteigen.
Wozu ein lokaler Webserver (und warum PHP)?
Die meisten Hostingpakete, die man bei den üblichen Verdächtigen wie Strato, IONOS, all-inkl.com, Hetzner etc. bekommt (die Reihenfolge der Auflistung stellt keine Bewertung dar) nutzen einem Apache-Webserver und enthalten fast immer MySQL (oder MariaDB) und PHP. Es macht also Sinn diese Werkzeuge, den AMP-Stack, zu nutzen. Und viele populäre Open Source Content Management Systeme wie WordPress, Typo3, Drupal, Joomla und – mein Favorit – ProcessWire setzen ebenfalls auf diesen AMP-Stack. Bei der Entwicklung der Website möchte man allerdings für gewöhnlich nicht direkt auf dem Server beim Hoster der Wahl arbeiten, unter anderem weil der stetige Up- und Download von Dateien Zeit kostet. Aber auch weil man z.B. irgendeine Form der Versionierung oder regelmäßige automatische Backups haben möchte. Über kurz oder lang braucht man also einen eigenen Webserver, auf dem eigenen Rechner.
Unter Windows ist dabei XAMPP ein beliebter Kandidat (das X steht für „Cross-Plattform“, das letzte P für „Perl“), auf dem Mac MAMP bzw. die kostenpflichtige Version mit weiteren Funktionen MAMP PRO – die Software die ich jahrelang zufrieden genutzt habe.
Was ich an der PRO-Version von MAMP ganz besonders mochte, war die Möglichkeit unterschiedliche Hosts mit unterschiedlichen PHP-Versionen zu konfigurieren. So konnte ich beispielsweise Änderungen an einer etwas älteren Website unter PHP 8.0 mit dem lokalen Hostnamen old-site.internal einbauen und parallel eine neue Website unter PHP 8.3 (zum Zeitpunkt des Artikels die aktuelle Version) auf new-site.internal vorbereiten.
Mein Problem mit MAMP PRO
Nach dem Update von MacOS 13 (Ventura) auf MacOS 14 (Sonoma) funktionierte SQLite nicht mehr – eine dateibasierte Datenbank die ich zwar so gut wie nie brauche, in einem Projekt (SIC3) aber ganz dringend. Der Aufruf von SQLite3() in PHP auf dem MAMP PRO Server mündete in einem Fatal Error (eigene Doofheit habe ich durch Tests auf anderen Servern ausgeschlossen). Durch dieses Problem konnte ich somit nicht mehr an und mit der SQLite-basierten Software arbeiten. Meine persönliche Erfahrung mit dem Support war dabei etwas unterwältigend: Nach einer recht ausführlichen Erstantwort (seltsamerweise auf englisch obwohl die Firma hinter MAMP ihren Sitz in Deutschland hat – aber okay, kein Problem) erfolgte, nach einer Rückfrage meinerseits, keine weitere Antwort. Seit der ersten Antwort sind inzwischen über 20 Tage vergangen und da ich natürlich weiterarbeiten wollte, musste ich mich nach einem Ersatz für MAMP PRO umsehen.
Wieso DDEV?
Genau wie bei MAMP PRO auch, kann ich bei DDEV pro Projekt unterschiedliche Serverkonfigurationen definieren, hier kann allerdings auch die PHP- und Datenbank-Version je nach Projekt variieren und selbst der Webserver-Typ kann projektspezifisch geändert werden. Neben dem o.g. Apache gibt es beispielsweise auch NGINX oder NodeJS zu Auswahl. Und auch wer eine Postgres-Datenbank statt MySQL benötigt, findet mit DDEV eine passende Lösung. Denn DDEV basiert auf Docker, wodurch die jeweils gewünschte Serverumgebung basierend auf der projektspezifischen DDEV-Konfiguration individuell durch entsprechende Docker Container zusammengestellt wird.
Im Gegensatz zu MAMP hat DDEV aber keine grafische Benutzeroberfläche sondern ist ein Kommandozeilen-Tool. Was auf den ersten Blick wie ein Nachteil klingt, ist es aber garnicht – denn dadurch dass die Hosts per Kommandozeile oder Konfigurationsdatei definiert werden, lässt sich die Einrichtung eines neuen Projekts automatisieren, die Konfiguration in eine Versionsverwaltung (z.B. Git) und Backups einschließen. Das ist cool!
Den Server für ein typisches AMP-Projekt, wie etwa eine ProcessWire- oder WordPress-Website kann ich z.B. mit folgendem Kommando im Terminal von DDEV „zusammenbauen“ lassen:
ddev config --project-type=php --webserver-type=apache-fpm --php-version=8.3 --database=mariadb:10.11 —docroot=Ich sage DDEV in diesem Befehl, dass es sich um ein PHP-Projekt handelt, dass ich Apache als Webserver, PHP in Version 8.3 und eine Datenbank mit MariaDB10.11 haben möchte. (Je nachdem wann ihr den Artikel lest, sind die Versionsnummer möglicherweise bereits veraltet)
Mit ddev start kann ich anschließend den Server starten, DDEV fährt dann im Hintergrund die nötigen Docker-Container hoch und richtet alles für den Betrieb ein. Auf Grundlage des Ordners in welchem ich DDEV gestartet habe, wird auch gleich ein entsprechender Hostname samt Routing angelegt. Nehmen wir also mal an, ich würde DDEV im Ordner „mustermann“ aufrufen, dann wäre der Webserver nach dem Starten unter mustermann.ddev.site im Browser erreichbar. Auf Wunsch auch via HTTPS.
Im Rahmen der Konfiguration mit ddev config legt DDEV einen Unterordner /.ddev an, welcher eine config.yaml enthält. Dort sind die während der Konfiguration vorgenommen Einstellungen hinterlegt, so das zukünftig einfach via ddev start der gleiche Server (mit den gleichen Containern) neu gestartet werden kann, ohne erneut ddev config auszuführen. Diesen Unterordner samt YAML-Datei kann ich dann mit in die Versionsverwaltung bzw. in Backups aufnehmen und damit auch irgendwann später mal ein altes Projekt raus kramen und per ddev start in exakt der „damaligen“ Serverkonfiguration erneut hochfahren.
MAMP PRO oder DDEV?
In meinem Fall ist die Entscheidung klar: DDEV.
Insbesondere da MAMP PRO nach dem MacOS-Update für mich nicht mehr vollumfänglich nutzbar ist. Vielleicht meldet sich der MAMP-Support auch noch mal und löst mein Problem aber ich habe da wenig Hoffnung (mein erneute Nachfrage vor einer Woche blieb bis jetzt ebenfalls unbeantwortet). Aber auch die Vorteile die die Bedienung von DDEV per Kommandozeile mit sich bringen, helfen bei meiner Entscheidung mich von MAMP PRO zu lösen.
Aber: MAMP PRO hat für mich lange sehr gut funktioniert und wäre das geschilderte Problem nicht aufgetreten, hätte ich mich vermutlich nicht nach Alternativen umgesehen. Zumindest nicht jetzt. Während DDEV eine gewisse Lernkurve mit sich bringt und Mut zur Nutzung der Kommandozeile erfordert, ist MAMP PRO sicher für Viele weiterhin eine gute Option. Mein Problem mag ein Einzelfall sein, welches bei anderen Nutzerinnen garnicht erst auftritt. Wer also einen einfach zu installierenden AMP-Stack benötigt und das Ganze in einer grafischen Nutzeroberfläche konfigurieren möchte: Go for it!
Wem die Kommandozeile nicht fremd ist, wer Git in seinem Workflow nutzt und zumindest grundlegendes Docker-Wissen hat, dem möchte ich DDEV aber hiermit mal aufs Kenntniss-Tableau bringen – lohnt sich auf jeden Fall, sich das mal anzuschauen.