Wir haben vor drei Monaten eine Umfrage gestartet und euch gefragt, welche Art von lokaler Entwicklungsumgebung ihr für die lokale Ausführung von WordPress einrichtet. Zum Zeitpunkt des Schreibens hatten wir 2.623 Stimmen, was eine beachtliche Aussagekraft hat. Insbesondere, da die Frage so formuliert war:
Wenn Sie WordPress lokal ausführen (d. h. PHP, MySQL und einen Webserver ausführen), wie machen Sie das?
Vorausgesetzt, Sie *führen* eine lokale Umgebung aus. (Bitte tun Sie das.)
Hier ist ein Bild der Ergebnisse
(Wenn Sie das nicht sehen können, machen Sie sich keine Sorgen, wir werden die Ergebnisse gleich durchgehen.)
Der Gewinner war mit 61% die Verwendung einer Art Software mit Benutzeroberfläche zur Verwaltung. WAMP / MAMP / AMPPS wurden erwähnt, aber es hieß auch „Ähnliche Software mit Benutzeroberfläche“, was meiner Meinung nach relevant ist, wie wir gleich sehen werden. Diese Option war mehr als 3 Mal beliebter als jede andere Wahl.
Vagrant belegte mit 15% den zweiten Platz. Ich bin sicher, dass ein Teil davon die direkte Nutzung von Vagrant ist, aber auch beträchtliche Teile gehen an vorkonfigurierte Projekte für WordPress wie VCCW, VVV oder Scotch Box.
An dritter Stelle stand die direkte Installation von Dingen mit 13%. Alle diese anderen Optionen versuchen zumindest ansatzweise, die Abhängigkeiten der lokalen Entwicklung zu isolieren. Das bedeutet, wenn Sie mehrere lokale Entwicklungsumgebungen haben (sehr üblich), müssen nicht alle dieselben Abhängigkeiten gemeinsam nutzen. Dies kann auch relevant sein, wenn Sie nur WordPress-Entwicklung betreiben. Vielleicht läuft ein Projekt mit PHP 7 und MySQL 5.7, ein anderes jedoch auf älteren Hosting-Systemen mit PHP 5.3 und MySQL 4. Es ist eine gute Idee, diese Produktionsversionen in der Entwicklung abzugleichen, damit Sie sicher sein können, dass das, was Sie lokal tun, auch in der Produktion funktioniert. Ohne jegliche lokale Isolierung sind Sie in der Entwicklungsumgebung an dieselben Versionen von allem gebunden. Mag in Ordnung sein, wenn Sie nur an einer Sache arbeiten!
Docker war die vorletzte Wahl mit 7%. So angesagt Docker auch zu sein scheint, seine Verbreitung unter WordPress-Nutzern hat sich bisher offenbar noch nicht sehr stark durchgesetzt.
Gilbert Pellegrom hat einen tollen Vergleich von Vagrant und Docker
Der Nachteil von [Vagrant] ist, dass jede virtuelle Maschine nicht nur Ihre Anwendung und all ihre Bibliotheken enthält, sondern auch das gesamte Gastbetriebssystem, das durchaus Dutzende von Gigabyte groß sein kann.
Docker hingegen verwendet „Container“, die Ihre Anwendung und alle ihre Abhängigkeiten enthalten, aber den Kernel (Betriebssystem) mit anderen Containern teilen. Container laufen als isolierte Prozesse auf dem Host-Betriebssystem, sind aber nicht an eine bestimmte Infrastruktur gebunden (sie können auf jedem Computer ausgeführt werden).
Was ist das Ergebnis all dessen?
- Vagrant ist einfacher zu verstehen und schneller einsatzbereit, kann aber sehr ressourcenintensiv sein (in Bezug auf RAM und Speicherplatz).
- Dockers Architektur ist schwieriger zu verstehen und kann schwieriger einzurichten sein, ist aber viel schneller, verbraucht deutlich weniger CPU und RAM und potenziell weniger Speicherplatz als Vagrant-VMs.
Persönlich nutze ich jetzt Docker für all meine WordPress-Sachen (auf meinem Mac) und fand es nicht besonders schwierig einzurichten oder zu verstehen. Eine Sache, die mir Probleme bereitete, war, meine MySQL-Sachen anfangs nicht auf ein „Volume“ zu legen, was die Datenbank anfällig dafür machte, gelöscht zu werden, wenn Docker den Container neu erstellte (aber das habe ich behoben). Ich habe dies hier befolgt.
5% der Leute stimmten für „Andere“ und wurden gebeten, sich in den Kommentaren zu äußern. Es gab 63 Kommentare, was für einen CSS-Tricks-Beitrag heutzutage ziemlich wenige sind!
22 Kommentare erwähnten Laravel Valet, also verdient das hier eine besondere Erwähnung.
Valet ist eine Laravel-Entwicklungsumgebung für Mac-Minimalisten. Kein Vagrant, keine `/etc/hosts`-Datei. Sie können Ihre Websites sogar öffentlich über lokale Tunnel teilen...
Laravel Valet konfiguriert Ihren Mac so, dass Nginx immer im Hintergrund läuft, wenn Ihr Computer startet. Dann leitet Valet mithilfe von DnsMasq alle Anfragen an die *.dev-Domäne so um, dass sie auf auf Ihrem lokalen Computer installierte Websites verweisen.
Mit anderen Worten, eine blitzschnelle Laravel-Entwicklungsumgebung, die etwa 7 MB RAM verbraucht.
Es gab auch 8 Erwähnungen für Local by Flywheel (Mac und Windows), was wie eine gute Benutzeroberfläche für die Verwaltung lokaler WordPress-Entwicklungsumgebungen aussieht.
Wenn Sie Valet oder Local verwenden, hätten Sie entweder in der Kategorie „Ähnliche Software mit Benutzeroberfläche“ oder „Andere“ abstimmen können. In der großen Tradition der CSS-Tricks-Umfragen sind die Daten also etwas ungenau.
Toller Artikel & Recherche! Zum „Nachteil“ von Vagrant möchte ich darauf hinweisen, dass es möglich ist, eine Vagrant-Maschine zu verwenden, die mehrere Projekte enthält. Ich habe Vagrant schon immer auf diese Weise für die WordPress-Entwicklung genutzt und bin immer noch erstaunt, dass viele Leute für jedes ihrer Website-Projekte eine neue Vagrant-Instanz erstellen, obwohl das System immer dasselbe ist.
Stimmt. Das Einrichten von virtuellen Hosts ist trivial, besonders mit Nginx.
Ich nutze heutzutage auch Laravel Valet! Super einfach zu bedienen, mockt HTTPS und teilt von lokal mit einer eindeutigen URL. Tatsächlich nutze ich es für die meiste lokale Entwicklung… nicht nur für WordPress. Auf jeden Fall einen Blick wert!
Ich habe Scotch-Box fast zwei Jahre lang mit gelegentlichem VVV genutzt. Allerdings ist Local by Flywheel (früher Pressmatic) das Beste seit geschnittener Brot. Ich kann es nur wärmstens empfehlen, es macht das Leben unglaublich einfach. Außerdem wird es von Docker angetrieben!
+1 für Valet, ich hatte ein paar Schwierigkeiten bei der Einrichtung – und vergiss es, wenn du einen wirklich alten Mac hast – aber jetzt ist es nur noch eine Frage des Erstellens eines Ordners und einer neuen Datenbank
Wir betreiben einen Headless Ubuntu-Server in einer VM und verwenden Port-Weiterleitung.
Docker unter Windows ist erstaunlich. Ich habe das Debugging noch nicht herausgefunden, aber es ist eine unglaublich großartige Möglichkeit, den gesamten WordPress-Stack in einer schönen kleinen Box zu starten.
Mein Cloudbook-Laptop hat nicht genug Speicherplatz, um lokal zu entwickeln, also verwende ich Cloud9, das ein schönes, vorkonfiguriertes Setup für WordPress-Projekte hat.
Ich stelle mir vor, dass Desktop Server keine beliebte Wahl ist? Möchte jemand seine Docker-Rigs hier teilen? Bonuspunkte, wenn es Swarm mit einem einzigen Redis-Cache verwendet, der über Instanzen verteilt ist.
Meiner Meinung nach gibt es keinen wirklichen Vorteil, etwas so Komplexes wie Docker über eine einfache (oder fortgeschrittene) Host-basierte Umgebung laufen zu lassen. Die komplexeren Setups erfordern eine richtige VM, also NICHT das Teilen des Kernels usw., da es meistens darum geht – der Kernel unterscheidet sich stark, spezifische GNU-Tools fehlen oder sind nicht zugänglich, nur FTP verfügbar, begrenzte PHP-Module usw. Im besten Fall können Sie mit einer Unix-VM arbeiten, die Kernel von 2.6 bis aktuell 4.8 zulässt (z. B. ArchLinux, Manjaro, Debian Unstable). Das schlimmste Szenario ist jedoch, dass die gesamte Einrichtung sorgfältig repliziert werden muss, z. B. die Installation des Betriebssystems, das auf der entfernten Live-Umgebung läuft, usw.pp.
Und nein, nicht jeder lebt in dem schicken Land, in dem „mein Kunde einen vollen Server zum Spielen hat“. Eigentlich bin ich immer ziemlich amüsiert bis genervt von Leuten, die immer behaupten, es müsste SO und nicht anders sein. Die meisten kleinen bis mittelgroßen Unternehmen nutzen einfache Shared-Hosting-Konten, vielleicht in einigen Fällen etwas aufgemotzt, aber trotzdem: Eine sehr reduzierte, ressourcenbeschränkte Umgebung. Leute wollen einfach nur eine Website, keine ganze verdammte Server-Infrastruktur. Und es ist ihnen egal, welche Vorteile ein verwalteter v-Server oder ein vollwertiger dedizierter Server ihnen bieten mag: Es ist eine Website, vielleicht ein bisschen Responsivität hier und ein paar Produkte dort, aber das war's. Außerdem geht es natürlich um die monatlichen Wartungskosten.
Oder kommen vielleicht all die hart arbeitenden Entwickler nicht mehr hierher oder haben einfach aufgegeben, ihre Gedanken zu äußern, weil heutzutage alles im glücklichen npm + gulp + Docker-Land stattfindet? Ich weiß es nicht.
Zurück zum Thema: VM, wo sie gebraucht wird. Selten, aber eine richtige, voll ausgestattete VirtualBox- oder KVM-VM ist schnell eingerichtet, insbesondere wenn Sie eine Vorlage verwenden (d. h. ein VM-Image, das Sie bereits für solche Aktionen vorbereitet haben). Laden Sie alles hinein, was Sie brauchen, verbinden Sie sich per SSH oder (im schlimmsten Fall) per FTP, entwickeln Sie alles auf Ihrem eigenen Rechner und dann ist Rollout-Zeit!
Abgesehen davon bleibe ich bei gutem altem XAMP – das funktioniert schon seit Ewigkeiten zuverlässig. PHP + MySQL / MariaDB sind immer recht aktuell, VHosts sind einfach einzurichten – auch ein vhost-spezifisches Setup für spezielle Aufgaben hilft sehr – und das Einrichten verschiedener Debugger ist ein nettes Feature (obwohl selten genutzt).
cu, w0lf.
Schamlose Werbung, aber wir entwickeln eine kostenlose lokale Entwicklungslösung für WordPress namens WPLib Box.
Im Moment ist es eine einzige Vagrant-Box, aber sie ist so konzipiert, dass sie „einfach funktioniert“ (so gut wir das sicherstellen können). Wir entwickeln sie aktiv weiter, um intern Docker zu nutzen, und planen, sie bald auf Multi-Projekt umzustellen.
Unser Ziel ist es, die flexibelste Lösung zu werden, die für die lokale WordPress-Entwicklung „einfach funktioniert“. Und wir planen, die Notwendigkeit von VirtualBox und Vagrant abzuschaffen, sobald die Technologie uns das erlaubt und es immer noch „einfach funktioniert“.
Wenn Sie daran interessiert sind, es auszuprobieren, haben wir einen kostenlosen Slack-Kanal, über den wir Support anbieten.