Como degradar WordPress? (Plugin, FTP, WP-CLI)

Hace clic en “Actualizar”, espera un momento, y de repente ve la “Pantalla Blanca de la Muerte” o un error crítico de PHP. Su sitio está caído, y el clientes está llamando.

No entre en panico. En WordPress, casi siempre puede revertir los cambios. En esta guía, le mostrare tres métodos para hacer un Downgrade, desde el más fácil hasta el más avanzado.

Antes de eso, un paso que casi todo el mundo se salta con las prisas: averiguar qué se rompió de verdad. Revertir a ciegas suele empeorar las cosas.

#Primero, identifica qué se rompió realmente

La tentación es revertir la última cosa que tocaste y rezar. En la práctica, cinco minutos de diagnóstico te ahorran una hora de reversiones a ciegas. El objetivo es aislar la causa: el núcleo, un plugin, el tema o un cambio de versión de PHP en el servidor.

Activa los registros de depuración. Edita wp-config.php (por FTP o por el gestor de archivos de tu hosting) y, justo encima de la línea /* That's all, stop editing! */, añade:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Con esto, WordPress escribe cada aviso y error fatal en wp-content/debug.log sin mostrarlos a los visitantes. Descarga ese archivo y busca la última línea Fatal error: normalmente incluye la ruta del archivo que provocó el fallo, y esa ruta te dice si el culpable está en wp-content/plugins/, en wp-content/themes/ o en el núcleo (wp-admin/ o wp-includes/).

Cruza el dato con los logs del servidor. El debug.log de WordPress no lo ve todo. En el panel de tu hosting (la mayoría de proveedores españoles lo exponen en un clic) busca el registro de errores de PHP o el error_log de Apache o nginx. Un error 500 sin rastro en debug.log casi siempre es memoria de PHP agotada o una incompatibilidad de versión de PHP, no un plugin.

Aísla al culpable desactivando plugins. Si aún entras al panel, desactiva todos los plugins y comprueba si el sitio revive. Reactívalos de uno en uno hasta que vuelva el fallo: el último que actives es el sospechoso. Si no entras al panel, renombra por FTP la carpeta wp-content/plugins a plugins-off; WordPress los desactivará todos de golpe. Para descartar el tema, activa temporalmente un tema por defecto como Twenty Twenty-Four.

Solo cuando sepas si fue el núcleo, un plugin, el tema o PHP tiene sentido elegir método de reversión. La tabla de más abajo cruza justamente esas dos variables: qué se rompió y qué acceso tienes.

#Método 1: Plugin WP Rollback (si el admin funciona)

Si aun tiene acceso al Dashboard (wp-admin), está salvado. La mejor herramienta para revertir plugins y temas es el plugin gratuito WP Rollback.

1. Instale y active WP Rollback.
2. Vaya a la lista de plugins (Plugins -> Instalados).
3. Un nuevo enlace “Rollback” aparecerá junto a cada plugin.
4. Haga clic y elija la versión a la que quiere volver (ej. de 5.4 a 5.3).
5. Confirme. Listo!

Nota: WP Rollback (versión gratuita) generalmente no revierte WordPress Core, solo plugins y temas. Para Core, necesita otro plugin: Core Rollback.

#Método 2: WP-CLI (para profesionales)

Si tiene acceso SSH (consulte nuestra guía de SSH), este es el método más rápido y seguro.

Para degradar WordPress Core:

wp core update --versión=6.4.3 --force

El parametro --force fuerza la instalación incluso si tiene una versión más nueva.

Para degradar un plugin (ej. WooCommerce):

wp plugin update woocommerce --versión=8.5.0 --force

Para degradar un tema:

wp theme update nombre-tema --versión=2.1.0 --force

#Verificación después de la degradación

Despues de ejecutar el comando, verifique que todo funciona:

## Verificar la versión instalada
wp core versión
wp plugin get woocommerce --field=versión

## Verificar integridad de archivos
wp core verify-checksums

## Verificar si hay errores en la base de datos
wp db check

#Método 3: Reemplazo manual de archivos (FTP)

Si no tiene acceso al panel ni a SSH, solo queda la “cirugia a corazón abierto” vía FTP.

Esto es riesgoso. Haga backup de su base de datos antes de empezar!

1. Vaya a WordPress.org Releases y descargue la versión antigua de WP (zip).
2. Descomprima en su computadora.
3. ELIMINE la carpeta wp-content y el archivo wp-config-sample.php de la carpeta descomprimida.
   • ¿Por qué? Para no sobrescribir accidentalmente sus fotos, temas y configuración!
4. Conecte vía FTP (FileZilla).
5. Suba los archivos restantes (wp-admin, wp-includes, archivos raíz) al servidor, eligiendo “Sobrescribir”.

Despues de subir, intente acceder a wp-admin. WordPress podría solicitar una “Actualización de Base de Datos” - acepte.

#Revertir desde el panel de tu hosting

Antes de operar a corazón abierto por FTP, mira si tu hosting ya tiene la solución hecha. Casi todo el alojamiento gestionado guarda puntos de restauración diarios y ofrece una restauración con un clic que devuelve archivos y base de datos al estado de ayer, sin que toques una sola línea.

En el mercado español lo tienes de serie: SiteGround incluye copias diarias y restauración selectiva en su panel; Webempresa y Raiola Networks generan backups automáticos que restauras desde el área de cliente o pidiendo al soporte que revierta a un punto concreto; los hostings con cPanel suelen traer JetBackup, donde eliges la fecha y restauras solo la base de datos, solo los archivos o ambos.

La ventaja frente al FTP manual es doble: recuperas también la base de datos (imprescindible cuando una actualización migró el esquema, como veremos ahora) y evitas sobrescribir archivos equivocados. La pega es la granularidad: un punto de restauración devuelve el sitio entero a esa fecha, así que perderás los pedidos o entradas creados después. Antes de restaurar, exporta la base de datos actual por si necesitas recuperar algo a mano.

Regla práctica: si el fallo llegó con una actualización de hace minutos y aún no ha entrado tráfico nuevo, la restauración del hosting es el camino más limpio. Si el sitio recibe pedidos cada pocos minutos, calcula qué pierdes antes de revertir el conjunto.

#Qué método usar según tu acceso y qué se rompió

No hay un método universal. La elección depende de dos cosas: a qué tienes acceso y qué componente falló. Esta tabla resuelve la mayoría de casos:

La última fila es la trampa: cuando la actualización tocó la base de datos, ningún método que solo mueva archivos sirve. Lo vemos en detalle a continuación.

#Cuando revertir los archivos no basta

Conozca más sobre los servicios de seguridad WordPress en WPPoland.

A veces degradar archivos no es suficiente, y este es el error que más sitios de tienda tumba. La razón es que muchos plugins no solo cambian su código al actualizar: ejecutan una migración de la base de datos. Añaden columnas, crean tablas propias o mueven datos de un formato a otro. Cuando eso ocurre, el código y el esquema quedan atados a la nueva versión.

El caso de manual es WooCommerce con HPOS (High-Performance Order Storage, el almacenamiento de pedidos en tablas propias wp_wc_orders en lugar de en wp_posts). Al actualizar, WooCommerce puede migrar todos los pedidos al nuevo esquema. Si después revierte los archivos a la versión anterior pero deja la base de datos ya migrada, el código antiguo busca los pedidos donde ya no están: la tienda muestra pedidos vacíos, errores fatales o un panel de administración inaccesible. Lo mismo pasa con plugins de membresía, LMS o reservas que mantienen sus propias tablas y las versionan.

Por eso revertir código contra un esquema ya migrado no es una reversión: es dejar el sitio a medio camino entre dos versiones incompatibles. La única solución limpia es restaurar una copia completa (archivos y base de datos juntos) del momento anterior a la actualización, de modo que código y esquema vuelvan a coincidir. Un backup solo de archivos no vale aquí.

#Como evitar problemas?

1. Staging: Nunca actualice “en vivo”. Clone el sitio en una copia de pruebas, aplique la actualización allí y compruebe el checkout, los formularios y las páginas clave antes de tocar producción.
2. WP_DEBUG en staging: Deje WP_DEBUG y WP_DEBUG_LOG activados en el entorno de pruebas para cazar avisos y errores fatales antes de que lleguen a los clientes.
3. Actualice en lotes pequeños: Un plugin cada vez, no veinte de golpe. Si algo falla, sabe exactamente qué fue sin tener que aislar entre decenas de cambios.
4. Lea los changelogs: Antes de actualizar, revise las notas de la versión. Un aviso de “database migration” o “breaking change” es la señal para hacer copia completa y probar en staging sin excepción.
5. Backups automáticos con restauración probada: Configure copias del hosting cada 24 horas, pero además pruebe una restauración de vez en cuando. Un backup que nunca ha restaurado no es un backup, es una suposición.

Recuerde: Las actualizaciones son importantes para la seguridad, pero la estabilidad es más importante para el negocio.

#Y si el culpable es la versión de PHP?

No todo rollback es de WordPress. A veces el sitio se rompe porque el hosting subió la versión de PHP (de 8.1 a 8.3, por ejemplo) y un plugin o tema antiguo no es compatible con la nueva. El síntoma típico es un error fatal que aparece sin que usted haya actualizado nada del propio WordPress.

En ese caso no hay que degradar WordPress, sino la versión de PHP. Casi todos los hostings españoles ofrecen un selector de PHP en el panel (cPanel lo llama “MultiPHP Manager”; Plesk, “Ajustes de PHP”). Baje a la versión con la que el sitio funcionaba, confirme que el error desaparece y aproveche para actualizar el plugin o tema incompatible a una versión que sí soporte el PHP nuevo.

Trate el downgrade de PHP como algo temporal: las versiones antiguas dejan de recibir parches de seguridad. Es un puente mientras actualiza el componente incompatible, no un estado en el que quedarse.

#Estrategia de actualización segura

Para evitar necesitar degradaciónes en el futuro, siga esta estrategia:

1. Antes de actualizar: Cree un backup completo y documente las versiones actuales de todos los plugins.
2. Entorno de staging: Clone su sitio de producción y aplique las actualizaciones alli primero.
3. Actualizaciones graduales: Actualice un plugin a la vez, no todos simultaneamente.
4. Monitoreo post-actualización: Verifique funcionalidad crítica después de cada actualización.
5. Plan de rollback: Tenga documentado el proceso de reversión antes de empezar.

#Automatizacion de pruebas pre-actualización

## Script de verificación pre-actualización
#!/bin/bash
echo "=== Verificacion pre-actualización ==="

## Backup de base de datos
wp db export backup-pre-update-$(date +%Y%m%d).sql
echo "Backup de BD creado"

## Listar versiones actuales
echo "=== Versiones actuales ==="
wp core versión
wp plugin list --fields=name,versión,update_versión
wp theme list --fields=name,versión,update_versión

## Verificar integridad
wp core verify-checksums
echo "=== Verificacion completa ==="

#Resumen

La prevención siempre es mejor que la curacion. Invierta en un flujo de trabajo de staging y backups automatizados para que las degradaciónes sean la excepcion, no la regla.

Conozca más sobre los servicios de mantenimiento WordPress y el desarrollo WordPress en WPPoland.