Lokale Entwicklungsumgebung auf Windows

Ich kann ddev empfehlen. Ich nutze es unter Linux, kenne aber auch Kollegen, die es unter Windows nutzen und schwer begeistert sind. ddev ist docker basiert, aber du brauchst eigentlich keine Docker Kenntnisse. In ein paar Minuten hast du eine lauffähige lokale Umgebung mit xdebug, phpmyadmin und alles weitere. PHP Version, DB Typ und Version kannst du simpel einstellen. Den Container kannst du nach belieben auf jedes andere System umziehen.

Danke schon Mal für die Idee mit ddev.
Ich hoffe, es werden sich noch mehr Kommentare einfinden :)

Ich nutze mittlerweile auch DDEV auf Windows und muss sagen, es läuft stabiler als alles, was ich mit XAMPP oder WAMP je hatte.
Die Einrichtung ist zwar am Anfang etwas ungewohnt, aber sobald es läuft, macht es vieles einfacher. Gerade bei mehreren Projekten ist das Wechseln der Umgebungen super praktisch. Composer, Docker und Co. greifen dabei gut ineinander.

Eine Entwicklungsumgebung besteht nicht aus aus dem Server-Setup. Da kommt auch noch ein Coding Programm hinzu. Prinzipiell geht das zwar auch mit einfachen Text-Editoren, aber das ist sehr ineffizient. Denn Integrierte Entwicklungsumgebungen (IDE) können mit diversen Erweiterungen diverse ENtwckungs- und Debug-Möglichkeiten verbessern. Das kommerzielle PHPstorm ist sehr beliebt aber es teilt sich mit dem quelloffenen Visual Studio Code (bzw. short "VS Code"von Microsoft) und seiner community compilierten Variante (VSCodium) glaube ich zusammen ungefahr nicht viel bei der Verbreitung.
Die Drupal Community hat sich über Git als Versionsverhaltung und dann zu Gitlab als Verwaltungsplatform entschieden und da läuft im Browser auch eine WebIDE von VS code. Das finde ich sehr praktisch, da wir bei Nodegard uns auch für VS Code / Codium entschieden haben.
Bezüglich lokaler Server-Umgebung ist DDEV nicht mehr nur ein einfacher Tipp oder ein Idee. Die Drupal Community hat DDEV zur offiziellen Plattform für lokale Entwicklung erklärt. Diverse komplexere Module wie z.B. Search API Solr bringen sogar DDEV Konfigurationshilfen mit. Obwohl wir viel Development und vor allem Testing direkt auf unseren Servern betreiben, haben wir unzwischen DDEV auch als lokales Setup schätzen gelernt. Gerade wenn es darum geht mal schnell ein Modul intensiver auszuprobieren (also mit Blick unter der Haube) ist DDEV ein praktisches Werkzeug unter Windows, Linux und Mac.

Ergänzung:
Man kann vor allem Drush und Composer mit DDEV im Container steuern und kann so vor allem die PHP Version anpassen sowie auch zwischen MariaDB und MySQL wechseln. Denn man sollte immer möglichst dicht an den Anforderungen des Ziel/Produkt-Systems arbeiten, testen usw.

Lokal sind Updates nicht immer so bedeutsam. DDEV verwaltet aber alles inkl. Backups im Container erstellen und außerhalb speichern.
Auf Servern benutzen wir inzwischen Docker nur wenn es nicht anders geht. Als Container-Lösung bevorzugen wir dort die ältere und meiner Meinung nach ausgereiftere Technik LXC und zur Verwaltung "Incus" (Fork von LXD). DDEV soll auch Incus können, das habe ich aber noch nicht sinnvoll zum laufen bekommen (das war aber Intel chip, auf Test auf Apple Chip steht noch aus). Aber zur Verwaltung der Docker-Container kann man auf Mac auch z.B. Colima verwenden (das hat keine Gui, was ich als Vorteil sehe). Aber das wichtigste DDEV hat eine sehr ausführliche Dokumentation und eine sehr große Community. E wird nicht nur von sehr vielen Drupal Developern weltweit genutzt, sondern auch für andere CMS Communities.

Nachtrag: Ich habe Incus inzwischen auf einem m4 mac zum laufen bekommen. Aber ddev erwartet wohl doch docker, sodaß ich colima dann doch mit Docker context starten musste.

Technische gesehen auf jeden Fall. Dazu gleich mehr. Aber da in Container auch sehr viel Unsinn gemacht wird, bzw. dies supptimal konfiguriert sein können, ist es nicht unebdingt ratsam irgendwelche Container zu verwenden, die keine offiziellen Container sind.
Docker Container auch in anderen Umgebungen zu benutzen ist inzwischen Standard wie z.B. in Kubernetes Cluster. Und auch das oben genannte Incus ist in der Lage Docker Container zu starten. Es gibt auch Projekt auch Docker-Compose setups damit verwenden zu können, das aber noch nicht ganz fertig ist.

Da in Container in der Regel per Default kein SSHd läuft, kann man sich erstmal nicht direkt dort einlogge auf gewohnte weise. Aber es gibt in der Regel einen Befehl mit dem nan in die Commandline kommt, zumeist "exec". Bei DDEV dann "ddev exec" und mit "ddev exec bash" landet man im Container. Das braucht man aber meistens nicht, weil, DDEV für composer und drush wie gesagt schon Befehle mit bringt, wenn man das Projekt als Drupal-Projekt konfiguriert hat.

Über DDEV hat Carsten ja schon eine ganze Menge erzählt. DDEV hat allerdings auch so seine Nachteile.

Zunächst muss man sagen, DDEV ist die offizielle Empfehlung der Drupal Community, wie man Drupal entwickeln soll.

Also ist es per se mal nicht schlecht. Aber es basiert auf Docker. Für Lernende, Neueinsteiger oder Umsteiger bedeutet das einfach, dass du dich entweder auf den Code, den dir die DDEV Entwicklungsumgebung vorgibt, verlassen musst oder dass du keine Ahnung haben wirst, was da eigentlich passiert.

Denn in der Regel sind die Leute, die mit DDEV arbeiten, wenn sie keine professionellen Entwickler sind, nicht willens, erst Docker zu lernen, um dann eine Website mit Drupal aufzubauen. Denn der Orthonormalverbraucher, a.k.a. der ambitionierte Benutzer, der Drupal einfach mal runterlädt, um damit sein Webprojekt zu starten, der ist nun mal kein Fullstack-Entwickler.

Deshalb hat er aller Wahrscheinlichkeit nach auch noch nicht so tiefe Dockerkenntnisse, dass er weiß, wann hier ein Volume gemountet wird, wann hier irgendwo mal eine Docker-Container hinzugefügt wird, wie man ein Docker-Makefile zusammensetzt, wie man eine Docker-Compose.yml schreibt, usw.

All das muss ich aber wissen, damit ich ernsthaft verstehe, was im Hintergrund mit DDEV passiert. Und das Ziel einer Drupal-Website ist ja, dass die irgendwann mal online im Internet auftaucht.

D.h. bevor du dich jetzt mit Docker beschäftigst, um DDEV zu begreifen und dann Drupal mit DDEV zu entwickeln, um anschließend auf einer ganz anderen Architektur, nämlich z.B. auf einem Virtual Private Server oder einem Root Server, wieder ein anderes System aufzusetzen, um damit Drupal ins Internet zu kriegen…

Du merkst schon, das ist eine Lernkurve, die wird immer steiler. Warum gehst du nicht gleich her und sagst, ich habe bei meinem Webposter aller Voraussicht nach für Drupal einen Virtual Private Server oder einen Root Server, darauf läuft ein Linux, beispielsweise Ubuntu.

Das bedeutet, ich möchte doch auf meiner Entwicklungsumgebung nach Möglichkeit die exakt selbe Umgebung haben, die ich später auch im Datacenter bei meinem Webposter haben werde, damit ich in der Entwicklungsumgebung nach Möglichkeit, wenn es Fehler gibt, wenn ich Fehler beseitigen muss, schon Troubleshooting betreiben kann.

Und hier passt es einfach nicht, wenn ich auf DDEV entwickle und dann aber auf einem Linux, ganz normal mit Apache oder Nginx, MySQL, PHP usw. hosten will.

No way. Warum nicht?

Ein Kleines Beispiel:

Es gibt für Drupal die sogenannte Image Optimize Pipeline.

Das ist ein Modul zum Optimieren von Bildern. Dieses Modul greift allerdings auf Kommandozeilenwerkzeuge zum Optimieren von Bildern zurück, die erstmal auf deinem Host-System, also auf dem Server im Internet, installiert werden müssen. Das kannst du natürlich auch in einer DDEV-Umgebung machen, indem du dort einfach für jedes Werkzeug einen Container einhängst, der das jeweilige Werkzeug enthält.

Also pngoptim, jpgtran, all diese Kommandozeilentools, die auf deinem System installiert werden müssen, damit das Drupal-Modul darauf zugreifen und sie nutzen kann, um diene Bilde in möglichst kleiner Dateigröße bei möglichst hoher Qualität ausliefern zu können.

Für Neueinsteiger, die sich mit Docker noch nicht auskennen, ist dass aber gar nicht so leicht zu bewerkstelligen.

Du kannst es aber auch einfach lassen und kannst direkt das WSL unter Windows 10 oder Windows 11 benutzen.

Dann hast du auch einen Container. Spoiler-Alarm! Docker für Windows benutzt im Hintergrund auch die WSL2.

Wenn du Docker jetzt aber weglässt und dich stattdessen lieber damit beschäftigst, wie du auf einem Ubuntu auf der WSL einen Apache-Webserver, ein PHP mit FPM, sowie MySQL aufsetzt und dir das beibringst, sodass du es auf einem V-Server oder auf einem Root-Server wiederholen kannst, sobald du deine Seite online bringst, dann ist das meiner Meinung nach die bessere Variante, weil du später auch in deinem Live-Setup weißt, wo du hingucken musst, wenn ein Fehler auftritt.

Du musst nicht lernen, wie du eine Docker-Log aufkriegst. Du musst nicht lernen, wie du Volumes oder neue Container mit speziellen Tools einhängst und so weiter und so weiter. Dieser ganze Docker-Overhead, der fällt erstmal weg.

Der ist auch für professionelle Entwickler gedacht, die ihre Arbeit mit einer absolut gleichen Umgebung weitergeben wollen, weil sie zusammen an einem Projekt arbeiten und die gleichen Voraussetzungen auf jedem Rechner schaffen wollen.

Das heißt, der eine hat einen MacBook, der andere hat einen Windows-PC, wieder einer arbeitet mit Linux und alle drei sollen auf der gleichen Entwicklungsumgebung in gleicher Art und Weise entwickeln können, damit das Projekt für den Kunden, das auf Drupal basiert, schneller fertig wird. Das ist legitim und das ist der Einsatzzweck von DDEV.

Eine absolut gleiche Entwicklungsumgebung für jeden am Projekt beteiligten Entwickler.

Wenn du jetzt aber alleine bist und deine Drupal-Webseite zu Hause auf dem heimischen Rechner erstellst, dann geht das mit dem Ansatz über die WSL erstens schneller und zweitens mit einem wesentlich größeren Lerneffekt oder um in der Drupal-Sprache zu bleiben, mit einer wesentlich flacheren Lernkurve, als wenn du DDEV und damit Docker einsetzt.

Also würde ich dir empfehlen, wenn du Windows 10 oder Windows 11 hast, benutze die WSL, pack dir da Ubuntu, einen Web-Server, einen MySQL-Server, eine PHP-Installation drauf, bring dir lieber bei, wie die miteinander sprechen und wenn du weißt, wo do hier nach Fehlern sehen musst und darauf dein Drupal perfekt läuft dann kannst du dich mit DDEV und Docker beschäftigen Denn in solchen Containern läuft oft auch Ubuntu. Es bringt dir jedoch nichts, wenn du dich gleich auf DDEV stürzt und von den Grundlagen absolut keine Ahnung hast. Wenn du das so machst, wirst du mit sicherheit keinen Spaß haben.

Deshalb macht es aus meiner Sicht keinen Sinn, den Leuten DDEV hinzulegen und sagen, hier hast du ein paar Kommandozeilen-Skripte. Das funktioniert!

Weil spätestens, und das ist das große Problem, wenn etwas nicht funktioniert, spätestens dann musst du wissen, warum nicht.

Und das geht in einer normalen WSL-Umgebung ohne Docker wesentlich einfacher als in einer DDEV-Umgebung, vor allem dann, wenn Docker an sich und DDEV sowieso für einen total neu sind.

Ich liebe Docker in meinem Homelab, ich liebe Docker auf meinem NAS, damit geht alles, damit geht auch Drupal, kein Thema, aber ich mache das jetzt seit über 15 Jahren.

Das heißt, ich hatte 15 Jahre Zeit, mir Dinge sukzessive beizubringen, von, wie installiere ich einen Web-Server und den ganzen Stack, bis hin zu wie schreibe ich einen Docker-Make-File, wie schreibe ich einen eigenen Docker-Container, wie schreibe ich eine eigene Docker-Anwendung wie DDEV. Wenn man dass weiß, dann kann man das machen, wenn man davon schon Ahnung hat.

Wenn man aber Ahnung kriegen möchte und man bindet sich quasi zusätzlich dazu, dass man eine Drupal-Webseite entwickelt, noch mit ans Bein, dass man Docker und DDEV lernen muss, um seine Entwicklungsumgebung bedienen, beherrschen und ganzheitlich verstehen zu können, dann ist es zumindest meiner Meinung nach der falsche Ansatz.

Deswegen empfehle ich dir, schau mal, hier ist ein Link für dich, guck dir einfach diese Videoreihe an, mach mit, installiere das mal mit dem Windows-Subsystem für Linux, auf deinem heimischen Windows 10 oder Windows 11 Rechner, was auch immer, und wenn du das geschafft hast und dein Drupal läuft und du sagst, schön, jetzt läuft mein Drupal, jetzt weiß ich auch, wie das alles zusammengesetzt ist, dann kannst du das von mir aus wieder von der Platte schmeißen und sagen, jetzt nehme ich Docker und DDEV, weil Docker und DDEV nehmen dir nämlich die Installation von PHP ab, die Installation von Apache ab, die Installation von Nginx ab, die Installation von Composer ab, die Installation von Drush ab…

Diese Entwicklungsumgebung nimmt dir alles ab, was du an Grundlagen wissen musst, um Drupal auf einem echten Server im Datacenter zu betreiben. Dort kannst du nämlich kein DDEV verwenden, weil Docker und auch DDEV nicht für den Live-Betrieb gedacht sind.

DDEV ist super, wenn man schnell sein will und schon Ahnung hat. Wenn man keine Ahnung hat und jemand, der mit WAMP und XAMPP gearbeitet hat, um Drupal zu entwickeln, nimm es nicht persönlich, der hat keine Ahnung, weil man das einfach seit gefühlten 10 Jahren nicht mehr macht, der sollte sich, wenn er denn wirklich was lernen will, seine Lernkurve nicht noch steiler machen, indem er direkt auf DDEV setzt. Alles klar?

Und natürlich kannst du mit der oben verlinkten Videoreihe direkt lernen, wie du Updates machst, Module installierst usw. Also wenn ich du wäre, dann würde ich mir dass mal geben.