WordPress Playground: Fremtiden for Testing og Demoer

WordPress Playground er en komplett WordPress-installasjon som kjører i nettleseren. PHP er kompilert til WebAssembly (PHP.wasm), databasen er SQLite, og den offisielle siden om begrensninger oppgir at WASM-filene er på 15 til 30 MB. Det finnes ingen server, ingen wp-config.php å fylle ut, ingen MAMP og ingen Docker. Du åpner en URL og er inne i wp-admin.

Hvis du gir ut utvidelser eller temaer, holder opplæring eller går gjennom pull requests, endrer Playground noen daglige arbeidsflyter. Hvis du drifter produksjonsnettsteder, erstatter det dem ikke. Behandle Playground som en sandkasse og et demoverktøy, ikke som hosting.

Les mer om profesjonell WordPress-utvikling hos WPPoland.

#Hva er WordPress Playground

Playground er et åpen kildekode-prosjekt fra WordPress, lisensiert under GPLv2 eller nyere. Nettinstansen ligger på playground.wordpress.net og dokumentasjonen på developer.wordpress.org/playground. Delene som teller i det daglige:

• PHP.wasm kjører PHP 7.4 til 8.5 i en Web Worker. Query API bruker PHP 8.5 som standard; du velger en annen versjon per økt med ?php= eller i en Blueprint
• SQLite erstatter MySQL gjennom den offisielle utvidelsen SQLite Database Integration. De fleste utvidelser som bruker $wpdb fungerer; kode med håndskrevet MySQL-spesifikk SQL kan feile
• Nettleserlagringen tar vare på nye Playgrounds som autolagringer når lagring er tilgjengelig. Playground beholder opptil fem nylige autolagringer, og en midlertidig Playground er borte etter en oppdatering
• E-post og WP-CLI fungerer i en sandkasseform. Meldinger fra wp_mail() havner i Email-verktøyet i stedet for i en innboks, og Terminal kjører WP-CLI-kommandoer mot det aktive nettstedet

Playground er en engangsinstans av WordPress som du kan gi noen via en URL. Det er hele produktet, og det holder for å være nyttig.

#Hvordan WordPress Playground fungerer

Arkitekturdokumentasjonen beskriver oppstartsrekkefølgen. Siden på playground.wordpress.net laster remote.html i en iframe. Den filen starter en Worker Thread og en Service Worker. Worker Thread starter PHP og fyller et virtuelt filsystem med en WordPress-versjon som er tilpasset SQLite. Service Worker fanger deretter opp hver HTTP-forespørsel fra WordPress-iframen og sender den videre til Worker Thread, som gjengir svaret.

#Hvordan WebAssembly kjører PHP i nettleseren

Teamet kompilerer PHP-tolken til WebAssembly med Emscripten. Ifølge oversikten over WebAssembly PHP trenger bygget bare noen få endringer; den større jobben var en PHP-API-modul i C og en JavaScript-klasse som sender forespørselsinnhold, opplastinger og php://stdin inn i PHP. Hver PHP-versjon er en egen statisk .wasm-fil, så å bytte versjon betyr at nettleseren laster ned en annen binærfil.

Nettleserfanen styrer alt. Lukker eller laster du den inn på nytt, forsvinner kjøremiljøet, og derfor betyr lagringsmodusene (beskrevet nedenfor) så mye.

#Hvordan Playground erstatter MySQL med SQLite

Det finnes ingen WebAssembly-versjon av MySQL som kjører i en nettleser. Playground leverer PHP med den innebygde SQLite-driveren, og utvidelsen SQLite Database Integration fanger opp MySQL-spørringer og skriver dem om til SQLite-dialekt. Dokumentasjonen oppgir at versjon 2.0 lar WordPress på SQLite bestå 99% av WordPress sine enhetstester. I det gjenstående gapet er det som regel egen SQL i utvidelser som feiler.

#Hvordan nettverk fungerer i Playground

WebAssembly-kode kan bare kalle JavaScript-API-er, så PHP kan ikke åpne sockets direkte. I nettleseren har Playground to transportveier: en rask som gjør wp_safe_remote_get-kall om til fetch()-forespørsler, og en tregere som tolker TLS-trafikken PHP starter og oversetter den til fetch(). Fordi hver forespørsel ender som en fetch() i nettleseren, må målserveren tillate forespørsler på tvers av opprinnelse. Dokumentasjonen for Query API krever headeren Access-Control-Allow-Origin for hver fil Playground importerer fra en URL.

#Slik bruker du WordPress Playground

Det finnes fire inngangsporter, fra helt uten kode til full programmatisk kontroll.

#Metode 1: bruke den offisielle Playground-nettsiden

Åpne playground.wordpress.net. En fersk WordPress lastes, og verktøyene ligger i Dock nederst på skjermen. Veiledningen for nettinstansen lister opp delene:

1. New: start fra Blueprint-galleriet, en offentlig Blueprint-URL, en ny Blueprint, en forhåndsvisning av en pull request, et GitHub-repo eller en importert .zip
2. Playgrounds: bytt mellom nylige og lagrede Playgrounds
3. Site Settings: WordPress-versjon, PHP-versjon, språk, nettverk og multisite
4. Blueprint, Database, Files, Logs: se og rediger gjeldende Blueprint, last ned SQLite-databasen, bla i filer og les PHP-feil
5. Export: last ned en .zip, kopier lenken til det opprinnelige oppsettet eller eksporter utvalgte filer til en pull request på GitHub

PHP-versjon og nettverk kan endres i en eksisterende, lagret Playground. WordPress-versjon, språk og multisite endrer selve installasjonen og starter derfor en ny Playground. For blokktemaer åpner landingPage: /wp-admin/site-editor.php i en Blueprint nettstedsredigeringen med en gang.

#Metode 2: bygge inn Playground på nettsiden din

Hvert alternativ i Query API er en URL-parameter, så en iframe er nok for en innebygd demo:

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

Parameterne du bruker oftest, ifølge referansen for Query API:

Når en utvidelse eller et tema installeres via URL, blir besøkende logget inn som administrator. Parameteren lazy utsetter lastingen til noen klikker på startknappen, så en side med innebygd demo forblir lett til besøkende faktisk vil prøve den.

#Metode 3: bruke Playground API for avansert integrasjon

JavaScript-klienten fra npm-pakken @wp-playground/client gir deg full kontroll fra din egen side, fra tester eller fra 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;
}

#Metode 4: Blueprint-konfigurasjon for gjentakbare miljøer

Blueprints er JSON-filer som setter opp en Playground-instans. Startsiden for Blueprints nevner tre måter å bruke dem på: lim inn i URL-fragmentet, send til JavaScript-API-et eller pek på en fil med blueprint-url. Blueprints kan ikke kjøre vilkårlig JavaScript, og derfor krever det ikke tillit til forfatteren å kjøre en annens Blueprint.

{
  "$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": "Mitt testnettsted",
        "blogdescription": "Test av WordPress Playground"
      }
    }
  ]
}

Linjen $schema gir autofullføring og validering i editoren. Ifølge dokumentasjonen for dataformatet godtar preferredVersions.wp de sju siste hovedversjonene (6.3 til 6.9 per april 2026) i tillegg til latest, beta og nightly, og features.networking må være på hvis besøkende skal installere utvidelser eller temaer.

#Slik kjører du WordPress Playground lokalt med CLI

Det samme kjøremiljøet fungerer i Node.js. Playground CLI (@wp-playground/cli) krever Node.js 20.18 eller nyere og erstatter den utgåtte pakken wp-now.

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

start oppdager om mappen er en utvidelse, et tema eller en full WordPress-installasjon, monterer den, logger deg inn og åpner nettleseren. Nettstedet bevares mellom økter i ~/.wordpress-playground/sites/<path-hash>/, og --reset gir en ren installasjon. server er den avanserte kommandoen med manuell kontroll over monteringer og lagring, ment for egne oppsett og CI. Begge godtar --wp=, --php= og --blueprint=; CLI bruker PHP 8.3 som standard.

CLI har også underkommandoen php. Veiledningen for PHPUnit kjører testsuiten til en utvidelse mot en ren WordPress ved hver kjøring, uten lokal database:

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

Dermed blir en versjonsmatrise for PHP og WordPress en løkke over to flagg i stedet for et sett med Docker-bilder.

#Hva kan du bruke WordPress Playground til

Fem arbeidsflyter der Playground erstatter noe som tidligere tok den langsomme veien.

#Slik legger du en lenke “prøv utvidelsen” på en salgsside

I stedet for “last ned zip-filen og installer på et testmiljø” åpner knappen en Blueprint-URL med utvidelsen ferdig installert og demoinnhold lagt inn. Besøkende lander på riktig adminskjerm, allerede innlogget. Mønsteret fungerer fordi oppsettet forsvinner for besøkende.

URL-mønsteret: https://playground.wordpress.net/?blueprint-url=https://example.com/blueprint.json. Legg Blueprint-filen hvor som helst der serveren sender CORS-headeren. I WordPress-innlegg bygger den offisielle WordPress Playground-blokken inn samme type demo, eventuelt med en levende kodeeditor.

#Slik forhåndsviser du pull requests for utvidelser i Playground

Veiledningen for PR-forhåndsvisning bruker handlingen WordPress/action-wp-playground-pr-preview@v3. Med plugin-path: . (eller theme-path: .) legger den til en Preview-knapp i beskrivelsen av pull requesten. Et klikk åpner Playground med utvidelsen eller temaet installert og aktivert fra PR-grenen.

Dokumentasjonen setter to krav. Alt Playground installerer, må ligge på en offentlig URL, så et privat repo trenger mer enn standardoppsettet. Og hvis utvidelsen trenger Composer eller et npm-bygg, bruker handlingen to arbeidsflyter: en byggeflyt med bare lesetilgang og en publiseringsflyt som laster opp zip-filen til en offentlig ci-artifacts-prerelease. Veiledningen advarer mot å bytte til pull_request_target for å kjøre PR-kode med skrivetilgang.

#WordPress Playground i opplæring og kurs

Hver deltaker får en isolert WordPress-instans fra den samme Blueprinten. Første dag kommer det ingen meldinger om at “XAMPP vil ikke starte”. Siden om begrensninger oppgir Chrome, Firefox, Safari og Edge på desktop og Safari og Chrome på mobil som støttet, noe som dekker Chromebooks og låste jobb-PC-er der Docker er blokkert. Ulempen: nettleserlagring er ikke en sikkerhetskopi, så det deltakerne vil beholde, må eksporteres som zip på slutten av økten.

#Slik gjenskaper du en kundefeil med en Blueprint

En kunde melder en feil på en bestemt WordPress-versjon, et sett utvidelser og et tema. Du sender kunden en Blueprint-URL med akkurat den stakken. Kunden bekrefter at feilen kan gjenskapes i sin nettleser. Du feilsøker mot den samme Blueprinten lokalt med CLI. Saken inneholder nå et deterministisk gjenskapingstilfelle i stedet for “det virker hos meg”.

#Slik tester du gamle WordPress-versjoner i Playground

Siden august 2026 har panelet Site Settings valget Include older versions. Kunngjøringen på make.wordpress.org beskriver PHP 5.2.17 kompilert til WebAssembly og oppstart i nettleseren for WordPress 0.7 til 6.2. Playground velger kjøremiljø automatisk: WordPress 0.7 til 4.9 låses til PHP 5.2, 5.0 til 6.2 låses til PHP 7.4, og 6.3 eller nyere bruker den moderne flyten. For en utvidelsesforfatter blir en gammel kompatibilitetsrapport da en innstilling i nettleseren i stedet for en utdatert serverstakk.

#Når du ikke bør bruke WordPress Playground

• Alt som må levere ekte e-post eller kjøre på en ekte cron-plan
• Lasttesting, siden PHP.wasm kjører i en Web Worker inne i nettleserfanen
• Utvidelser som kaller exec(), skriver til absolutte stier eller trenger PHP-utvidelser som Playground ikke leverer
• Kall til eksterne API-er som krever autentisering fra server til server, siden nettleserens CORS-regler gjelder og de fleste API-er ikke godtar playground.wordpress.net som opprinnelse

#Hvilke begrensninger har WordPress Playground

Siden om begrensninger er kort og verdt å lese før du setter Playground foran kunder.

#Hvor mye nettleserlagring WordPress Playground kan bruke

Playground oppgir ingen fast kvote. Lagringen tilhører nettleseren, og dokumentasjonen advarer om at lite lagringsplass, privat surfing, profilbytte eller sletting av nettstedsdata kan fjerne lagrede Playgrounds. Demoer med mye media laster raskere og varer lenger når store filer hentes fra en URL via et Blueprint-steg i stedet for å lastes opp i økten.

#Hvor lang tid WordPress Playground bruker på å laste

De offisielle tallene:

Størrelsen på utvidelser, nettverkshastighet (WASM-filene er 15 til 30 MB), minnet på enheten og nettleseren spiller inn. Dokumentasjonen peker på Chrome og Edge som raskest og Safari som litt tregere.

#Er WordPress Playground tregere enn en ekte server

Ja, for CPU-tungt arbeid. Arkitekturdokumentasjonen beskriver PHP-serveren som så treg at den må kjøre i en Web Worker, ellers ville hver forespørsel fryse siden. Bildebehandling, masseimport og store spørringer tar merkbart lengre tid enn på en vanlig PHP-server, så ikke mål ytelsen til utvidelser i Playground.

#Hvilke iframe-særheter som påvirker Playground-demoer

WordPress gjengis i en iframe. Lenker med target="_top" laster inn hele siden du jobber på, og JavaScript-popuper fra iframen vises kanskje ikke. Hvis utvidelsen din åpner OAuth-vinduer eller bruker window.top, bør du teste demoflyten for hånd.

#Er WordPress Playground trygt for ekte data

Den offisielle dokumentasjonen beskriver Playground som kjørt helt på klientsiden, uten backend og uten autentisering. Nettstedet du bygger, blir i nettleseren din, så risikoen ligger på enheten.

#Lagrer WordPress Playground dataene dine

Dokumentasjonen definerer tre lagringsmoduser:

• Autosaved: lagret i nettleseren, beholdt bare så lenge den er blant de fem nyeste autolagringene
• Saved: lagret permanent i nettleseren, eller i en lokal mappe i nettlesere som støtter File System Access API
• Temporary: opprettet med ?storage=temp eller når lagring ikke er tilgjengelig, forkastet ved oppdatering eller når fanen lukkes

Konsekvenser for sikkerheten:

• Delte datamaskiner: autolagrede og lagrede Playgrounds blir liggende i nettleserprofilen til neste bruker
• Sensitive data: ikke skriv inn ekte påloggingsdata eller personopplysninger om kunder
• Opprydding i nettleseren: sletting av nettstedsdata fjerner lagrede Playgrounds
• Eksport: nedlasting som .zip eksporterer filer, database, utvidelser, temaer og opplastinger, og New, Import zip gjenoppretter den

#Kan WordPress Playground kalle eksterne API-er

Nettverk er på som standard (networking=yes i Query API, features.networking: true i Blueprints). Er det av, feiler wp_safe_remote_get og lignende funksjoner umiddelbart. Er det på, går forespørslene gjennom nettleseren, og CORS avgjør hva som fungerer. Bruk testnøkler for eksterne tjenester i en offentlig demo, fordi API-nøkkelen ligger i en nettleser som alle kan inspisere.

#Hva som endret seg i WordPress Playground i 2026

Teamet publiserer oppdateringer på make.wordpress.org/playground. Fire endringer fra 2026 berører arbeidsflytene over:

• Nytt grensesnitt (juli 2026): Dock erstattet de tidligere sidepanelene og dialogene. Det vokste fram ved Playground-bordet under Contributor Day på WordCamp Europe 2026 i Kraków
• Gamle versjoner (august 2026): WordPress 0.7 til 6.2 starter i nettleseren med automatisk valg av PHP
• Terminal (september 2026): Dev Tools, Terminal kjører PHP-snutter med WordPress lastet og WP-CLI-kommandoer mot det aktive nettstedet; WP-CLI lastes ned første gang det brukes
• Email-verktøyet (september 2026): meldinger sendt med wp_mail() fanges opp og vises med emne, avsender, mottaker og innhold. En oppfanget e-post er ikke en levert e-post, og utvidelser som sender via egen SMTP-tilkobling eller en leverandørs API, går utenom oppfangingen

Dokumentasjonen dekker også KI-kodeagenter: en agentferdighet wp-playground og en WebMCP-bro. Den siden dekker vi i WordPress Playground og MCP for KI-agenter.

#Vanlige Blueprint-feil i WordPress Playground

Noen feller som slår til når ekte brukere ser Playground.

PHP-versjonsdrift. Produksjonsserveren kjører PHP 8.1. Query API bruker PHP 8.5 som standard. En demo går gjennom; kunden installerer utvidelsen på sitt nettsted og får en fatal feil i en funksjon demoen aldri kjørte på 8.1. Lås preferredVersions.php til den laveste versjonen du støtter, ikke den nyeste.

Midlertidig lagring i innebygginger. En innebygging med storage=temp eller can-save=no mister alt ved oppdatering. Det er riktig for en engangsdemo og feil for en kursoppgave. Hvis demoen trenger filer, legg dem inn med et writeFile-steg ved hver kjøring.

CORS ved import og API-er. blueprint-url, zip-filer for import-site og manifester for PHP-utvidelser krever alle headeren Access-Control-Allow-Origin på serveren som leverer dem. En Blueprint som fungerer fra rå GitHub-URL-er, kan feile fra ditt eget CDN til du legger til headeren.

Rekkefølgen på stegene. Kortformer som plugins, login, siteOptions og constants utvides før steps-listen. Hvis én handling må skje før en annen, skriver du begge som eksplisitte steg i rekkefølgen du trenger.

Blandede formater for utvidelser. Det gjeldende steget installPlugin bruker pluginData, og activate hører hjemme i options. Eldre eksempler bruker den utgåtte pluginZipFile, og dokumentasjonen sier at de to ikke skal blandes. En slug skrevet inn i ressursen (wordpress.org/plugins/woocommerce) er også feil: ressursen trenger et eget slug-felt.

SQLite- mot MySQL-syntaks. Oversettelseslaget dekker nesten hele kjernen, men egen SQL i en utvidelse er ditt ansvar. Test Blueprinten med hele utvidelsen og dens ekte databaner, ikke bare kjernen.

#JSON-LD-eksempel for WordPress Playground

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "WordPress Playground: Fremtiden for Testing og Demoer",
  "description": "Lær hvordan du bruker WordPress Playground til å kjøre WP i nettleseren via WebAssembly. En komplett guide for testing i 2026.",
  "author": {
    "@type": "Organization",
    "name": "WPPoland"
  },
  "datePublished": "2026-01-29",
  "dateModified": "2026-10-14",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://wppoland.com/nb/wordpress-playground-guide-2026/"
  }
}

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "Slik bruker du WordPress Playground til testing og utvikling",
  "description": "Steg-for-steg-guide for å kjøre WordPress i nettleseren med WebAssembly",
  "totalTime": "PT15M",
  "supply": [
    "Moderne nettleser",
    "Internettforbindelse"
  ],
  "tool": [
    {
      "@type": "HowToTool",
      "name": "Nettleser"
    }
  ],
  "step": [
    {
      "@type": "HowToStep",
      "position": 1,
      "name": "Åpne WordPress Playground",
      "text": "Gå til playground.wordpress.net for å åpne den offisielle instansen av WordPress Playground.",
      "url": "https://playground.wordpress.net"
    },
    {
      "@type": "HowToStep",
      "position": 2,
      "name": "Konfigurer miljøet",
      "text": "Åpne Site Settings i Dock og velg WordPress-versjon, PHP-versjon, språk og nettverk."
    },
    {
      "@type": "HowToStep",
      "position": 3,
      "name": "Vent på instansen",
      "text": "En fersk WordPress uten utvidelser laster vanligvis på 5 til 10 sekunder; store utvidelser som WooCommerce tar 30 til 60 sekunder."
    },
    {
      "@type": "HowToStep",
      "position": 4,
      "name": "Begynn å teste",
      "text": "Gå til WordPress-kontrollpanelet, installer utvidelser, lag innhold og test funksjoner i det isolerte miljøet."
    },
    {
      "@type": "HowToStep",
      "position": 5,
      "name": "Lagre eller eksporter arbeidet",
      "text": "Bruk Export for å laste ned nettstedet som zip, eller Store permanently for å beholde det i nettleserlagringen."
    }
  ]
}

En Playground-Blueprint er den raskeste måten å vise en kunde en utvidelse på uten å be om server, database eller påloggingsdata. Slike demoer lager vi som en del av utvikling av WordPress-utvidelser.