Actualizar un sitio, plugin o tema de WordPress a una nueva versión de PHP es una tarea que se repite con regularidad. Pero, ¿cómo hacerlo de la forma más eficiente posible? ¿Cómo sabes que no pasarás nada por alto? ¿Existe una hoja de ruta para ello?
En este artículo, abordaremos estas preguntas (y otras) y veremos qué implica una transición sin problemas a PHP 8.x para tu sitio, plugin o tema de WordPress, incluida una hoja de ruta.
Lo haremos basándonos en una entrevista que hicimos a la experta en PHP Juliette Reinders Folmer. Dedica la mayor parte de su vida diaria a la programación y todo lo que la rodea, centrándose principalmente en proyectos de código abierto, incluido WordPress.
¿Tú también estás preparado para hacer el cambio sin problemas? ¿Tienes curiosidad por conocer nuestro plan paso a paso? Entonces, ¡manos a la obra!
PHP 8.x – Qué ha Cambiado
Para tener una visión general de los cambios, te recomendamos los siguientes artículos:
- Notas de la versión para PHP PHP 8.0 y PHP 8.1
- Guía de migración para PHP 8.0 y PHP 8.1
- WordPress y PHP 8.0 y estado actual
- Novedades en PHP 8.0 y PHP 8.1
- Novedades en PHP 8.2 y guía de migración a PHP 8.2.
Después de leer estos artículos, estarás completamente al día de lo que ha cambiado en PHP 8.x y de lo que necesitas hacer para que tus proyectos PHP funcionen sin problemas.
Si no estás seguro de cuál es la mejor manera de empezar, no hay problema. En la conversación con Juliette, hablaremos de esto en detalle, y en este artículo te explicaremos de la forma más completa posible cómo puedes cambiar a PHP 8.x.
También te explicaremos en recuadros informativos cómo realizar diversas operaciones en MyKinsta, nuestro propio panel de control para todos tus sitios, aplicaciones y bases de datos de WordPress.
Cambiar a PHP 8.x: Cómo Empezar
Cambiar a PHP 8.x parece sencillo, y técnicamente lo es. Muchos alojamientos te permiten especificar qué versión de PHP quieres utilizar para tu sitio web en el panel de control. En Kinsta, cambiar la versión de PHP se puede hacer con un solo clic en el panel de control MyKinsta.
Pero antes de hacerlo, debes asegurarte de algunas cosas. Dependiendo de tu nivel de conocimientos y experiencia, te recomendamos lo siguiente:
- Si has construido tu propio sitio WordPress con temas y plugins estándar, sin tener muchos conocimientos de PHP, contrata a un desarrollador o a una agencia para que investigue si tu sitio es apto para funcionar con PHP 8.x. ¿Estás buscando a un proveedor externo que pueda ayudarte con esto? Entonces consulta nuestra página Socios, en la que figuran varias empresas de confianza que pueden ayudarte.
- Si tu sitio WordPress fue construido por un proveedor externo, un desarrollador o una agencia, ponte en contacto con ellos para preguntarles si tu sitio puede funcionar con PHP 8.x.
- Si has construido tu sitio WordPress -con tu propio tema personalizado, por ejemplo, o plugins desarrollados por ti mismo- tenemos una hoja de ruta para ti a continuación.
Si tu sitio pertenece a una de las dos primeras categorías, te invitamos a que leas el resto del artículo, pero no te recomendamos que empieces a comprobar la compatibilidad de tu sitio con PHP 8 por ti mismo. Déjaselo a los profesionales.
Elijas lo que elijas, te aconsejamos que no te limites a cambiar tu sitio activo a PHP 8 y «ver si funciona» ¿Tienes curiosidad por saber qué aspecto tendrá tu sitio y no puedes esperar a verlo funcionando con PHP 8? Entonces empieza a hacer pruebas en un entorno staging. Un buen host te permitirá configurar fácilmente un entorno staging.
En el entorno staging, puedes activar PHP 8.x y ver si esta actualización funciona bien con tu sitio. También es posible trabajar con una copia local de tu sitio. Con nuestra herramienta gratuita de desarrollo DevKinsta, puedes importar fácilmente tu sitio desde el panel de MyKinsta, tras lo cual puedes cambiar la versión PHP a 8.0 u 8.1.
Si no ves ningún problema en el entorno de prueba, no significa necesariamente que no haya ningún problema. La hoja de ruta que aparece a continuación te explicará por qué.
Pruebas de Compatibilidad con PHP 8.x: La Hoja de Ruta
Pruebas: la palabra clave de un buen software. Incluso para los sitios web de WordPress y sus componentes, como temas, plugins y el núcleo de WordPress, las pruebas son el medio para garantizar que no ocurran cosas que no quieres que ocurran.
Un proyecto de desarrollo de software consiste en gran medida en las pruebas. En este artículo, examinamos específicamente las pruebas que pueden ayudarte a que la transición a PHP 8.x se realice sin problemas. En nuestro artículo sobre Herramientas DevOps, encontrarás una sección con una colección de herramientas que puedes utilizar.
En esta entrada de blog tratamos los siguientes tipos de pruebas:
Veamos con más detalle los distintos tipos de pruebas que podemos realizar.
Análisis estático (o pruebas estáticas)
El primer paso que puedes dar como desarrollador PHP es realizar un análisis estático de tu código con diversas herramientas. El análisis estático es el proceso de analizar el software sin ejecutar el código. Con el análisis estático es posible detectar errores, detectar problemas de compatibilidad con PHP 8.x, aplicar normas de codificación (por ejemplo, las Normas de Codificación de WordPress), e incluso es posible modificar y limpiar el código.
Herramientas para el análisis estático
Puedes realizar un análisis estático con varias herramientas, como:
En el momento de escribir esto, no todas las pruebas de PHP 8.1 están soportadas en la última versión de PHPCompatibility. Las pruebas de PHP 8.1 pueden estar en la versión de desarrollo, así que asegúrate de utilizarlas (por ahora) cuando uses PHPCompatibility para analizar tu proyecto y ver qué errores/recomendaciones hay.
Las pruebas de PHP 8.1 se publicarán pronto en una nueva versión principal . Si quieres estar al día al respecto, y tienes una cuenta de GitHub, abre el repositorio de GitHub de PHPCompatibility y navega hasta Watch -> Custom -> Releases, donde puedes elegir que se te notifique cuando se publique una nueva versión.
PHPCompatibility, que sólo comprueba la compatibilidad para una determinada versión (o rango de versiones) de PHP, es fácil de configurar. Obtendrás los mejores resultados si ejecutas una testVersion – por ejemplo, 8.0+ (8.0 y superiores) – dentro de PHPCompatibility.
Deberías estar atento a las funciones obsoletas o eliminadas, a los cambios en los valores por defecto de los parámetros de las funciones, al uso de concat sin paréntesis, al uso de match como nombre de función (ya que está reservado desde PHP 8.0), etc.
Psalm y PHPStan son buenos complementos y pueden ayudarte a realizar pruebas adicionales relacionadas con los tipos de variables. El inconveniente de estas herramientas es que requieren mucha configuración para obtener informes sobre PHP 8.0 y 8.1. Incluso si tienen éxito, puedes esperar muchos falsos positivos. Los falsos positivos son notificaciones que se dan erróneamente, causadas por las limitaciones del análisis estático.
Se requieren conocimientos sólidos para interpretar correctamente los resultados de estas dos herramientas, pero esos conocimientos pueden ayudarte a identificar incompatibilidades adicionales que PHPCompatibility no puede encontrar. Consulta la documentación de Psalm y PHPStan si quieres saber más sobre ellas.
Resumen:
- Realizar análisis estáticos con PHPCompatibility, Psalm, PHPStan
- Resuelve todos los problemas legítimos
Pruebas unitarias
El siguiente paso en el proceso son las pruebas unitarias. Las pruebas unitarias son un método para probar piezas de código individualmente. En las pruebas unitarias, se desarrollarán pruebas específicas para cada unidad. Para ello, se ejecutarán diferentes escenarios. Es preferible que cada escenario se pruebe por separado de los demás, para que las pruebas sean independientes entre sí.
Por supuesto, no basta con tener pruebas unitarias. También hay que ejecutarlas. Las pruebas unitarias se automatizan mejor utilizando herramientas de CI (integración continua) como Jenkins, Acciones de GitHub o Travis.
Compatibilidad con varias versiones de PHP
Como constructor de plugins, si quieres soportar múltiples versiones de PHP, asegúrate de que las pruebas en CI se ejecutan contra todas las versiones de PHP que soportas.
Por supuesto, también puedes admitir sólo las versiones más recientes, la elección depende totalmente de ti.
Probar con varias versiones de PHP requiere que utilices varias versiones de PHPUnit, dependiendo de la versión de PHP. Dado que PHPUnit ha introducido varios cambios a lo largo de los años que afectan a la forma de escribir las pruebas, esta parte puede ser complicada.
Para evitarlo, puedes utilizar los Polyfills de PHPUnit (escritos por Juliette y patrocinados por Yoast). Esto te permite escribir pruebas que oficialmente no son compatibles con PHPUnit 9 (y por tanto pueden ejecutarse en PHP 8.x). Los Polyfills hacen que tus pruebas funcionen en PHPUnit 4.x hasta 9.x y con PHP 5.4 hasta PHP 8.1 (a partir de ahora).[/notice]
Ahora que ya tienes las pruebas funcionando, el siguiente paso es asegurarte de que se solucionan los problemas encontrados en las pruebas.
Cobertura del código
Ejecutar estas pruebas es la forma más fiable de encontrar incompatibilidades entre versiones.
Al hacerlo, presta atención a la cobertura del código de tus pruebas:
- Supongamos que tienes una función A y has escrito una prueba para ella, y la función A llama a las funciones B, C y D como parte de la lógica de la función.
- La prueba de la función A está escrita para probar la lógica de la función A, pero también llamará a las funciones B, C y D durante la prueba. En el caso de las funciones B, C y D, lo normal es que sólo pruebes el «camino feliz» -la situación en la que todo va bien- y, por tanto, esas funciones tampoco están aún totalmente probadas, aunque (parte de) el código de esas funciones se ejecute durante la prueba de la función A.
- Para cada una de tus pruebas, indica qué código se está probando específicamente. Para ello, asigna a cada prueba una @covers. De este modo, B, C y D no se «cuentan» en el cálculo de la cobertura del código, lo que te permite ver qué parte de tu código está cubierta por las pruebas.
A menudo los desarrolladores escriben y prueban -a veces incluso sin saberlo- para el «camino feliz» En estos casos, también es necesario probar lo que ocurre cuando se pasan datos inesperados a una función. Probar sólo con los valores/tipos esperados no es suficiente.
A menudo se olvida la segunda parte de la cita anterior, cuando quizá sea incluso más importante que la primera. ¿Qué ocurre si pasas un tipo incorrecto? ¿Recibes un mensaje de error? ¿O la variable se pasa a la función y ésta continúa normalmente? ¿Y si se pasa un valor inesperado a la función?
Asegúrate de probar tus funciones con variables, tipos y valores inesperados. Sólo entonces podrás confiar en tus pruebas para encontrar los problemas que pueda causar una nueva versión de PHP.
PHP se está volviendo más estricto
PHP se está volviendo más preciso (estricto) en cómo maneja los «tipos» de las funciones propias de PHP, así como cosas como las propiedades dinámicas. En general, estos cambios pretenden ayudar a los desarrolladores a entregar código sin errores (bueno, código con menos errores). Pero esto puede suponer todo un obstáculo de actualización para el código preexistente escrito según los «viejos» principios de PHP.
Debido a este impulso de mensajes de error más útiles en PHP, puedes ver que hacer que el código existente se adapte a las nuevas versiones de PHP lleva cada vez más tiempo. Hacer que el código que funcionaba en PHP 5.6 sea adecuado para PHP 7.0 sólo lleva una fracción del tiempo en la mayoría de los casos, en comparación con actualizar el código para hacerlo adecuado para PHP 8.1. Y eso a pesar de que PHP 7.0 era una versión «mayor», mientras que PHP 8.1 es una «menor»
En muchos casos, las pruebas siguen siendo la única forma fiable de determinar lo que hay que modificar para que sea compatible con una nueva versión.
Las pruebas unitarias son posibles con varias herramientas, entre ellas:
Muchas de estas herramientas se basan en PHPUnit o se desarrollan conjuntamente con él.
En última instancia, no importa qué herramientas utilices. Lo más importante es que hagas pruebas y que éstas se ejecuten en las nuevas versiones de PHP. Este paso a veces puede ser muy complicado, pero afortunadamente, como se ha mencionado antes, existen herramientas para ello, como PHPUnit Polyfills.
Pruebas de integración
Las pruebas de integración son el siguiente paso que realizaremos, después del análisis estático y las pruebas unitarias. Una prueba de integración es aquella en la que se prueban situaciones de la vida real en un contexto más amplio que una simple «unidad de código» Esto incluye pruebas con una base de datos activa (de prueba) o pruebas con una API externa, por poner sólo dos ejemplos.
Así, cuando pruebas el código de un plugin o tema en el contexto de WordPress y utilizas una versión real, se trata, por definición, de pruebas de integración.
WP Test Utils (de nuevo escrito por Juliette y patrocinado por Yoast) es una herramienta excelente para las pruebas de integración. WP Test Utils proporciona herramientas para escribir pruebas de integración y unitarias, en las que WordPress se «simula» utilizando Brainmonkey y Mockery, donde se «simulan» las funciones de WordPress más utilizadas, de modo que estés probando tu propio código y no el código de WordPress.
Las pruebas de integración con WordPress son más complicadas porque implican la integración con WordPress y el conjunto de pruebas de WordPress. Dependiendo de las versiones de WordPress que admita un plugin o un tema, tienes que tener en cuenta qué versiones de PHPUnit admite el propio WordPress para ejecutar las pruebas en diferentes versiones de PHP.
Por ejemplo, WordPress 5.6 a 5.8 utiliza PHPUnit 5 a 7 para probar PHP 5.6 a PHP 8.0, pero a partir de WordPress 5.9, el propio WordPress también utiliza PHPUnit Polyfills para un soporte más amplio. WP Test Utils actúa como puente para superar todas estas diferencias.
¿Quieres saber más sobre cómo ejecutar pruebas de integración con varias versiones diferentes de WordPress, incluyendo WordPress 5.9 y superiores? Entonces lee sobre ello en el sitio web de WordPress.
Pruebas manuales
Ahora que ya has realizado las pruebas unitarias y de integración y has solucionado todos los problemas que encontraste, es el momento de realizar las pruebas manuales. Tu sitio está en funcionamiento y tu propio código funciona, pero también utilizas los plugins A, B y C. ¿Sabes si esos plugins son compatibles?
Por ejemplo, compruébalo con los autores del plugin y mira si indican que es compatible con PHP 8.x. La pregunta entonces, por supuesto, es cómo se ha probado el plugin. A menudo la respuesta es: de forma aislada. Por lo general, las funciones del plugin se han probado sólo con WordPress, sin otros plugins activos. E incluso si se utilizaron otros plugins en estas pruebas, lo más probable es que no todos los plugins que utilizas formaran parte de las pruebas, así que tómate esa afirmación de compatibilidad con un grano de sal.
Por ejemplo, un sitio WordPress con 3 plugins (A, B y C). Es posible que el plugin B, por ejemplo, devuelva un tipo de variable incorrecto a través de un filtro, con el que el plugin C, que utiliza el mismo filtro, quiere trabajar. Esto puede provocar un error fatal porque el tipo ya no es el esperado. Entonces, el plugin C se considera el culpable del mensaje de error, aunque el verdadero infractor sea el plugin B.
Las incompatibilidades de interoperabilidad de los plugins son imposibles de descubrir cuando se prueban de forma aislada. Cuantos más plugins activos haya, más probable es que algo vaya mal. Por ejemplo, sería muy beneficioso pasar peticiones de páginas de un sitio web activo a un entorno staging (con el registro de errores activado) para descubrir qué es lo que realmente va mal.
Con este tipo de problema, el propietario de un sitio normalmente sólo verá un mensaje de que se ha producido un error con el último código ejecutado (en este caso, del plugin C), aunque el plugin C no sea necesariamente la causa del problema.
En la mayoría de los casos, se requiere mucho trabajo humano manual y una buena cantidad de esfuerzo para detectar y solucionar estos problemas. Esto podría automatizarse mediante pruebas de extremo a extremo, pero no vemos que ocurra mucho en WordPress.
Disponibilidad de pruebas para los plugins utilizados
Para desarrolladores y equipos de desarrollo: Acepta el código sólo cuando las pruebas estén disponibles. De este modo, te aseguras de que se requieren menos pruebas manuales, lo que te ahorra mucho tiempo.
Cuestiona su estrategia de pruebas si quieres comprar un plugin o tema comercial. De esta forma, creamos conciencia colectiva entre los desarrolladores/equipos de desarrollo de la comunidad de WordPress para que las pruebas ocupen un lugar más destacado en la agenda, y todos nos beneficiamos.
A menudo se considera -injustamente- que las pruebas suponen un coste, cuando, en realidad, ahorran dinero. La inversión adicional necesaria para escribir pruebas se amortiza en forma de un número significativamente menor de informes de errores y menos tiempo dedicado a solucionarlos. Además, con las pruebas de software automatizadas, las ampliaciones y modificaciones pueden hacerse más rápidamente porque las pruebas pueden confirmar rápidamente que la funcionalidad existente sigue funcionando.
El Papel de los Hosts de WordPress y PHP 8.x
Para el propietario medio de un sitio web, la orientación de tu host es muy deseable. Considera lo siguiente:
- Documentación y actualizaciones para los clientes sobre el hecho de que WordPress Core, los plugins y/o los temas (en algunos casos) no son compatibles con las versiones cruzadas de PHP
- Opciones para realizar pruebas (como trabajar con un entorno de staging)
- Métodos para informar sobre errores y contactar con el servicio de asistencia
Esto también beneficia al proveedor de alojamiento web, ya que los propietarios de los sitios suelen ponerse en contacto con él para solicitar ayuda cuando surgen problemas. En el caso de un cambio a PHP 8.0, 8.1, u 8.2, el propietario del sitio es responsable de los posibles problemas, y cuanta más información tenga el propietario para preparar adecuadamente el cambio, mejor.
Poner PHP 8.1 o 8.2 a disposición de los clientes como alojamiento web es una cosa, pero al hacerlo, deben asegurarse de concienciar a los clientes para que sean conscientes de que pueden surgir problemas. Se recomienda probar el sitio en un entorno staging con una versión diferente a la del sitio en vivo. (La selección de versiones de PHP está disponible por defecto en Kinsta.)
Versión Mínima de PHP para WordPress
Más del 15% de todos los sitios web utilizan actualmente la versión 7.0 o inferior de PHP. Esto puede verse en las estadísticas oficiales de WordPress. Alrededor del 83% de todos los sitios WordPress utilizan actualmente la versión PHP 7.4 o inferior. Ten en cuenta que cualquier versión inferior o igual a la 8.0 ya no está soportada por PHP. Utilizar versiones de PHP al final de su vida útil puede ocasionar problemas porque ya no se publican actualizaciones de seguridad.
Para evitar problemas, es importante que los propietarios de sitios WordPress conozcan y estén informados sobre la versión mínima de PHP que permitirá que su sitio funcione con seguridad. Por su parte, los propietarios de sitios pueden modificar ellos mismos la versión de PHP (posible en Kinsta para todos los paquetes) o pedir a su alojamiento que actualice el sitio a una versión de PHP más reciente. En casos extremos, puedes cambiar a un host que soporte estas versiones más recientes.
Como WordPress sólo requiere una versión mínima de 7.4, no hay motivación suficiente para que muchos hosts y propietarios de sitios web actualicen sus sitios. Y ello a pesar de que PHP 7.4 llegó al final de su vida útil en noviembre de 2022.
Si alguna vez WordPress aumenta la versión mínima de PHP, esto puede significar que muchos sitios dejarán de ser compatibles con una actualización a la última versión de WordPress. Sin embargo, se seguirán publicando actualizaciones de seguridad para esas versiones obsoletas durante bastante tiempo.
Resumen
Para cambiar a PHP 8.0 o superior para tu sitio web, hay varios pasos que tú, o tu desarrollador, debéis realizar. Algunos pasos importantes son:
- Análisis estático
- Pruebas unitarias
- Pruebas de integración
- Pruebas manuales
Al cambiar a PHP 8.x, asegúrate de que todo se ha probado correctamente. Ésta es la única forma de garantizar que tu sitio funcionará correctamente, con rapidez y seguridad en una versión PHP más reciente.
Agradecemos inmensamente a Juliette su participación en este artículo y todo su trabajo en las herramientas mencionadas
Foto de Juliette, tomada por Jip Moors y utilizada con permiso.
Deja una respuesta