WordPress Playground: WordPress läuft vollständig im Browser

 (developer.wordpress.org)
5 Punkte von GN⁺ 2023-07-15 | 1 Kommentare | Auf WhatsApp teilen
  • WordPress Playground ist ein Online-Tool, mit dem sich WordPress ohne Installation ausprobieren und erlernen lässt; diese Seite dient nicht als Produktseite, sondern als offizieller Dokumentations-Hub
  • Die Dokumentation ist in Documentation, Blueprints, Developers und API Reference unterteilt und erklärt jeweils den Einstieg, JSON-basierte Konfiguration, Code-Integration und API-Referenz
  • Nutzer können innerhalb von 5 Minuten eine neue WordPress-Website starten, Blöcke, Themes und Plugins testen oder bestimmte WordPress/PHP-Versionen prüfen
  • Entwickler können je nach Zweck zwischen Query API, Blueprints API und JavaScript API wählen und Playground als lokale Entwicklungsumgebung ohne Konfiguration nutzen
  • Da es in einer Browser-Sandbox läuft und nur wenige Abhängigkeiten von Backend und Authentifizierung hat, eignet es sich für schnelle Demos, Prototypen und KI-generierte Experimentierumgebungen

Dokumentations-Hub für WordPress Playground

  • Die offizielle Playground-Website ist zu wordpress.org/playground/ umgezogen; diese Seite dient als Einstiegspunkt in die Dokumentation
  • WordPress Playground ist ein Online-Tool zum Experimentieren mit und Lernen von WordPress
  • Die Dokumentation besteht aus vier Hubs
    • Documentation: Einführung in WordPress Playground, Einstiegsleitfaden und Einstiegspunkt in die Dokumentation
    • Blueprints: Dokumentation zu JSON-Dateien zur Konfiguration von Playground-Instanzen
    • Developers: Wie sich Playground im Code nutzen lässt
    • API Reference: Vollständige Referenz der von WordPress Playground bereitgestellten APIs

Einstieg und Entwicklungsablauf

  • Neue Nutzer können im Quick Start Guide schnell damit beginnen, eine neue WordPress-Website zu erstellen, Blöcke, Themes und Plugins zu testen sowie bestimmte WordPress/PHP-Versionen zu prüfen
  • Die Playground web instance behandelt die unter https://playground.wordpress.net/ bereitgestellte Playground-Instanz
  • Unter About Playground finden sich Informationen zur Sicherheit von Playground, zu Nutzungsmöglichkeiten und aktuellen Einschränkungen
    • Über die Dokumente Build, Test und Launch lässt sich nachvollziehen, wie Playground für Produktentwicklung, Validierung und Veröffentlichung eingesetzt werden kann
  • Guides bündelt Schritt-für-Schritt-Anleitungen und Nutzungsszenarien; Links and resources sammelt verwandte Materialien

Erste Schritte und API-Auswahl

Beiträge und KI-Nutzung

  • WordPress Playground ist ein Open-Source-Projekt und nimmt Beiträge zu Code, Design, Dokumentation und Triage an
  • Playground ist für die Nutzung mit KI-Coding-Agenten und KI-basierten Tools konzipiert
    • Es läuft vollständig clientseitig in WebAssembly, benötigt keine Authentifizierung und kein Backend und hinterlässt keine dauerhaften Seiteneffekte außerhalb der Browser-Sandbox
    • Using Playground with AI agents: In Claude Code, Cursor, Gemini CLI, GitHub Copilot und ähnlichen Tools kann der wp-playground-Skill installiert werden, um Befehle ausführen zu lassen
    • AI-readable site index: Maschinenlesbare llms.txt-Zusammenfassung der Playground-Funktionen, APIs und Dokumentation
    • AGENTS.md: Richtlinien für KI-Coding-Agenten, die zu dieser Codebasis beitragen
  • WordPress Playground ist freie Software unter den Bedingungen der GNU General Public License Version 2 oder später; die vollständige Lizenz steht in LICENSE.md

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-07-15
Hacker-News-Kommentare

  • Auf Firefox auf einem günstigen Android-Tablet ausprobiert: Die Reaktion ist nicht sofortig, aber es unterscheidet sich kaum davon, einen kompletten LAMP-Stack auf einer brauchbaren Cloud-Instanz oder einem VPS laufen zu lassen – ziemlich beeindruckend.
    Hier laufen der komplette PHP-Interpreter, tausende Zeilen der WordPress-Codebasis und sogar SQLite. Umso erstaunlicher, dass es trotzdem gut benutzbar ist.

    • Ich hatte immer das Gefühl, dass sich die WordPress-Performance auf schwacher und starker Hardware nicht stark unterscheidet. Am Ende scheint WordPress selbst der Flaschenhals zu sein.

  • Die Art, wie das zum Laufen gebracht wurde, ist sehr modern: PHP läuft als WebAssembly-Binärdatei, MySQL wird in WordPress per Plugin durch SQLite ersetzt, und der Webserver ist als JavaScript-Service Worker umgesetzt.

  • Bei der Aussage „Playground unterstützt eine Notiz-App für Mobilgeräte, automatisierte Testumgebungen und sogar auf Websites laufende WooCommerce-Demos“ leuchten mir die letzten beiden völlig ein, aber die Vorstellung einer WordPress-basierten mobilen App, die im Browser PHP per WebAssembly ausführt, sprengt mir den Kopf.

  • WordPress spaltet die HN-Gemeinde stark. Die eine Seite sieht WordPress als Werkzeug zur Wertsteigerung, mit dem Nichtentwickler sich auf ihr eigentliches Geschäft konzentrieren können, ohne sich um Code zu kümmern; die andere hasst es wegen der chaotischen Codebasis und hängt stattdessen an perfekt formatiertem, ultraerweiterbarem Code, den in der Praxis fast niemand nutzen wird.
    WordPress betreibt mehr als die Hälfte des Webs. Vielleicht ist es nicht die beste Technologie, vielleicht die schlimmste, aber die Lektion, die viele Programmierer immer wieder verpassen, ist: Niemand interessiert sich dafür, wie die Wurst gemacht wird.

    • Wenn es darum geht, kleine Utility-Websites etwa für eine Band zu bauen, stimme ich dem voll zu. Wenn es reicht, das Ding billig zu hosten und zu hoffen, dass sich die Band auflöst, bevor die Google-Calendar-Integration kaputtgeht, dann ist das völlig in Ordnung.
      Da ich allerdings gerade aufschiebe, ein Third-Party-SSO von einer alten, chaotischen WordPress-Seite auf eine neue, chaotische WordPress-Seite umzuziehen, muss ich mal loswerden: Es gibt tatsächlich eine dritte Gruppe, die dafür sorgt, dass die erste Gruppe sich nicht darum kümmern muss, wie die Wurst gemacht wird.
      Ich mache so etwas seit ungefähr 14 Jahren, hoste rund 300 WordPress-Seiten einer mittelgroßen Universität, habe .gov-Seiten gebaut und gepflegt und wegen der Richtung des Gutenberg-Teams etliche React-basierte Blöcke über drei stark unterschiedliche Muster hinweg entwickelt. Ich habe alles gemacht, von Server-Deployments über CSS-Fixes für IE6, das Scrapen eines nicht vorhandenen CMS zur Migration von tausenden Seiten und zehntausenden Bildern nach WordPress, bis hin zum Schreiben von WP-CLI-Befehlen und Code, der Kalenderereignisse in einem Multisite-Setup mit Gewalt weiterreicht.
      Irgendwer muss wissen, wie die Wurst gemacht wird, und ich weiß es. Deshalb weiß ich auch, was für ein wackeliger Müllhaufen WordPress ist. Ich habe auch tatsächlich nützliche Codebasen mit besseren Tools und verständlichen Datenbanken betreut und weiß, dass andere Plattformen ebenfalls Probleme haben, aber WordPress ist wirklich schlecht.
      Deshalb habe ich kein Problem damit, darüber herzuziehen. Ich bin komplett ausgebrannt und denke manchmal ernsthaft daran, einfach aufzuhören, in einem Truck zu leben und Musik zu machen. Es ist eine miserable Plattform, und die Leute bezahlen einen auch nicht besonders gut dafür, sie am Laufen zu halten. Am Ende gibt es wegen der Umstände immer wieder Menschen, die zu WordPress zurückkehren wie zu einem brennenden Gebäude, und der kollektive Hass auf diese Plattform ist völlig begründet.
    • Für die zuerst genannte Gruppe ist WordPress großartig. Ich sehe es ähnlich wie Werkzeuge wie Excel, FileMaker oder Visual Basic, die Software demokratisiert und für alle zugänglich gemacht haben.
      Natürlich haben solche Werkzeuge Grenzen und Qualitätsprobleme, und einige Nutzer stoßen irgendwann darauf. Das ist an sich in Ordnung. Das Problem entsteht, wenn man von Profis erwartet, darauf zu integrieren oder darauf aufzubauen. Leute, die zu Webentwicklern kommen, bringen Qualitätserwartungen, spezielle Probleme und Anforderungen mit, und das Erbe von WordPress legt vor diese Ziele so viele Fallen und Hürden, dass es oft wirkt, als wolle man einen eckigen Nagel in ein rundes Loch stecken. Ähnliches ließe sich auch über gängige CRM- oder E-Commerce-Plattformen sagen.
    • Ich halte mich für einen ernsthaften Softwareingenieur, benutze für die Firmenwebsite aber WordPress.
    • Vielleicht geht es weniger darum, für „perfekt formatierten und ultraerweiterbaren Code“ wegzugehen, sondern eher darum, die Arbeit an der aktuellen unvollkommenen Codebasis einzustellen und stattdessen ein neues Projekt zu starten, das diesmal perfekt sein soll.
    • Diese Spaltung wirkt eher wie der Unterschied zwischen der neuen Generation von Full-Stack-JavaScript-Entwicklern und Leuten, die mit PHP + MySQL gelernt haben.

  • In der State-of-the-Word-Keynote im Dezember 2022 sollte das ziemlich groß behandelt werden: https://wordpress.tv/2023/01/04/matt-mullenweg-state-of-the-...
    Als Ingenieur war es ziemlich beeindruckend, das tatsächlich in Aktion zu sehen und über all die Schichten nachzudenken, die dafür zusammenspielen müssen. Lustig, es sechs Monate später auf HN als Diskussionsthema zu sehen.

    • Ich finde es sehr spannend, Dinge, die bisher als „serverseitige“ Anwendungen galten, im Browser laufen zu lassen. Besonders interessant ist es, weil es wie der erste Fall wirkt, in dem SQLite in einem echten Produkt läuft; bisher hatte ich nur Spielzeug-Demos gesehen.
      Als ich ein wenig in den Code geschaut habe, wurde mir auch klar, dass ich aktuell fast nichts über PHP weiß, und es scheint auch nicht so, als würde hier für Persistenz der „traditionelle“ SQLite-over-OPFS-Ansatz verwendet. Je mehr ich gelesen habe, desto unklarer wurde auch, ob persistenter Speicher über Emscripten überhaupt schon möglich ist. Am Ende habe ich https://github.com/WordPress/wordpress-playground/issues/19 gefunden, und das scheint zu bedeuten, dass Persistenz für WordPress im Browser noch nicht möglich ist, was schade ist.
    • Die Präsentation war gut. Für Interessierte: Ab 48:33 wird WordPress Playground vorgestellt.

  • Rein aus Neugier: Heißt das, dass man WordPress, wenn man die Datenbank erstmal ausklammert, auf einem Cloudflare Worker laufen lassen könnte? https://developers.cloudflare.com/workers/runtime-apis/webas...

  • Ich nutze WordPress häufig für mehrere fast statische Websites. Es ist gut geeignet, damit Nicht-Techniker fortlaufend Inhalte hinzufügen können, und für diesen Zweck gibt es kaum eine Alternative, die an WordPress herankommt.
    Man muss nur die verwendeten Plugins sorgfältig auswählen, ein passendes Cloudflare-Frontend aufsetzen und verhindern, dass Nutzer Dinge tun, die oberflächlich simpel wirken, aber riskant sind. Ein großer Teil des WordPress-Hasses kommt mir so vor, als stamme er von Leuten, die es vor sehr langer Zeit benutzt haben, Anforderungen hatten, die WordPress nicht erfüllen konnte, oder es als Legacy mitgeschleppt haben.

    • Bei mir war es die zweite und dritte Variante zusammen mit Projekten, bei denen der Kunde auf WordPress bestanden hat, obwohl ein Headless CMS + Custom Code viel besser gewesen wäre.
      Eigentlich ist das nicht die Schuld von WordPress, aber allein der Name lässt mich immer noch ein wenig ängstlich zusammenzucken.

  • Dieses Playground, das PHP in WASM ausführt, ist deutlich reaktionsschneller als 95 % aller normalen Websites.

    • Das Coolste daran ist, dass es eine enorme Menge an Server-Roundtrips einspart. Alle Datenbankaufrufe und Asset-Anfragen passieren auf dem Client. Natürlich muss man dafür Ladezeiten von ein paar Sekunden in Kauf nehmen.
      WordPress ist vermutlich die am weitesten verbreitete Lösung für Multi-Page-Anwendungen, und das hier verwandelt es praktisch in eine Single-Page-Anwendung. Außerdem ist die Performance besser als bei den meisten Single-Page-Anwendungen, weil nicht ständig API-Anfragen an den Server geschickt werden müssen.
      Die Single-Page-Anwendungs-Teile wie der Beitrags-/Seiteneditor und der Site-Editor sind komplexe React-Apps, und in dieser Demo fühlen sie sich sogar flotter an als in einer lokalen Entwicklungsumgebung. Das zeigt gut, wie viel besser Single-Page-Anwendungen werden können, wenn man Server-Roundtrips eliminiert. Zur Einordnung: Ich arbeite bei Automattic, und es war wirklich großartig, dieses Experiment zu beobachten.

  • Man muss WordPress nicht schlechtreden, aber es hat eine lange Geschichte und viele Probleme. Es wäre schön, wenn es eine moderne Self-Hosting-Alternative gäbe, die ohne statische Seitengenerierung oder kompliziertes Hosting nutzbar ist.

    • Jeder Konkurrent muss ein wirklich brutales Henne-Ei-Problem überwinden. Für WordPress gibt es Plugins für fast alles, und in der Regel ist auch bezahlter Support möglich, deshalb ist es schwer, daran vorbeizukommen.
      Die Codebasis ist nicht gut, darauf zu entwickeln ist unerquicklich, und weder die Art des Designs noch die Verwaltung des offiziellen Stores verhindern das Chaos und die Risiken auf der Datenbankseite. Trotzdem lässt sich ein Angebot wie „Klingt gut, wir brauchen erstmal mindestens zwei Monate Entwicklungszeit“ viel schwerer verkaufen als zwei Tage Setup und 80 Dollar pro Monat für Plugins/Themes.
      Selbst wenn Entwicklungsarbeit nötig ist, findet man leicht Leute mit WordPress-Erfahrung, und wenn man niemanden direkt einstellen will, gibt es auch viele auf WordPress spezialisierte Agenturen. Ein neu aufkommender Konkurrent hat diesen Größenvorteil nicht. Ein erweiterbares System mit Plugin- und Theme-Struktur deutlich besser als WordPress zu entwerfen, ist keine Kleinigkeit, aber auch nicht unmöglich und erfordert kein Genieteam. Auf dem tatsächlichen Marktweg, WordPress zu verdrängen, ist das aber noch der einfachste Schritt.
    • Funktional gibt es viele perfekte Ersatzlösungen, aber das eigentliche Wertversprechen von WordPress ist das Plugin-Ökosystem, der Entwicklerpool und die Unterstützung durch die Nutzerbasis.
      Jeder hat schon einmal einen Kunden erlebt, der nur WordPress will und alles andere ablehnt. Selbst wenn man eine saubere neue Lösung ausrollt, kehren Kunden oft wieder zu WordPress zurück. Wert gesehen habe ich bei einem hybriden Ansatz, bei dem komplexe Anforderungen von Custom-Apps in anderen Frameworks umgesetzt werden und Inhalte über eine WordPress-Instanz mit Connectoren verwaltet werden.
    • Der Grund, warum WordPress heute erfolgreich ist, liegt darin, dass WordPress über Jahre hinweg größtenteils stabil blieb, während andere CMS ständig ihre APIs kaputtgemacht haben, und dadurch konnte ein riesiges Plugin-Ökosystem wachsen.
      Außerdem verwendet die WordPress-PHP-API kaum Objektorientierung und besteht größtenteils aus Funktionen und Arrays, sodass auch Leute mit nur sehr grundlegenden Programmierkenntnissen eigene Plugins oder Themes bauen konnten.
    • Das CMS, mit dem Entwickler gern arbeiten möchten, und das CMS, das Unternehmen einsetzen möchten, sind nicht dasselbe. Um in Letzteres hineinzukommen, muss man viele pragmatische Entscheidungen treffen, die einen vom Ersteren wegführen.
      Unternehmen mögen Dinge, die lange überlebt haben, und solche Dinge sind per Definition oft altmodisch.
    • Hier ist es: https://github.com/Qbix/Platform

  • Die Technik hinter dieser Demo ist wirklich großartig. Es wäre schön, PHP-Fehler-/Warn-Logs in Echtzeit sehen zu können, und ich würde besonders gern prüfen, wie vollständig dieser Simulator ist, einschließlich der Umschreibung der SQLite-Datenbank.
    Auch das Testen von Plugins oder Themes ist sehr einfach. Man muss nur &plugin=plugin-slug-from-dir anhängen; wenn der Slug mit dem Plugin-Slug der WordPress.org-URL übereinstimmt, wird es automatisch heruntergeladen und zur Sandbox hinzugefügt. Die vollständige Dokumentation der Query-API zum Konfigurieren der Sandbox steht hier: https://wordpress.github.io/wordpress-playground/query-api/
    Ich bin sicher, dass es irgendeine Möglichkeit gibt, das Debug-Log zu öffnen oder anzuzeigen. Wenn es so etwas nicht gäbe, hätte man das hier gar nicht entwickeln können.