wp-playground

Überblick über die wp-playground-Skill

wp-playground ist die Skill für das Einrichten und Arbeiten mit WordPress-Playground-Instanzen, wenn Sie eine wegwerfbare, reproduzierbare Umgebung brauchen statt eines kompletten lokalen WordPress-Stacks. Die wp-playground Skill ist besonders geeignet für Plugin- und Theme-Entwickler, QA-Tester und Backend-Entwickler, die Fehler reproduzieren, Versionen testen oder ein Setup teilen wollen, das im Browser oder über @wp-playground/cli läuft.

Entscheidend ist, welches Problem sie löst: eine WordPress-Site schnell starten, den richtigen Code einhängen, die passende WP-/PHP-Version auswählen und genug Kontrolle behalten, um zu debuggen oder das Ergebnis zu paketieren. Das ist kein generischer „Schreib mir einen WordPress-Prompt“-Skill; es ist ein praktischer wp-playground guide für kontrollierte Setups, Blueprints, Snapshots und isoliertes Testen.

Am besten geeignet für wegwerfbare WP-Workflows

Nutzen Sie wp-playground, wenn Sie:

• eine temporäre WordPress-Site starten müssen, um eine Plugin- oder Theme-Änderung zu prüfen,
• gegen eine bestimmte WordPress- oder PHP-Version testen wollen,
• einen Blueprint ausführen oder einen Snapshot zum Teilen erzeugen möchten,
• Verhalten isoliert debuggen wollen, ohne Produktion oder eine lokale Datenbank zu beeinflussen.

Was den Skill unterscheidet

Die stärksten Unterschiede sind der CLI-Workflow, Blueprint-Unterstützung und die vorhersagbare ephemere Laufzeit. wp-playground funktioniert besonders gut, wenn Wiederholbarkeit wichtiger ist als eine polierte UI. Ebenfalls wichtig: Die Umgebung basiert auf SQLite und WebAssembly, was Leistung und Einschränkungen gegenüber einer klassischen Server-Installation verändert.

Wichtige Einschränkungen, die Sie zuerst kennen sollten

Das passt nur, wenn Sie in einer wegwerfbaren Umgebung arbeiten können. Es ist nichts für Produktionsdaten, langlebigen lokalen Zustand oder Workflows, die einen herkömmlichen WordPress-Stack auf MySQL-Basis brauchen. Für die besten Ergebnisse sollten Sie es als kontrolliertes Testlabor behandeln und nicht als Ersatz für Ihre Haupt-Entwicklungsumgebung.

So verwenden Sie die wp-playground-Skill

Installieren und die Quelldateien öffnen

Beginnen Sie mit dem standardmäßigen wp-playground install-Pfad für Ihr Directory-Tooling und lesen Sie dann die Quelldateien der Skill, bevor Sie sie mit Aufgaben ansprechen. Die wichtigsten Dateien in diesem Repo sind SKILL.md, references/blueprints.md, references/cli-commands.md und references/debugging.md. Diese Dateien zeigen, welche Eingaben der Skill erwartet und welche CLI-Flags relevant sind.

Eine grobe Idee in einen brauchbaren Prompt übersetzen

Ein schwacher Prompt lautet: „Richte WordPress Playground für mein Plugin ein.“
Ein stärkerer Prompt lautet: „Nutze wp-playground, um eine wegwerfbare lokale Instanz für das Plugin in packages/my-plugin zu erstellen, das Projekt automatisch zu mounten, gegen WP 6.9 und PHP 8.3 zu testen und mir den exakten CLI-Befehl plus alle Mount- oder Blueprint-Anpassungen zu nennen.“

Für wp-playground usage sollten Sie angeben:

• den Pfad zum Projekt,
• ob Sie server, run-blueprint oder build-snapshot möchten,
• die WordPress- und PHP-Versionen,
• ob der Code automatisch gemountet werden soll,
• ob Sie Xdebug oder eine Blueprint-Datei brauchen.

Zuerst den richtigen Workflow wählen

Nutzen Sie server --auto-mount, wenn Sie eine interaktive Instanz für Live-Tests brauchen. Nutzen Sie run-blueprint, wenn Sie ein skriptgesteuertes Setup brauchen, das startet und wieder endet. Nutzen Sie build-snapshot, wenn Sie ein wiederverwendbares Artefakt wollen, das Sie weitergeben oder später erneut ausführen können. Wenn es um Backend-Debugging geht, nennen Sie den genauen Fehlermodus und bitten Sie um Xdebug-freundliche Schritte, statt nur nach einem Startbefehl zu fragen.

Das Repo in dieser Reihenfolge lesen

Ein guter wp-playground guide beginnt mit SKILL.md, dann folgt references/cli-commands.md für die Form der Befehle, dann references/blueprints.md, wenn Sie Setup-Automatisierung brauchen, und schließlich references/debugging.md, wenn die Aufgabe Breakpoints, Mounts oder festhängende Läufe betrifft. Diese Reihenfolge reduziert Rätselraten und verhindert, dass Sie Flags wie --mount-before-install oder --blueprint-may-read-adjacent-files übersehen.

wp-playground-Skill FAQ

Ist wp-playground nur für Frontend-Demos?

Nein. Die wp-playground skill ist besonders nützlich für Plugin-, Theme- und Backend-Entwicklung, wenn Sie isoliertes WordPress-Verhalten, reproduzierbare Versionen oder Debug-Sessions brauchen. Es geht weniger um visuelle Demos als um kontrollierte Ausführung.

Brauche ich zuerst ein vollständiges lokales WordPress-Setup?

Meistens nein. Der Zweck von wp-playground install ist, Ihnen ohne Provisionierung eines klassischen Stacks eine schnelle Umgebung zu geben. Wenn Sie bereits einen lokalen Stack haben, ist wp-playground trotzdem nützlich, wenn Sie einen sauberen Vergleichspunkt oder eine bestimmte WP-/PHP-Kombination brauchen.

Wann sollte ich es nicht verwenden?

Verwenden Sie es nicht für Produktionsdaten, dauerhafte Content-Arbeit oder Workflows, die von MySQL-spezifischem Verhalten abhängen. Wenn Ihr Plugin auf externe Dienste, persistentes Dateisystem oder langlaufenden Zustand angewiesen ist, ist wp-playground möglicherweise nicht die richtige Standardwahl, außer Sie können diese Abhängigkeiten explizit in einem Blueprint abbilden.

Ist es anfängerfreundlich?

Ja, wenn die Aufgabe einfach ist und Sie den CLI-Beispielen genau folgen. Der größte Fehlerpunkt sind vage Angaben: Wenn Sie den Projektpfad, die Zielversionen oder die Frage nach einem Blueprint nicht nennen, wird das Ergebnis weniger nützlich. Einsteiger erzielen die besten Resultate, wenn sie jeweils nur einen klaren Workflow anfragen.

So verbessern Sie die wp-playground-Skill

Geben Sie der Skill die exakten Setup-Variablen

Der größte Qualitätsgewinn entsteht, wenn Sie den Projekt-Root, die gewünschten WP-/PHP-Versionen und die Frage, ob der Code automatisch oder explizit gemountet werden soll, angeben. Zum Beispiel ist „Nutze wp-playground, um plugins/contact-form gegen WP 6.9 und PHP 8.3 mit --auto-mount zu testen“ deutlich besser als „bring es zum Laufen“.

Nennen Sie den Fehlermodus, nicht nur das Ziel

Wenn Sie debuggen, sagen Sie genau, was kaputt ist: Die Installation schlägt fehl, ein Plugin-Hook wird nicht ausgelöst, eine REST-Antwort ist falsch oder ein versionsspezifischer Regressionseffekt tritt nur auf PHP 8.3 auf. So kann der Skill zwischen server, run-blueprint und build-snapshot wählen, und das macht auch jeden wp-playground for Backend Development-Workflow deutlich hilfreicher.

Achten Sie auf Mount- und Blueprint-Fehler

Häufige Probleme sind relative Mount-Pfade, Dateien, die vor der Installation vorhanden sein müssen, und Blueprints, die lokale Dateien in benachbarten Ordnern benötigen. Wenn Ihr erster Lauf fehlschlägt, verbessern Sie den Prompt, indem Sie absolute Pfade ergänzen, bestätigen, ob --mount-before-install nötig ist, und angeben, ob der Blueprint lokale Assets liest. Für Debugging sollten Sie nach Xdebug-Setup-Details und dem erwarteten IDE-Mapping fragen.

Iterieren Sie immer nur mit einer Variable auf einmal

Wenn die erste Ausgabe nah dran, aber nicht ganz richtig ist, ändern Sie nur eine Sache: WP-Version, PHP-Version, Mount-Modus oder Blueprint-Quelle. So lässt sich leichter erkennen, ob das Problem an der Umgebungswahl, den Befehlsschaltern oder dem eigentlichen Setup-Rezept liegt.