Cambiar a PHP 8.x en cuatro pasos: una entrevista con Juliette Reinders Folmer

Publicado: 2023-03-04

Actualizar un sitio, complemento o tema de WordPress a una nueva versión de PHP es una tarea que se repite regularmente. Pero, ¿cómo hacer esto de la manera más eficiente posible? ¿Cómo sabes que no pasarás nada por alto? ¿Hay una hoja de ruta para ello?

En este artículo, abordaremos estas preguntas (y más) y veremos lo que implica una transición fluida a PHP 8.x para su sitio, complemento o tema de WordPress, incluida una hoja de ruta.

Haremos esto basándonos en una entrevista que realizamos con 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.

¿Estás listo para hacer el cambio sin problemas también? ¿Tienes curiosidad por conocer nuestro plan paso a paso? Entonces, ¡vamos a sumergirnos!

PHP 8.x — ¿Qué ha cambiado?

Para obtener una descripción general de los cambios, recomendamos los siguientes artículos:

  • Notas de la versión para 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

Después de leer estos artículos, estará completamente actualizado sobre lo que ha cambiado en PHP 8.x y lo que debe hacer para que sus proyectos PHP funcionen sin problemas.

Si no está seguro de cuál es la mejor manera de empezar, no hay problema. En la conversación con Juliette, discutimos esto en detalle, y le explicaremos en este artículo de la manera más completa posible cómo puede cambiar a PHP 8.x.

También explicaremos en recuadros informativos cómo realizar varias operaciones en MyKinsta, nuestro panel de control patentado para todos sus sitios, aplicaciones y bases de datos de WordPress.

Cambiar a PHP 8.x: Cómo empezar

Cambiar a PHP 8.x suena simple y, técnicamente, lo es. Muchos hosts te permiten especificar qué versión de PHP quieres usar para tu sitio web en el panel de administración. En Kinsta, se puede cambiar la versión de PHP con un solo clic en el panel de control de MyKinsta.

Pero antes de hacerlo, hay algunas cosas de las que debe estar seguro. Dependiendo de su nivel de conocimiento y experiencia, le recomendamos lo siguiente:

  • Si ha creado su propio sitio de WordPress con temas y complementos estándar, sin tener mucho conocimiento de PHP, contrate a un desarrollador o agencia para investigar si su sitio es adecuado para ejecutarse en PHP 8.x. ¿Estás buscando un tercero que pueda ayudarte con esto? Luego mire nuestra página de Socios que enumera varias compañías confiables que pueden ayudarlo.
  • Si su sitio de WordPress fue creado por una parte externa, un desarrollador o una agencia, comuníquese con ellos para preguntar si su sitio puede ejecutarse en PHP 8.x.
  • Si ha creado su sitio de WordPress, con su propio tema personalizado, por ejemplo, o complementos desarrollados por usted mismo, tenemos una hoja de ruta para usted a continuación.


Si su sitio pertenece a una de las dos primeras categorías, sin duda lo invitamos a leer el resto del artículo, pero no le recomendamos que comience a probar la compatibilidad con PHP 8 de su sitio usted mismo. Déjalo en manos de profesionales.

Independientemente de lo que elija, le recomendamos que no solo cambie su sitio en vivo a PHP 8 y ​​"vea si funciona". ¿Tiene curiosidad acerca de cómo se verá su sitio y no puede esperar a verlo funcionando en PHP 8? Luego comience a probar dentro de un entorno de prueba. Un buen anfitrión le permitirá configurar fácilmente un entorno de ensayo.

MyKinsta - Crea un nuevo entorno
MyKinsta – Crea un nuevo entorno

En el entorno de prueba, puede activar PHP 8.x y ver si esta actualización funciona bien con su sitio. También es posible trabajar con una copia local de su sitio. Con nuestra herramienta de desarrollo gratuita DevKinsta, puede importar fácilmente su sitio desde el panel de MyKinsta, después de lo cual puede cambiar la versión de PHP a 8.0 u 8.1.

Si no ve ningún problema en el entorno de prueba, no significa necesariamente que en realidad no haya ningún problema. La siguiente hoja de ruta le dirá por qué.

Prueba de compatibilidad de PHP 8.x: la hoja de ruta

Pruebas: la palabra clave para un buen software. Incluso para los sitios web de WordPress y sus componentes, como temas, complementos y el núcleo de WordPress, las pruebas son los medios para garantizar que no sucedan cosas que no desea que sucedan.

Un proyecto de desarrollo de software consiste principalmente en pruebas. En este artículo, analizamos específicamente las pruebas que pueden ayudarlo a realizar la transición a PHP 8.x sin problemas. En nuestro artículo sobre herramientas DevOps, encontrará una sección con una colección de herramientas que puede usar.

En esta publicación de blog se analizan los siguientes tipos de pruebas:

Veamos más de cerca los diferentes tipos de pruebas que podemos realizar.

Análisis estático (o prueba estática)

El primer paso que puede tomar como desarrollador de PHP es realizar un análisis estático de su código con varias herramientas. El análisis estático es el proceso de analizar software sin ejecutar el código. Con el análisis estático, es posible detectar errores, detectar problemas con la compatibilidad de PHP 8.x, hacer cumplir los estándares de codificación (por ejemplo, los estándares de codificación de WordPress) e incluso es posible modificar y limpiar el código.

Herramientas para análisis estático

Puede realizar un análisis estático con varias herramientas, como:

  • PHPCompatibilidad
  • Salmo
  • PHPStan

En el momento de escribir este artículo, no todas las comprobaciones de PHP 8.1 son compatibles con la última versión de PHPCompatibility. Las verificaciones de PHP 8.1 pueden estar en la versión de desarrollo, así que asegúrese de usarlas (por ahora) cuando use PHPCompatibility para analizar su proyecto y ver qué errores/recomendaciones hay.

Las comprobaciones de PHP 8.1 pronto se lanzarán en una nueva versión principal . Si desea mantenerse actualizado sobre esto y tiene una cuenta de GitHub, abra el repositorio de GitHub de PHPCompatibility y navegue hasta Watch -> Custom -> Releases , donde puede optar por recibir una notificación cuando se publique una nueva versión.

PHPCompatibility, que solo prueba la compatibilidad para una versión particular (o rango de versiones) de PHP, es fácil de configurar. Obtiene los mejores resultados si ejecuta una versión de prueba, por ejemplo, 8.0+ (8.0 y superior), dentro de PHPCompatibility.

Debería estar atento a las funciones obsoletas o eliminadas, los valores predeterminados modificados de los parámetros de la función, si usar concat sin paréntesis, si usar match como nombre de función (ya que se ha reservado desde PHP 8.0), etc.

Captura de pantalla de la página PHPCompatibility GitHub
Captura de pantalla de la página PHPCompatibility GitHub

Psalm y PHPStan son buenas adiciones y pueden ayudarlo realizando verificaciones adicionales relacionadas con los tipos de variables. La desventaja de estas herramientas es que se necesita mucha configuración para obtener informes sobre PHP 8.0 y 8.1. Incluso si tienen éxito, puede esperar muchos falsos positivos. Los falsos positivos son notificaciones que se dan de forma incorrecta, provocadas por las limitaciones del análisis estático.

Se requiere un conocimiento sólido para interpretar correctamente los resultados de estas dos herramientas, pero ese conocimiento puede ayudarlo a identificar incompatibilidades adicionales que PHPCompatibility no puede encontrar. Consulte la documentación de Psalm y PHPStan si desea obtener más información sobre ellos.

Resumen:

  • Realice análisis estáticos con PHPCompatibility, Psalm, PHPStan
  • Resolver todos los problemas legítimos
MyKinsta - visualización de archivos de registro
MyKinsta: visualización de archivos de registro

Examen de la unidad

El siguiente paso en el proceso es la prueba unitaria. La prueba unitaria es un método para probar piezas de código individualmente. En las pruebas unitarias, se desarrollarán pruebas dirigidas específicas para cada unidad. Esto implicará correr a través de diferentes escenarios. Preferiblemente, cada escenario se prueba por separado de los demás para que las pruebas sean independientes entre sí.

Tener pruebas unitarias por sí solas, por supuesto, no es suficiente. También necesitan ser ejecutados. Las pruebas unitarias se automatizan mejor con herramientas de CI (integración continua) como Jenkins, GitHub Actions o Travis.

Un ejemplo de GitHub Actions
Un ejemplo de GitHub Actions

Compatibilidad con múltiples versiones de PHP

Como creador de complementos, si desea admitir varias versiones de PHP, asegúrese de que las pruebas en CI se ejecuten en todas las versiones de PHP que admita.

Por supuesto, también puede admitir solo versiones más nuevas, la elección depende totalmente de usted.

La prueba con varias versiones de PHP requiere que use varias versiones de PHPUnit, según la versión de PHP. Dado que PHPUnit ha introducido varios cambios a lo largo de los años que afectan la forma en que se escriben las pruebas, esta parte puede ser complicada.

Para evitar esto, puede usar PHPUnit Polyfills (escrito por Juliette y patrocinado por Yoast). Esto le permite escribir pruebas que oficialmente no son compatibles con PHPUnit 9 (y, por lo tanto, pueden ejecutarse en PHP 8.x). Luego, Polyfills hace que sus pruebas funcionen en PHPUnit 4.x a 9.x y con PHP 5.4 a PHP 8.1 (a partir de ahora).[/notice]

Ahora que tiene las pruebas en ejecución, el siguiente paso es asegurarse de que los problemas encontrados en las pruebas estén solucionados.

Cobertura de código

Ejecutar estas pruebas es la forma más confiable de encontrar incompatibilidades entre versiones.

Al hacerlo, preste atención a la cobertura de código de sus pruebas:

  • Suponga que tiene una función A y ha 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 para 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. Para las funciones B, C y D, generalmente solo prueba el "camino feliz", la situación en la que todo va bien, y por lo tanto, esas funciones aún no se prueban por completo, aunque (parte de) el código en esas funciones es ejecutado durante la prueba de la función A.
  • Para cada una de sus pruebas, indique qué código se está probando específicamente. Para ello, asigna a cada prueba un @covers De esta manera, B, C y D no se "cuentan" en el cálculo de cobertura de código, lo que le permite ver qué parte de su código está cubierta por las pruebas.

A menudo, los desarrolladores escriben y prueban, a veces incluso sin saberlo, el "camino feliz". En estos casos, también es necesario probar qué sucede cuando se pasan datos inesperados a una función. Probar solo con valores/tipos esperados no es suficiente .

"En las pruebas, debe asegurarse de que una función haga lo que debe hacer, pero también que una función no haga lo que no debe". - Juliette Reinders Folmer Haga clic para twittear

A menudo se olvida la segunda parte de la cita anterior, cuando tal vez sea incluso más importante que la primera parte. ¿Qué sucede si pasa un tipo incorrecto? ¿Recibes un mensaje de error? ¿O la variable lanzada con la función continúa normalmente? ¿Qué sucede si se pasa un valor inesperado a la función?

Asegúrese de probar sus funciones con variables, tipos y valores inesperados. Solo entonces puede confiar en sus pruebas para encontrar 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 la forma en que maneja los "tipos" para las funciones propias de PHP, así como cosas como las propiedades dinámicas. Estos cambios generalmente están destinados a ayudar a los desarrolladores a entregar código sin errores (bueno, código con menos errores). Pero esto puede representar un gran obstáculo para la actualización del código preexistente escrito en base a los principios "antiguos" de PHP.

Debido a esta búsqueda de mensajes de error más útiles en PHP, puede ver que adaptar el código existente a las nuevas versiones de PHP lleva cada vez más tiempo. En la mayoría de los casos, hacer que el código que funcionaba en PHP 5.6 fuera adecuado para PHP 7.0 solo tomó una fracción del tiempo en comparación con actualizar el código para hacerlo adecuado para PHP 8.1. Y eso a pesar del hecho de que PHP 7.0 fue una versión "principal", mientras que PHP 8.1 es una "menor".

En muchos casos, las pruebas siguen siendo la única forma confiable de determinar qué se debe modificar para admitir una nueva versión.

La prueba unitaria es posible con varias herramientas, que incluyen:

  • Unidad PHP
  • Mofa
  • behat,
  • jugador de historia

Muchas de estas herramientas se basan en, o en conjunto con, PHPUnit.

En última instancia, no importa qué herramientas uses. Lo más importante es que pruebe y haga que las pruebas se ejecuten en nuevas versiones de PHP. Este paso a veces puede ser muy complicado, pero afortunadamente, como se mencionó anteriormente, existen herramientas para esto, 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 donde se prueban situaciones de la vida real en un contexto más amplio que solo una "unidad de código". Estos incluyen pruebas con una base de datos activa (de prueba) o pruebas con una API externa, por dar solo dos ejemplos.

Entonces, cuando pruebas el código de un complemento o tema en el contexto de WordPress y usas una versión real, estas son, por definición, pruebas de integración.

WP Test Utils (nuevamente escrito por Juliette y patrocinado por Yoast) es una excelente herramienta para las pruebas de integración. WP Test Utils proporciona herramientas para escribir pruebas unitarias y de integración, en las que WordPress se "simula" usando Brainmonkey y Mockery, donde las funciones de WordPress comúnmente utilizadas se "falsan" para que esté probando su propio código y no el código de WordPress.

Utilidades de prueba de WP en GitHub
Utilidades de prueba de WP en GitHub

La prueba de integración con WordPress es una historia más complicada porque implica la integración con WordPress y el conjunto de pruebas de WordPress. Dependiendo de las versiones de WordPress que admita un complemento o tema, debe considerar qué versiones de PHPUnit son compatibles con WordPress para ejecutar las pruebas en diferentes versiones de PHP.

Por ejemplo, WordPress 5.6 a 5.8 usa PHPUnit 5 a 7 para probar PHP 5.6 a PHP 8.0, pero a partir de WordPress 5.9, WordPress mismo también usa PHPUnit Polyfills para un soporte más amplio. WP Test Utils actúa como un puente para superar todas estas diferencias.

¿Desea obtener más información sobre cómo ejecutar pruebas de integración en varias versiones diferentes de WordPress, incluido WordPress 5.9 y superior? Luego lea sobre esto en el sitio web de WordPress.

Prueba manual

Ahora que pasó por las pruebas unitarias y las pruebas de integración y solucionó todos los problemas que encontró, es hora de realizar las pruebas manuales. Su sitio se está ejecutando y su propio código funciona, pero también está utilizando los complementos A, B y C. ¿Sabe si esos complementos son compatibles?

Por ejemplo, verifique esto con los autores del complemento y vea si indican que es compatible con PHP 8.x. La pregunta entonces, por supuesto, es cómo se probó el complemento. A menudo, la respuesta aquí es: de forma aislada. Las funciones del complemento generalmente se han probado junto con WordPress solo, sin otros complementos activos. E incluso si se usaron otros complementos en estas pruebas, es probable que no todos los complementos utilizados por usted formaran parte de la prueba, así que tome tal declaración de compatibilidad con un grano de sal.

Por ejemplo, un sitio de WordPress con 3 complementos (A, B y C). Es posible que el complemento B, por ejemplo, devuelva un tipo de variable incorrecto a través de un filtro, con el que el complemento C quiere trabajar usando el mismo filtro. Esto puede causar un error fatal porque el tipo ya no es el esperado. El complemento C se ve entonces como el culpable del mensaje de error, aunque el complemento B es el verdadero infractor.

Las incompatibilidades de interoperabilidad de complementos son imposibles de descubrir cuando se realizan pruebas de forma aislada. Cuantos más complementos activos, más probable es que algo salga mal. Por ejemplo, sería muy beneficioso pasar las solicitudes de página de un sitio web en vivo a un entorno de prueba (con el registro de errores habilitado) para descubrir qué es lo que realmente está fallando.

Con este tipo de problema, el propietario de un sitio generalmente solo verá un mensaje de que hubo un error con el último código ejecutado (en este caso, del complemento C), aunque el complemento C no es necesariamente la causa del problema.

En la mayoría de los casos, se requiere mucho trabajo manual y humano, y se requiere 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 esto suceda mucho en WordPress.

Disponibilidad de prueba para complementos utilizados

Para desarrolladores y equipos de desarrollo: acepte código solo cuando haya pruebas disponibles. De esta manera, se asegura de que se requieran menos pruebas manuales, lo que le ahorra mucho tiempo.

Cuestione su estrategia de prueba si desea comprar un complemento o tema comercial. De esa manera, colectivamente creamos conciencia entre los desarrolladores/equipos de desarrollo en la comunidad de WordPress para que las pruebas ocupen un lugar más alto en la agenda, y todos nos beneficiamos.

Las pruebas a menudo se ven, injustamente, como un costo cuando, en realidad, ahorran dinero. La inversión adicional requerida para escribir las pruebas vale la pena en forma de una cantidad significativamente menor de informes de errores y menos tiempo dedicado a corregir errores. Además, con las pruebas de software automatizadas, las extensiones y modificaciones se pueden hacer más rápido porque las pruebas pueden confirmar rápidamente que la funcionalidad existente sigue funcionando.

''Sé amable con tu futuro yo, por favor ;-)'' - Juliette Reinders Folmer Haz clic para twittear

El papel de los hosts de WordPress y PHP 8.x

Para el propietario promedio de un sitio, la orientación de su anfitrión es muy deseable. Considera lo siguiente:

  • Documentación y actualizaciones para los clientes de que WordPress Core, complementos y/o temas (en algunos casos) no son compatibles con versiones cruzadas de PHP
  • Opciones de prueba (como trabajar con un entorno de pruebas)
  • Métodos para informar de errores y ponerse en contacto con el soporte

Esto también beneficia a un proveedor de alojamiento web, ya que los propietarios de los sitios a menudo se ponen en contacto con el servidor para pedir ayuda cuando surgen problemas. En el caso de un cambio a PHP 8.0 u 8.1, el propietario del sitio es responsable de los posibles problemas, y cuanta más información tenga el propietario para prepararse adecuadamente para el cambio, mejor.

Hacer que PHP 8.0 u 8.1 esté disponible para los clientes como alojamiento web es una cosa, pero al hacerlo, deben asegurarse de crear conciencia entre los clientes para que sepan que pueden surgir problemas. Se recomienda probar su sitio en un entorno de prueba con una versión diferente a la actual. (La selección de versiones de PHP está disponible de forma predeterminada en Kinsta).

Versión mínima de PHP para WordPress

Más del 15 % de todos los sitios web utilizan actualmente PHP versión 7.0 o inferior. Esto se puede ver en las estadísticas oficiales de WordPress. Alrededor del 83% de todos los sitios de WordPress actualmente usan PHP versión 7.4 o inferior. Tenga en cuenta que PHP ya no admite nada inferior o igual a la versión 7.4. El uso de versiones de PHP al final de su ciclo de vida puede generar problemas porque ya no se publican actualizaciones de seguridad.

Para evitar problemas, es importante que los propietarios de sitios de WordPress conozcan e informen sobre la versión mínima de PHP que permitirá que su sitio funcione de manera segura. Por su parte, los propietarios del sitio pueden modificar la versión de PHP ellos mismos (posible en Kinsta para todos los paquetes) o pedirle a su anfitrión que actualice el sitio a una versión de PHP más nueva. En casos extremos, puede cambiar a un host que admita estas versiones más nuevas.

Debido a que WordPress solo requiere una versión mínima de 7.4, no hay suficiente motivación para que muchos hosts y propietarios de sitios web actualicen sus sitios. Y esto a pesar de que PHP 7.4 llegó al final de su vida útil en noviembre de 2022.

Si WordPress alguna vez aumenta la versión mínima de PHP, esto puede significar que muchos sitios ya no serán 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 su sitio web, hay varios pasos que usted o su desarrollador deben realizar. Los pasos importantes incluyen:

  • Análisis estático
  • Examen de la unidad
  • Pruebas de integración
  • Prueba manual

Al cambiar a PHP 8.x, asegúrese de que todo se haya probado correctamente. Esta es la única forma de garantizar que su sitio se ejecutará correctamente, de forma rápida y segura en una versión de PHP más reciente.

¡Agradecemos inmensamente a Juliette por participar en este artículo y por todo su trabajo en las herramientas mencionadas!

Foto de Juliette, tomada por Jip Moors y utilizada con autorización.