WordPress roto después de actualizar: volver a la versión anterior

¿Qué se ha actualizado?

En un sitio WordPress se actualizan cuatro elementos, y cada uno se revierte de forma distinta: el núcleo de WordPress, los plugins, el tema y la versión de PHP del servidor, que el proveedor de hosting cambia por su cuenta. Para saber cuál ha cambiado:

• Los correos de WordPress: tras una actualización automática, WordPress escribe a la dirección de correo electrónico de administración del sitio, con un asunto como «[Nombre del sitio] Algunos plugins se han actualizado automáticamente», y la lista de lo que ha cambiado.
• La pantalla de plugins: la columna «Actualizaciones automáticas» muestra los que se actualizan solos, y cada fila indica la versión instalada.
• Herramientas > Salud del sitio > Información: la sección «Servidor» da la versión de PHP, y las secciones de plugins y de temas, la versión de cada componente.
• Las fechas de las carpetas: una carpeta de plugin reescrita por una actualización lleva la fecha de esa actualización.

wp plugin list
ls -lt wp-content/plugins | head

El primer comando lista los plugins con su versión y su estado; el segundo, las carpetas de plugins de la modificada más recientemente a la más antigua. Cruce los datos con la hora a la que cambió el sitio.

Vaciar las cachés antes de sacar conclusiones

Tras una actualización, los archivos CSS y JavaScript cambian de contenido, y una caché puede seguir sirviendo los antiguos. El resultado parece una avería: diseño descolocado, menús que ya no se abren. Vacíe, en este orden, la caché del plugin de caché o de optimización, la caché del proveedor de hosting si ofrece una y, después, la del navegador, y vuelva a cargar la página. Si el sitio vuelve a verse bien, la actualización no era la causa.

El sitio se queda bloqueado en mantenimiento

Durante una actualización, WordPress crea un archivo .maintenance en la raíz del sitio y muestra el mensaje «No disponible temporalmente por mantenimiento programado. Vuelve a comprobarlo en unos minutos». Cuando la actualización se interrumpe, el archivo no se borra. WordPress lo ignora diez minutos después de la hora que contiene; para no esperar, o si el mensaje persiste, elimínelo por SFTP o con el administrador de archivos del proveedor. Como su nombre empieza por un punto, active la visualización de archivos ocultos para verlo.

Vuelva después a Escritorio > Actualizaciones: el elemento cuya actualización se interrumpió debe relanzarse, o reinstalarse en su versión anterior.

Volver a la versión anterior de un plugin

Reinstalar la versión anterior sustituye los archivos del plugin y conserva sus ajustes, que están en la base de datos.

wp plugin install nombre-plugin --version=2.4.1 --force

• Plugin del directorio de WordPress.org: en su página pública, la pestaña «Vista avanzada» lleva a la lista «Versiones anteriores». Descargue el archivo que necesite y, desde la pantalla «Añadir plugins», haga clic en «Subir plugin»: WordPress reconoce el plugin ya instalado y propone «Reemplazar el actual con el subido».
• Plugin comprado a un desarrollador: las versiones anteriores suelen descargarse desde su cuenta de cliente en la web del desarrollador.
• Después: haga clic en «Desactivar las actualizaciones automáticas» junto a ese plugin, hasta que el desarrollador publique una corrección.

WordPress ya sabe volver atrás en dos casos. Desde la versión 6.3, cuando la actualización de un plugin o de un tema falla a mitad del proceso, se restaura la versión anterior. Desde la versión 6.6, cuando la actualización automática de un plugin activo provoca un error fatal, WordPress reinstala la versión anterior. Una actualización que termina bien y rompe una función sin error fatal se revierte a mano.

El tema: la versión anterior, y las modificaciones perdidas

wp theme install nombre-del-tema --version=3.1.0 --force

Una actualización de tema sustituye todos sus archivos. Las modificaciones hechas directamente en los archivos del tema, por ejemplo en functions.php o en una hoja de estilos, desaparecen por tanto con cada actualización. La copia de seguridad hecha antes de la actualización permite recuperarlas; para conservarlas de forma duradera, se colocan en un tema hijo, que las actualizaciones del tema padre dejan intacto.

El núcleo de WordPress

WP-CLI reinstala una versión concreta del núcleo:

wp core update --version=7.0 --force

Una actualización mayor del núcleo también puede cambiar la estructura de la base de datos, que este comando deja como está. Lo más seguro suele ser mantener el núcleo actualizado y volver a la versión anterior del plugin o del tema incompatible. Si es imprescindible volver a la versión anterior del núcleo, se hace desde una copia de seguridad completa hecha antes de la actualización.

La versión de PHP, cambiada por el proveedor de hosting

Los proveedores de hosting actualizan la versión de PHP a medida que las antiguas dejan de recibir correcciones de seguridad. Un plugin o un tema antiguo puede entonces detenerse con un error fatal. El panel del proveedor suele permitir elegir la versión de PHP del sitio:

1. Anote la versión instalada y vuelva a la anterior.
2. Compruebe que el sitio vuelve a funcionar.
3. Actualice o sustituya el componente responsable, identificado con el registro de depuración.
4. Vuelva a la versión reciente.

Esta vuelta atrás es un paso de reparación temporal: una versión de PHP sin correcciones de seguridad expone el sitio. Según el calendario oficial publicado en php.net, PHP 8.1 ya no recibe correcciones de seguridad desde el 31 de diciembre de 2025, PHP 8.2 las recibe hasta el 31 de diciembre de 2026 y PHP 8.3, hasta el 31 de diciembre de 2027. WordPress recomienda PHP 8.3 o superior.

Restaurar una copia de seguridad completa, como último recurso

Una restauración devuelve los archivos y la base de datos al estado de la copia de seguridad. Todo lo que el sitio ha recibido desde entonces desaparece: pedidos, mensajes de formulario, comentarios, registros de usuarios, entradas publicadas.

1. Exporte primero lo que ha llegado desde la copia de seguridad: pedidos, envíos de formularios, cuentas nuevas.
2. Restaure archivos y base de datos del mismo momento, desde la herramienta del proveedor o desde su plugin de copias de seguridad. Unos archivos de un día y una base de datos de otro día producen errores difíciles de interpretar.
3. Vuelva a importar los datos exportados.
4. Aplique de nuevo las actualizaciones una a una, comprobando el sitio entre una y otra: la última aplicada antes de la avería es la que la provoca.

Para la próxima actualización

• Una copia de prueba: muchos proveedores de hosting ofrecen un entorno de preproducción (staging) que copia el sitio con un clic. Las actualizaciones se aplican allí primero.
• Una copia de seguridad justo antes, archivos y base de datos juntos.
• Una actualización cada vez, comprobando las páginas clave entre una y otra: inicio, formulario de contacto, carrito.
• El registro de cambios del plugin o del tema, leído antes de una actualización mayor.