WordPress Studio ejecuta PHP mediante WebAssembly dentro de Electron, sin Apache, Nginx, Docker ni un proceso MySQL separado. Desarrollo puede crear un WordPress local en segundos. Cambios de compilación publicados en marzo redujeron los binarios PHP.wasm en 122 MB y mejoraron el inicio.
El entorno incluye Xdebug para VS Code y PhpStorm, un asistente de IA que ejecuta WP-CLI, Blueprints repetibles, sincronización selectiva y enlaces públicos de preview. Estas capacidades llevan Studio de demo técnica a espacio práctico para muchas tareas de themes y plugins.
El caso más fuerte para gestión es onboarding. Una persona nueva llega a la aplicación antes de resolver versiones de PHP, containers, puertos y bases. El equipo codifica una base común en Blueprints y usa la primera hora en el proyecto, no en el portátil.
El onboarding que el portátil deja de cobrar
Studio empaqueta PHP en WebAssembly dentro de Electron. Crear un WordPress local deja de depender de MAMP, Docker, pelea de versión de PHP y MySQL olvidado en el login. Para un equipo que recibe gente nueva, eso devuelve la primera mañana.
Los Blueprints convierten la ganancia en un estándar: tema, plugins, contenido de demo y settings en un paquete que sube igual en la máquina siguiente. Sin Blueprint, cada persona sigue inventando su propio sitio de prueba y el onboarding solo cambió de lugar. La primera hora de soporte debería ir al repositorio, al ticket y al preview, no a la versión de PHP.
Documenta el Blueprint como baseline del equipo. El botón "crear sitio" solo replica lo que ese paquete ya describió.
Xdebug en un solo sitio y el costo de dejar el debugger encendido
Xdebug vía PHP de Playground se enciende en los settings del sitio, escucha en el puerto 9003 y conecta VS Code o PhpStorm. No instala extensión en el PHP del sistema. El ritual de compilación desaparece.
Dos límites operativos están en el anuncio de marzo. Solo un sitio a la vez con Xdebug; el activo muestra un icono en la barra. Encenderlo deja el entorno visiblemente más lento, así que úsalo en la sesión de debug y apágalo después. Para el caso en que solo necesitas ver el error, el toggle de debug log define WP_DEBUG y WP_DEBUG_LOG y abre wp-content/debug.log sin cazar el path.
"Show errors in browser" enciende WP_DEBUG_DISPLAY. Sirve en tu máquina. En un preview compartido con un cliente, déjalo apagado: path y lógica se filtran en el HTML. Un agente de código puede leer el log si apuntas el archivo. Eso no sustituye un breakpoint cuando el bug es estado.
El Linux que WebAssembly no imita
Playground carga Intl, Xdebug, Memcached y Redis como módulos dinámicos, y el recorte de 122 MB en los binarios (888 MB a 766 MB, sin quitar feature) mejoró descarga, parse de JS glue y startup. Sigue siendo PHP compilado a Wasm, con dos estrategias de async (Asyncify y JSPI) y el recorte de símbolos que MAIN_MODULE=2 pasó a exportar.
Una extensión que depende de un binario nativo específico, de sockets al modo del servidor, de la SAPI Apache o de una lib que el build no empaqueta puede fallar. Cola, object cache Redis de producción, cron del sistema, upload en NFS, certificado e IPv6 del host siguen pidiendo Docker, Herd, Valet, Forge o staging. Studio acelera tema, plugin y flujo editorial. El deploy todavía necesita el PHP, las extensiones y la SAPI que producción corre de verdad.
Si el proyecto declara "funciona en Studio" como criterio de listo, añade un job en Linux en el CI para la parte que el encapsulamiento no cubre.
Preview, sync y el puerto que ya estaba ocupado
La URL pública de preview y el sync selectivo resuelven el "en mi máquina" para contenido y para el cliente. El preview alojado pide cuenta WordPress.com, permanece siete días después del último update y tiene cuota de diez sitios. El sync con producción está en WordPress.com de pago o en Pressable con Jetpack. Quien hospeda en otro lado necesita otro camino de deploy; el botón de Studio no inventa un servidor.
Puertos 80 y 443: si Local WP o Laravel Herd ya los usan, cierra uno o reconfigura antes del onboarding. Es el roce que quema la promesa de "clicaste, abrió" si el README interno lo omite.
Trata Studio como entorno estándar de UI, de Xdebug y de Blueprint. Mantén un Linux, aunque sea solo en CI, para extensión nativa, cola y el PHP que producción corre de verdad. Sin esa división, la extensión que falta aparece el día del lanzamiento.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
