WordPress Playground: przyszłość testowania i demonstracji

WordPress Playground to pełna instalacja WordPressa działająca w przeglądarce. PHP jest skompilowane do WebAssembly (PHP.wasm), baza danych to SQLite, a oficjalna strona ograniczeń podaje, że pliki WASM ważą od 15 do 30 MB. Nie ma serwera, nie ma wp-config.php do uzupełniania, nie ma MAMP-a ani Dockera. Otwierasz adres URL i jesteś w wp-admin.

Jeśli wydajesz wtyczki albo motywy, prowadzisz szkolenia lub przeglądasz pull requesty, Playground zmienia kilka codziennych procesów. Jeśli utrzymujesz strony produkcyjne, ich nie zastąpi. Traktuj Playground jak piaskownicę i narzędzie do dem, a nie hosting.

Więcej o profesjonalnym programowaniu WordPressa w WPPoland.

#Czym jest WordPress Playground

Playground to otwartoźródłowy projekt WordPressa na licencji GPLv2 lub nowszej. Instancja webowa działa pod adresem playground.wordpress.net, a dokumentacja pod developer.wordpress.org/playground. Elementy, które liczą się w codziennej pracy:

• PHP.wasm uruchamia PHP od 7.4 do 8.5 w Web Workerze. Query API domyślnie wybiera PHP 8.5; inną wersję ustawiasz na sesję przez ?php= albo w Blueprincie
• SQLite zastępuje MySQL dzięki oficjalnej wtyczce SQLite Database Integration. Większość wtyczek korzystających z $wpdb działa; kod z ręcznie pisanym SQL-em pod MySQL może się wyłożyć
• Pamięć przeglądarki przechowuje nowe Playgroundy jako autozapisy, gdy zapis jest dostępny. Playground trzyma do pięciu ostatnich autozapisów, a tymczasowy Playground znika po odświeżeniu
• Poczta i WP-CLI działają w wersji piaskownicowej. Wiadomości z wp_mail() lądują w narzędziu Email zamiast w skrzynce, a Terminal uruchamia polecenia WP-CLI na aktywnej stronie

Playground to jednorazowa instancja WordPressa, którą możesz komuś przekazać jednym linkiem. To cały produkt i to wystarcza, żeby był przydatny.

#Jak działa WordPress Playground

Dokumentacja architektury opisuje sekwencję startu. Strona na playground.wordpress.net ładuje remote.html w ramce iframe. Ten plik uruchamia Worker Thread i Service Workera. Worker Thread startuje PHP i wypełnia wirtualny system plików WordPressem załatanym do pracy na SQLite. Service Worker przechwytuje potem każde żądanie HTTP z ramki WordPressa i przekazuje je do Worker Threada, który renderuje odpowiedź.

#Jak WebAssembly uruchamia PHP w przeglądarce

Zespół kompiluje interpreter PHP do WebAssembly za pomocą Emscriptena. Według przeglądu WebAssembly PHP sama kompilacja wymaga tylko kilku poprawek; większą pracą był moduł API PHP w C oraz klasa JavaScript, która przekazuje do PHP treść żądań, uploady i php://stdin. Każda wersja PHP to osobny statyczny plik .wasm, więc zmiana wersji oznacza, że przeglądarka pobiera inny plik binarny.

Karta przeglądarki steruje wszystkim. Zamknięcie lub przeładowanie jej niszczy środowisko wykonawcze, dlatego tryby zapisu (opisane niżej) mają tak duże znaczenie.

#Jak Playground zastępuje MySQL bazą SQLite

Nie istnieje kompilacja MySQL do WebAssembly, która działałaby w przeglądarce. Playground dostarcza PHP z natywnym sterownikiem SQLite, a wtyczka SQLite Database Integration przechwytuje zapytania MySQL i przepisuje je na dialekt SQLite. Dokumentacja podaje, że wydanie 2.0 pozwala WordPressowi na SQLite przejść 99% testów jednostkowych WordPressa. W pozostałej luce najczęściej psuje się własny SQL wtyczek.

#Jak działa sieć w Playgroundzie

Kod WebAssembly może wywoływać wyłącznie API JavaScriptu, więc PHP nie otworzy gniazda bezpośrednio. W przeglądarce Playground ma dwa transporty: szybki, który zamienia wywołania wp_safe_remote_get na żądania fetch(), oraz wolniejszy, który parsuje ruch TLS rozpoczęty przez PHP i tłumaczy go na fetch(). Ponieważ każde żądanie kończy jako fetch() przeglądarki, serwer docelowy musi zezwalać na żądania cross-origin. Dokumentacja Query API wymaga nagłówka Access-Control-Allow-Origin dla każdego pliku importowanego przez Playground z adresu URL.

#Jak uruchomić WordPress Playground

Są cztery punkty wejścia, od zera kodu do pełnej kontroli programistycznej.

#Metoda 1: oficjalna strona Playground

Otwórz playground.wordpress.net. Ładuje się świeży WordPress, a narzędzia siedzą w Docku na dole ekranu. Przewodnik po instancji webowej wymienia jego sekcje:

1. New: start z galerii Blueprintów, publicznego adresu Blueprintu, nowego Blueprintu, podglądu pull requesta, repozytorium GitHub albo zaimportowanego pliku .zip
2. Playgrounds: przełączanie między ostatnimi i zapisanymi Playgroundami
3. Site Settings: wersja WordPressa, wersja PHP, język, sieć i multisite
4. Blueprint, Database, Files, Logs: podgląd i edycja bieżącego Blueprintu, pobranie bazy SQLite, przeglądanie plików i odczyt błędów PHP
5. Export: pobranie pliku .zip, skopiowanie linku do pierwotnej konfiguracji albo eksport wybranych plików do pull requesta na GitHubie

Wersję PHP i sieć można zmienić w istniejącym, zapisanym Playgroundzie. Wersja WordPressa, język i multisite zmieniają samą instalację, więc uruchamiają nowy Playground. Przy motywach blokowych ustawienie landingPage: /wp-admin/site-editor.php w Blueprincie od razu otwiera Edytor witryny.

#Metoda 2: osadzanie Playground na własnej stronie

Każda opcja Query API to parametr w adresie URL, więc do osadzonego dema wystarczy 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>

Parametry, których użyjesz najczęściej, według dokumentacji Query API:

Instalacja wtyczki lub motywu przez URL loguje odwiedzającego jako administratora. Parametr lazy odkłada ładowanie do kliknięcia przycisku uruchomienia, więc strona z osadzonym demem pozostaje lekka, dopóki odwiedzający faktycznie nie zechce go użyć.

#Metoda 3: Playground API do zaawansowanej integracji

Klient JavaScript z pakietu npm @wp-playground/client daje pełną kontrolę z poziomu Twojej strony, testów albo pipeline’ów CI/CD:

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;
}

#Metoda 4: Blueprint do odtwarzalnych środowisk

Blueprinty to pliki JSON, które konfigurują instancję Playground. Strona startowa Blueprintów wymienia trzy sposoby użycia: wklejenie do fragmentu adresu URL, przekazanie do API JavaScript albo wskazanie pliku przez blueprint-url. Blueprinty nie mogą wykonywać dowolnego JavaScriptu, dlatego uruchomienie cudzego Blueprintu nie wymaga zaufania do autora.

{
  "$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": "Moja strona testowa",
        "blogdescription": "Test WordPress Playground"
      }
    }
  ]
}

Linia $schema daje podpowiedzi i walidację w edytorze. Według dokumentacji formatu danych pole preferredVersions.wp przyjmuje siedem ostatnich głównych wydań (od 6.3 do 6.9 według stanu z kwietnia 2026) oraz latest, beta i nightly, a features.networking musi zostać włączone, jeśli odwiedzający ma instalować wtyczki albo motywy.

#Jak uruchomić WordPress Playground lokalnie przez CLI

To samo środowisko działa w Node.js. Playground CLI (@wp-playground/cli) wymaga Node.js 20.18 lub nowszego i zastępuje wycofany pakiet wp-now.

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

start rozpoznaje, czy katalog to wtyczka, motyw czy pełna instalacja WordPressa, montuje go, loguje Cię i otwiera przeglądarkę. Strona przetrwa między sesjami w ~/.wordpress-playground/sites/<path-hash>/, a --reset daje czystą instalację. server to polecenie zaawansowane z ręczną kontrolą montowania i zapisu, przeznaczone do niestandardowych konfiguracji i CI. Oba przyjmują --wp=, --php= i --blueprint=; CLI domyślnie używa PHP 8.3.

CLI ma też podpolecenie php. Przewodnik po PHPUnit uruchamia zestaw testów wtyczki na czystym WordPressie przy każdym przebiegu, bez lokalnej bazy danych:

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

Dzięki temu macierz wersji PHP i WordPressa to pętla po dwóch flagach zamiast zestawu obrazów Dockera.

#Do czego używać WordPress Playground

Pięć procesów, w których Playground zastępuje coś, co wcześniej robiło się wolną drogą.

#Jak dodać link “wypróbuj wtyczkę” na stronie sprzedażowej

Zamiast “pobierz zip i zainstaluj na stagingu” przycisk otwiera adres Blueprintu z zainstalowaną wtyczką i przygotowaną treścią demo. Odwiedzający trafia na właściwy ekran panelu, już zalogowany. Ten wzorzec działa, bo znika krok konfiguracji po stronie odwiedzającego.

Wzorzec adresu Blueprintu: https://playground.wordpress.net/?blueprint-url=https://example.com/blueprint.json. Plik JSON hostuj gdziekolwiek, gdzie serwer wysyła nagłówek CORS. We wpisach WordPressa to samo demo osadzisz oficjalnym blokiem WordPress Playground, opcjonalnie z edytorem kodu na żywo.

#Jak testować pull requesty wtyczki w Playground

Przewodnik po podglądzie PR korzysta z akcji WordPress/action-wp-playground-pr-preview@v3. Z ustawieniem plugin-path: . (albo theme-path: .) dodaje przycisk Preview do opisu pull requesta. Kliknięcie otwiera Playground z wtyczką lub motywem zainstalowanym i włączonym z gałęzi PR.

Dokumentacja stawia dwa warunki. Wszystko, co Playground instaluje, musi leżeć pod publicznym adresem, więc prywatne repozytorium wymaga więcej niż domyślna konfiguracja. Jeśli wtyczka potrzebuje Composera albo builda npm, akcja używa dwóch workflowów: builda z uprawnieniami tylko do odczytu i publikacji, która wrzuca zip do publicznego prerelease’u ci-artifacts. Przewodnik ostrzega przed przełączaniem na pull_request_target, żeby uruchamiać kod z PR z uprawnieniami zapisu.

#WordPress Playground na kursach i szkoleniach

Każdy kursant dostaje odizolowaną instancję WordPressa z tego samego Blueprintu. Pierwszego dnia nie ma wiadomości “XAMPP mi nie startuje”. Strona ograniczeń wymienia jako wspierane desktopowe Chrome, Firefox, Safari i Edge oraz mobilne Safari i Chrome, co obejmuje Chromebooki i zablokowane laptopy firmowe, na których Docker jest niedostępny. Haczyk: pamięć przeglądarki to nie kopia zapasowa, więc to, co kursanci chcą zachować, wymaga eksportu do zip na koniec zajęć.

#Jak odtworzyć błąd klienta za pomocą Blueprintu

Klient zgłasza błąd na konkretnej wersji WordPressa, zestawie wtyczek i motywie. Wysyłasz mu adres Blueprintu z dokładnie tym stackiem. Klient potwierdza reprodukcję w swojej przeglądarce. Ty debugujesz na tym samym Blueprincie lokalnie przez CLI. Zgłoszenie zawiera teraz deterministyczny przypadek reprodukcji zamiast “u mnie działa”.

#Jak testować stare wersje WordPressa w Playgroundzie

Od sierpnia 2026 panel Site Settings ma opcję Include older versions. Ogłoszenie na make.wordpress.org opisuje PHP 5.2.17 skompilowane do WebAssembly i start w przeglądarce dla WordPressa od 0.7 do 6.2. Playground dobiera środowisko automatycznie: WordPress od 0.7 do 4.9 dostaje PHP 5.2, od 5.0 do 6.2 dostaje PHP 7.4, a 6.3 i nowsze korzystają ze współczesnej ścieżki. Dla autora wtyczki stare zgłoszenie zgodności staje się ustawieniem w przeglądarce zamiast przestarzałego stosu serwerowego.

#Kiedy nie używać WordPress Playground

• Do wszystkiego, co musi doręczać prawdziwą pocztę albo działać na prawdziwym harmonogramie crona
• Do testów obciążeniowych, bo PHP.wasm działa w Web Workerze wewnątrz karty przeglądarki
• Do wtyczek, które wywołują exec(), zapisują pod absolutnymi ścieżkami albo potrzebują rozszerzeń PHP, których Playground nie dostarcza
• Do wywołań zewnętrznych API wymagających autoryzacji serwer-serwer, bo obowiązują reguły CORS przeglądarki, a większość API nie akceptuje playground.wordpress.net jako źródła

#Jakie ograniczenia ma WordPress Playground

Strona ograniczeń jest krótka i warto ją przeczytać, zanim pokażesz Playground klientom.

#Ile danych zmieści WordPress Playground w przeglądarce

Playground nie publikuje stałego limitu. Pamięć należy do przeglądarki, a dokumentacja ostrzega, że brak miejsca, tryb prywatny, zmiana profilu albo wyczyszczenie danych witryny mogą usunąć zapisane Playgroundy. Dema z dużą ilością mediów ładują się szybciej i żyją dłużej, gdy duże pliki przychodzą z adresu URL przez krok Blueprintu, a nie są wgrywane w trakcie sesji.

#Ile trwa ładowanie WordPress Playground

Oficjalne wartości:

Znaczenie mają rozmiar wtyczek, szybkość łącza (pliki WASM ważą 15 do 30 MB), pamięć urządzenia i przeglądarka. Dokumentacja wskazuje Chrome i Edge jako najszybsze, a Safari jako nieco wolniejsze.

#Czy WordPress Playground jest wolniejszy od serwera

Tak, przy pracy obciążającej procesor. Dokumentacja architektury nazywa serwer PHP na tyle wolnym, że musi działać w Web Workerze, inaczej każde żądanie zamrażałoby stronę. Przetwarzanie obrazów, masowe importy i duże zapytania trwają wyraźnie dłużej niż na natywnym hostingu PHP, więc nie mierz w Playgroundzie wydajności wtyczek.

#Jakie problemy z iframe dotyczą dem w Playgroundzie

WordPress renderuje się w ramce iframe. Linki z target="_top" przeładowują całą stronę, na której pracujesz, a okienka JavaScript otwierane z ramki mogą się nie pojawić. Jeśli wtyczka otwiera okna OAuth albo korzysta z window.top, przejdź ścieżkę dema ręcznie.

#Czy WordPress Playground jest bezpieczny dla danych

Oficjalna dokumentacja opisuje Playground jako działający w całości po stronie klienta, bez backendu i bez uwierzytelniania. Strona, którą budujesz, zostaje w Twojej przeglądarce, więc ryzyko leży po stronie urządzenia.

#Czy WordPress Playground zapisuje dane

Dokumentacja definiuje trzy tryby zapisu:

• Autosaved: zapis w pamięci przeglądarki, trzymany tylko dopóki jest jednym z pięciu ostatnich autozapisów
• Saved: trwały zapis w pamięci przeglądarki albo w lokalnym katalogu w przeglądarkach obsługujących File System Access API
• Temporary: tworzony przez ?storage=temp albo gdy zapis jest niedostępny, znika po odświeżeniu lub zamknięciu karty

Konsekwencje dla bezpieczeństwa:

• Współdzielone komputery: autozapisane i zapisane Playgroundy zostają w tym profilu przeglądarki dla następnego użytkownika
• Dane wrażliwe: nie wpisuj prawdziwych haseł ani danych osobowych klientów
• Czyszczenie przeglądarki: usunięcie danych witryny kasuje zapisane Playgroundy
• Eksport: pobranie jako .zip eksportuje pliki, bazę, wtyczki, motywy i uploady, a New, Import zip je przywraca

#Czy WordPress Playground może łączyć się z zewnętrznymi API

Sieć jest domyślnie włączona (networking=yes w Query API, features.networking: true w Blueprintach). Po wyłączeniu wp_safe_remote_get i podobne funkcje od razu zwracają błąd. Po włączeniu żądania idą przez przeglądarkę, więc o tym, co działa, decyduje CORS. W publicznym demie używaj testowych danych dostępowych do zewnętrznych usług, bo klucz API siedzi w przeglądarce, którą każdy może podejrzeć.

#Co zmieniło się w WordPress Playground w 2026

Zespół publikuje zmiany na make.wordpress.org/playground. Cztery zmiany z 2026 roku dotyczą opisanych wyżej procesów:

• Nowy interfejs (lipiec 2026): Dock zastąpił wcześniejsze panele boczne i okna modalne. Powstał przy stole Playground podczas Contributor Day na WordCamp Europe 2026 w Krakowie
• Stare wersje (sierpień 2026): WordPress od 0.7 do 6.2 startuje w przeglądarce z automatycznym doborem PHP
• Terminal (wrzesień 2026): Dev Tools, Terminal uruchamia fragmenty PHP z załadowanym WordPressem i polecenia WP-CLI na aktywnej stronie; WP-CLI pobiera się przy pierwszym użyciu
• Narzędzie Email (wrzesień 2026): wiadomości wysłane przez wp_mail() są przechwytywane i pokazywane z tematem, nadawcą, odbiorcą i treścią. Przechwycony e-mail to nie doręczony e-mail, a wtyczki wysyłające przez własne połączenie SMTP albo API dostawcy omijają przechwytywanie

Dokumentacja obejmuje też agentów AI do programowania: skill agenta wp-playground i most WebMCP. Ten temat opisuję w artykule WordPress Playground i MCP dla agentów AI.

#Najczęstsze błędy Blueprintu w WordPress Playground

Kilka pułapek, które wychodzą, gdy pokazujesz Playground prawdziwym użytkownikom.

Rozjazd wersji PHP. Hosting produkcyjny działa na PHP 8.1. Query API domyślnie używa PHP 8.5. Demo przechodzi, klient instaluje wtyczkę u siebie i dostaje błąd krytyczny w funkcji, której demo nigdy nie sprawdziło na 8.1. Przypnij preferredVersions.php do minimalnej wspieranej wersji, nie do najnowszej.

Tymczasowy zapis w osadzeniach. Osadzenie z storage=temp albo can-save=no traci wszystko po odświeżeniu. Dla jednorazowego dema to dobre ustawienie, dla ćwiczenia na szkoleniu złe. Jeśli demo potrzebuje plików, wgrywaj je krokiem writeFile przy każdym uruchomieniu.

CORS przy importach i API. blueprint-url, pliki zip dla import-site i manifesty rozszerzeń PHP wymagają nagłówka Access-Control-Allow-Origin na serwerze, który je hostuje. Blueprint działający z surowych adresów GitHuba może nie zadziałać z Twojego CDN-a, dopóki nie dodasz nagłówka.

Kolejność kroków. Skróty takie jak plugins, login, siteOptions i constants są rozwijane przed tablicą steps. Jeśli jedna akcja musi nastąpić przed inną, zapisz obie jako jawne kroki w potrzebnej kolejności.

Pomieszane formaty wtyczek. Aktualny krok installPlugin używa pluginData, a activate siedzi w options. Starsze przykłady używają wycofanego pluginZipFile i dokumentacja zabrania mieszania obu. Slug wpisany w zasób (wordpress.org/plugins/woocommerce) też jest błędem: zasób potrzebuje osobnego pola slug.

Składnia SQLite a MySQL. Warstwa tłumacząca pokrywa prawie cały core, ale własny SQL wtyczki to Twoja odpowiedzialność. Testuj Blueprint z pełną wtyczką i jej prawdziwymi ścieżkami danych, nie tylko z samym core.

#Przykład JSON-LD dla WordPress Playground

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "WordPress Playground: przyszłość testowania i demonstracji",
  "description": "Dowiedz się, jak używać WordPress Playground do uruchamiania WP w przeglądarce przez WebAssembly. Kompletny przewodnik na 2026 rok.",
  "author": {
    "@type": "Organization",
    "name": "WPPoland"
  },
  "datePublished": "2026-01-29",
  "dateModified": "2026-10-14",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://wppoland.com/pl/wordpress-playground-przewodnik-2026/"
  }
}

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "Jak używać WordPress Playground do testów i developmentu",
  "description": "Instrukcja krok po kroku uruchamiania WordPressa w przeglądarce dzięki WebAssembly",
  "totalTime": "PT15M",
  "supply": [
    "Nowoczesna przeglądarka",
    "Połączenie z internetem"
  ],
  "tool": [
    {
      "@type": "HowToTool",
      "name": "Przeglądarka internetowa"
    }
  ],
  "step": [
    {
      "@type": "HowToStep",
      "position": 1,
      "name": "Otwórz WordPress Playground",
      "text": "Wejdź na playground.wordpress.net, aby otworzyć oficjalną instancję WordPress Playground.",
      "url": "https://playground.wordpress.net"
    },
    {
      "@type": "HowToStep",
      "position": 2,
      "name": "Skonfiguruj środowisko",
      "text": "Otwórz Site Settings w Docku i wybierz wersję WordPressa, wersję PHP, język i sieć."
    },
    {
      "@type": "HowToStep",
      "position": 3,
      "name": "Poczekaj na instancję",
      "text": "Świeży WordPress bez wtyczek ładuje się zwykle 5 do 10 sekund; duże wtyczki, takie jak WooCommerce, 30 do 60 sekund."
    },
    {
      "@type": "HowToStep",
      "position": 4,
      "name": "Zacznij testować",
      "text": "Wejdź do panelu WordPressa, instaluj wtyczki, twórz treści i testuj funkcje w odizolowanym środowisku."
    },
    {
      "@type": "HowToStep",
      "position": 5,
      "name": "Zapisz albo wyeksportuj pracę",
      "text": "Użyj Export, aby pobrać stronę jako zip, albo Store permanently, aby zachować ją w pamięci przeglądarki."
    }
  ]
}

Blueprint Playground to najszybszy sposób, żeby pokazać klientowi wtyczkę bez proszenia o serwer, bazę danych czy dane dostępowe. Takie dema przygotowuję w ramach programowania wtyczek WordPress.