WordPress Playground: O Futuro dos Testes e Demonstrações

O WordPress Playground é uma instalação completa de WordPress que corre no browser. O PHP é compilado para WebAssembly (PHP.wasm), a base de dados é SQLite e a página oficial de limitações indica que os ficheiros WASM têm entre 15 e 30 MB. Não há servidor, não há wp-config.php para preencher, nem MAMP, nem Docker. Abre um URL e está dentro do wp-admin.

Se publica plugins ou temas, dá formação ou revê pull requests, o Playground muda alguns fluxos de trabalho diários. Se gere sites em produção, não os substitui. Trate o Playground como uma sandbox e uma ferramenta de demonstração, não como alojamento.

Saiba mais sobre desenvolvimento profissional de WordPress na WPPoland.

#O que é o WordPress Playground

O Playground é um projeto open source do WordPress, publicado sob GPLv2 ou posterior. A instância web está em playground.wordpress.net e a documentação em developer.wordpress.org/playground. As peças que contam no trabalho diário:

• PHP.wasm corre PHP 7.4 a 8.5 dentro de um Web Worker. A Query API usa PHP 8.5 por omissão; escolhe outra versão por sessão com ?php= ou num Blueprint
• SQLite substitui o MySQL através do plugin oficial SQLite Database Integration. A maioria dos plugins que usam $wpdb funciona; código com SQL escrito à mão para MySQL pode falhar
• O armazenamento do browser guarda os Playgrounds novos como gravações automáticas quando a gravação está disponível. O Playground guarda até cinco gravações automáticas recentes, e um Playground temporário desaparece depois de atualizar a página
• Email e WP-CLI funcionam em modo sandbox. As mensagens de wp_mail() vão para a ferramenta Email em vez de uma caixa de correio, e o Terminal corre comandos WP-CLI no site ativo

O Playground é uma instância descartável de WordPress que pode entregar a alguém através de um URL. É o produto inteiro, e chega para ser útil.

#Como funciona o WordPress Playground

A documentação de arquitetura descreve a sequência de arranque. A página em playground.wordpress.net carrega remote.html num iframe. Esse ficheiro arranca uma Worker Thread e um Service Worker. A Worker Thread inicia o PHP e preenche um sistema de ficheiros virtual com um WordPress adaptado para correr sobre SQLite. Depois, o Service Worker interceta cada pedido HTTP do iframe do WordPress e encaminha-o para a Worker Thread, que gera a resposta.

#Como o WebAssembly executa PHP no browser

A equipa compila o interpretador PHP para WebAssembly com o Emscripten. Segundo a visão geral do WebAssembly PHP, a compilação precisa apenas de alguns patches; o trabalho maior foi um módulo de API PHP em C e uma classe JavaScript que passa ao PHP o corpo dos pedidos, os uploads e o php://stdin. Cada versão do PHP é um ficheiro .wasm estático separado, por isso mudar de versão significa que o browser descarrega outro binário.

O separador do browser orquestra tudo. Fechá-lo ou recarregá-lo destrói o ambiente de execução, e é por isso que os modos de armazenamento (explicados abaixo) contam tanto.

#Como o Playground substitui o MySQL por SQLite

Não existe uma compilação do MySQL para WebAssembly que corra num browser. O Playground distribui o PHP com o driver nativo de SQLite, e o plugin SQLite Database Integration interceta as consultas MySQL e reescreve-as no dialeto SQLite. A documentação indica que a versão 2.0 permite ao WordPress sobre SQLite passar 99% dos testes unitários do WordPress. É na diferença restante que o SQL próprio dos plugins costuma falhar.

#Como funciona a rede dentro do Playground

O código WebAssembly só pode chamar APIs de JavaScript, por isso o PHP não consegue abrir sockets diretamente. No browser, o Playground oferece dois transportes: um rápido que converte as chamadas wp_safe_remote_get em pedidos fetch(), e outro mais lento que analisa o tráfego TLS iniciado pelo PHP e o traduz para fetch(). Como cada pedido acaba como um fetch() do browser, o servidor de destino tem de permitir pedidos de origem cruzada. A documentação da Query API exige o cabeçalho Access-Control-Allow-Origin em qualquer ficheiro que o Playground importe a partir de um URL.

#Como usar o WordPress Playground

Há quatro pontos de entrada, desde zero código até controlo programático total.

#Método 1: usar o website oficial do Playground

Abra playground.wordpress.net. Carrega um WordPress limpo, e as ferramentas ficam no Dock na parte inferior do ecrã. O guia da instância web lista as suas secções:

1. New: começar a partir da galeria de Blueprints, de um URL público de Blueprint, de um Blueprint novo, da pré-visualização de um pull request, de um repositório GitHub ou de um .zip importado
2. Playgrounds: alternar entre Playgrounds recentes e guardados
3. Site Settings: versão do WordPress, versão do PHP, idioma, rede e multisite
4. Blueprint, Database, Files, Logs: ver e editar o Blueprint atual, descarregar a base de dados SQLite, explorar ficheiros e ler erros de PHP
5. Export: descarregar um .zip, copiar a ligação da configuração original ou exportar ficheiros selecionados para um pull request no GitHub

A versão do PHP e a rede podem ser alteradas num Playground guardado que já existe. A versão do WordPress, o idioma e o multisite mudam a própria instalação, por isso iniciam um Playground novo. Para temas de blocos, landingPage: /wp-admin/site-editor.php num Blueprint abre logo o editor do site.

#Método 2: incorporar o Playground no seu website

Cada opção da Query API é um parâmetro de URL, por isso um iframe chega para uma demonstração incorporada:

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

Os parâmetros que vai usar mais, segundo a referência da Query API:

Instalar um plugin ou tema através do URL inicia sessão como administrador. O parâmetro lazy adia o carregamento até alguém clicar no botão de execução, e assim a página com a demonstração incorporada continua leve até o visitante querer mesmo usá-la.

#Método 3: usar a API do Playground para integração avançada

O cliente JavaScript do pacote npm @wp-playground/client dá-lhe controlo total a partir da sua própria página, de testes ou de pipelines 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;
}

#Método 4: configuração Blueprint para ambientes reproduzíveis

Os Blueprints são ficheiros JSON que configuram uma instância do Playground. A página inicial dos Blueprints indica três formas de os usar: colar no fragmento do URL, passar à API JavaScript ou referenciar um ficheiro com blueprint-url. Os Blueprints não podem executar JavaScript arbitrário, e por isso correr o Blueprint de outra pessoa não exige confiança no 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": "O Meu Site de Teste",
        "blogdescription": "A Testar o WordPress Playground"
      }
    }
  ]
}

A linha $schema dá preenchimento automático e validação no editor. Segundo a documentação do formato de dados, preferredVersions.wp aceita as sete últimas versões principais (6.3 a 6.9 em abril de 2026), além de latest, beta e nightly, e features.networking tem de ficar ligado se o visitante for instalar plugins ou temas.

#Como correr o WordPress Playground localmente com a CLI

O mesmo ambiente funciona em Node.js. A Playground CLI (@wp-playground/cli) precisa do Node.js 20.18 ou mais recente e substitui o pacote descontinuado wp-now.

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

O start deteta se a pasta é um plugin, um tema ou uma instalação completa do WordPress, monta-a, inicia a sua sessão e abre o browser. O site mantém-se entre sessões em ~/.wordpress-playground/sites/<path-hash>/, e --reset dá-lhe uma instalação limpa. O server é o comando avançado, com controlo manual de montagens e armazenamento, pensado para configurações próprias e CI. Ambos aceitam --wp=, --php= e --blueprint=; a CLI usa PHP 8.3 por omissão.

A CLI tem também o subcomando php. O guia de PHPUnit corre a bateria de testes de um plugin contra um WordPress limpo em cada execução, sem base de dados local:

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

Assim, uma matriz de versões de PHP e WordPress passa a ser um ciclo sobre duas flags em vez de um conjunto de imagens Docker.

#Para que serve o WordPress Playground

Cinco fluxos de trabalho em que o Playground substitui algo que antes se fazia pelo caminho lento.

#Como adicionar uma ligação “experimente este plugin” a uma página de vendas

Em vez de “descarregue o zip e instale num ambiente de staging”, o botão abre um URL de Blueprint com o plugin já instalado e conteúdo de demonstração carregado. O visitante chega ao ecrã de administração certo, já com sessão iniciada. O padrão funciona porque o passo de configuração desaparece para o visitante.

O padrão de URL: https://playground.wordpress.net/?blueprint-url=https://example.com/blueprint.json. Aloje o JSON do Blueprint em qualquer servidor que envie o cabeçalho CORS. Dentro de artigos WordPress, o bloco oficial WordPress Playground incorpora o mesmo tipo de demonstração, com editor de código ao vivo se precisar.

#Como pré-visualizar pull requests de plugins no Playground

O guia de pré-visualização de PR usa a ação WordPress/action-wp-playground-pr-preview@v3. Com plugin-path: . (ou theme-path: .) acrescenta um botão Preview à descrição do pull request. Um clique abre o Playground com o plugin ou tema instalado e ativado a partir do ramo do PR.

A documentação impõe duas condições. Tudo o que o Playground instala tem de estar num URL público, por isso um repositório privado precisa de mais do que a configuração por omissão. E se o plugin precisar de Composer ou de um build npm, a ação usa dois workflows: um de build com permissões apenas de leitura e outro de publicação que envia o zip para uma prerelease pública ci-artifacts. O guia avisa contra mudar para pull_request_target para correr código do PR com permissões de escrita.

#WordPress Playground em formações e cursos

Cada formando recebe uma instância isolada de WordPress a partir do mesmo Blueprint. No primeiro dia não chegam mensagens de “o meu XAMPP não arranca”. A página de limitações indica como suportados Chrome, Firefox, Safari e Edge no computador e Safari e Chrome no telemóvel, o que cobre Chromebooks e portáteis empresariais bloqueados onde o Docker não é permitido. A contrapartida: o armazenamento do browser não é uma cópia de segurança, por isso o que os formandos quiserem guardar precisa da exportação em zip no fim da sessão.

#Como reproduzir erros de clientes com um Blueprint

Um cliente reporta um erro numa versão específica do WordPress, com um conjunto de plugins e um tema. Envia-lhe um URL de Blueprint com exatamente essa combinação. O cliente confirma a reprodução no browser dele. Depura contra o mesmo Blueprint localmente com a CLI. O ticket passa a ter um caso de reprodução determinístico em vez de “no meu computador funciona”.

#Como testar versões antigas do WordPress no Playground

Desde agosto de 2026, o painel Site Settings tem a opção Include older versions. O anúncio em make.wordpress.org descreve o PHP 5.2.17 compilado para WebAssembly e o arranque no browser do WordPress 0.7 ao 6.2. O Playground escolhe o ambiente automaticamente: o WordPress 0.7 a 4.9 fica preso ao PHP 5.2, o 5.0 a 6.2 ao PHP 7.4, e o 6.3 ou mais recente usa o fluxo moderno. Para quem mantém um plugin, um relatório de compatibilidade antigo passa a ser uma definição no browser em vez de uma stack de servidor obsoleta.

#Quando não usar o WordPress Playground

• Nada que tenha de entregar email real ou correr num cron real
• Testes de carga, porque o PHP.wasm corre num Web Worker dentro do separador do browser
• Plugins que chamam exec(), escrevem em caminhos absolutos ou precisam de extensões PHP que o Playground não inclui
• Chamadas a APIs externas que exigem autenticação de servidor para servidor, porque se aplicam as regras CORS do browser e a maioria das APIs não aceita playground.wordpress.net como origem

#Limitações e desempenho do WordPress Playground

A página de limitações é curta e vale a pena lê-la antes de pôr o Playground à frente de clientes.

#Quanto armazenamento do browser o WordPress Playground pode usar

O Playground não publica uma quota fixa. O armazenamento pertence ao browser, e a documentação avisa que falta de espaço, navegação privada, mudanças de perfil ou a limpeza dos dados do site podem remover Playgrounds guardados. Demonstrações com muitos ficheiros multimédia carregam mais depressa e duram mais quando os ficheiros grandes vêm de um URL através de um passo do Blueprint, em vez de serem carregados durante a sessão.

#Quanto tempo o WordPress Playground demora a carregar

Os valores oficiais:

Contam o tamanho dos plugins, a velocidade da rede (os ficheiros WASM têm entre 15 e 30 MB), a memória do dispositivo e o browser. A documentação aponta o Chrome e o Edge como os mais rápidos e o Safari como ligeiramente mais lento.

#O WordPress Playground é mais lento que um servidor real

Sim, em trabalho intensivo de CPU. A documentação de arquitetura descreve o servidor PHP como tão lento que tem de correr num Web Worker, caso contrário cada pedido congelaria a página. O processamento de imagens, as importações em massa e as consultas grandes demoram bastante mais do que num alojamento PHP nativo, por isso não meça o desempenho de plugins no Playground.

#Que particularidades do iframe afetam as demonstrações no Playground

O WordPress é apresentado dentro de um iframe. Ligações com target="_top" recarregam toda a página em que está a trabalhar, e popups de JavaScript abertos a partir do iframe podem não aparecer. Se o seu plugin abre janelas OAuth ou usa window.top, teste o fluxo da demonstração à mão.

#O WordPress Playground é seguro para dados reais

A documentação oficial descreve o Playground como algo que corre inteiramente no cliente, sem backend e sem autenticação. O site que constrói fica no seu browser, por isso o risco está no dispositivo.

#O WordPress Playground guarda os seus dados

A documentação define três modos de armazenamento:

• Autosaved: no armazenamento do browser, mantido apenas enquanto for uma das cinco gravações automáticas mais recentes
• Saved: guardado de forma permanente no browser, ou numa pasta local em browsers que suportam a File System Access API
• Temporary: criado com ?storage=temp ou quando não é possível guardar, descartado ao atualizar ou ao fechar o separador

Implicações de segurança:

• Computadores partilhados: Playgrounds com gravação automática ou guardados ficam nesse perfil do browser para o utilizador seguinte
• Dados sensíveis: não introduza credenciais reais nem dados pessoais de clientes
• Limpeza do browser: apagar os dados do site elimina os Playgrounds guardados
• Exportação: a transferência em .zip exporta ficheiros, base de dados, plugins, temas e uploads, e New, Import zip restaura-a

#O WordPress Playground pode chamar APIs externas

A rede está ligada por omissão (networking=yes na Query API, features.networking: true nos Blueprints). Se a desligar, wp_safe_remote_get e funções semelhantes falham de imediato. Se estiver ligada, os pedidos passam pelo browser e o CORS decide o que funciona. Use credenciais de teste para serviços externos numa demonstração pública, porque a chave de API fica num browser que qualquer pessoa pode inspecionar.

#O que mudou no WordPress Playground em 2026

A equipa publica as novidades em make.wordpress.org/playground. Quatro mudanças de 2026 afetam os fluxos descritos acima:

• Nova interface (julho de 2026): o Dock substituiu as barras laterais e janelas modais anteriores. Nasceu na mesa do Playground no Contributor Day do WordCamp Europe 2026, em Cracóvia
• Versões antigas (agosto de 2026): o WordPress 0.7 a 6.2 arranca no browser com emparelhamento automático do PHP
• Terminal (setembro de 2026): Dev Tools, Terminal corre excertos de PHP com o WordPress carregado e comandos WP-CLI no site ativo; o WP-CLI é descarregado na primeira utilização
• Ferramenta Email (setembro de 2026): as mensagens enviadas com wp_mail() são capturadas e mostradas com assunto, remetente, destinatário e corpo. Um email capturado não é um email entregue, e os plugins que enviam por uma ligação SMTP própria ou pela API de um fornecedor contornam a captura

A documentação cobre também agentes de IA para programação: uma skill de agente wp-playground e uma ponte WebMCP. Tratamos esse lado em WordPress Playground e MCP para agentes de IA.

#Erros comuns de Blueprint no WordPress Playground

Algumas armadilhas que aparecem quando utilizadores reais veem o Playground.

Desvio da versão do PHP. O seu alojamento de produção corre PHP 8.1. A Query API usa PHP 8.5 por omissão. A demonstração passa; o cliente instala o plugin no site dele e encontra um erro fatal numa função que a demonstração nunca executou em 8.1. Fixe preferredVersions.php na versão mínima que suporta, não na mais recente.

Armazenamento temporário em incorporações. Uma incorporação com storage=temp ou can-save=no perde tudo ao atualizar. Está certo para uma demonstração descartável e errado para um exercício de formação. Se a demonstração precisar de ficheiros, crie-os com um passo writeFile em cada execução.

CORS em importações e APIs. blueprint-url, os zips de import-site e os manifestos de extensões PHP precisam do cabeçalho Access-Control-Allow-Origin no servidor que os aloja. Um Blueprint que funciona a partir de URLs raw do GitHub pode falhar a partir do seu próprio CDN até acrescentar o cabeçalho.

Ordem dos passos. Atalhos como plugins, login, siteOptions e constants são expandidos antes do array steps. Se uma ação tiver de acontecer antes de outra, escreva ambas como passos explícitos pela ordem de que precisa.

Formatos de plugin misturados. O passo atual installPlugin usa pluginData, com activate dentro de options. Exemplos antigos usam o descontinuado pluginZipFile, e a documentação pede para não misturar os dois. Um slug escrito dentro do recurso (wordpress.org/plugins/woocommerce) também está errado: o recurso precisa de um campo slug separado.

Sintaxe SQLite versus MySQL. A camada de tradução cobre quase todo o núcleo, mas o SQL próprio de um plugin é responsabilidade sua. Teste o Blueprint com o plugin completo e os seus caminhos de dados reais, não apenas com o núcleo.

#Exemplo de JSON-LD para o WordPress Playground

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "WordPress Playground: O Futuro dos Testes e Demonstrações",
  "description": "Aprenda a usar o WordPress Playground para correr WP no browser via WebAssembly. Guia técnico para testes e demonstrações em 2026.",
  "author": {
    "@type": "Organization",
    "name": "WPPoland"
  },
  "datePublished": "2026-01-29",
  "dateModified": "2026-10-14",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://wppoland.com/pt-pt/wordpress-playground-guide-2026/"
  }
}

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "Como usar o WordPress Playground para testes e desenvolvimento",
  "description": "Guia passo a passo para executar o WordPress no seu browser com WebAssembly",
  "totalTime": "PT15M",
  "supply": [
    "Browser web moderno",
    "Ligação à internet"
  ],
  "tool": [
    {
      "@type": "HowToTool",
      "name": "Browser web"
    }
  ],
  "step": [
    {
      "@type": "HowToStep",
      "position": 1,
      "name": "Aceda ao WordPress Playground",
      "text": "Abra playground.wordpress.net no seu browser para aceder à instância oficial do WordPress Playground.",
      "url": "https://playground.wordpress.net"
    },
    {
      "@type": "HowToStep",
      "position": 2,
      "name": "Configure o ambiente",
      "text": "Abra Site Settings no Dock e escolha a versão do WordPress, a versão do PHP, o idioma e a rede."
    },
    {
      "@type": "HowToStep",
      "position": 3,
      "name": "Aguarde pela instância",
      "text": "Um WordPress limpo sem plugins carrega normalmente em 5 a 10 segundos; plugins grandes como o WooCommerce demoram 30 a 60 segundos."
    },
    {
      "@type": "HowToStep",
      "position": 4,
      "name": "Comece a testar",
      "text": "Aceda ao painel de administração do WordPress, instale plugins, crie conteúdo e teste funcionalidades no ambiente isolado."
    },
    {
      "@type": "HowToStep",
      "position": 5,
      "name": "Guarde ou exporte o seu trabalho",
      "text": "Use Export para descarregar o site em zip, ou Store permanently para o manter no armazenamento do browser."
    }
  ]
}

Um blueprint do Playground é a forma mais rápida de mostrar um plugin a um cliente sem lhe pedir servidor, base de dados ou credenciais. Preparamos demonstrações assim como parte do desenvolvimento de plugins WordPress.