El código y el contenido necesitan límites de reversión distintos. Restaurar la base de ayer para deshacer los archivos de hoy puede borrar entradas, usuarios, ajustes y envíos recientes. La opción más segura sustituye solo el código implicado, salvo que su migración de datos también exija recuperación.
Congela cambios innecesarios y documenta la ventana del incidente antes de decidir.
Identifica qué cambió la actualización
Anota componente, versiones, hora, PHP, WordPress y cualquier mensaje de migración.
Clasifica:
solo archivos
archivos y opciones o esquema
recursos generados o caché
estado de integraciones externas
datos creados por usuarios desde la actualizaciónLee changelog, instrucciones de downgrade y registros. El número de versión no describe todo el estado.
Conserva los datos actuales
Haz una copia nueva de archivos y base del estado roto y mantén la anterior. Exporta por separado contenido crítico nuevo cuando sea práctico.
Inventaría entradas, usuarios, formularios o pedidos creados durante la incidencia. El plan debe decir cómo se conservarán.
No inicies otra actualización o limpieza mientras recoges pruebas.
Revierte los archivos de forma precisa
Para un plugin o tema, sustituye únicamente su directorio por el paquete anterior fiable tras probarlo. No mezcles archivos.
Para el núcleo, reinstala una versión soportada preservando wp-content, subidas y wp-config.php.
component -> component.failed
trusted-previous -> componentConserva propietario, limpia OPcache y usa solo fuentes oficiales.
Evalúa la compatibilidad de la base
Si la actualización modificó esquema u opciones, el código anterior quizá no entienda la nueva base. Consulta al fabricante si admite downgrade.
No disminuyas manualmente una versión guardada para forzar migraciones; puedes repetir operaciones destructivas.
Si hay que restaurar datos, planifica incorporar el contenido nuevo con exportaciones o APIs de la aplicación, no copiando filas directamente.
Protege tareas y acciones externas
Pausa cron, colas e integraciones que puedan ejecutar callbacks incompatibles. Comprueba si el componente nuevo ya envió correo, cambió datos remotos o creó tareas.
Restaurar WordPress no deshace los efectos externos. Concílialos mediante referencias estables.
Reanuda las colas solo cuando el código pueda interpretar sus argumentos.
Prueba en una copia similar a producción
Restaura la base actual en staging, aplica el rollback propuesto y prueba el fallo, guardados y cron.
Desactiva correo, indexación y APIs reales. Confirma que ninguna migración automática de downgrade borra datos.
Utiliza contenido reciente representativo para demostrar que sobrevive.
Planifica la unión si la base debe restaurarse
Define la hora de restauración e inventaría cada entrada, usuario, comentario, formulario y registro posterior. Usa la exportación o API de su aplicación para conservar relaciones y saneamiento.
No copies filas por ID sin revisar colisiones y metadatos. Ensaya y congela o encola escrituras durante la ventana final.
Conserva los medios nuevos
Los registros de adjuntos y los archivos deben permanecer emparejados. Inventaría IDs, rutas _wp_attached_file y originales.
Copia con checksums y conserva rutas; incorpora registros con herramientas de WordPress. No regeneres metadatos antes de que existan los originales. Protege las subidas privadas.
Aplica y verifica
Haz una última copia, aplica la reversión mínima, limpia cachés y prueba web, administración, editor, medios, tareas y funciones del componente.
Compara recuentos y fechas más recientes con el inventario. Busca errores de compatibilidad.
Vigila tráfico antes de cerrar.
Prepara la solución definitiva
Documenta la causa, el riesgo de la versión temporal y la reparación probada. Corrige código propio, actualiza dependencias o elige un PHP soportado en staging.
El mantenimiento recurrente debe separar paquetes de código y copias de base y ensayar la compatibilidad de downgrade. Un rollback profesional recupera el servicio sin considerar desechables los datos nuevos.