O WordPress Studio roda PHP inteiro no navegador via WebAssembly. Sem Apache, sem Nginx, sem Docker, sem MySQL rodando em background. Você abre o app, clica em "criar site" e em segundos tem um WordPress local funcionando.
Eu sei que parece marketing. Mas a arquitetura é real. O WordPress Playground compila PHP pra WebAssembly e roda tudo dentro do Electron. Em março cortaram 122 MB dos binários .wasm só trocando flags de compilação, o que deixou o startup visivelmente mais rápido.
E agora tem Xdebug embutido. Sem instalar nada no sistema. Ativa nas configurações do site, conecta o VS Code ou PhpStorm, e está debugando com breakpoints, step-by-step, inspeção de variáveis. Tudo via WebAssembly. Isso era impensável há dois anos.
Tem também um assistente de IA que roda comandos WP-CLI por chat, Blueprints pra criar ambientes repetíveis, sync seletivo com sites em produção e geração de URL pública pra compartilhar preview com clientes. Grátis, open source.
Para quem gerencia times que mantêm projetos WordPress, o ganho mais concreto é outro: onboarding. Cada dev novo que entrava no time perdia meio dia configurando ambiente local. MAMP, Docker, conflitos de porta, versão de PHP errada. Com o Studio, esse problema deixa de existir.
Mas vale ser honesto sobre os limites. Ambiente WebAssembly não é idêntico a um servidor Linux real. Extensions de PHP que dependem de binários nativos podem não funcionar. Projetos com integrações pesadas de servidor provavelmente ainda precisam de Docker ou Forge. E se você já roda Local WP ou Laravel Herd, cuidado: as portas 80 e 443 vão conflitar. Fecha um antes de abrir o outro, ou reconfigura as portas. É uma ferramenta de produtividade, não um substituto de infra.
O onboarding que o laptop deixa de cobrar
Studio empacota PHP em WebAssembly dentro do Electron. Criar um WordPress local deixa de depender de MAMP, Docker, conflito de versão de PHP e MySQL esquecido no login. Para time que recebe gente nova, isso devolve a primeira manhã.
Blueprints transformam o ganho em padrão: tema, plugins, conteúdo de demo e settings num pacote que sobe igual na máquina seguinte. Sem Blueprint, cada pessoa ainda inventa o próprio site de teste e o onboarding só mudou de lugar. A primeira hora de suporte deve ir para o repositório, o ticket e o ambiente de preview, não para a versão do PHP.
Documente o Blueprint como baseline do time. O botão "criar site" só replica o que esse pacote já descreveu.
Xdebug num site só e o custo de deixar o debugger ligado
O Xdebug via PHP do Playground liga nas settings do site, escuta na porta 9003 e conecta VS Code ou PhpStorm. Não instala extensão no PHP do sistema. O ritual de compilação some.
Dois limites operacionais estão no anúncio de março. Só um site por vez com Xdebug; o ativo mostra um ícone na barra. Ligar deixa o ambiente visivelmente mais lento, então use na sessão de debug e desligue depois. Para o caso em que você só precisa ver o erro, o toggle de debug log define WP_DEBUG e WP_DEBUG_LOG e abre wp-content/debug.log sem caçar path.
"Show errors in browser" liga WP_DEBUG_DISPLAY. Serve na sua máquina. Em preview compartilhado com cliente, deixe desligado: path e lógica vazam no HTML. Agente de código pode ler o log se você apontar o arquivo. Isso não substitui breakpoint quando o bug é estado.
O Linux que o WebAssembly não imita
Playground carrega Intl, Xdebug, Memcached e Redis como módulos dinâmicos, e o corte de 122 MB nos binários (888 MB para 766 MB, sem remover feature) melhorou download, parse de JS glue e startup. Continua sendo PHP compilado para Wasm, com duas estratégias de async (Asyncify e JSPI) e o recorte de símbolos que o MAIN_MODULE=2 passou a exportar.
Extensão que depende de binário nativo específico, de socket no jeito do servidor, de SAPI Apache ou de uma lib que o build não empacota pode falhar. Fila, object cache Redis de produção, cron do sistema, upload no NFS, certificado e IPv6 do host continuam pedindo Docker, Herd, Valet, Forge ou o staging. Studio acelera tema, plugin e fluxo editorial. O deploy ainda precisa do PHP, das extensões e da SAPI que a produção realmente corre.
Se o projeto declara "funciona no Studio" como critério de pronto, acrescente um job em Linux no CI para a parte que o encapsulamento não cobre.
Preview, sync e a porta que já estava ocupada
URL pública de preview e sync seletivo resolvem o "na minha máquina" para conteúdo e para cliente. Preview hospedado pede conta WordPress.com, permanece sete dias após o último update e tem cota de dez sites. Sync com produção no WordPress.com pago ou no Pressable com Jetpack. Quem hospeda em outro lugar precisa de outro caminho de deploy; o botão do Studio não inventa um servidor.
Portas 80 e 443: se Local WP ou Laravel Herd já as usam, feche um ou reconfigure antes do onboarding. É o atrito que queima a promessa de "clicou, abriu" se o README interno omitir.
Trate o Studio como ambiente padrão de UI, de Xdebug e de Blueprint. Mantenha um Linux, mesmo que só no CI, para extensão nativa, fila e o PHP que a produção realmente corre. Sem essa divisão, a extensão que falta aparece no dia do lançamento.
