Una actualización puede introducir PHP incompatible, depender de otro componente más reciente, interrumpirse o activar una migración de base de datos. La hora señala al primer sospechoso, pero el error fatal y los archivos instalados demuestran qué se rompió.
Conserva versión y error antes de desactivar varios plugins. Revertir solo el responsable es más seguro que restaurar toda la web y perder contenido nuevo.
Registra la actualización y el síntoma
Anota plugin, versiones anterior y nueva, hora, operador y método, y si falla la parte pública, administración, cron o una sola función.
Busca el primer error fatal a esa hora:
Conserva:
mensaje y ruta de llamadas
versiones PHP y WordPress
paquete y versión del plugin
estado HTTP
última petición correctaOculta rutas, secretos y datos de clientes.
Crea un punto de reversión
Haz copia de los archivos y base actuales aunque la web esté rota. Así conservas migraciones posteriores y contenido creado desde la copia anterior.
Localiza un paquete anterior fiable y confirma origen o checksum. No descargues «versiones antiguas» de repositorios no oficiales.
Si faltó disco o inodos durante la extracción, recupera margen antes de otra operación.
Desactiva sin acceder al administrador
Renombra únicamente el directorio implicado dentro de wp-content/plugins mediante cPanel, Plesk, SFTP o SSH. WordPress lo tratará como no disponible.
example-plugin
example-plugin.disabledAnota la ruta y conserva los archivos. No renombres todo plugins salvo que no haya pruebas y dispongas de un orden de reactivación.
Los plugins obligatorios cargan desde otra ubicación.
Busca archivos incompletos
Compara recuento o checksums con el paquete oficial. Un fallo de red, permisos, disco o inodos puede mezclar archivos viejos y nuevos.
Reinstala el paquete completo y fiable en staging. No copies PHP suelto de otra instalación con edición o licencia distinta.
Limpia OPcache para evitar bytecode antiguo.
Evalúa migraciones de datos
Algunas versiones cambian tablas u opciones al cargar. Lee notas y registros. Revertir archivos tras una migración no reversible puede crear otra incompatibilidad.
Haz copia de la base antes de usar herramientas de reparación. No restaures toda la base para revertir código si existen entradas, usuarios o pedidos nuevos.
Pregunta al proveedor por la compatibilidad de downgrade si hay dudas.
Reproduce en staging
Crea una copia con el mismo PHP, WordPress, tema y plugins relevantes. Prueba versión anterior y nueva sobre la función afectada.
Revisa dependencias y orden de carga. Una función inexistente puede significar que un complemento necesario quedó antiguo, no que el plugin nuevo sea defectuoso.
Desactiva correo, indexación y acciones externas reales en staging.
Comprueba dependencias y edición
Los complementos premium suelen exigir una versión mínima del plugin base, y una licencia caducada puede impedir actualizar su pareja. Confirma que ambos pertenecen a la misma familia compatible.
Revisa si el tema incluye plantillas o APIs antiguas del plugin. Actualiza el conjunto en staging y prueba la integración exacta. No actives simultáneamente dos ediciones que declaren las mismas clases.
Elige reversión o solución hacia delante
Durante una caída, restaura los últimos archivos compatibles si la base lo permite. Documenta el riesgo de seguridad y una fecha límite para actualizar.
Como alternativa, actualiza la dependencia, corrige la integración propia o usa una versión PHP compatible según las pruebas.
No edites el plugin del proveedor como solución permanente; la próxima actualización lo sobrescribirá.
Verifica toda la aplicación
Prueba páginas, acceso, editor, cron y cada función que pertenezca al plugin. Revisa nuevos errores y confirma que las cachés se regeneran.
Vigila tras recuperar tráfico. El mantenimiento recurrente debe ensayar actualizaciones, conservar paquetes fiables y comprobar funciones concretas; que cargue la portada no demuestra que haya sobrevivido la función comercial del plugin.