WordPress Playground: El futuro de las pruebas y demos

WordPress Playground es una instalación completa de WordPress que se ejecuta en el navegador. PHP está compilado a WebAssembly (PHP.wasm), la base de datos es SQLite y la página oficial de limitaciones indica que los archivos WASM pesan entre 15 y 30 MB. No hay servidor, ni wp-config.php que rellenar, ni MAMP, ni Docker. Abres una URL y estás dentro de wp-admin.

Si publicas plugins o temas, impartes formación o revisas pull requests, Playground cambia varios flujos de trabajo diarios. Si gestionas sitios en producción, no los sustituye. Trata Playground como un sandbox y una herramienta de demos, no como un hosting.

Más sobre desarrollo profesional de WordPress en WPPoland.

#Qué es WordPress Playground

Playground es un proyecto de código abierto de WordPress, publicado bajo GPLv2 o posterior. La instancia web está en playground.wordpress.net y la documentación en developer.wordpress.org/playground. Las piezas que importan en el día a día:

• PHP.wasm ejecuta PHP 7.4 a 8.5 dentro de un Web Worker. La Query API usa PHP 8.5 por defecto; eliges otra versión por sesión con ?php= o en un Blueprint
• SQLite sustituye a MySQL mediante el plugin oficial SQLite Database Integration. La mayoría de plugins que usan $wpdb funcionan; el código con SQL escrito a mano para MySQL puede fallar
• El almacenamiento del navegador guarda los Playgrounds nuevos como autoguardados cuando el guardado está disponible. Playground conserva hasta cinco autoguardados recientes, y un Playground temporal desaparece tras recargar
• El correo y WP-CLI funcionan en modo sandbox. Los mensajes de wp_mail() llegan a la herramienta Email en lugar de a un buzón, y el Terminal ejecuta comandos de WP-CLI sobre el sitio activo

Playground es una instancia desechable de WordPress que puedes pasar a alguien con una URL. Ese es todo el producto, y basta para que resulte útil.

#Cómo funciona WordPress Playground

La documentación de arquitectura describe la secuencia de arranque. La página de playground.wordpress.net carga remote.html en un iframe. Ese archivo arranca un Worker Thread y un Service Worker. El Worker Thread inicia PHP y llena un sistema de archivos virtual con un WordPress adaptado para funcionar sobre SQLite. Después, el Service Worker intercepta cada petición HTTP del iframe de WordPress y la reenvía al Worker Thread, que genera la respuesta.

#Cómo ejecuta WebAssembly PHP en el navegador

El equipo compila el intérprete de PHP a WebAssembly con Emscripten. Según la introducción a WebAssembly PHP, la compilación solo necesita unos pocos parches; el trabajo grande fue un módulo de API de PHP en C y una clase de JavaScript que pasa a PHP el cuerpo de las peticiones, las subidas de archivos y php://stdin. Cada versión de PHP es un archivo .wasm estático independiente, así que cambiar de versión significa que el navegador descarga otro binario.

La pestaña del navegador lo orquesta todo. Cerrarla o recargarla destruye el entorno de ejecución, y por eso los modos de almacenamiento (explicados más abajo) importan tanto.

#Cómo sustituye Playground MySQL por SQLite

No existe una compilación de MySQL a WebAssembly que funcione en un navegador. Playground distribuye PHP con el driver nativo de SQLite, y el plugin SQLite Database Integration intercepta las consultas de MySQL y las reescribe en el dialecto de SQLite. La documentación indica que su versión 2.0 permite a WordPress sobre SQLite superar el 99% de los tests unitarios de WordPress. En el hueco restante es donde suele romperse el SQL propio de los plugins.

#Cómo funciona la red dentro de Playground

El código WebAssembly solo puede llamar a APIs de JavaScript, así que PHP no puede abrir sockets directamente. En el navegador, Playground ofrece dos transportes: uno rápido que convierte las llamadas a wp_safe_remote_get en peticiones fetch(), y otro más lento que analiza el tráfico TLS que inicia PHP y lo traduce a fetch(). Como cada petición acaba como un fetch() del navegador, el servidor de destino debe permitir peticiones de origen cruzado. La documentación de la Query API exige la cabecera Access-Control-Allow-Origin en cualquier archivo que Playground importe desde una URL.

#Cómo usar WordPress Playground paso a paso

Hay cuatro puntos de entrada, desde cero código hasta control programático completo.

#Método 1: usando el sitio web oficial de Playground

Abre playground.wordpress.net. Se carga un WordPress limpio, y las herramientas están en el Dock de la parte inferior de la pantalla. La guía de la instancia web enumera sus secciones:

1. New: empezar desde la galería de Blueprints, una URL pública de Blueprint, un Blueprint nuevo, la vista previa de un pull request, un repositorio de GitHub o un .zip importado
2. Playgrounds: cambiar entre Playgrounds recientes y guardados
3. Site Settings: versión de WordPress, versión de PHP, idioma, red y multisitio
4. Blueprint, Database, Files, Logs: ver y editar el Blueprint actual, descargar la base de datos SQLite, explorar archivos y leer errores de PHP
5. Export: descargar un .zip, copiar el enlace de la configuración original o exportar archivos seleccionados a un pull request de GitHub

La versión de PHP y la red se pueden cambiar en un Playground guardado que ya existe. La versión de WordPress, el idioma y el multisitio cambian la propia instalación, así que inician un Playground nuevo. Para temas de bloques, landingPage: /wp-admin/site-editor.php en un Blueprint abre directamente el editor del sitio.

#Método 2: incrustar Playground en tu sitio web

Cada opción de la Query API es un parámetro de URL, así que para una demo incrustada basta un iframe:

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

Los parámetros que más usarás, según la referencia de la Query API:

Instalar un plugin o un tema desde la URL inicia sesión como administrador. El parámetro lazy aplaza la carga hasta que alguien pulsa el botón de ejecutar, así la página con la demo incrustada sigue siendo ligera hasta que el visitante quiere usarla.

#Método 3: usando la API de Playground para integración avanzada

El cliente JavaScript del paquete npm @wp-playground/client te da control total desde tu propia página, desde tests o desde pipelines de 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: configuración Blueprint para entornos reproducibles

Los Blueprints son archivos JSON que configuran una instancia de Playground. La página de inicio de Blueprints cita tres formas de usarlos: pegarlos en el fragmento de la URL, pasarlos a la API de JavaScript o referenciar un archivo con blueprint-url. Los Blueprints no pueden ejecutar JavaScript arbitrario, por eso ejecutar el Blueprint de otra persona no exige confiar en su 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": "Mi sitio de pruebas",
        "blogdescription": "Probando WordPress Playground"
      }
    }
  ]
}

La línea $schema da autocompletado y validación en el editor. Según la documentación del formato de datos, preferredVersions.wp acepta las siete últimas versiones mayores (de 6.3 a 6.9 a fecha de abril de 2026) además de latest, beta y nightly, y features.networking debe seguir activado si el visitante va a instalar plugins o temas.

#Cómo ejecutar WordPress Playground en local con la CLI

El mismo entorno funciona en Node.js. La Playground CLI (@wp-playground/cli) necesita Node.js 20.18 o superior y sustituye al paquete obsoleto wp-now.

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

start detecta si la carpeta es un plugin, un tema o una instalación completa de WordPress, la monta, inicia tu sesión y abre el navegador. El sitio se conserva entre sesiones en ~/.wordpress-playground/sites/<path-hash>/, y --reset te da una instalación limpia. server es el comando avanzado, con control manual de montajes y almacenamiento, pensado para configuraciones propias y CI. Ambos aceptan --wp=, --php= y --blueprint=; la CLI usa PHP 8.3 por defecto.

La CLI también tiene el subcomando php. La guía de PHPUnit ejecuta la batería de tests de un plugin contra un WordPress limpio en cada ejecución, sin base de datos 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

Así, una matriz de versiones de PHP y WordPress se convierte en un bucle sobre dos flags en lugar de un conjunto de imágenes de Docker.

#Para qué sirve WordPress Playground

Cinco flujos de trabajo en los que Playground sustituye algo que antes se hacía por el camino lento.

#Cómo añadir un enlace “prueba este plugin” a una página de ventas

En lugar de “descarga el zip e instálalo en un staging”, tu botón abre una URL de Blueprint con el plugin ya instalado y contenido de demo cargado. El visitante llega a la pantalla de administración correcta con la sesión iniciada. El patrón funciona porque el paso de configuración desaparece para el visitante.

El patrón de URL: https://playground.wordpress.net/?blueprint-url=https://example.com/blueprint.json. Aloja el JSON del Blueprint en cualquier servidor que envíe la cabecera CORS. Dentro de entradas de WordPress, el bloque oficial WordPress Playground incrusta el mismo tipo de demo, con editor de código en vivo si lo necesitas.

#Cómo previsualizar pull requests de plugins en Playground

La guía de vista previa de PR usa la acción WordPress/action-wp-playground-pr-preview@v3. Con plugin-path: . (o theme-path: .) añade un botón Preview a la descripción del pull request. Al pulsarlo se abre Playground con el plugin o tema instalado y activado desde la rama del PR.

La documentación pone dos condiciones. Todo lo que instala Playground debe estar en una URL pública, así que un repositorio privado necesita algo más que la configuración por defecto. Y si el plugin necesita Composer o un build de npm, la acción usa dos workflows: uno de build con permisos de solo lectura y otro de publicación que sube el zip a una prerelease pública ci-artifacts. La guía advierte de no cambiar a pull_request_target para ejecutar código del PR con permisos de escritura.

#WordPress Playground en formaciones y cursos

Cada alumno recibe una instancia aislada de WordPress a partir del mismo Blueprint. El primer día no llegan mensajes de “mi XAMPP no arranca”. La página de limitaciones cita como compatibles Chrome, Firefox, Safari y Edge en escritorio y Safari y Chrome en móvil, lo que cubre Chromebooks y portátiles corporativos bloqueados en los que Docker no está permitido. La contrapartida: el almacenamiento del navegador no es una copia de seguridad, así que lo que los alumnos quieran conservar necesita la exportación a zip al final de la sesión.

#Cómo reproducir un error de un cliente con un Blueprint

Un cliente reporta un error en una versión concreta de WordPress, con un conjunto de plugins y un tema. Le envías una URL de Blueprint con exactamente esa combinación. El cliente confirma la reproducción en su navegador. Tú depuras contra el mismo Blueprint en local con la CLI. El ticket contiene ahora un caso de reproducción determinista en lugar de “en mi máquina funciona”.

#Cómo probar versiones antiguas de WordPress en Playground

Desde agosto de 2026, el panel Site Settings tiene la opción Include older versions. El anuncio en make.wordpress.org describe PHP 5.2.17 compilado a WebAssembly y arranque en el navegador para WordPress 0.7 a 6.2. Playground elige el entorno automáticamente: WordPress 0.7 a 4.9 queda fijado a PHP 5.2, 5.0 a 6.2 a PHP 7.4, y 6.3 o posterior usa el flujo moderno. Para quien mantiene un plugin, un informe de compatibilidad antiguo pasa a ser un ajuste del navegador en lugar de un servidor heredado.

#Cuándo no usar WordPress Playground

• Nada que tenga que entregar correo real o ejecutarse con un cron real
• Pruebas de carga, porque PHP.wasm se ejecuta en un Web Worker dentro de la pestaña del navegador
• Plugins que llaman a exec(), escriben en rutas absolutas o necesitan extensiones de PHP que Playground no incluye
• Llamadas a APIs externas que requieren autenticación de servidor a servidor, porque se aplican las reglas CORS del navegador y la mayoría de APIs no admiten playground.wordpress.net como origen

#Limitaciones y rendimiento de WordPress Playground

La página de limitaciones es breve y conviene leerla antes de poner Playground delante de clientes.

#Cuánto almacenamiento del navegador puede usar WordPress Playground

Playground no publica una cuota fija. El almacenamiento pertenece al navegador, y la documentación advierte de que la falta de espacio, la navegación privada, los cambios de perfil o borrar los datos del sitio pueden eliminar los Playgrounds guardados. Las demos con muchos medios cargan antes y duran más cuando los archivos grandes llegan desde una URL mediante un paso del Blueprint en lugar de subirse durante la sesión.

#Cuánto tarda en cargar WordPress Playground

Las cifras oficiales:

Influyen el tamaño de los plugins, la velocidad de red (los archivos WASM pesan entre 15 y 30 MB), la memoria del dispositivo y el navegador. La documentación señala Chrome y Edge como los más rápidos y Safari como algo más lento.

#Es WordPress Playground más lento que un servidor real

Sí, en trabajo intensivo de CPU. La documentación de arquitectura describe el servidor PHP como tan lento que debe ejecutarse en un Web Worker, porque si no cada petición congelaría la página. El procesado de imágenes, las importaciones masivas y las consultas grandes tardan bastante más que en un hosting PHP nativo, así que no midas el rendimiento de un plugin en Playground.

#Qué particularidades del iframe afectan a las demos de Playground

WordPress se renderiza dentro de un iframe. Los enlaces con target="_top" recargan toda la página en la que estás trabajando, y los popups de JavaScript abiertos desde el iframe pueden no aparecer. Si tu plugin abre ventanas de OAuth o usa window.top, prueba el flujo de la demo a mano.

#Es seguro usar WordPress Playground con datos reales

La documentación oficial describe Playground como algo que se ejecuta por completo en el cliente, sin backend y sin autenticación. El sitio que construyes se queda en tu navegador, así que el riesgo está en el dispositivo.

#Guarda WordPress Playground tus datos

La documentación define tres modos de almacenamiento:

• Autosaved: en el almacenamiento del navegador, solo mientras sea uno de los cinco autoguardados más recientes
• Saved: guardado de forma permanente en el navegador, o en una carpeta local en navegadores compatibles con File System Access API
• Temporary: creado con ?storage=temp o cuando no se puede guardar, se descarta al recargar o cerrar la pestaña

Implicaciones de seguridad:

• Ordenadores compartidos: los Playgrounds autoguardados y guardados se quedan en ese perfil del navegador para el siguiente usuario
• Datos sensibles: no introduzcas credenciales reales ni datos personales de clientes
• Limpieza del navegador: borrar los datos del sitio elimina los Playgrounds guardados
• Exportación: la descarga como .zip exporta archivos, base de datos, plugins, temas y subidas, y New, Import zip la restaura

#Puede WordPress Playground llamar a APIs externas

La red está activada por defecto (networking=yes en la Query API, features.networking: true en los Blueprints). Si la desactivas, wp_safe_remote_get y funciones parecidas fallan de inmediato. Si está activada, las peticiones pasan por el navegador y CORS decide qué funciona. Usa credenciales de prueba para servicios externos en una demo pública, porque la clave de API queda en un navegador que cualquiera puede inspeccionar.

#Qué cambió en WordPress Playground en 2026

El equipo publica las novedades en make.wordpress.org/playground. Cuatro cambios de 2026 afectan a los flujos descritos:

• Nueva interfaz (julio de 2026): el Dock sustituyó a las barras laterales y ventanas modales anteriores. Surgió en la mesa de Playground del Contributor Day de WordCamp Europe 2026 en Cracovia
• Versiones antiguas (agosto de 2026): WordPress 0.7 a 6.2 arrancan en el navegador con emparejamiento automático de PHP
• Terminal (septiembre de 2026): Dev Tools, Terminal ejecuta fragmentos de PHP con WordPress cargado y comandos de WP-CLI sobre el sitio activo; WP-CLI se descarga en el primer uso
• Herramienta Email (septiembre de 2026): los mensajes enviados con wp_mail() se capturan y se muestran con asunto, remitente, destinatario y cuerpo. Un correo capturado no es un correo entregado, y los plugins que envían por su propia conexión SMTP o la API de un proveedor se saltan la captura

La documentación también cubre agentes de IA para programar: una skill de agente wp-playground y un puente WebMCP. Esa parte la tratamos en WordPress Playground y MCP para agentes de IA.

#Errores comunes de Blueprint en WordPress Playground

Algunas trampas que aparecen en cuanto usuarios reales ven Playground.

Desfase de versión de PHP. Tu hosting de producción usa PHP 8.1. La Query API usa PHP 8.5 por defecto. La demo funciona; el cliente instala tu plugin en su sitio y se encuentra un error fatal en una función que la demo nunca ejecutó en 8.1. Fija preferredVersions.php a tu versión mínima soportada, no a la más reciente.

Almacenamiento temporal en incrustaciones. Una incrustación con storage=temp o can-save=no lo pierde todo al recargar. Es lo correcto para una demo desechable y lo incorrecto para un ejercicio de formación. Si la demo necesita archivos, créalos con un paso writeFile en cada ejecución.

CORS en importaciones y APIs. blueprint-url, los zip de import-site y los manifiestos de extensiones de PHP necesitan la cabecera Access-Control-Allow-Origin en el servidor que los aloja. Un Blueprint que funciona desde URLs raw de GitHub puede fallar desde tu propio CDN hasta que añadas la cabecera.

Orden de los pasos. Los atajos como plugins, login, siteOptions y constants se expanden antes del array steps. Si una acción debe ocurrir antes que otra, escribe ambas como pasos explícitos en el orden que necesitas.

Formatos de plugin mezclados. El paso actual installPlugin usa pluginData, con activate dentro de options. Los ejemplos antiguos usan el obsoleto pluginZipFile, y la documentación pide no mezclar ambos. Un slug escrito dentro del recurso (wordpress.org/plugins/woocommerce) también es un error: el recurso necesita un campo slug aparte.

Sintaxis de SQLite frente a MySQL. La capa de traducción cubre casi todo el núcleo, pero el SQL propio de un plugin es responsabilidad tuya. Prueba el Blueprint con el plugin completo y sus rutas de datos reales, no solo con el núcleo.

#Ejemplo de JSON-LD para WordPress Playground

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "WordPress Playground: El futuro de las pruebas y demos",
  "description": "Aprende a usar WordPress Playground para ejecutar WP en el navegador vía WebAssembly. Guía práctica para pruebas y demos en 2026.",
  "author": {
    "@type": "Organization",
    "name": "WPPoland"
  },
  "datePublished": "2026-01-29",
  "dateModified": "2026-10-14",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://wppoland.com/es/wordpress-playground-guide-2026/"
  }
}

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "Cómo usar WordPress Playground para pruebas y desarrollo",
  "description": "Guía paso a paso para ejecutar WordPress en el navegador con WebAssembly",
  "totalTime": "PT15M",
  "supply": [
    "Navegador web moderno",
    "Conexión a internet"
  ],
  "tool": [
    {
      "@type": "HowToTool",
      "name": "Navegador web"
    }
  ],
  "step": [
    {
      "@type": "HowToStep",
      "position": 1,
      "name": "Abre WordPress Playground",
      "text": "Ve a playground.wordpress.net para abrir la instancia oficial de WordPress Playground.",
      "url": "https://playground.wordpress.net"
    },
    {
      "@type": "HowToStep",
      "position": 2,
      "name": "Configura el entorno",
      "text": "Abre Site Settings en el Dock y elige la versión de WordPress, la versión de PHP, el idioma y la red."
    },
    {
      "@type": "HowToStep",
      "position": 3,
      "name": "Espera a la instancia",
      "text": "Un WordPress limpio sin plugins suele cargar en 5 a 10 segundos; los plugins grandes como WooCommerce tardan de 30 a 60 segundos."
    },
    {
      "@type": "HowToStep",
      "position": 4,
      "name": "Empieza a probar",
      "text": "Entra en el escritorio de WordPress, instala plugins, crea contenido y prueba funciones en el entorno aislado."
    },
    {
      "@type": "HowToStep",
      "position": 5,
      "name": "Guarda o exporta tu trabajo",
      "text": "Usa Export para descargar el sitio como zip, o Store permanently para conservarlo en el almacenamiento del navegador."
    }
  ]
}

Un Blueprint de Playground es la forma más rápida de enseñar un plugin a un cliente sin pedirle servidor, base de datos ni credenciales. Preparamos demos así como parte del desarrollo de plugins para WordPress.