{"id":20879,"date":"2026-10-27T15:09:00","date_gmt":"2026-10-27T14:09:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=20879"},"modified":"2026-10-25T22:34:29","modified_gmt":"2026-10-25T21:34:29","slug":"wordpress-playground-blueprints-fur-plugin-vorschau-und-tests","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/wordpress-plugins-tricks-de\/tutorials-de-wordpress-plugins-tricks-de\/wordpress-playground-blueprints-fur-plugin-vorschau-und-tests\/","title":{"rendered":"WordPress Playground: Blueprints f\u00fcr Plugin-Vorschau und Tests"},"content":{"rendered":"
Die Schaltfl\u00e4che \u201ePreview\u201c auf einer WordPress.org-Pluginseite \u00f6ffnet eine vor\u00fcbergehende Testwebsite im Browser. PHP und Datenbank laufen dort mithilfe von WebAssembly. Eine Datei namens Blueprint beschreibt die Einrichtung: etwa die PHP-Version, ben\u00f6tigte Plugins und Demowerte. Dieselbe Datei l\u00e4sst sich f\u00fcr die Verzeichnis-Vorschau, lokale Playground-L\u00e4ufe und den Playground-Teil automatischer Tests verwenden.<\/p>\n
Das Beispiel erg\u00e4nzt Contact Form 7 um ein kleines Demonstrationsplugin. Eine zweite Teststrecke l\u00e4uft mit Docker und wp-env<\/code>. Diese Strecke verwendet eine eigene .wp-env.json<\/code> und f\u00fchrt den Blueprint nicht aus. Der Unterschied ist sichtbar: Der Blueprint setzt eine Option auf 14, die reine Aktivierung ohne Blueprint auf 30. Der Beitrag zeigt diese zwei Wege und benennt genau, was die Tests pr\u00fcfen. Die urspr\u00fcnglichen Laufzeitbelege stammen vom 29.09.2026; Schema, Quellen und isolierte Pr\u00fcfungen wurden am 25.10.2026 erneut abgeglichen.<\/p>\n
Playground, Blueprints und die wichtigen Schritte<\/h2>\n
Im Browser ben\u00f6tigt Playground keinen eigenen PHP-Webserver. PHP l\u00e4uft als WebAssembly, die Datenbank verwendet SQLite. Die Kommandozeilenfassung nutzt diese Laufzeit unter Node.js. Der hier verwendete Blueprint im Format V1 ist eine JSON-Datei: landingPage<\/code> bestimmt die erste ge\u00f6ffnete Seite, preferredVersions<\/code> enth\u00e4lt php<\/code> und wp<\/code>, und steps<\/code> nennt die Einrichtungsschritte in Reihenfolge. features.networking<\/code> wird im Beispiel ausdr\u00fccklich aktiviert. $schema<\/code> verweist auf die Regeln, gegen die ein Editor die Datei pr\u00fcfen kann.<\/p>\n
Die unterst\u00fctzten Versionen h\u00e4ngen vom jeweiligen Playground-Stand ab. Das aktuelle Schema akzeptiert unter anderem PHP 7.4 und 8.0 bis 8.5 sowie latest<\/code> und next<\/code>; zus\u00e4tzlich existieren besondere Legacy-Eintr\u00e4ge. F\u00fcr den Beispielablauf sind konkrete Kombinationen wichtiger als eine dauerhafte Vollst\u00e4ndigkeitsliste. Die Testmatrix nennt deshalb WordPress 6.7.9, 7.0.6 und 7.1.2. Das sind festgelegte Pr\u00fcfst\u00e4nde, keine Aussage \u00fcber die heute neueste Version.<\/p>\n
F\u00fcr die Einrichtung des Beispiels werden drei Schritte ben\u00f6tigt:<\/p>\n
\n
installPlugin<\/code> erwartet eine Ressource in pluginData<\/code>, etwa {\"resource\": \"wordpress.org\/plugins\", \"slug\": \"contact-form-7\"}<\/code>, eine url<\/code> auf eine ZIP-Datei oder einen Verweis vom Typ git:directory<\/code>. Die Aktivierung steuert options.activate<\/code>; der Schl\u00fcssel geh\u00f6rt in options<\/code>, nicht in pluginData<\/code>. Ohne diese Angabe gilt im Quellcode true.<\/li>\n
login<\/code> braucht nur username<\/code>, Standard ist admin<\/code>. Das Feld password<\/code> ist im Schema als veraltet markiert.<\/li>\n
setSiteOptions<\/code> speichert die Werte aus options<\/code> als WordPress-Optionen. Das Beispiel setzt damit den Website-Titel und den Demowert 14.<\/li>\n<\/ul>\n
Weitere Schritte k\u00f6nnen PHP-Code ausf\u00fchren, Sprachpakete installieren oder Einstellungen in wp-config.php<\/code> setzen. Alte Beispiele enthalten noch pluginZipFile<\/code> und phpExtensionBundles<\/code>; das aktuelle Schema markiert diese Angaben als veraltet beziehungsweise nicht mehr verwendet. Bei Abh\u00e4ngigkeiten steht die Reihenfolge ausdr\u00fccklich in steps<\/code>. Ein \u00f6ffentlich erreichbarer Blueprint l\u00e4sst sich \u00fcber ?blueprint-url=<\/code> \u00f6ffnen; auch ein JSON-Fragment nach https:\/\/playground.wordpress.net\/#<\/code> ist m\u00f6glich. Das Diagramm trennt den gemeinsamen Playground-Blueprint von der eigenen Docker-Konfiguration.<\/p>\n\n\nDer Blueprint versorgt Vorschau, lokale Playground-L\u00e4ufe und Playground-CI. Docker verwendet separat .wp-env.json und im Beispiel den Standardwert 30 statt des Demo-Werts 14.<\/figcaption>\n<\/figure>\n
Der Blueprint f\u00fcr die Vorschau im Verzeichnis<\/h2>\n
F\u00fcr eine \u00f6ffentliche Vorschau braucht das Plugin eine g\u00fcltige Datei unter assets\/blueprints\/blueprint.json<\/code> im SVN-Verzeichnis. Zus\u00e4tzlich muss ein Committer, also ein Konto mit Schreibrecht f\u00fcr dieses Plugin, die Vorschau unter \u201eAdvanced\u201c auf \u201epublic\u201c stellen. Davor ist \u201eTest Preview\u201c nur f\u00fcr diese Konten sichtbar. Ein automatisch erzeugter Test-Blueprint kann als Ausgangspunkt dienen.<\/p>\n
Der gepr\u00fcfte Importcode \u00fcbernimmt passende Blueprint-Dateien aus diesem Ordner bis zu 102.400 Byte je Datei und beh\u00e4lt h\u00f6chstens zehn. F\u00fcr die normale Vorschau wird blueprint.json<\/code> verwendet. Ung\u00fcltiges JSON wird verworfen. Beim Beispielplugin erg\u00e4nzt der Import die Installation des eigenen Slugs am Ende, falls kein passender Schritt vorhanden ist, und erzwingt die Aktivierung. Passende ZIP-Adressen von downloads.wordpress.org<\/code> werden in Slug-Ressourcen umgeschrieben. Eine im Dateinamen enthaltene Versionsbindung kann dabei verloren gehen. Der Import ist somit keine unver\u00e4nderte Weitergabe der Datei.<\/p>\n
Der Blueprint installiert deshalb Contact Form 7 und setzt Demowerte, enth\u00e4lt aber keinen Download des eigenen Add-ons. Das Verzeichnis erg\u00e4nzt diesen Download. Die lokale Playground-CLI bindet stattdessen den Arbeitsordner ein und aktiviert das Add-on nach den Blueprint-Schritten. Ein eigener Downloadschritt k\u00f6nnte bei einem unver\u00f6ffentlichten Plugin scheitern oder mit der Standardoption overwrite<\/code> den eingebundenen Arbeitsordner ersetzen. Der Docker-Weg verwendet unabh\u00e4ngig davon seine Pluginliste.<\/p>\n
Im Git-Projekt liegt die Datei hier unter .wordpress-org\/blueprints\/blueprint.json<\/code>. Dieser Ordnername ist eine Konvention des Beispiels. Erst der Releaseablauf kopiert die Datei nach assets\/blueprints\/<\/code> in SVN. Ein Punkt am Ordneranfang schlie\u00dft Dateien nicht automatisch aus einer Plugin-ZIP aus; das Packskript muss den Ausschluss tats\u00e4chlich vornehmen.<\/p>\nJSON<\/span>
![\"Der](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/playground-reviewed-20879-de-20261025.png\")
\n