WordPress Playground: Die Zukunft von Tests und Demos

WordPress Playground ist eine vollständige WordPress-Installation, die im Browser läuft. PHP ist nach WebAssembly kompiliert (PHP.wasm), die Datenbank ist SQLite, und laut offizieller Seite zu den Einschränkungen sind die WASM-Dateien 15 bis 30 MB groß. Es gibt keinen Server, keine wp-config.php zum Ausfüllen, kein MAMP, kein Docker. Sie öffnen eine URL und sind in wp-admin.

Wenn Sie Plugins oder Themes veröffentlichen, Schulungen geben oder Pull Requests prüfen, ändert Playground einige tägliche Abläufe. Wenn Sie Produktionsseiten betreiben, ersetzt es diese nicht. Behandeln Sie Playground als Sandbox und Demo-Werkzeug, nicht als Hosting.

Mehr zur professionellen WordPress-Entwicklung bei WPPoland.

#Was ist WordPress Playground

Playground ist ein Open-Source-Projekt von WordPress unter GPLv2 oder neuer. Die Web-Instanz läuft unter playground.wordpress.net, die Dokumentation unter developer.wordpress.org/playground. Die Teile, die im Arbeitsalltag zählen:

• PHP.wasm führt PHP 7.4 bis 8.5 in einem Web Worker aus. Die Query API nutzt standardmäßig PHP 8.5; eine andere Version wählen Sie pro Sitzung mit ?php= oder in einem Blueprint
• SQLite ersetzt MySQL über das offizielle Plugin SQLite Database Integration. Die meisten Plugins, die $wpdb verwenden, funktionieren; Code mit handgeschriebenem MySQL-SQL kann scheitern
• Der Browserspeicher hält neue Playgrounds als Autosaves, wenn Speichern verfügbar ist. Playground behält bis zu fünf aktuelle Autosaves, ein temporärer Playground ist nach dem Neuladen weg
• Mail und WP-CLI funktionieren in einer Sandbox-Form. Nachrichten aus wp_mail() landen im Email-Werkzeug statt in einem Postfach, und das Terminal führt WP-CLI-Befehle auf der aktiven Seite aus

Playground ist eine Wegwerf-Instanz von WordPress, die Sie jemandem per URL übergeben. Das ist das ganze Produkt, und das reicht, um nützlich zu sein.

#Wie WordPress Playground funktioniert

Die Architektur-Dokumentation beschreibt den Startablauf. Die Seite auf playground.wordpress.net lädt remote.html in einem iframe. Diese Datei startet einen Worker Thread und einen Service Worker. Der Worker Thread startet PHP und füllt ein virtuelles Dateisystem mit einem WordPress, das für SQLite gepatcht ist. Der Service Worker fängt danach jede HTTP-Anfrage aus dem WordPress-iframe ab und leitet sie an den Worker Thread weiter, der die Antwort rendert.

#Wie WebAssembly PHP im Browser ausführt

Das Team kompiliert den PHP-Interpreter mit Emscripten nach WebAssembly. Laut der Übersicht zu WebAssembly PHP braucht der Build nur wenige Patches; die größere Arbeit war ein PHP-API-Modul in C plus eine JavaScript-Klasse, die Request-Bodys, Uploads und php://stdin an PHP übergibt. Jede PHP-Version ist eine eigene statische .wasm-Datei, ein Versionswechsel bedeutet also, dass der Browser eine andere Binärdatei lädt.

Der Browser-Tab steuert alles. Schließen oder Neuladen zerstört die Ausführungsumgebung, deshalb sind die Speichermodi (siehe unten) so wichtig.

#Wie Playground MySQL durch SQLite ersetzt

Es gibt keinen WebAssembly-Build von MySQL, der im Browser läuft. Playground liefert PHP mit dem nativen SQLite-Treiber aus, und das Plugin SQLite Database Integration fängt MySQL-Abfragen ab und schreibt sie in den SQLite-Dialekt um. Laut Dokumentation besteht WordPress auf SQLite mit Version 2.0 99% der WordPress-Unit-Tests. In der verbleibenden Lücke bricht meist eigenes Plugin-SQL.

#Wie Netzwerkzugriffe in Playground funktionieren

WebAssembly-Code kann nur JavaScript-APIs aufrufen, PHP kann also keine Sockets direkt öffnen. Im Browser bietet Playground zwei Transportwege: einen schnellen, der wp_safe_remote_get-Aufrufe in fetch()-Anfragen umwandelt, und einen langsameren, der den von PHP gestarteten TLS-Verkehr parst und in fetch() übersetzt. Weil jede Anfrage als Browser-fetch() endet, muss der Zielserver Cross-Origin-Anfragen erlauben. Die Query-API-Dokumentation verlangt den Header Access-Control-Allow-Origin für jede Datei, die Playground von einer URL importiert.

#Wie benutzt man WordPress Playground

Es gibt vier Einstiegspunkte, von ganz ohne Code bis zur vollen programmatischen Kontrolle.

#Methode 1: Nutzung der offiziellen Playground-Website

Öffnen Sie playground.wordpress.net. Ein frisches WordPress lädt, und die Werkzeuge liegen im Dock am unteren Bildschirmrand. Der Leitfaden zur Web-Instanz nennt seine Bereiche:

1. New: Start aus der Blueprint-Galerie, über eine öffentliche Blueprint-URL, einen neuen Blueprint, eine Pull-Request-Vorschau, ein GitHub-Repository oder eine importierte .zip
2. Playgrounds: Wechsel zwischen aktuellen und gespeicherten Playgrounds
3. Site Settings: WordPress-Version, PHP-Version, Sprache, Netzwerk und Multisite
4. Blueprint, Database, Files, Logs: aktuellen Blueprint ansehen und bearbeiten, SQLite-Datenbank herunterladen, Dateien durchsuchen, PHP-Fehler lesen
5. Export: .zip herunterladen, Link zur ursprünglichen Konfiguration kopieren oder ausgewählte Dateien in einen GitHub-Pull-Request exportieren

PHP-Version und Netzwerk lassen sich in einem bestehenden, gespeicherten Playground ändern. WordPress-Version, Sprache und Multisite ändern die Installation selbst und starten deshalb einen neuen Playground. Für Block-Themes öffnet landingPage: /wp-admin/site-editor.php im Blueprint direkt den Website-Editor.

#Methode 2: Einbetten von Playground in Ihre Website

Jede Option der Query API ist ein URL-Parameter, für eine eingebettete Demo reicht also ein iframe:

<iframe
  src="https://playground.wordpress.net/?plugin=gutenberg&url=/wp-admin/post-new.php&mode=seamless"
  width="100%"
  height="800px"
  frameborder="0"
  allow="clipboard-write"
></iframe>

Die Parameter, die Sie am häufigsten brauchen, laut Query-API-Referenz:

Die Installation eines Plugins oder Themes per URL meldet den Besucher als Administrator an. Der Parameter lazy verschiebt das Laden bis zum Klick auf die Startschaltfläche, eine Seite mit Einbettung bleibt so leicht, bis der Besucher die Demo tatsächlich will.

#Methode 3: Verwendung der Playground-API für erweiterte Integration

Der JavaScript-Client aus dem npm-Paket @wp-playground/client gibt Ihnen volle Kontrolle aus Ihrer eigenen Seite, aus Tests oder aus CI/CD-Pipelines:

import { startPlaygroundWeb } from '@wp-playground/client';

async function initializePlayground() {
  const client = await startPlaygroundWeb({
    iframe: document.getElementById('wp-playground'),
    remoteUrl: 'https://playground.wordpress.net/remote.html',
    blueprint: {
      landingPage: '/wp-admin/',
      preferredVersions: {
        php: '8.3',
        wp: 'latest'
      },
      steps: [
        {
          step: 'installPlugin',
          pluginData: {
            resource: 'wordpress.org/plugins',
            slug: 'gutenberg'
          }
        },
        {
          step: 'installTheme',
          themeData: {
            resource: 'wordpress.org/themes',
            slug: 'twentytwentyfive'
          }
        }
      ]
    }
  });

  return client;
}

#Methode 4: Blueprint-Konfiguration für reproduzierbare Umgebungen

Blueprints sind JSON-Dateien, die eine Playground-Instanz einrichten. Die Einstiegsseite zu Blueprints nennt drei Wege: in das URL-Fragment einfügen, an die JavaScript-API übergeben oder per blueprint-url auf eine Datei verweisen. Blueprints können kein beliebiges JavaScript ausführen, deshalb verlangt das Ausführen eines fremden Blueprints kein Vertrauen in den Autor.

{
  "$schema": "https://playground.wordpress.net/blueprint-schema.json",
  "landingPage": "/wp-admin/plugins.php",
  "preferredVersions": {
    "php": "8.2",
    "wp": "6.8"
  },
  "features": {
    "networking": true
  },
  "steps": [
    {
      "step": "login",
      "username": "admin",
      "password": "password"
    },
    {
      "step": "installPlugin",
      "pluginData": {
        "resource": "wordpress.org/plugins",
        "slug": "query-monitor"
      },
      "options": {
        "activate": true
      }
    },
    {
      "step": "setSiteOptions",
      "options": {
        "blogname": "Meine Testseite",
        "blogdescription": "WordPress Playground im Test"
      }
    }
  ]
}

Die Zeile $schema liefert Autovervollständigung und Validierung im Editor. Laut Dokumentation zum Datenformat akzeptiert preferredVersions.wp die letzten sieben Hauptversionen (6.3 bis 6.9, Stand April 2026) sowie latest, beta und nightly, und features.networking muss eingeschaltet bleiben, wenn Besucher Plugins oder Themes installieren sollen.

#Wie man WordPress Playground lokal mit der CLI startet

Dieselbe Laufzeit funktioniert in Node.js. Die Playground CLI (@wp-playground/cli) braucht Node.js 20.18 oder neuer und ersetzt das veraltete Paket wp-now.

cd my-plugin
npx @wp-playground/cli@latest start

start erkennt, ob der Ordner ein Plugin, ein Theme oder eine vollständige WordPress-Installation ist, bindet ihn ein, meldet Sie an und öffnet den Browser. Die Seite bleibt zwischen Sitzungen in ~/.wordpress-playground/sites/<path-hash>/ erhalten, und --reset liefert eine saubere Installation. server ist der fortgeschrittene Befehl mit manueller Kontrolle über Mounts und Speicher, gedacht für eigene Setups und CI. Beide akzeptieren --wp=, --php= und --blueprint=; die CLI nutzt standardmäßig PHP 8.3.

Die CLI hat außerdem einen Unterbefehl php. Der PHPUnit-Leitfaden führt die Testsuite eines Plugins bei jedem Lauf gegen ein sauberes WordPress aus, ohne lokale Datenbank:

npx @wp-playground/cli@latest php \
  --auto-mount --php=8.1 --wp=6.5 \
  -- \
  /wordpress/wp-content/plugins/MY_PLUGIN/vendor/bin/phpunit \
  -c /wordpress/wp-content/plugins/MY_PLUGIN/phpunit.xml.dist

Damit wird eine Versionsmatrix aus PHP und WordPress zu einer Schleife über zwei Flags statt zu einem Satz Docker-Images.

#Wofür eignet sich WordPress Playground

Fünf Abläufe, in denen Playground etwas ersetzt, das früher den langsamen Weg ging.

#Wie man einen Link “Plugin ausprobieren” auf eine Verkaufsseite setzt

Statt “ZIP herunterladen und auf einer Staging-Seite installieren” öffnet Ihr Button eine Blueprint-URL mit vorinstalliertem Plugin und vorbereiteten Demo-Inhalten. Der Besucher landet bereits angemeldet auf dem richtigen Admin-Bildschirm. Das Muster funktioniert, weil der Einrichtungsschritt für den Besucher entfällt.

Das URL-Muster: https://playground.wordpress.net/?blueprint-url=https://example.com/blueprint.json. Hosten Sie die Blueprint-JSON überall, wo der Server den CORS-Header sendet. In WordPress-Beiträgen bettet der offizielle WordPress-Playground-Block dieselbe Art von Demo ein, auf Wunsch mit Live-Code-Editor.

#Wie man Plugin-Pull-Requests in Playground testet

Der Leitfaden zu PR-Vorschauen nutzt die Action WordPress/action-wp-playground-pr-preview@v3. Mit plugin-path: . (oder theme-path: .) fügt sie der Pull-Request-Beschreibung eine Preview-Schaltfläche hinzu. Ein Klick öffnet Playground mit dem Plugin oder Theme, installiert und aktiviert aus dem PR-Branch.

Die Dokumentation nennt zwei Bedingungen. Alles, was Playground installiert, muss unter einer öffentlichen URL liegen, ein privates Repository braucht also mehr als die Standardkonfiguration. Und wenn das Plugin Composer oder einen npm-Build braucht, nutzt die Action zwei Workflows: einen Build-Workflow mit reinen Leserechten und einen Publish-Workflow, der das ZIP in ein öffentliches ci-artifacts-Prerelease hochlädt. Der Leitfaden warnt davor, auf pull_request_target umzustellen, um PR-Code mit Schreibrechten auszuführen.

#WordPress Playground in Schulungen und Kursen

Jeder Teilnehmer bekommt eine isolierte WordPress-Instanz aus demselben Blueprint. Am ersten Tag gibt es keine Nachrichten wie “mein XAMPP startet nicht”. Die Seite zu den Einschränkungen nennt Chrome, Firefox, Safari und Edge auf dem Desktop sowie Safari und Chrome auf Mobilgeräten als unterstützt, das deckt Chromebooks und gesperrte Firmenlaptops ab, auf denen Docker blockiert ist. Der Haken: Browserspeicher ist kein Backup, alles, was Teilnehmer behalten wollen, braucht am Ende der Sitzung den ZIP-Export.

#Wie man einen Kundenfehler mit einem Blueprint reproduziert

Ein Kunde meldet einen Fehler mit einer bestimmten WordPress-Version, einem Plugin-Set und einem Theme. Sie schicken ihm eine Blueprint-URL mit genau diesem Stack. Er bestätigt die Reproduktion in seinem Browser. Sie debuggen lokal mit der CLI gegen denselben Blueprint. Das Ticket enthält jetzt einen deterministischen Reproduktionsfall statt “bei mir läuft es”.

#Wie man alte WordPress-Versionen in Playground testet

Seit August 2026 hat das Panel Site Settings die Option Include older versions. Die Ankündigung auf make.wordpress.org beschreibt PHP 5.2.17, kompiliert nach WebAssembly, und Browser-Start für WordPress 0.7 bis 6.2. Playground wählt die Laufzeit automatisch: WordPress 0.7 bis 4.9 läuft fest auf PHP 5.2, 5.0 bis 6.2 auf PHP 7.4, und 6.3 oder neuer nutzt den modernen Ablauf. Für Plugin-Autoren wird ein alter Kompatibilitätsbericht damit zu einer Browsereinstellung statt zu einem veralteten Server-Stack.

#Wann man WordPress Playground nicht einsetzen sollte

• Für alles, was echte Mails zustellen oder nach echtem Cron-Zeitplan laufen muss
• Für Lasttests, denn PHP.wasm läuft in einem Web Worker innerhalb des Browser-Tabs
• Für Plugins, die exec() aufrufen, auf absolute Pfade schreiben oder PHP-Erweiterungen brauchen, die Playground nicht mitliefert
• Für Aufrufe externer APIs mit Server-zu-Server-Authentifizierung, denn es gelten die CORS-Regeln des Browsers, und die meisten APIs erlauben playground.wordpress.net nicht als Origin

#Was sind Grenzen und Performance von WordPress Playground

Die Seite zu den Einschränkungen ist kurz und lohnt sich, bevor Sie Playground vor Kunden stellen.

#Wie viel Browser-Speicher WordPress Playground nutzen kann

Playground veröffentlicht kein festes Kontingent. Der Speicher gehört dem Browser, und die Dokumentation warnt, dass Speicherknappheit, privates Surfen, Profilwechsel oder das Löschen von Websitedaten gespeicherte Playgrounds entfernen können. Medienlastige Demos laden schneller und halten länger, wenn große Dateien über einen Blueprint-Schritt von einer URL kommen, statt in der Sitzung hochgeladen zu werden.

#Wie lange WordPress Playground zum Laden braucht

Die offiziellen Werte:

Plugin-Größe, Netzwerkgeschwindigkeit (die WASM-Dateien sind 15 bis 30 MB groß), Gerätespeicher und Browser spielen mit. Die Dokumentation nennt Chrome und Edge als die schnellsten, Safari als etwas langsamer.

#Ist WordPress Playground langsamer als ein echter Server

Ja, bei CPU-lastiger Arbeit. Die Architektur-Dokumentation beschreibt den PHP-Server als so langsam, dass er in einem Web Worker laufen muss, sonst würde jede Anfrage die Seite einfrieren. Bildverarbeitung, Massenimporte und große Abfragen dauern deutlich länger als auf einem nativen PHP-Host, messen Sie Plugin-Performance also nicht in Playground.

#Welche iframe-Eigenheiten Playground-Demos betreffen

WordPress rendert in einem iframe. Links mit target="_top" laden die ganze Seite neu, an der Sie arbeiten, und JavaScript-Popups aus dem iframe erscheinen möglicherweise nicht. Wenn Ihr Plugin OAuth-Fenster öffnet oder window.top nutzt, testen Sie den Demo-Ablauf von Hand.

#Ist WordPress Playground sicher für echte Daten

Die offizielle Dokumentation beschreibt Playground als vollständig clientseitig, ohne Backend und ohne Authentifizierung. Die Seite, die Sie bauen, bleibt in Ihrem Browser, das Risiko liegt also auf dem Gerät.

#Speichert WordPress Playground Ihre Daten

Die Dokumentation definiert drei Speichermodi:

• Autosaved: im Browserspeicher, nur solange es zu den fünf neuesten Autosaves gehört
• Saved: dauerhaft im Browserspeicher oder in einem lokalen Ordner in Browsern mit File System Access API
• Temporary: erstellt mit ?storage=temp oder wenn Speichern nicht verfügbar ist, verworfen beim Neuladen oder Schließen des Tabs

Folgen für die Sicherheit:

• Geteilte Computer: Autosaves und gespeicherte Playgrounds bleiben im Browserprofil für den nächsten Nutzer
• Sensible Daten: geben Sie keine echten Zugangsdaten und keine personenbezogenen Kundendaten ein
• Browser-Bereinigung: das Löschen von Websitedaten entfernt gespeicherte Playgrounds
• Export: der Download als .zip exportiert Dateien, Datenbank, Plugins, Themes und Uploads, und New, Import zip stellt ihn wieder her

#Kann WordPress Playground externe APIs aufrufen

Netzwerk ist standardmäßig an (networking=yes in der Query API, features.networking: true in Blueprints). Ist es aus, schlagen wp_safe_remote_get und ähnliche Funktionen sofort fehl. Ist es an, laufen Anfragen über den Browser, und CORS entscheidet, was funktioniert. Nutzen Sie in einer öffentlichen Demo Test-Zugangsdaten für externe Dienste, denn der API-Schlüssel liegt in einem Browser, den jeder inspizieren kann.

#Was sich 2026 in WordPress Playground geändert hat

Das Team veröffentlicht Neuerungen auf make.wordpress.org/playground. Vier Änderungen aus 2026 betreffen die oben beschriebenen Abläufe:

• Neue Oberfläche (Juli 2026): das Dock ersetzte die früheren Seitenleisten und Modals. Es entstand am Playground-Tisch des Contributor Day auf dem WordCamp Europe 2026 in Krakau
• Alte Versionen (August 2026): WordPress 0.7 bis 6.2 startet im Browser mit automatischer PHP-Zuordnung
• Terminal (September 2026): Dev Tools, Terminal führt PHP-Snippets mit geladenem WordPress und WP-CLI-Befehle auf der aktiven Seite aus; WP-CLI wird bei der ersten Nutzung geladen
• Email-Werkzeug (September 2026): über wp_mail() gesendete Nachrichten werden abgefangen und mit Betreff, Absender, Empfänger und Text angezeigt. Eine abgefangene Mail ist keine zugestellte Mail, und Plugins, die über eine eigene SMTP-Verbindung oder die API eines Anbieters senden, umgehen das Abfangen

Die Dokumentation behandelt auch KI-Coding-Agenten: einen Agent-Skill wp-playground und eine WebMCP-Brücke. Diese Seite beschreiben wir in WordPress Playground und MCP für KI-Agenten.

#Häufige Blueprint-Fehler in WordPress Playground

Ein paar Fallen, die zuschnappen, sobald echte Nutzer Playground sehen.

PHP-Versionsdrift. Ihr Produktionshost läuft mit PHP 8.1. Die Query API nutzt standardmäßig PHP 8.5. Eine Demo läuft durch; der Kunde installiert Ihr Plugin auf seiner Seite und trifft auf einen fatalen Fehler in einer Funktion, die Ihre Demo auf 8.1 nie durchlaufen hat. Pinnen Sie preferredVersions.php auf Ihre minimal unterstützte Version, nicht auf die neueste.

Temporärer Speicher in Einbettungen. Eine Einbettung mit storage=temp oder can-save=no verliert beim Neuladen alles. Für eine Wegwerf-Demo ist das richtig, für eine Schulungsübung falsch. Wenn die Demo Dateien braucht, legen Sie sie bei jedem Lauf mit einem writeFile-Schritt an.

CORS bei Importen und APIs. blueprint-url, ZIP-Dateien für import-site und Manifeste von PHP-Erweiterungen brauchen alle den Header Access-Control-Allow-Origin auf dem Server, der sie hostet. Ein Blueprint, der mit Raw-URLs von GitHub funktioniert, kann von Ihrem eigenen CDN scheitern, bis Sie den Header ergänzen.

Reihenfolge der Schritte. Kurzformen wie plugins, login, siteOptions und constants werden vor dem Array steps aufgelöst. Muss eine Aktion vor einer anderen passieren, schreiben Sie beide als explizite Schritte in der nötigen Reihenfolge.

Gemischte Plugin-Formate. Der aktuelle Schritt installPlugin nutzt pluginData, und activate gehört in options. Ältere Beispiele nutzen das veraltete pluginZipFile, und die Dokumentation rät davon ab, beides zu mischen. Ein in die Ressource geschriebener Slug (wordpress.org/plugins/woocommerce) ist ebenfalls falsch: die Ressource braucht ein separates Feld slug.

SQLite- gegen MySQL-Syntax. Die Übersetzungsschicht deckt fast den ganzen Core ab, eigenes SQL im Plugin liegt aber in Ihrer Verantwortung. Testen Sie den Blueprint mit dem vollständigen Plugin und seinen echten Datenpfaden, nicht nur mit dem Core.

#JSON-LD Schema-Beispiel für WordPress Playground

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "WordPress Playground: Die Zukunft von Tests und Demos",
  "description": "Erfahren Sie, wie Sie WordPress Playground nutzen, um WP via WebAssembly im Browser auszuführen. Der komplette Guide für 2026.",
  "author": {
    "@type": "Organization",
    "name": "WPPoland"
  },
  "datePublished": "2026-01-29",
  "dateModified": "2026-10-14",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://wppoland.com/de/wordpress-playground-guide-2026/"
  }
}

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "So nutzen Sie WordPress Playground für Tests und Entwicklung",
  "description": "Schritt-für-Schritt-Anleitung, um WordPress mit WebAssembly im Browser auszuführen",
  "totalTime": "PT15M",
  "supply": [
    "Moderner Webbrowser",
    "Internetverbindung"
  ],
  "tool": [
    {
      "@type": "HowToTool",
      "name": "Webbrowser"
    }
  ],
  "step": [
    {
      "@type": "HowToStep",
      "position": 1,
      "name": "WordPress Playground öffnen",
      "text": "Rufen Sie playground.wordpress.net auf, um die offizielle Instanz von WordPress Playground zu öffnen.",
      "url": "https://playground.wordpress.net"
    },
    {
      "@type": "HowToStep",
      "position": 2,
      "name": "Umgebung konfigurieren",
      "text": "Öffnen Sie Site Settings im Dock und wählen Sie WordPress-Version, PHP-Version, Sprache und Netzwerk."
    },
    {
      "@type": "HowToStep",
      "position": 3,
      "name": "Auf die Instanz warten",
      "text": "Ein frisches WordPress ohne Plugins lädt in der Regel in 5 bis 10 Sekunden; große Plugins wie WooCommerce brauchen 30 bis 60 Sekunden."
    },
    {
      "@type": "HowToStep",
      "position": 4,
      "name": "Mit dem Testen beginnen",
      "text": "Öffnen Sie das WordPress-Dashboard, installieren Sie Plugins, erstellen Sie Inhalte und testen Sie Funktionen in der isolierten Umgebung."
    },
    {
      "@type": "HowToStep",
      "position": 5,
      "name": "Arbeit speichern oder exportieren",
      "text": "Nutzen Sie Export, um die Seite als ZIP herunterzuladen, oder Store permanently, um sie im Browserspeicher zu behalten."
    }
  ]
}

Ein Playground-Blueprint ist der schnellste Weg, einem Kunden ein Plugin zu zeigen, ohne nach Server, Datenbank oder Zugangsdaten zu fragen. Solche Demos bauen wir im Rahmen der WordPress-Plugin-Entwicklung.