Desde que me dedico al mantenimiento de páginas webs he ido teniendo distintos periodos con trabajos muy parecidos. Cuando salió la última versión de la legislación de cookies y RGPD me pasé meses adaptando sitios webs a la nueva normativa. Pues bien, ahora estoy con un aluvión de pequeños proyectos consistentes en actualizar páginas webs WordPress mas o menos obsoletas que estaban funcionando sobre PHP 7.4 a versiones actuales compatibles con PHP 8.X
La situación suele ser la siguiente. Una pequeña empresa solicita el desarrollo de su web a una agencia. No se presupuesta mantenimiento, o la agencia que montó la web desaparece. Años después, se quieren hacer cambios en la página y se descubre que la web lleva tres o cuatro años sin actualizar.
O desde el hosting se avisa de que el soporte para PHP 7.4 está a punto de finalizar, y al activar PHP 8.0 todo falla. Sin que el dueño de la web sepa muy bien que está pasando ni como actualizar su web.
Actualizar WordPress no es demasiado complicado y hasta se puede automatizar. Pero actualizar una web que lleva años sin actualizar y que también requiera una actualización de PHP puede ser algo problemático.
¿Cómo actualizar WordPress a PHP 8?
Preparando una versión de testeo (staging)
Al hacer una actualización de este tipo, con un cambio de la versión de PHP, podemos dejar la web fuera de servicio. Así que mejor probar bien. Para ello, lo primero es sacar un duplicado de la web.
Hay varias opciones, pero en esta situación la mejor suele ser usar el plugin WP Staging. Este plugin crea un duplicado de la web en el mismo servidor. Esta puede no ser la solución optima para sacar una copia de desarrollo o de seguridad, pero para este caso nos viene muy bien porque nos aseguramos que trabajaremos sobre la misma configuración.
WP Staging es sencillo de usar. Una vez instalado nos saldrá una pantalla invitándonos a pagar la versión PRO, le decimos que no y pulsamos en «Create Staging Site». Ponemos un nombre (ejemplo: devel) y le damos a empezar clonación. Y ya estaría. Si necesitas saber más o tienes problemas, te remito a la documentación
Una vez creado nuestro sitio de pruebas podemos acceder a ella a través de la dirección que se nos indicará.
Creando un subdominio
El siguiente paso será generar un subdominio para nuestra web de Staging. ¿Para qué? Pues porque la mayoría de hostings nos permiten cambiar la versión de PHP a nivel de subdominio. Así tendremos la oportunidad de probar primero el cambio en el subdominio.
Ejemplo. Imaginemos que mi web angelaparicio.dev estuviera funcionando en PHP 7.4. La idea es generar un subdominio test.angelaparicio.dev apuntando a la copia de Staging y configurar ahí PHP 8.0 (o superior). Y si todo funciona, pues hacer el cambio en angelaparicio.dev
¿Cómo se genera un subdominio? Pues tendremos que irnos al panel de control del hosting que tengamos contratado y buscar la opción. Esto es distinto en cada hosting. Pero en general tenemos que hacer dos cosas:
Primero, añadir el subdominio e indicar que la web está en la dirección donde tenemos creada la web de staging. Quedaría algo así:
Aún nos queda una cosa más. Tenemos que ir a la web de staging y cambiar la dirección de la web. Esto lo hacemos modificando el archivo wp-config.php y añadimos dos constantes con la nueva dirección
define( 'WP_SITEURL', 'https://test.angelaparicio.dev/' );
define( 'WP_HOME', 'https://test.angelaparicio.dev/' );Con esto ya tendríamos nuestra web de pruebas lista para actualizar WordPress a PHP 8.
Por cierto, ¿por qué he elegido test como nombre de subdominio? Pues porque en el caso de que estemos usando Elementor Pro para maquetar nuestra web, el usar este subdominio nos permitirá mantener la licencia. Esto es importante si usamos plugins con licencias, pues solo los podremos actualizar si estamos en el mismo dominio. (Más info: Elementor Expands License To Include Staging Sites)
Pasos previos
Antes de seguir, vamos a activar el registro de errores para saber que está ocurriendo en caso de tener algún problema. Para esto, en el archivo wp-config.php buscamos la constante WP_DEBUG, que estará a false, y la cambiamos como sigue:
define( 'WP_DEBUG', true );
if ( WP_DEBUG ) {
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );
}Con esto le decimos a WordPress que registre los errores en un fichero, que por defecto está en wp-content/debug.log. Aquí podremos leer que errores ocurren al actualizar, si ocurre alguno.
Otro paso previo es cambiar el correo de avisos de errores críticos. WordPress tiene una característica por la cual envía un correo avisando cuando ha ocurrido un error grave en la web. Este correo se envía al administrador principal de la web, y puede ser que no nos interese que ocurra eso. Por ejemplo, si estamos trabajando en la web de un cliente. Si queremos cambiar el correo, tenemos que usar la siguiente constante:
define( 'RECOVERY_MODE_EMAIL', 'direccionquequeramos@correo.com');Y para acabar, me gusta instalar el plugin Version Info, que nos muestra en el backend que versión de PHP estamos usando. Esto también lo podemos ver en: Herramientas => Salud del Sitio => Información => Servidor. Pero me resulta más cómodo con este plugin. La información aparece en cualquier sección del panel de control, abajo a la derecha.
Procediendo a actualizar WordPress a PHP 8
Pues con todo listo, ya podemos actualizar. Si todo va bien no debería haber mucho problema. Si falla algo, estamos preparados para saber que ha ocurrido sin que el fallo afecte a la versión principal.
Lo primero sería actualizar plugins, plantillas y el núcleo de WordPress. Una vez hecho esto, pasamos a activar la nueva versión de PHP, pasando de la antigua (suele ser la 7.4) a una versión nueva. Lo mejor es activar la 8.0 y si todo va bien ya pasaremos a 8.1 o, incluso, a 8.2.
¿Ha ido todo bien? Genial. Pues podemos proceder a hacer el mismo proceso en producción y ya está, todo resuelto y sin dolor. Por seguridad, es recomendable eliminar la versión de staging y desactivar el registro de errores.
Por cierto, ¿por qué en este orden? Primero el WordPress y después la versión de PHP. Pues por dos motivos. Primero, por retrocompatibilidad. Si un código funciona en 8.0 es bastante probable que funcione también en 7.4 (los desarrolladores suelen tardar un tiempo en adaptar las nuevas características). Al revés es donde suele haber más problema, código obsoleto que funciona «por los pelos» en 7.4, pero que en 8.0 ya falla por completo.
Segundo, porque si al actualizar a 8.0 dejamos la web sin funcionar, pues ya no tendremos la opción de actualizar los plugins y el core de WP. Bueno, siempre podemos hacerlo a mano, pero es algo menos cómodo.
Aunque en esencia, tampoco importa mucho. De una forma u otro, tendremos que actualizarlo todo. Sigamos el orden que sigamos, el resultado buscado es el mismo.
¿Y si hay problemas?
Ahora vamos a los posibles problemas. Imaginemos que actualizamos a 8.0 y nos da un «Error crítico» dejando a la web sin funcionar. Lo primero, tranquilidad. Estamos en la versión de pruebas, volvamos a 7.4. Y ahora tocará mirar el log de errores o el correo de aviso crítico que nos haya podido pasar.
Lo que suele ocurrir es que haya algún plugin que no sea compatible con 8.0. En el log deberíamos ver que plugin es el que ha provocado el fallo, pues vendrá indicado por el aviso «Fatal error». En el correo que nos debería haber llegado también se nos debería indicar quien es el culpable.
Por ejemplo, si vemos algo parecido a esto:
PHP Fatal error: Array and string offset access syntax with curly braces is no longer supported in /var/users/angel/public_html/wp-content/plugins/plugin_obsoleto/incs/functions.php on line 181El error lo estará dando el «plugin_obsoleto»
Plugins obsoletos
¿Por que ha ocurrido esto? Pues por un plugin que no es compatible con la nueva versión de PHP. ¿Pero como puede ser, si hemos actualizado todo? Pues porque para ese plugin no habría actualización.
Esto puede pasar por dos motivos: El plugin dejó de actualizarse porque su desarrollador paró el mantenimiento. O es un plugin de pago cuya licencia no hemos renovado.
En el primer caso lo mejor suele ser borrar el plugin y ver si podemos reemplazarlo por otro. Por ejemplo, cuando surgieron las Accelerated Mobile Pages salieron muchos plugin para usarlas. Hasta que salió uno oficial de los propios creadores de WordPress, con lo que la mayoría de los no oficiales fueron abandonados. Si este fuera nuestro caso, toca eliminar el plugin y sustituirlo por uno moderno que tenga una funcionalidad equivalente.
Para comprobar si un plugin está obsoleto, podemos ver su página en el repositorio de WordPress. Por ejemplo, este caso es el de uno que dejó de actualizarse hace 8 años y que seguramente hoy daría problemas si quisiéramos mantenerlo en una instalación actualizada: https://wordpress.org/plugins/qtranslate/
En el caso de plugins de pago, la solución es obvia. Renovar la licencia y actualizar. Aunque quizás podríamos querer aprovechar para comprobar si seguimos necesitando ese plugin, o si lo podemos sustituir por otro. Por ejemplo, ¿puede ser que estemos pagando la licencia de Elementor PRO sin usar ninguno de sus bloques exclusivos? O tal vez estemos usando un plugin de pago para hacer carruseles de imágenes, cuando lo mismo podría valernos uno gratuito más sencillo.
Plantillas obsoletas
El otro problema que podemos encontrarnos es el de tener una plantilla obsoleta. Esto puede estar causado por tener una plantilla de pago con licencia caducada y sin actualizar o con una plantilla creada desde cero cuyo desarrollador ya no nos hace mantenimiento. Las plantillas gratuitas del repositorio suelen tener versiones actualizadas o equivalentes. Por ejemplo la clásica plantilla «Kubrick» ya no está disponible, pero tenemos Kubrick2: https://wordpress.org/themes/kubrick2/
Las plantillas no suelen provocar tantos problemas como los plugins porque en general no deberían tener tanto código PHP. Aunque algunas si que pueden dar problemas, sobre todo plantillas de pago con muchas funcionalidades.
El problema es que mientras que sustituir un plugin por una versión actual que ofrezca una funcionalidad similar suele ser sencillo (aunque no siempre), cambiar de plantilla suele implicar cambiar el aspecto visual completo, por lo que pasamos de un pequeño arreglo a un rediseño
Pero la solución es similar a la que tenemos que aplicar con los plugins. Renovar la licencia y actualizar, o sustituir la plantilla por otra.
Actualizando código
Otra opción es actualizar nosotros mismos el código PHP obsoleto. Claro que para esto necesitaremos conocimiento técnico. A veces los cambios a hacer son pocos y sencillos, por lo que puede ser la mejor opción. Sobre todo cuando el problema viene de la plantilla, y no queremos rediseñar la web.
Un ejemplo. Me he encontrado mucho con el error «Fatal error: curly braces is no longer supported», que es a raíz de un cambio en el acceso a arrays y que se soluciona cambiando un {} por []. Si tenemos una plantilla antigua que solo da este error (me ha pasado), pues la solución es rápida.
Conclusiones
Actualizar la versión de PHP de 7.4 a 8.X puede ser problemático, aunque si tenemos la posibilidad de actualizar plugins y plantillas a versiones recientes no suele dar problemas. En caso de tener plantillas o plugins obsoletos o sin licencia la situación se complica algo más, pero también deberíamos poder hacer la migración.
A medio y largo plazo es algo que tendremos que hacer, pues tener una web funcionando sobre una versión obsoleta de PHP nunca es buena idea, ni por rendimiento, ni por seguridad.
Si necesitas ayuda para actualizar tu web, puedes contratar mis servicios de mantenimiento WordPress