Cómo probar la compatibilidad PHP de WordPress en diferentes versiones de plugin

Probar la compatibilidad PHP de WordPress significa verificar si tu plugin se comporta correctamente en cada combinación de versiones de PHP y WordPress que soportas. Con un sandbox de WordPress en wp.run, puedes lanzar instalaciones de prueba limpias, como PHP 8.4 con WordPress 6.9, y luego repetir la misma prueba de humo sin servidores locales ni riesgo en producción.

Puedes empezar la primera comprobación ahora mismo: pulsa Lanzar WordPress en la parte superior de esta página, elige las versiones de PHP y WordPress que quieres probar, y ejecuta el plugin dentro de un sitio de WordPress desechable con acceso real a wp-admin.

Por qué la compatibilidad PHP de WordPress necesita una matriz

Un plugin puede pasar en un stack y fallar en otro. Los cambios en PHP pueden dejar al descubierto sintaxis obsoleta, un tipado más estricto, funciones eliminadas o advertencias que no aparecían en un entorno de ejecución anterior. Los cambios en WordPress pueden afectar el comportamiento del editor, los hooks, los endpoints REST, las pantallas de administración y el JavaScript incluido.

Por eso una sola comprobación de “en mi máquina funciona” no es suficiente. Las pruebas de compatibilidad de plugins deberían cubrir las combinaciones que realmente usan tus usuarios:

El manual oficial de WordPress Core mantiene una tabla de compatibilidad PHP para el propio WordPress. Trátala como tu base para el núcleo. Tu trabajo es probar tu plugin sobre esos stacks, porque la compatibilidad del núcleo de WordPress no garantiza que cada plugin o tema se comporte correctamente.

Construye una matriz pequeña de PHP x versiones de WordPress

Empieza con la matriz más pequeña que responda a una pregunta real de lanzamiento. Para la mayoría de los equipos de plugins, eso significa tres filas antes de cada lanzamiento importante:

1. El stack soportado más antiguo. Esto detecta el uso de sintaxis o de la API que rompe a los usuarios que todavía no han actualizado.
2. El stack recomendado actual. Es el stack que esperas que usen la mayoría de las pruebas y demostraciones nuevas.
3. El stack más nuevo. Esto detecta cambios futuros de PHP y WordPress antes de que los usuarios los reporten.

En wp.run, el modal de lanzamiento admite elegir explícitamente la versión de WordPress y de PHP. También puedes usar URLs de lanzamiento cuando quieras lanzar un sandbox de WordPress desde un enlace de prueba repetible, por ejemplo:

https://wp.run/new?php=8.4&wp=6.9

Para los presets soportados, añade el parámetro de plugin para que el entorno sea reproducible:

https://wp.run/new?plugin=woocommerce&php=8.4&wp=6.9

Para tus propias compilaciones de plugin, sube el ZIP dentro de wp-admin y anota la compilación exacta en tus notas. Cada fila de tu matriz debería tener un stack, una versión del plugin, las comprobaciones ejecutadas y un resultado.

Cómo probar la compatibilidad del plugin con PHP 8.4 en wp.run

Usa este flujo de trabajo cuando necesites probar el comportamiento del plugin en PHP 8.4 sin reconstruir un entorno local.

1. Lanza el stack objetivo. Pulsa Lanzar WordPress, elige PHP 8.4 y la versión de WordPress que quieres validar, y crea el sandbox. wp.run aprovisiona una instalación temporal de WordPress con credenciales de administrador y una URL *.wprun.site.
2. Confirma el entorno. Abre wp-admin y revisa Herramientas → Salud del sitio → Información para confirmar las versiones de PHP y WordPress antes de empezar a probar.
3. Instala o activa el plugin. Carga un preset soportado desde un parámetro de URL de lanzamiento, o sube el ZIP de tu plugin en wp-admin. Anota la compilación exacta del plugin en tu registro de pruebas.
4. Ejecuta la comprobación de activación. Activa el plugin y vigila si aparecen errores fatales, avisos de administración, dependencias faltantes, bucles de redirección o fallos del asistente de configuración.
5. Ejercita la función principal. Ejecuta el flujo de trabajo real más pequeño para el que existe el plugin: crear un formulario, completar un pago, añadir un bloque, generar un mapa del sitio, importar contenido o disparar la tarea programada.
6. Revisa las superficies de administración y front-end. Abre el editor de bloques, los ajustes del plugin, la salida de la página pública, los endpoints REST si aplica, y la consola del navegador.
7. Repite en el siguiente stack. Lanza la siguiente versión de PHP o WordPress y ejecuta la misma lista de verificación. Cambia una dimensión a la vez cuando estés aislando un fallo.

Esto te da una señal de compatibilidad manual con rapidez. No reemplaza las pruebas unitarias, las pruebas de integración ni el análisis estático, pero detecta los fallos a nivel de producto que los usuarios realmente ven en wp-admin y en el front-end.

Añade análisis estático, pero no te quedes solo con eso

Los analizadores de compatibilidad estáticos son útiles porque detectan patrones de código antes de la ejecución. La lección de Learn WordPress sobre cómo probar productos para la compatibilidad de versiones de PHP cubre dos enfoques habituales: la prueba manual en un entorno PHP objetivo y el análisis con las reglas de PHPCompatibility a través de PHP_CodeSniffer.

Usa ambas señales juntas:

• Primero, el análisis estático. Encuentra el uso evidente de funciones eliminadas, firmas obsoletas y sintaxis específica de una versión de PHP.
• Segundo, la prueba en sandbox. Confirma que el plugin arranca, dibuja la interfaz, escribe las opciones esperadas y completa su flujo de trabajo real en el stack objetivo.
• Por último, la nota de regresión. Registra qué falló, las versiones exactas de PHP, WordPress y el plugin, y si el problema es una advertencia, un error fatal, una interfaz rota o un problema de datos.

Las herramientas estáticas te pueden decir que una línea de código quizá sea incompatible. Un sandbox te dice si el plugin sigue funcionando como producto de WordPress.

Qué verificar durante las pruebas de versiones de WP

Las pruebas de versiones de WP no consisten solo en si el plugin se activa. Los errores más costosos suelen aparecer después de la activación, cuando un usuario edita contenido, configura ajustes o actualiza desde una versión anterior.

Revisa estas áreas en cada fila de la matriz:

• Activación y desactivación. El plugin debe activarse limpiamente, desactivarse limpiamente y no dejar el sitio en un estado roto.
• Ruta de actualización. Instala primero la versión anterior del plugin, crea datos de muestra, actualiza a la nueva versión y confirma que las migraciones se ejecutan.
• Pantallas de administración y del editor. Abre cada menú que añade el plugin. Si toca bloques, shortcodes, embebidos, tipos de contenido personalizados o meta boxes, prueba el editor en cada versión de WordPress.
• Salida del front-end. Confirma que las plantillas, los shortcodes, los recursos, las redirecciones, los flujos de pago, los formularios o los widgets se renderizan como se espera.
• REST, AJAX y tareas programadas. Envía las solicitudes relevantes a los endpoints e inspecciona el comportamiento que depende de cron cuando el plugin se apoya en trabajo en segundo plano.
• Higiene de desinstalación. Desactiva y elimina el plugin en un sandbox desechable para verificar si su limpieza es aceptable.

Mantén esta lista de verificación constante. Si cada persona que prueba inventa un camino distinto por wp-admin, tu matriz se vuelve más difícil de comparar.

Una matriz práctica para el lanzamiento de un plugin

Aquí tienes una matriz compacta para un equipo de plugin que prepara un lanzamiento:

Usa la matriz como una puerta de lanzamiento, no como una ocurrencia tardía de documentación. Si una fila falla, copia los pasos exactos, incluye la salida de depuración o capturas de pantalla, y adjunta la URL temporal del sandbox mientras siga viva.

Fallos de compatibilidad comunes a vigilar

La mayoría de los fallos de compatibilidad siguen unos pocos patrones:

• Error fatal en la activación. Suele deberse a funciones de PHP eliminadas, clases faltantes, problemas de autocarga de dependencias o código que se ejecuta demasiado pronto.
• Advertencias que se vuelven ruidosas en PHP más nuevo. Las propiedades dinámicas, los argumentos anulables, las suposiciones de tipado estricto y las firmas obsoletas pueden inundar los registros incluso cuando la página parece funcionar.
• Rotura del editor. Un plugin puede funcionar en el front-end mientras su integración con el editor de bloques falla en una versión más nueva de WordPress.
• Fallos de AJAX, REST o actualización. El manejo de nonces, el registro de rutas, las opciones guardadas o las tablas personalizadas pueden dejar al descubierto suposiciones débiles.
• Conflictos de dependencias. Dos plugins pueden incluir versiones incompatibles de una misma biblioteca PHP o paquete JavaScript.

Cuando una fila falla, no saltes directamente a “PHP es incompatible”. Vuelve a ejecutar el mismo plugin en la misma versión de WordPress con la versión anterior de PHP, y luego cambia WordPress manteniendo PHP fijo. Aislar una dimensión a la vez es como encuentras la verdadera línea de fallo.

Dónde encaja el sandbox

Un sandbox desechable de WordPress es ideal para pruebas de humo de compatibilidad, comprobaciones de candidatos a lanzamiento, reproducción de casos de soporte, enlaces de demostración y QA rápido de plugins. Usa staging o un entorno local cuando la prueba dependa de una base de datos con forma de producción, archivos persistentes, configuración de servidor personalizada o depuración de larga duración.

El flujo de trabajo práctico va por capas: analiza el código, ejecuta pruebas automatizadas, usa sandboxes de wp.run para comprobaciones de compatibilidad de PHP y WordPress a nivel de producto, y luego pasa a staging solo cuando necesites verificar un sitio concreto.

Preguntas frecuentes

¿Qué es la compatibilidad PHP de WordPress?

La compatibilidad PHP de WordPress es la capacidad del núcleo de WordPress, de un plugin o de un tema para ejecutarse correctamente en una versión específica de PHP. En el caso de los plugins, la compatibilidad debe probarse en un entorno real de WordPress, porque el plugin depende de los hooks de WordPress, las pantallas de administración, el comportamiento de la base de datos y otro código activo.

¿Cómo pruebo un plugin en PHP 8.4?

Lanza un sandbox de wp.run con PHP 8.4, confirma la versión de PHP en Salud del sitio, instala el plugin y ejecuta las comprobaciones de activación, administración, editor, front-end, REST/AJAX y desinstalación. Repite la misma lista de verificación en la versión anterior de PHP si necesitas aislar un fallo específico de PHP.

¿La compatibilidad del núcleo de WordPress significa que mi plugin también es compatible?

No. El núcleo de WordPress puede ser compatible con una versión de PHP mientras un plugin sigue fallando por su propio código, sus dependencias, su interfaz de administración o su lógica de actualización. Usa la tabla de compatibilidad del núcleo de WordPress como base, y luego prueba el plugin por separado.

¿Cuántas combinaciones de PHP y WordPress debería probar?

Prueba el stack más antiguo que soportas, el stack predeterminado actual que esperas que usen los usuarios y el stack más nuevo para el que te quieres preparar. Añade filas para rutas de actualización, dependencias o entornos reportados por clientes cuando sean relevantes.

Haz que las pruebas de compatibilidad sean repetibles

El mejor proceso de compatibilidad es aburrido: una matriz, una lista de verificación, un registro de resultados, repetido en cada candidato a lanzamiento. wp.run te da la capa de entorno rápida para ese proceso: WordPress limpio, versiones de PHP y WordPress seleccionables, acceso de administrador generado y sandboxes temporales que puedes descartar cuando termine cada fila.