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), bazą danych jest SQLite, a cały stack to paczka 30 do 40 MB. Nie ma serwera, nie ma wp-config.php do uzupełnienia, nie ma XAMPP-a, Local by Flywheel ani Dockera. Otwierasz URL i już jesteś w wp-admin.

Projekt prowadzi Adam Zieliński, polski deweloper z core teamu WordPressa, który pierwszy commit do Playground popełnił jeszcze w 2022 roku. Jeśli wypuszczasz wtyczki albo motywy, prowadzisz szkolenia z WordPressa albo robisz code review pull requestów, to zmienia kilka codziennych workflow. Jeśli prowadzisz produkcyjne strony, Playgroundu nie wkładasz w miejsce hostingu. Traktuj go jak sandbox i narzędzie do dem, nie jak hosting.

Dowiedz się więcej o profesjonalnym rozwoju WordPress w WPPoland.

#Czym Playground naprawdę jest

Playground to projekt core teamu WordPressa pod adresem playground.wordpress.net. Najciekawsze elementy:

• PHP.wasm uruchamia PHP w wersjach 7.4 do 8.3 wewnątrz Web Workera. Wersję wybierasz per sesja przez Blueprint
• SQLite zastępuje MySQL przez oficjalny drop-in sqlite-database-integration. Większość wtyczek używających $wpdb działa bez problemu; cokolwiek pisze surowy SQL specyficzny dla MySQL nie działa
• Wirtualny system plików trzyma się w pamięci domyślnie. Zamknięcie karty wymazuje wszystko, chyba że podepniesz storage OPFS albo wyeksportujesz zip
• Bez maila, bez crona, bez binarki WP-CLI w domyślnym sandboxie. WP-CLI uruchamia się tylko przez krok wp-cli w Blueprincie, a wychodzące maile nie idą nigdzie

Uczciwe ujęcie: Playground to jednorazowy WordPress, którego oddasz komuś przez URL. To cały produkt i wystarczy, żeby był użyteczny.

#Jak działa WordPress Playground

Pod maską Playground łączy kilka technologii webowych w jedną instancję WordPressa działającą po stronie klienta. Warto wiedzieć, co siedzi pod spodem, bo determinuje to, co zadziała, a co nie.

#Fundament WebAssembly

WebAssembly (WASM) to format wykonywalny działający w przeglądarkach z wydajnością bliską natywnej. Adam Zieliński i zespół skompilowali PHP do WASM, dzięki czemu cały interpreter PHP dostajesz jako plik, który przeglądarka odpala wewnątrz Web Workera.

Baza danych SQLite zastępuje MySQL przez ten sam drop-in sqlite-database-integration, który oficjalnie hostuje wordpress.org. Plugin tłumaczy zapytania $wpdb na dialekt SQLite w locie. Jeśli kiedyś używałeś go na produkcyjnym hostingu (przykładowo na Mikrusie albo cyber_Folks na pakiecie startowym, gdzie MySQL jest limitowany), zachowanie jest identyczne.

#Kluczowe komponenty

• PHP-WASM: Interpreter PHP skompilowany do WebAssembly, wykonujący kod po stronie klienta
• Integracja SQLite: System bazodanowy oparty na pliku, ten sam drop-in co sqlite-database-integration z wordpress.org
• Wirtualny system plików: Działa w pamięci podczas sesji, opcjonalnie wpięty do OPFS dla trwałości
• Service Worker API: Buforuje pliki rdzenia i mediuje między iframem a workerem PHP
• Klient JavaScript: Pakiet @wp-playground/client na npm, używany do programowego sterowania instancją

#Pierwsze kroki z WordPress Playground

Cztery sposoby uruchomienia Playgroundu, od najszybszego do najbardziej zaawansowanego.

#Metoda 1: oficjalna strona Playground

Najkrótsza droga: wejdź na playground.wordpress.net. Świeży WordPress odpala się w 5 do 10 sekund na laptopie z 2020 roku, na MacBooku M1 jest to 2 do 3 sekundy. Kliknięcie i jesteś w wp-admin/index.php z wp-userem admin i hasłem password.

Na demach na meetupie WordPress Warsaw używamy tego trybu, kiedy ktoś z sali pyta “ale jak to wygląda po aktywacji”. Odpalasz, instalujesz wtyczkę z wordpress.org bezpośrednio z Wtyczki → Dodaj nową i pokazujesz w 30 sekund.

#Metoda 2: osadzanie Playground na własnej stronie

Iframe to najprostsza droga do interaktywnego dema na landingu wtyczki albo motywu:

<iframe
  src="https://playground.wordpress.net/?theme=twentytwentyfour&plugin=gutenberg"
  width="100%"
  height="800px"
  frameborder="0"
  allow="clipboard-write"
></iframe>

Parametry query, które się przydają:

#Metoda 3: Playground API do zaawansowanej integracji

Kiedy potrzebujesz programowej kontroli (testy E2E, CI/CD, niestandardowy launcher), używasz pakietu @wp-playground/client:

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.2',
        wp: 'latest'
      },
      steps: [
        {
          step: 'installPlugin',
          pluginZipFile: {
            resource: 'wordpress.org/plugins',
            slug: 'gutenberg'
          }
        },
        {
          step: 'installTheme',
          themeZipFile: {
            resource: 'wordpress.org/themes',
            slug: 'twentytwentyfour'
          }
        }
      ]
    }
  });

  return client;
}

#Metoda 4: Blueprint do odtwarzalnych środowisk

Blueprint to plik JSON definiujący stan instancji. Trzymasz go w repo razem z wtyczką i każdy reviewer dostaje identyczne środowisko:

{
  "$schema": "https://playground.wordpress.net/blueprint-schema.json",
  "landingPage": "/wp-admin/plugins.php",
  "preferredVersions": {
    "php": "8.2",
    "wp": "6.5"
  },
  "phpExtensionBundles": ["kitchen-sink"],
  "features": {
    "networking": true,
    "fullscreen": false
  },
  "steps": [
    {
      "step": "login",
      "username": "admin",
      "password": "password"
    },
    {
      "step": "installPlugin",
      "pluginZipFile": {
        "resource": "wordpress.org/plugins",
        "slug": "query-monitor"
      },
      "options": {
        "activate": true
      }
    },
    {
      "step": "setSiteOptions",
      "options": {
        "blogname": "Moja testowa strona",
        "blogdescription": "Testowanie WordPress Playground"
      }
    }
  ]
}

#Gdzie naprawdę się sprawdza

Cztery workflow, w których Playground zastępuje coś, co kiedyś robiłeś wolniej.

#Linki “wypróbuj wtyczkę” na stronie sprzedażowej

Zamiast “pobierz zip, zainstaluj na stagingu”, twoje CTA otwiera URL Blueprintu z preinstalowaną wtyczką i podsianym demo produktu albo posta. Odwiedzający ląduje od razu w wp-admin/edit.php?post_type=product, zalogowany. Konwersja zależy od projektu, ale schemat działa, bo tarcie spada z “30 minut konfiguracji” do “jedno kliknięcie”.

W Polski WordPress newsletterze Tomek Niezgoda kilka miesięcy temu opisywał, jak Bartłomiej Jankowski na landingu swojej wtyczki Members Only podmienił “demo na YouTube” na osadzony Playground i zaobserwował większe zaangażowanie na stronie produktu. Schemat URL Blueprintu: https://playground.wordpress.net/?blueprint-url=https://example.com/blueprint.json. JSON Blueprintu hostujesz gdziekolwiek, gdzie masz przyjazne CORS-y.

#Podglądy PR-ów dla repo wtyczek

Oficjalna GitHub Action WordPress/wordpress-playground bierze zip wtyczki z buildu PR-a i postuje link do Playgroundu jako komentarz. Reviewer klika, branch ładuje się do świeżego WordPressa, błąd reprodukuje się w 20 sekund. Koniec próśb “nagraj loomik”.

Maciej Bis, autor Email Address Encoder i WP Email Smtp, używa tego flow do recenzji PR-ów na trac.wordpress.org bez stawiania lokalnego środowiska.

#Środowiska szkoleniowe

Każdy student dostaje izolowany WordPress z tego samego Blueprintu. Koniec slackowych “u mnie XAMPP nie startuje” pierwszego dnia kursu. Działa na Chromebookach i zablokowanych korpo-laptopach, gdzie Docker jest zablokowany przez politykę bezpieczeństwa. Trade-off: zamknięcie karty kasuje pracę, więc cokolwiek student chce zachować, eksportujesz zipem na koniec sesji.

Na kursach WordPressa po polsku na Udemy oraz na zajęciach prowadzonych przez Mikoláša Ševčíka na blogu, Playground stał się standardem zamiast lokalnego LAMP-a. Skraca pierwsze 30 minut zajęć do zera.

#Reprodukcja błędów dla wsparcia

Klient zgłasza błąd na WP 6.5 + WooCommerce 9.4 + Astra. Wysyłasz mu URL Blueprintu z dokładnie tym stackiem. On potwierdza reprodukcję w swojej przeglądarce. Ty debugujesz przeciw temu samemu Blueprintowi lokalnie. Ticket zawiera deterministyczny przypadek reprodukcji zamiast “u mnie działa”.

Dla integracji z polskimi platformami (Allegro Marketplace przez wtyczkę WP Allegro, BaseLinker, Furgonetka) Playground jest praktyczny do reprodukcji bugu w sandboxie bez ryzykowania prawdziwych danych w polu NIP czy REGON.

#Do czego się nie nadaje

• Cokolwiek zależnego od prawdziwego crona, prawdziwego maila (wp_mail to no-op) ani trwałych uploadów między sesjami
• Testy obciążeniowe, bo PHP.wasm działa jednowątkowo w Web Workerze
• Wtyczki używające exec(), piszące do absolutnych ścieżek systemu plików albo wymagające binarnych rozszerzeń PHP spoza paczki kitchen-sink
• Wywołania API trzecich stron z autoryzacją serwer-do-serwer, bo obowiązują reguły CORS przeglądarki, a większość API SaaS nie pozwala na origin playground.wordpress.net

#Wydajność i ograniczenia

Playground potrafi dużo, ale ma sztywne ograniczenia narzucone przez przeglądarkę. Warto je znać przed zaplanowaniem wdrożenia.

#Limity przechowywania przeglądarki

IndexedDB pozwala na 50-250 MB per domena, w zależności od przeglądarki i urządzenia. Duża biblioteka mediów albo zestaw 30 wtyczek szybko trafiają w sufit. W praktyce:

• Trzymaj media na CDN-ie zewnętrznym (Cloudflare Images, Bunny CDN), nie w lokalnych uploadach
• Wybieraj tylko niezbędne wtyczki do scenariusza testowego
• Eksportuj instancję zipem przed jej zamknięciem
• Włącz networking: true w Blueprintcie i pobieraj zewnętrzne zasoby on-demand

#Wymagania sieciowe

Pierwsze ładowanie to 30 do 40 MB binarki PHP-WASM i plików rdzenia. Na łączu Atman LIM albo na 5G to 2-3 sekundy; na hotspocie z telefonu w pociągu Pendolino - 20 sekund białego ekranu. Service worker buforuje pliki na kolejne ładowania, ale instalacja wtyczek dalej wymaga sieci.

#Wydajność obliczeniowa

PHP w WASM jest wolniejsze od natywnego PHP-FPM, szczególnie w operacjach masowych. Generowanie 1000 postów przez WP-CLI step w Blueprincie zajmuje 30-40 sekund w przeglądarce wobec 5-6 sekund na typowym hostingu cyber_Folks albo home.pl. Praktyki, które pomagają:

• Limituj równoczesne operacje
• Używaj mniejszych obrazków w testach związanych z mediami
• Włącz OPcache, gdy jest dostępny w konfiguracji PHP
• Do benchmarków wydajności używaj natywnego środowiska, nie Playgroundu

#Bezpieczeństwo i prywatność

Uruchamianie WordPressa w przeglądarce wprowadza nietypowe kwestie bezpieczeństwa.

#Trwałość danych

Domyślnie instancje są efemeryczne; zamknięcie karty kasuje wszystko. Funkcja “Save” przechowuje stan w storage przeglądarki, ale to ma konsekwencje:

• Współdzielone komputery: zapisana instancja jest dostępna dla każdego, kto otworzy tę samą przeglądarkę
• Wrażliwe dane: nie wprowadzaj prawdziwych loginów, kluczy API, danych osobowych ani danych logowania do bramek typu Przelewy24 czy Tpay
• Czyszczenie przeglądarki: wyczyszczenie ciasteczek/storage usuwa zapisane Playgroundy
• Eksport: regularnie eksportuj ważną pracę zipem

Tomasz Dziuda, polski tłumacz Wordfence i autor pakietu polskich tłumaczeń wtyczek bezpieczeństwa, podkreśla na Polski WordPress Slacku, że Playground nie zastępuje stagingu z prawdziwym WAF-em, kiedy testuje się scenariusze ataków.

#Sieć i komunikacja zewnętrzna

Z włączoną siecią Playground rozmawia z zewnętrznymi API. Wymaga to świadomego podejścia do CORS i bezpieczeństwa transmisji:

• Używaj testowych kluczy API do integracji z usługami zewnętrznymi
• Implementuj rotację kluczy w publicznych demonstracjach
• Rozważ rate limiting dla publicznych instancji Playground
• Waliduj dane zewnętrzne tak samo jak w produkcji

#Tryby awarii, o których warto wiedzieć przed wdrożeniem Blueprintu

Kilka pułapek, które wychodzą dopiero, kiedy oddasz Playground prawdziwym użytkownikom.

Drift wersji PHP. Hosting produkcyjny chodzi na PHP 8.1. Twój Blueprint defaultuje na 8.2, bo to default Playgroundu. Demo przechodzi; klient instaluje wtyczkę u siebie i dostaje deprecation warning. Pinuj preferredVersions.php do minimalnej wspieranej wersji, nie do najnowszej. Na hostingu cyber_Folks startowym dostajesz PHP 8.1 jako domyślne; na home.pl 8.2; na wielu starych instalacjach na nazwa.pl ciągle 7.4.

Zapisy do plików nie przeżywają. Wtyczka pisząca do wp-content/uploads/my-plugin/cache/ działa w sesji, wygląda że działa po refreshu, znika w momencie zamknięcia karty. Jeśli demo zależy od trwałych uploadów: (a) użyj OPFS w startPlaygroundWeb, albo (b) podsiej pliki krokiem Blueprintu writeFile przy każdym starcie.

CORS na zewnętrznych API. Proxy networkingowe Playgroundu obsługuje WordPress.org, GitHub i małą whitelistę. Cokolwiek poza tym wymaga, żeby API zezwalało na origin Playgroundu w Access-Control-Allow-Origin, a większość SaaS-ów tego nie robi. Workaround: własne proxy na własnej domenie, wołane z JS-a wtyczki. Dla integracji z polskimi API typu Allegro REST albo Apaczka, własne proxy jest jedyną realną drogą.

Kolejność kroków Blueprintu. installPlugin przed login działa; setSiteOptions przed installPlugin dla wtyczki rejestrującej ustawienia w aktywacji po cichu zgubi te ustawienia. Kroki wykonują się w kolejności tablicy bez resolve’owania zależności.

Rozmiar paczki na wolnych łączach. Pierwsze ładowanie to 30 do 40 MB WASM-a i plików rdzenia. Cache działa potem, ale pierwsze wrażenie na 3G albo na hotspocie w Pendolino to 20-sekundowy biały ekran. Pokazuj własny loader, nie domyślny spinner Playgroundu.

SQLite kontra składnia MySQL. Wtyczki piszące INSERT ... ON DUPLICATE KEY UPDATE albo używające funkcji JSON z MySQL-a wykrzaczą się. Drop-in SQLite tłumaczy popularne wzorce, ale nie wszystkie. Testuj Blueprint z pełną wtyczką, nie tylko z corem. Wtyczki polskich autorów takie jak WPMU DEV Smush czy WP Rocket przeszły rebranding i są bezpieczne, ale wiele własnych integracji magazynowych dla sklepów na BaseLinkerze ciągle pisze surowy MySQL.

#LLM-Friendly Structured Data

{
  "@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-01-29",
  "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 testowania i developmentu",
  "description": "Przewodnik krok po kroku po uruchamianiu WordPressa w przeglądarce przez WebAssembly",
  "totalTime": "PT15M",
  "supply": [
    "Nowoczesna przeglądarka",
    "Połączenie z internetem"
  ],
  "tool": [
    {
      "@type": "HowToTool",
      "name": "Przeglądarka internetowa"
    }
  ],
  "step": [
    {
      "@type": "HowToStep",
      "position": 1,
      "name": "Wejdź na WordPress Playground",
      "text": "Otwórz playground.wordpress.net w przeglądarce, aby uzyskać dostęp do oficjalnej instancji WordPress Playground.",
      "url": "https://playground.wordpress.net"
    },
    {
      "@type": "HowToStep",
      "position": 2,
      "name": "Skonfiguruj środowisko",
      "text": "Wybierz wersję WordPressa, wersję PHP oraz preinstalowane wtyczki lub motywy z dostępnych opcji."
    },
    {
      "@type": "HowToStep",
      "position": 3,
      "name": "Uruchom instancję",
      "text": "Kliknij przycisk uruchomienia, aby zainicjować przeglądarkowe środowisko WordPress. Pierwsze ładowanie zajmuje 10-30 sekund."
    },
    {
      "@type": "HowToStep",
      "position": 4,
      "name": "Zacznij testować",
      "text": "Wejdź do panelu administracyjnego, instaluj dodatkowe wtyczki, twórz treści i eksperymentuj w izolowanym środowisku."
    },
    {
      "@type": "HowToStep",
      "position": 5,
      "name": "Zapisz lub wyeksportuj pracę",
      "text": "Użyj funkcji eksportu, aby pobrać instancję WordPress do migracji na serwer produkcyjny lub zapisz ją w storage przeglądarki na później."
    }
  ]
}

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Czy WordPress Playground nadaje się do produkcyjnych stron?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Nie, WordPress Playground jest zaprojektowany do testowania, developmentu i celów edukacyjnych. Brakuje mu niezawodności, systemów backupu i optymalizacji wydajności wymaganych w środowiskach produkcyjnych."
      }
    },
    {
      "@type": "Question",
      "name": "Czy mogę przenieść instancję Playground na serwer produkcyjny?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Tak, WordPress Playground obsługuje eksport generujący standardowe pliki backupu WordPressa kompatybilne z większością wtyczek migracyjnych i ręcznych procesów importu."
      }
    },
    {
      "@type": "Question",
      "name": "Czy Playground obsługuje wszystkie wtyczki i motywy WordPress?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Większość wtyczek i motywów działa poprawnie, ale niektóre mogą mieć problemy z kompatybilnością przez SQLite lub środowisko PHP-WASM. Wtyczki wymagające specyficznej konfiguracji serwera lub binarnych rozszerzeń mogą nie działać."
      }
    }
  ]
}