WordPress Playground: prueba WordPress de forma segura directamente en el navegador

Cómo clasificar correctamente WordPress Playground

WordPress Playground lanza una instancia aislada de WordPress directamente en el navegador. La instalación en ejecución está separada de un sitio web ya existente: los cambios en las entradas, la configuración, los temas o los complementos no acceden ni al alojamiento ni a la base de datos del sitio en producción. Para ello, los componentes necesarios se cargan en el navegador y se ejecutan allí.

Esto resulta útil para realizar una primera comprobación del plugin antes de su instalación, para explorar un tema de bloques o para ofrecer una demostración clara durante las reuniones con los clientes y el equipo editorial. Puedes utilizar un entorno inicial limpio, activar extensiones y comprobar si la interfaz de usuario y una función principal claramente definida funcionan de forma comprensible. Especialmente en el caso de los mensajes de conflicto, una instancia vacía ayuda a descartar, en un primer momento, los problemas heredados de una página ya existente.

Sin embargo, Playground no es un entorno de prueba convencional. En teoría, un sistema de prueba reproduce lo más fielmente posible la futura configuración del servidor y los procesos operativos; Playground, por el contrario, sirve principalmente para realizar pruebas rápidas en un entorno de navegador independiente. Por lo tanto, para poder hacer afirmaciones sobre el comportamiento de una configuración concreta de servidor, base de datos o alojamiento, es necesario realizar además una prueba en un entorno de destino lo más similar posible.

Así es como funciona WordPress directamente en el navegador

WordPress Playground no se basa en una pila clásica compuesta por un servidor web, PHP instalado y un servidor de base de datos independiente. WordPress y el entorno de ejecución de PHP se transfieren al navegador; allí, PHP se ejecuta sobre la base de WebAssembly. De este modo, el navegador proporciona el entorno de ejecución, mientras que la instalación productiva de WordPress que está abierta no se ve afectada técnicamente.

Para el almacenamiento de datos, Playground apuesta por una integración con SQLite en lugar de un servidor MySQL independiente. Esto es suficiente para muchas pruebas de funcionalidad, por ejemplo, al guardar ajustes, crear contenidos o explorar la interfaz de un plugin. Sin embargo, supone un cambio en la base técnica respecto a muchos servicios de alojamiento de WordPress que utilizan MySQL o MariaDB.

Por lo tanto, un resultado positivo solo responde a la pregunta concreta que se ha comprobado en ese entorno de navegador. Se trata de un primer resultado valioso, pero no constituye una prueba general de compatibilidad. Especialmente en el caso de las extensiones que realizan consultas a bases de datos propias o integran servicios cercanos al servidor, debería realizarse a continuación una prueba en un entorno que se corresponda con el alojamiento de destino.

• Las consultas SQL pueden comportarse de forma diferente en SQLite que en MySQL o MariaDB; por lo tanto, las funciones de los complementos específicas de cada base de datos requieren una prueba adicional.
• Las extensiones especiales de PHP, los módulos de servidor o los permisos de los archivos del futuro alojamiento web no forman parte automáticamente del entorno del navegador.
• Los resultados relativos al envío de correos electrónicos, los webhooks externos, los servicios de pago y otras integraciones de servidor similares no pueden interpretarse como una prueba de funcionamiento en producción.

Esta limitación no es un inconveniente, sino que determina un uso adecuado: Playground reduce el esfuerzo que suponen las pruebas iniciales. Para Compatibilidad relacionada con el alojamiento web Complementa la prueba en el navegador con un entorno de staging o un entorno de servidor local que cuente con la base de datos adecuada, la configuración de PHP y los servicios que realmente se necesitan.

Instancia web, almacenamiento y selección de versión

La instancia web pública es la forma más rápida de empezar: la abres en el navegador de escritorio que estés utilizando y, si es necesario, configuras la versión de WordPress, la versión de PHP, el idioma, las opciones de red o la función multisitio. De este modo, por ejemplo, se puede comprobar de forma específica si un complemento funciona con una combinación concreta de WordPress y PHP. Las opciones de configuración disponibles hacen de Playground algo más que una simple instalación de demostración fija.

Para búsquedas breves, puede bastar con guardar los datos en el navegador. Sin embargo, si se trata de un trabajo continuo, no es una estrategia de copia de seguridad fiable: los guardados automáticos son limitados, y la limpieza del navegador, las ventanas privadas, un perfil diferente o la falta de espacio de almacenamiento pueden eliminar los datos. Un Exportación en formato ZIP Es la forma más práctica de guardar un entorno de pruebas fuera del navegador y volver a importarlo más adelante.

Anota las versiones concretas de cada prueba repetible, en lugar de limitarte a utilizar „última versión“. Anota, como mínimo, la versión de WordPress y de PHP, así como la versión y el origen del plugin o tema probado. Solo así se podrá distinguir más adelante si un resultado se debe a un cambio en la extensión, en el núcleo de WordPress o en el entorno de ejecución.

Los términos relacionados con Playground también deben mantenerse claramente diferenciados. Un «release» hace referencia a una versión publicada; las «versiones de paquete» se refieren al paquete en cuestión. La rama de desarrollo trunk Por el contrario, se trata de una versión en desarrollo y no sustituye a una versión publicada y documentada. Por lo tanto, para el control de calidad y las demostraciones, debes utilizar versiones concretamente definidas y disponibles en la prueba correspondiente, y documentarlas junto con el objetivo de la prueba.

Probar plugins y temas de forma segura

Para realizar una prueba rápida, inicia una nueva instancia web y, si la prueba lo requiere, selecciona la versión documentada de WordPress y PHP. Instala un plugin o un tema únicamente desde una fuente fiable, actívalo y comprueba primero si aparecen los menús, ajustes o bloques esperados. Una instancia inicial limpia evita que los plugins, contenidos o ajustes existentes distorsionen los resultados.

A continuación, comprueba una función básica claramente definida: por ejemplo, si se puede configurar un bloque de formulario, si se crea un tipo de entrada propio o si aparece una opción de tema. Anota las versiones utilizadas, la fuente de instalación, los pasos concretos y el resultado. De este modo, lo que era una mera exploración se convierte en una Prueba inicial, que luego se puede reproducir en otro entorno. Playground también resulta especialmente adecuado para probar plugins sin riesgo alguno para un sitio web en producción.

• Lo importante es que la instalación y la activación se realicen correctamente, que aparezca la interfaz de usuario y que la función principal seleccionada funcione en la nueva instancia.
• Quedan por aclarar: el comportamiento con tráfico real, el envío de correos electrónicos, el almacenamiento en caché, las API externas, los proveedores de pago y las particularidades del alojamiento posterior.
• En el caso de los temas de bloques, comprueba además el editor del sitio, las plantillas, los fragmentos de plantilla y los estilos globales. Los cambios se limitan a la instancia de prueba.

Por lo tanto, un resultado positivo no significa que la extensión sea adecuada para cualquier página de producción. Playground no dispone de una dirección a la que se pueda acceder de forma permanente; además, la ejecución basada en el navegador y la falta de servicios de servidor pueden limitar las funciones de terceros. Para decisiones delicadas, complementa la prueba en el navegador con una prueba en un entorno que sea técnicamente similar al futuro sitio web.

Plantillas para entornos de prueba reproducibles

A Plan de acción Es una descripción basada en JSON de cómo debe crear Playground una instancia. En lugar de configurar manualmente una demo cada vez, puedes, por ejemplo, establecer versiones fijas de WordPress y PHP, plugins, temas, opciones, un paso de registro y contenidos de prueba. Esto crea condiciones repetibles para cursos de formación, descripciones de errores o un proceso de pruebas definido. Los blueprints se pueden utilizar en la instancia web, así como a través de JavaScript y Node.js.

El archivo automatiza la configuración, pero no sustituye a una comprobación de los recursos integrados. Anota la fuente y la versión de los plugins, los temas, las importaciones WXR y los archivos ZIP externos. No utilices datos de acceso reales, URL de producción ni contenidos confidenciales. Especialmente al importar contenido, debes decidir deliberadamente si se deben cargar los archivos multimedia adjuntos y reescribir las URL, en lugar de copiar sin revisar los datos de un sitio web en producción.

Los pasos runSql y wp-cli tienen un alcance mucho mayor que una simple instalación: permiten modificar datos o ejecutar comandos. Para las demostraciones, este artículo recomienda incluir únicamente pasos verificables y no destructivos; las consultas de eliminación o los cambios de esquema no cumplirían el objetivo de ofrecer un ejemplo claramente comprensible. Lo mismo se aplica a WP-CLI: el hecho de que un paso esté disponible no garantiza que cada comando sea compatible en el contexto del navegador.

Comparar la CLI, el navegador y el entorno de pruebas

En cuanto empieces a trabajar con los archivos de un plugin o tema propio, la interfaz del navegador ya no es necesariamente la opción más adecuada. La CLI de Playground puede iniciar una instancia local de WordPress a través del terminal e integrar automáticamente una carpeta de plugins local. Ejecuta el siguiente comando desde el directorio raíz del proyecto de plugin en cuestión; esto iniciará una instancia de desarrollo local, no un servidor de producción accesible públicamente.

npx @wp-playground/cli server --auto-mount

La guía de inicio rápido documentada no incluye una versión concreta del paquete. Esto permite npx utilizar otra versión disponible de la CLI en ejecuciones posteriores. Esto resulta práctico para una exploración local espontánea; sin embargo, para procesos de desarrollo o pruebas reproducibles, deberías especificar y documentar en el proyecto la versión del paquete que se utiliza realmente, en lugar de depender constantemente de una versión variable.

Con Montaje automático La CLI carga el complemento desde su carpeta de proyecto local en la instancia de Playground iniciada. De este modo, los cambios en el código fuente local pueden comprobarse inmediatamente en este entorno de desarrollo. Los archivos o datos adicionales del sitio web que deban conservarse tras un reinicio dependen del proceso de CLI, montaje y almacenamiento seleccionado, y deben especificarse expresamente para cada proyecto.

La elección depende, por tanto, de la tarea: para una demostración rápida o una interfaz reproducible, suele bastar con el navegador; para trabajar con el código fuente, se necesita una instancia de CLI con la carpeta del proyecto integrada de forma deliberada. Para una prueba de aceptación con servicios cercanos al servidor, comportamiento de la base de datos y vista previa permanente, necesitas un Puesta en escena o un entorno de destino similar. En el artículo se explican otros criterios para entornos de prueba y de producción cercanos a la producción. Elegir un entorno de prueba y una infraestructura de servidores para WordPress.

Garantizar la seguridad de los bancos de pruebas y documentarlos de forma trazable

Una prueba útil en el entorno de pruebas comienza con un objetivo claro: por ejemplo, reproducir un error, comprobar la interfaz de usuario de un plugin o analizar la presentación de un tema de bloques. Para ello, anota la versión de WordPress y de PHP, el nombre y la versión exacta del tema o del plugin, la fuente de donde lo has obtenido, así como los pasos que has seguido. Solo con estos datos, el informe resultará comprensible para otras personas y se podrá reproducir más adelante.

Anota además el resultado observado de la forma más concreta posible. En lugar de „el plugin no funciona“, es más útil indicar, por ejemplo, si la activación falla, si falta un bloque concreto en el editor o si no se guarda una configuración. Añade si la prueba se ha realizado en una instancia nueva y qué otros plugins estaban activos. De este modo, una breve prueba se convierte en una Descripción reproducible del error.

Las copias de seguridad automáticas del navegador facilitan retomar un trabajo, pero no constituyen un archivo fiable. Playground solo conserva un número limitado de las últimas instancias guardadas automáticamente; las ventanas privadas del navegador, el borrado de los datos del navegador, un cambio de perfil o la falta de espacio de almacenamiento pueden eliminar estos datos. Por lo tanto, exporta una versión importante como archivo ZIP y guárdala junto con tus notas de prueba.

La exportación en formato ZIP es portátil y separa el entorno de prueba del navegador correspondiente. Para demostraciones recurrentes, un «blueprint» complementa la exportación de forma útil: describe la configuración con versiones específicas, pasos de instalación y ajustes. La exportación guarda el estado alcanzado, mientras que el «blueprint» explica cómo se debe configurar una nueva instancia de forma específica.

Un ejemplo: compruebas si un tema de bloques muestra una plantilla de forma incorrecta. En primer lugar, documenta las versiones de WordPress y PHP utilizadas, el archivo del tema junto con su versión y los pasos seguidos en el editor del sitio. A continuación, exporta el estado actual como archivo ZIP. Para repetir el proceso, inicia una nueva instancia, instala únicamente el tema documentado y realiza los mismos cambios.

No utilices datos de acceso operativos, extractos de bases de datos ni contenidos confidenciales. Para la reproducción, utiliza páginas de ejemplo neutras, imágenes de prueba y cuentas ficticias. Si es necesario comprobar un error con contenidos realistas, elimina los datos personales y la información interna antes de la importación. Una documentación precisa no sustituye a una selección cuidadosa de los datos que pueden introducirse en un entorno de prueba.

Detectar errores típicos en la instancia del navegador

Si una instancia que acabas de configurar parece haberse restablecido, distingue primero entre la actualización dentro de WordPress y una Actualizar el navegador. Al realizar una recarga, se reinicia la aplicación Playground. En concreto, las instancias temporales con ?storage=temp se pierden en el proceso. Por eso, para realizar una comprobación normal en WordPress, actualiza la página de WordPress en cuestión, no toda la pestaña del navegador sin comprobarla primero.

Un comportamiento anómalo en el backend tampoco tiene por qué ser necesariamente un error del plugin probado. Playground muestra WordPress en un iframe. Un enlace con target="_top" Por eso, es posible que se vuelva a cargar la página circundante; además, las ventanas emergentes de JavaScript del iframe no siempre se ven. Si observas estos síntomas, comprueba el tipo de enlace y, si es necesario, repite el paso en un entorno de prueba simplificado.

Además, las funciones disponibles dependen del navegador y de la plataforma. Para guardar archivos directamente en un directorio local, Playground necesita la API de acceso al sistema de archivos. La documentación de la instancia web menciona este requisito; la documentación de errores señala que Chrome y Edge ofrecen una compatibilidad especialmente amplia con los directorios locales. Si tu navegador no dispone de esta función, la opción más adecuada es una exportación en formato ZIP u otra forma de almacenamiento compatible.

En el caso de los procesos automatizados, hay otra limitación: WP-CLI está disponible en Playground, pero la documentación no ofrece una lista completa de los comandos compatibles. Por lo tanto, no consideres que el hecho de que un comando concreto se ejecute correctamente sea prueba de una compatibilidad total Compatibilidad con WP-CLI. Comprueba los comandos que realmente se necesitan con la versión de Playground prevista y, en el caso de los procesos relacionados con el servidor, realiza una prueba en el entorno de destino.

Las mediciones o las diferencias percibidas en la instancia del navegador no constituyen una indicación fiable sobre los tiempos de respuesta, los encabezados de caché o el comportamiento bajo carga de un sitio web en producción. Playground no utiliza el mismo servidor web, la misma base de datos ni la misma cadena de red que tu alojamiento. Para comprender mejor cómo funcionan las cachés reales del navegador y del servidor, te recomendamos este artículo: Cómo configurar correctamente el almacenamiento en caché del navegador en WordPress; no obstante, comprueba los resultados cercanos a la producción en un entorno de pruebas o de alojamiento adecuado.

Cuándo Playground es la opción adecuada

WordPress Playground Es ideal si necesitas rápidamente una instancia aislada de WordPress para una cuestión concreta. Esto se aplica, por ejemplo, a la prueba inicial de un plugin, a la exploración de un tema de bloques, a los cambios en las plantillas y los estilos globales o a una demostración formativa. La instancia permanece separada del alojamiento y de los datos en producción; esto permite analizar los flujos de trabajo sin alterar un sitio web en producción.

Para casos de asistencia técnica recurrentes y demostraciones, Playground resulta especialmente útil cuando un «blueprint» especifica los componentes y las versiones necesarios. De este modo, otra persona puede reproducir el mismo punto de partida, en lugar de tener que recrear una instalación descrita de forma incompleta. Esto mejora la comparabilidad de un error, pero no sustituye a la comprobación de los servicios que se encuentran fuera de la instancia del navegador.

• Elige Browser-Playground para pruebas funcionales breves, experimentos con el editor y demostraciones sin datos de producción.
• Elige la CLI de Playground si los archivos locales del proyecto van a integrarse durante un periodo prolongado y se van a seguir utilizando siguiendo un proceso de almacenamiento documentado.
• Elige un entorno de pruebas o un servidor similar al de alojamiento si la infraestructura concreta forma parte del problema.

Por el contrario, un entorno permanente de vista previa o de aceptación no es la función principal de Playground. Su entorno de navegador y WebAssembly difiere de una pila de alojamiento convencional; además, Playground utiliza una integración con SQLite en lugar de un servidor MySQL independiente. Por lo tanto, para aquellas funciones cuyo resultado dependa de una configuración de servidor o una base de datos concretas, la prueba en el navegador no basta como única prueba.

Una prueba aislada en el navegador tampoco es suficiente para las pruebas de carga, las aceptaciones relacionadas con la seguridad y las autorizaciones previas al alojamiento. Las consultas que dependen de bases de datos, las extensiones PHP, el almacenamiento en caché y la configuración del servidor pueden comportarse de forma diferente en el sistema definitivo. Esto afecta igualmente a los procesos que requieren un servicio concreto de correo electrónico, webhook o de terceros del entorno de destino.

Por lo tanto, la decisión depende de la cuestión pendiente, no de quién sea el ganador en general. Si se quiere detectar una ampliación sin riesgo o reproducir un error de forma mínima, la instancia de prueba aislada conveniente. Sin embargo, si se debe evaluar un proceso en el entorno de alojamiento previsto, con su base de datos o con los servicios conectados, tras la prueba en el entorno de pruebas se lleva a cabo una comprobación complementaria en condiciones de funcionamiento lo más similares posible.